Skip to content

Tool discovery

Tool discovery

Tool discovery turns the audit log into a feedback loop for catalog completeness.

When an agent calls a tool or MCP server that isn't yet catalogued, the call still flows through the Pipeline and lands in the Audit trail — discovery surfaces it for the operator to review, classify, and add to the Tool catalog.

Without discovery, the operator has to imagine every tool the agent might call. With discovery, the audit trail tells them.

At a glance


Reads	the Audit trail — specifically tool / MCP call events
Surfaces	calls whose tool/server isn't in the Tool catalog
Action	review → approve / deny / classify; once approved, the call type joins the catalog
Where it runs	offline aggregation job + UI surface
Status	next

The loop

agent makes a call ──▶ Pipeline runs ──▶ Audit row written
                                              │
                                              ▼
                                       discovery aggregator
                                       (groups by signature)
                                              │
                                              ▼
                                       Operator review queue
                                              │
                              ┌───────────────┼────────────────┐
                              ▼               ▼                ▼
                          approve          deny            classify
                       (add to catalog)   (block in       (assign tags,
                                          policy)          compliance scope)

A "call signature" groups identical tool/server invocations across many sessions: mcp_server: github.com, tool: search_repos, schema_hash: abc123. The operator reviews each unique signature once, not every call.

What gets surfaced

Surface	Example
Unknown tool	`agent X called tool Y, not in catalog`
Unknown MCP server	`agent X connected to mcp://internal-jira/, not registered`
Drifted schema	`tool` slack.send`arguments now include`attachments[] `field, schema differs from catalog version`
New compliance scope	`tool touches PII fields not previously seen`

Why this concept exists

Catalog completeness can't be authored upfront. Customers' agents will reach for tools the platform team didn't anticipate — internal MCP servers, vendor APIs adopted mid-quarter, new SaaS subscriptions. Without discovery, every gap forces a manual audit-log query.

Discovery also catches drift: when a previously-catalogued tool's schema changes, discovery flags the divergence so the catalog stays accurate.

Surfaces

Persona	Surface	What they do
Operator	Admin UI → Catalog → Discovery queue	Review unknown signatures, approve/deny/classify
Operator	`tappass discovery list`	CLI equivalent of the queue
Auto-policy author	(future) Discovery → suggested rules	Discovery output drives suggested policy/check additions

reads ← Audit trail — the source of truth for what was called
feeds → Tool catalog — approved signatures land here
may trigger → policy authoring loop (deny / scope)
part of ↑ Catalog operator-help

Status

Per memory: a 7-PR plan exists for splitting catalog membership from per-call govern, with a discover → review → approve loop. This concept card describes that loop's user-facing model.