agent-capability-inventory

Data-sensitivity inventory for AI agent tool surfaces. Point it at your fleet of MCP servers; get back a catalog of every tool, each one classified by risk level, data sensitivity, and capability class. Feeds governance, DLP, and approval-flow decisions for agentic deployments.

Inventory + classification + policy is the DNA of every data-governance platform on the planet. This applies the same playbook to AI agents, where the "data" flows through tool calls instead of rows in a database.

Why

Large agentic deployments fan out across dozens of MCP servers. Each server has tools that read, write, call out, or act destructively. Today nobody's cataloging which tools touch which data at what sensitivity — the same category of problem that BigID, Varonis, and Immuta solved for traditional databases a decade ago.

Before you can govern or enforce policy on agent tool calls, you need an inventory. This tool produces it.

What it does

For every tool in every MCP server you scan, agent-capability-inventory assigns:

Data sensitivity tags (reads-* / writes-*):

• pii · phi · financial · credentials · source_code · messaging · infra_config · logs_observability

Capability classes:

• shell_exec · network_out · file_read · file_write · destructive · mutating · read_only

Risk score rolled up from the above: critical · high · medium · low · minimal.

Install

npm install -g @dj_abstract/agent-capability-inventory
# or one-shot:
npx @dj_abstract/agent-capability-inventory scan <path>

Usage

# Scan a directory of MCP manifests
agent-capability-inventory scan ~/path/to/manifests/

# Scan individual manifest or mcp-audit report JSONs
agent-capability-inventory scan brain-tools.json supabase.json

# Pipe from mcp-audit directly — works because mcp-audit >= 0.3.1 embeds
# the tool snapshot inside audit reports
mcp-audit scan --stdio "node server.js" --json /tmp/s.json
agent-capability-inventory scan /tmp/s.json --stdout

Outputs three artifacts (override paths with --json, --csv, --md):

| File | Purpose | |---|---| | inventory.json | Full machine-readable inventory — feed to downstream policy engines | | inventory.csv | Flat per-tool table — paste into BigID / governance worksheets | | inventory.md | Human-readable roll-up — for PR reviews, approval flows, exec readouts |

Example output

## Fleet summary

- **Servers:** 45
- **Tools:** 253

### Risk distribution

| Risk     | Tools |
|----------|------:|
| critical |     0 |
| high     |     1 |
| medium   |     7 |
| low      |    26 |
| minimal  |   219 |

### Capabilities (server coverage)

| Capability   | # servers |
|--------------|----------:|
| read_only    |        36 |
| mutating     |        16 |
| destructive  |        11 |
| file_read    |         2 |
| file_write   |         2 |
| shell_exec   |         1 |

### Data sensitivities (server coverage)

| Sensitivity           | # servers |
|-----------------------|----------:|
| reads-infra_config    |         6 |
| writes-infra_config   |         4 |
| reads-messaging       |         4 |
| reads-pii             |         2 |
| reads-financial       |         2 |
| reads-credentials     |         2 |

Classification approach

Name-based, deliberately narrow. Each tag is assigned only when the tool name contains an unambiguous verb+noun combination (e.g. get_customer_records → reads-pii, execute_sql → shell_exec-adjacent). Descriptions are a weaker signal and get skipped unless they add unambiguous corroboration.

Why narrow: this inventory is intended to feed policy decisions. A policy like "tools tagged reads-credentials may not share a session with tools tagged network_out" is only actionable if the tagging has high precision. False-tagging a filesystem tool as reads-credentials because its description mentions "file system" would break trust in the whole inventory.

Analytics tools that return aggregates about sensitive data (get_leaked_credentials_data returning breach statistics) are not flagged as direct readers; the rule looks for analytics tokens (data, trend, stats, count, summary) as negation signals.

Roadmap

• 0.2.0 — policy engine. Declare policies in YAML (policies/*.yaml), run them against the inventory, emit a violations report. Planned rule types:
  • cross-tool data flow ("reads-pii" → "writes-external")
  • lethal-trifecta by tag combinations (credentials + network-out on same server)
  • destructive-without-approval (destructive tools not gated behind a confirmation schema)
• 0.3.0 — runtime enforcement hook. Emit a policy bundle consumable by agent-firewall so call-time middleware can enforce the inventory policies live.
• Classification pipeline plugins — custom sensitivity taxonomies (HIPAA, PCI-DSS, GDPR-specific).
• Baseline + drift integration — compare an inventory snapshot to a prior run; surface new tools that appeared across the fleet.

Related tools

• @dj_abstract/mcp-audit — static security audit per MCP server (design-time)
• prompt-eval — runtime prompt-injection eval harness (test-time)
• @dj_abstract/agent-firewall — call-time defensive middleware (runtime)
• mcp-audit-sweep — reproducible audit of public MCP servers (methodology + report)

Together they form a detect → inventory → test → defend pipeline for agentic applications.

License

MIT — see LICENSE.