Agent Tool Inventory Audit Prompt

This prompt is designed for AI operations, governance, and platform engineering teams who need to conduct a periodic, comprehensive audit of all tools registered across an agent ecosystem. The primary job-to-be-done is producing a structured inventory report that includes last-used timestamps, call frequency, ownership metadata, and security boundary classifications. Use this prompt when you need to identify stale registrations, detect unauthorized or orphaned tools, prepare for a security review, or generate evidence for a compliance audit. The ideal user is someone who already has a complete tool registry in place and needs to systematically analyze it, not someone who is still discovering or registering tools.

This prompt assumes a complete and accurate tool registry already exists as input. You must provide the full registry data, including tool names, descriptions, registration timestamps, ownership records, and any available usage logs. The prompt works best when you also supply [CONSTRAINTS] that define what counts as stale (e.g., tools unused for 90 days), what security boundaries matter (e.g., tools with write access to production databases), and what ownership metadata is required. Without these constraints, the model will apply reasonable defaults, but you should review and adjust them for your organization's specific policies. The output is a structured report, not a live system action, so you retain full control over what happens next.

Do not use this prompt when you need to discover new tools, register tools dynamically, or validate tool schemas against live servers. Those tasks require different playbooks, such as the MCP Server Capability Discovery Prompt or the Tool Manifest Validation Prompt. This prompt is also not suitable for real-time tool selection during agent execution; it is a batch audit tool for periodic governance reviews. If your registry is incomplete, outdated, or untrusted, run a discovery or validation prompt first, then feed the cleaned registry into this audit prompt. Always review the output before taking action on production tool registrations, especially when decommissioning or reclassifying tools that may still be in use.

This prompt template is designed to be copied directly into your agent orchestration layer, LLM gateway, or audit automation pipeline. It instructs the model to act as an auditor, consuming a provided tool registry payload and producing a structured inventory report. The prompt uses square-bracket placeholders for all dynamic inputs—such as the registry data, output schema, and risk classification rules—so you can parameterize it safely in code before each execution. The template is self-contained: it includes the role, task, constraints, and output format instructions needed to produce a consistent report without relying on external system prompts.

textCopy
You are an AI tool auditor. Your task is to produce a comprehensive inventory report from the provided agent tool registry. Follow these instructions exactly.

## INPUT
[TOOL_REGISTRY_JSON]

## TASK
Audit every tool in the registry and produce a structured inventory report. For each tool, you must extract or compute the following fields:
- tool_name: The unique identifier for the tool.
- tool_description: A one-sentence summary of what the tool does.
- owner_team: The team or service responsible for the tool, inferred from metadata or naming conventions.
- security_boundary: Classify as READ_ONLY, READ_WRITE, WRITE_ONLY, or EXECUTE based on the tool's described actions.
- last_used_timestamp: The most recent invocation timestamp, or "never" if no usage data exists.
- call_frequency_7d: The number of calls in the last 7 days, or 0 if no data.
- capability_status: ACTIVE if the tool is registered and callable, DEPRECATED if marked as deprecated, STALE if last used > 30 days ago, UNKNOWN if status cannot be determined.
- schema_valid: true if the tool has a complete input/output schema, false otherwise.
- notes: Any anomalies, missing metadata, or recommendations.

## OUTPUT_SCHEMA
Return a single JSON object with the following structure:
{
  "audit_timestamp": "ISO 8601 timestamp of audit execution",
  "registry_source": "Identifier for the registry being audited",
  "total_tools": <integer>,
  "summary": {
    "active_count": <integer>,
    "deprecated_count": <integer>,
    "stale_count": <integer>,
    "unknown_count": <integer>,
    "read_only_count": <integer>,
    "read_write_count": <integer>,
    "write_only_count": <integer>,
    "execute_count": <integer>,
    "schema_incomplete_count": <integer>
  },
  "tools": [
    {
      "tool_name": "string",
      "tool_description": "string",
      "owner_team": "string",
      "security_boundary": "READ_ONLY | READ_WRITE | WRITE_ONLY | EXECUTE",
      "last_used_timestamp": "string | null",
      "call_frequency_7d": <integer>,
      "capability_status": "ACTIVE | DEPRECATED | STALE | UNKNOWN",
      "schema_valid": <boolean>,
      "notes": "string"
    }
  ]
}

