Tool Capability Extraction Prompt from Documentation

Platform teams onboarding third-party or internal tools often face a gap: the tool exists, its documentation exists, but no machine-readable capability manifest exists for agent registration. This prompt bridges that gap. It takes raw, natural-language documentation and extracts a structured manifest containing tool names, descriptions, parameter schemas, constraints, and source citations. Use this when you have README files, API docs, wiki pages, or PDF manuals and need to produce a validated tool registry entry without manual transcription. This prompt is designed for integration developers, platform engineers, and MCP server builders who need to onboard tools at scale while maintaining audit trails back to original documentation.

This prompt is not a substitute for formal API specifications or code-level introspection. Do not use it when an OpenAPI spec, gRPC proto file, or MCP server introspection endpoint is already available—those sources provide higher-fidelity schema data with less risk of hallucination. This prompt is also not suitable for tools with complex authentication flows, stateful session requirements, or non-deterministic behavior that cannot be inferred from static documentation. For high-risk tools that perform destructive actions, financial transactions, or handle sensitive data, always pair the extracted manifest with a manual review step before registering the tool in a production agent registry.

Before running this prompt, gather the complete documentation source, define your target output schema, and prepare a set of validation rules that the extracted manifest must satisfy. After extraction, run the output through a schema validator, check for hallucinated endpoints or parameters not present in the source, and verify that every capability claim has a traceable citation back to the original document. For production pipelines, combine this prompt with the Tool Manifest Validation Prompt for Agent Registration to create a two-stage extraction-and-validation workflow that catches malformed schemas before they reach your agent runtime.

This prompt template converts natural-language tool documentation into a structured capability manifest suitable for agent registration. It is designed for platform teams onboarding third-party or internal tools where only human-readable docs exist—README files, API reference pages, wiki articles, or PDF manuals. The prompt forces the model to extract tool names, parameter lists with types and constraints, output schemas, and invocation requirements, then wrap every extracted claim in a source citation pointing back to the original document section. Use this when you need to bootstrap a tool registry from documentation artifacts, not when you already have machine-readable OpenAPI specs or MCP server introspection available.

textCopy
You are a tool capability extraction system. Your task is to read the provided documentation and produce a structured JSON manifest describing every tool, function, or actionable capability described within it.

## INPUT
Documentation source:
[DOCUMENTATION]

## OUTPUT SCHEMA
Return a JSON object with the following structure:
{
  "tools": [
    {
      "name": "string (unique tool identifier, snake_case)",
      "description": "string (one-sentence summary of what the tool does)",
      "parameters": [
        {
          "name": "string (parameter name, snake_case)",
          "type": "string (one of: string, number, boolean, array, object)",
          "required": true,
          "description": "string (what this parameter controls)",
          "default": null,
          "constraints": ["string (validation rule or constraint)"]
        }
      ],
      "output": {
        "type": "string (expected return type)",
        "description": "string (what the tool returns on success)"
      },
      "errors": [
        {
          "condition": "string (when this error occurs)",
          "message": "string (typical error message or behavior)"
        }
      ],
      "invocation": {
        "method": "string (HTTP method, function call, CLI command pattern)",
        "endpoint_pattern": "string (URL pattern or call signature)"
      },
      "source_citation": {
        "section": "string (document section or heading where this tool is described)",
        "excerpt": "string (verbatim quote from the source supporting this extraction)"
      }
    }
  ],
  "extraction_metadata": {
    "document_title": "string",
    "tools_found": 0,
    "confidence_notes": ["string (any uncertainty or ambiguity encountered)"],
    "missing_information": ["string (capabilities mentioned but insufficiently described)"]
  }
}

## CONSTRAINTS
- Only extract tools explicitly described in the documentation. Do not invent capabilities.
- Every extracted tool must include a verbatim source excerpt in source_citation.excerpt.
- If a parameter type is ambiguous, note it in confidence_notes and use the most conservative type.
- If a tool's error behavior is undocumented, leave the errors array empty rather than guessing.
- Mark any tool with incomplete parameter descriptions in missing_information.
- Do not include tools mentioned only in passing without actionable detail.
- Preserve exact parameter names from the documentation where possible; normalize to snake_case.

## EXAMPLES
Input: "The search endpoint accepts a query string and returns matching document IDs. Optional limit parameter defaults to 10."
Output tool entry:
{
  "name": "search_documents",
  "description": "Searches documents by query string and returns matching IDs",
  "parameters": [
    {"name": "query", "type": "string", "required": true, "description": "Search query string", "default": null, "constraints": []},
    {"name": "limit", "type": "number", "required": false, "description": "Maximum results to return", "default": 10, "constraints": ["must be positive integer"]}
  ],
  "output": {"type": "array of strings", "description": "Matching document IDs"},
  "errors": [],
  "invocation": {"method": "GET", "endpoint_pattern": "/search?query={query}&limit={limit}"},
  "source_citation": {"section": "Search Endpoint", "excerpt": "The search endpoint accepts a query string and returns matching document IDs. Optional limit parameter defaults to 10."}
}

After pasting this template, replace [DOCUMENTATION] with the full text of your tool documentation. If the document is long, consider chunking it by section and running the prompt per section, then merging the results. Validate the output against your tool registry schema before ingestion—this prompt produces structured JSON, but field completeness depends on documentation quality. For high-stakes registrations, add a human review step where an engineer confirms each extracted tool against the original source before the manifest enters production. Run the extraction against a known tool with documented capabilities first to calibrate your expectations for completeness and accuracy.

This prompt is designed to run as a batch processing step inside a tool onboarding pipeline, not as a one-off chat interaction. The typical integration pattern is: a documentation URL or raw text enters the pipeline, the prompt extracts structured capability records, a validator checks schema compliance and source grounding, and the output is written to a tool registry database. The prompt expects a single document as input, so if you are processing a documentation site with multiple pages, you should chunk the source material by logical tool or endpoint boundary before invoking the prompt. Each invocation should be independent and idempotent so that reprocessing a single page does not affect previously extracted tools.

Wire the prompt into an application using a queue-based worker pattern. The worker reads a job containing the [DOCUMENTATION_TEXT] and optional [TOOL_NAME_HINT], calls the model with the prompt template, and receives a JSON array of capability objects. Before writing to the registry, run a schema validator that checks: every required field is present (name, description, parameters, source_citation), parameter objects include name, type, required, and description, and every source_citation field contains a non-empty excerpt from the input document. If validation fails, log the failure with the raw model output and the validation errors, then retry once with the same input and the validation errors appended as [PREVIOUS_ERRORS] in the prompt. If the retry also fails, route the job to a human review queue with the original document, the failed output, and the validation report. This prevents silently ingesting malformed capability records into the registry.

For model selection, prefer a model with strong structured output support and a large context window, since documentation pages can be long. If you are using OpenAI, enable response_format: { type: "json_object" } and include the output schema in the prompt. If you are using a model without native JSON mode, add a post-processing step that attempts to parse the output and repair common JSON errors (trailing commas, unescaped quotes) before validation. Log every extraction attempt with the document hash, model version, timestamp, and validation result. This audit trail is essential for debugging capability drift when tool documentation changes upstream. Do not use this prompt for real-time agent tool discovery at runtime; it is a registration-time pipeline step. Runtime discovery should read from the validated registry, not call this prompt directly.