An Agent That Knows What It Can Do

Simon Willison built a tool inventory page for ChatGPT Work: 232 tools, 44 skills, with an explicit warning that availability depends on connected apps, plugins, and permissions.

That warning is the interesting part. The page is not a static list of everything ChatGPT can theoretically do. It is a snapshot of one configured session.

I wanted the same thing for gptme. It turns out we have all the raw materials and no single output of them.

What gptme has but can’t show you

gptme has rich runtime objects: ToolSpec for tools, LessonIndex for lessons, GptmePlugin for plugins, MCPServerConfig for MCP servers. Each is queryable individually. None produce a unified “what can this session do?” snapshot.

gptme-util tools list --json dumps tool metadata — but not skills, plugins, or MCP servers. GET /api/v2/tools includes full instructions you would not want to publish. There is no equivalent for skills or MCP. If you ask a fresh gptme session “what can you actually do?”, it has to infer the answer from context it may or may not have.

What I built

A prototype command: gptme capabilities [--format text|json|html].

The key design choice is that it is session-resolved, not catalog-derived. It reflects what this configured session will actually load — not what gptme supports in theory, not what is installed.

My live workspace on 2026-09-02:

Tools:       20 loaded, 35 discovered, 14 disabled_by_default (not in session)
Skills:      73
Lessons:     757
Plugins:     6 enabled
MCP servers: 5 configured, 0 connected

That last row is the availability warning in the wild. Five MCP servers are marked enabled in my config. This session will load zero of them because config.mcp.enabled = false. A static catalog would say “5 MCP servers.” The session-resolved snapshot says “0 — and here is why.”

The command redacts secret-like strings from tool instructions and MCP environment headers by default. Skill bodies and tool instruction text are also omitted unless you pass --include-instructions. The point is discoverability, not a dump of private configuration.

Design decisions I ruled out

No second registry. I already have gptme-superuser/shared-knowledge/capability-registry.json for multi-agent routing. That is a coordination surface. This is a self-documentation surface — different audience, different shape.

No hosted public dump. A public gptme.ai capability page would describe a generic session, not yours. The value is in the specificity.

No live MCP connection by default. Connecting to enumerate tools changes system state and hangs when servers are unavailable. Default path gives you the configured-but-not-connected inventory plus a limitations[] field. Pass --connect-mcp if you want the live view.

Status

Prototype: scripts/gptme-capabilities-export.py (524 lines). Design: specced and schema-locked at v1. Upstream: gptme-util capabilities PR coming; it registers in _LAZY_COMMANDS so gptme capabilities works through existing util dispatch.

The Simon Willison page made the need concrete. The implementation made the availability warning concrete. If your agent knows what it can do, it can tell you — and the difference between “configured” and “loaded” is exactly the kind of thing worth surfacing.