## CONSTRAINTS
- Do not invent tools. Only report tools present in [TOOL_REGISTRY_JSON].
- If a field cannot be determined, use null for strings and 0 for integers, and note the gap in "notes".
- Classify security boundaries conservatively: if a tool can modify data, it is at least READ_WRITE.
- Flag any tool that lacks an owner_team or has an empty schema as needing human review in "notes".
- If [TOOL_REGISTRY_JSON] is empty or invalid, return a JSON object with "error": "Invalid or empty registry" and stop.

## RISK_LEVEL
[RISK_LEVEL]

## EXAMPLES
[EXAMPLES]

To adapt this template, replace [TOOL_REGISTRY_JSON] with the serialized registry payload from your agent framework, MCP server, or tool database. Set [RISK_LEVEL] to HIGH, MEDIUM, or LOW to adjust the audit's scrutiny—HIGH adds stricter ownership and schema checks, while LOW permits more inference. Optionally, provide [EXAMPLES] as one or two few-shot input/output pairs to calibrate the model's classification behavior for your specific tool naming conventions and security taxonomy. After substitution, validate that the resulting prompt does not exceed your model's context window, especially for large registries with hundreds of tools.

Before deploying this prompt into a production audit pipeline, implement a validation layer that parses the JSON output against the declared schema. Reject malformed responses and retry with a repair prompt. For high-risk environments, route audit reports with STALE, DEPRECATED, or schema_incomplete tools to a human reviewer before the report is considered final. Do not use this prompt to make automated de-registration or permission changes—its output is an observability artifact, not a control-plane action.

The audit prompt is designed to run as a scheduled batch job, not a real-time agent call. Wire it into a cron-like scheduler (Airflow, Prefect, a simple Lambda with EventBridge) that executes weekly or monthly depending on your governance cadence. The prompt expects a complete tool registry snapshot as input, so your harness must first query your registry store—whether that's an MCP gateway, a database table, or a configuration repository—and serialize the current state into the [TOOL_REGISTRY_SNAPSHOT] placeholder. Do not pass live server responses directly; the audit needs a point-in-time snapshot to produce a repeatable, versioned report.

Validation and retry logic is critical because the output is a structured audit artifact, not conversational text. After the model responds, validate the JSON against a strict schema that checks for required fields (tool_id, last_used_timestamp, call_frequency, owner, security_boundary), correct enum values for boundary classifications (read_only_internal, read_only_external, write_internal, write_external, admin), and timestamp format compliance (ISO 8601). If validation fails, retry once with the validation errors appended to the [CONSTRAINTS] block. If the second attempt fails, log the raw output and route to a human review queue—do not silently accept a malformed audit report. For high-security environments, flag any tool with an admin or write_external boundary classification for mandatory human approval before the report is finalized.

Logging and observability should capture the registry snapshot version, the model and temperature used, the validation pass/fail status, and the final report hash. Store the output as a versioned artifact in your governance system (S3 with object versioning, a compliance database, or a GRC platform). Include a generated_at timestamp and a registry_snapshot_id in the report metadata so auditors can trace every report back to its source data. For teams using multiple model providers, test this prompt on your primary model first; if you switch providers, re-validate schema compliance and boundary classification consistency, as different models interpret security boundary language with varying strictness. The next step after generating the report is to diff it against the previous audit to detect drift—wire the output into a separate comparison step rather than asking the model to perform the diff, which reduces hallucination risk in the change analysis.