Primitiv demonstrates solid definition quality across 7 tools. All tools have explicit names, descriptions, and input schemas with type definitions. Naming is strong (verb_noun pattern: get_, list_). Descriptions are well-crafted (average ~120 chars, contextual). Parameters are typed with descriptions. However, output schemas are not explicitly documented in the source code (only inferred from implementation logic), which prevents a higher score. Error handling strategy is not visible in the provided code excerpt. Tools follow single-responsibility principle well. No security concerns with parameter exposure (all READ_ONLY, no secrets). Pagination parameters present on list tools with reasonable defaults (limit=50, max=200). Tool composition is excellent, each tool serves one purpose and output from discovery tools (list_*) chains naturally into detail tools (get_*).

• Document output schema for each tool as a formal JSON Schema block in the tool registration. Example: get_token should declare it returns {name: string, modes: array, usageStats: object, rationale: string}. This enables LLMs to understand what fields they can extract and chain into downstream tools.
• Add error handling and recovery hints to tool descriptions. E.g., get_token: 'If token not found, call list_tokens with namePattern to search by partial name.' This teaches LLMs how to self-correct on 404s.
• For list_* tools, add a note: 'Results are paginated; use limit and offset to retrieve all items. If you need all tokens, iterate until offset >= total_count.' This guides agents to properly handle large datasets.
• In descriptions for optional parameters (category, mode, source), explicitly state the behavior when omitted. E.g., 'If mode is not specified, returns the default mode (usually the first defined).' This prevents LLMs from guessing.
• Add constraint descriptions for filter parameters. E.g., 'namePattern: substring match, case-insensitive, max 100 chars. Special regex chars are treated literally.' This prevents LLMs from trying complex regex when simple substring match is intended.
• Document the 'rationale' field that appears in get_token and get_component responses. Explain what kind of justification is included and how to use it for user guidance. This clarifies why a design decision was made.
• Consider adding an optional 'format' parameter to list_* tools to support both summary and detailed response formats (e.g., format='summary' returns just names and IDs; format='detailed' returns full definitions). This lets agents control verbosity and context window usage.