Skip to content
TapPass

Explore the capability database

Before you can govern an agent, you need to know what’s on the menu: which capabilities exist, which intents they express, and which concrete tools (on which MCP servers) actually fulfil them. tappass capability list prints that whole map as a tree.

This is the vocabulary behind everything else — the capabilities a prompt maps to, and the ones your rules constrain.

The whole catalog

Section titled “The whole catalog”
Terminal window
tappass capability list
capability map (catalog)
├── code_integration  3 servers · 14 tools
│   ├── github
│   │   ├── create_pull_request  → code.write
│   │   ├── merge_pull_request   → code.write
│   │   └── get_file_contents    → code.read
│   └── gitlab
│       └── create_merge_request → code.write
├── messaging  2 servers · 6 tools
│   ├── slack
│   │   ├── send_message         → message.send
│   │   └── list_channels        → message.read
│   └── gmail
│       ├── send                 → message.send
│       └── list_messages        → message.read
└── payments  1 server · 4 tools
    └── stripe
        ├── create_charge        → payment.write
        └── list_charges         → payment.read

Read it top-down: a capability (code_integration) unfolds into the servers that provide it (github, gitlab), which unfold into the tools (create_pull_request), each tagged with its intent (→ code.write). The spine is capability → intent → tool → server — intent is the tag that tells you what kind of action a tool performs, regardless of which server exposes it.

That tagging is what makes policy portable: a ConstrainCapabilityArgs rule on the messaging capability applies to slack.send_message and gmail.send at once, because both carry the message.send intent.

Narrow the view

Section titled “Narrow the view”
Terminal window
tappass capability list --connected            # only MCPs you've actually connected
tappass capability list -c code_integration    # drill into one capability
tappass capability list -o json                # the raw tree, for scripts and diffs
  • --connected shows your ledger — the servers and tools live in your org right now — instead of the full catalog of what could be connected.
  • -c / --capability NAME filters to a single capability’s subtree.
  • -o json emits { "scope": …, "capabilities": [ … ] } — handy for asserting in CI that a newly connected server didn’t add tools you never reviewed.

How this feeds policy

Section titled “How this feeds policy”

Once you can see the tree, the other flows click into place:

  • Author from a sentence. policy create --from-prompt picks capabilities off this exact tree to build the envelope — capability list is how you sanity-check what it chose.
  • Constrain across tools. DenyCapability and ConstrainCapabilityArgs target a capability, so one rule covers every tool that carries the matching intent.
  • Review new tools. When a server is connected, its tools appear here; the tool integrity flow gates anything unrecognized.

Next steps

Section titled “Next steps”