AXIS Toolbox — Agentic Commerce Codebase Intelligence

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden and does well by disclosing key behavioral traits: 'Deterministic: same input → byte-identical output' explains consistency, 'Requires API key' states authentication needs, and 'Returns snapshot_id' describes the output. It also mentions 'max varies by tier' for file limits. While comprehensive, it doesn't cover rate limits or error conditions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is appropriately sized and front-loaded with the core purpose in the first sentence. Each subsequent sentence adds important information (artifacts, parameters, output, determinism, authentication). While slightly dense due to listing 86 artifacts, every sentence earns its place by providing necessary context for tool usage.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity (5 parameters, no annotations, no output schema), the description does well by explaining the output ('Returns snapshot_id'), authentication ('Requires API key'), and behavioral consistency ('Deterministic'). It could be more complete by detailing error cases or the structure of returned artifacts, but it covers the essential context for a complex analysis tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The description adds some value by explaining the 'files' parameter format ('Pass files as [{path, content}] array') and mentioning 'max varies by tier', but doesn't provide additional meaning for other parameters like 'goals' or 'frameworks' beyond what the schema already documents.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Analyze source files directly (no GitHub required) and receive all 86 AXIS artifacts'. It specifies the verb ('analyze'), resource ('source files'), and distinguishes from sibling 'analyze_repo' by emphasizing 'no GitHub required'. The detailed list of artifacts (AGENTS.md, .cursorrules, etc.) provides concrete examples of what the analysis produces.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context for when to use this tool: 'Analyze source files directly (no GitHub required)' implicitly suggests using 'analyze_repo' for GitHub-based analysis. It also mentions 'Use get_artifact to retrieve any specific file' as a follow-up action. However, it doesn't explicitly state when NOT to use this tool or provide detailed alternatives beyond the GitHub distinction.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool returns a 'snapshot_id' for artifact retrieval and requires an API key, which are useful behavioral details. However, it lacks information on rate limits, error conditions, authentication specifics, or what happens if the repo is private, leaving gaps in transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the core functionality but includes a lengthy list of artifact examples (e.g., 'AGENTS.md, .cursorrules...') that could be summarized. While informative, this reduces conciseness. The sentences are clear, but the list feels excessive for a tool description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no annotations and no output schema, the description partially compensates by explaining the return value ('snapshot_id') and API key requirement. However, it lacks details on output structure, error handling, or operational constraints, making it incomplete for a tool that performs complex analysis with multiple artifacts.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema fully documents the single parameter 'github_url'. The description adds no additional parameter semantics beyond what the schema provides, such as format constraints or examples. Baseline score of 3 is appropriate as the schema handles parameter documentation adequately.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool analyzes public GitHub repositories and produces structured AI-context artifacts, with specific examples like AGENTS.md and .cursorrules. It distinguishes from sibling 'analyze_files' by focusing on entire repositories rather than individual files, though it doesn't explicitly name this distinction. The verb 'analyze' and resource 'public GitHub repo' are specific.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description mentions 'Requires API key' as a prerequisite but provides no guidance on when to use this tool versus alternatives like 'analyze_files' or 'get_snapshot'. It doesn't specify scenarios where this tool is preferred over siblings or any exclusions, leaving the agent to infer usage context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden and effectively discloses key behavioral traits: it specifies the return values (e.g., 'earned_credits_millicents'), notes 'No cost to call' (indicating it's free and likely read-only), and states 'Requires API key' (highlighting authentication needs). However, it lacks details on rate limits or error handling.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is highly concise and front-loaded, with every sentence earning its place: the first sentence states the purpose and return values, the second adds behavioral context (cost and API key requirement). There is no wasted text or redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's low complexity (0 parameters, no annotations, no output schema), the description is largely complete—it explains what the tool does, its returns, and key constraints. However, it could be slightly improved by clarifying the data format (e.g., units for 'earned_credits_millicents') or error cases, though this is minor given the simplicity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately focuses on output semantics by listing return values, which compensates for the lack of an output schema, adding significant value beyond the empty input schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the specific action ('Check') and resource ('your agent's referral earnings, lifetime conversions, discount tier, and free calls remaining'), distinguishing it from sibling tools like 'get_referral_code' or 'list_programs' by focusing on status metrics rather than code generation or program listing.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context for when to use this tool ('Check your agent's referral earnings...'), but does not explicitly mention when not to use it or name alternatives among siblings. It implies usage for monitoring referral-related metrics without specifying prerequisites beyond the API key requirement.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden and does well by disclosing key behavioral traits: authentication requirements ('no authentication required'), rate/access considerations ('free discovery endpoint'), and output characteristics ('ranked overview', 'includes shareable manifest JSON for agent swarms and system prompt snippets'). It doesn't mention error handling or performance characteristics, keeping it from a perfect score.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Perfectly front-loaded with the core purpose in the first sentence, followed by supporting details. Every sentence adds unique value: authentication status, return content, ideal usage context, and additional output features. Zero wasted words while maintaining complete information density.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a parameterless discovery tool with no output schema, the description provides excellent context about what the tool returns and when to use it. It covers authentication, output format, and workflow positioning. The only minor gap is not explicitly describing the exact structure of the 'ranked overview' return data, though this is somewhat mitigated by mentioning specific content elements like pricing and capability tags.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0 parameters and 100% schema coverage, the baseline is 4. The description appropriately explains this is a parameterless discovery endpoint, confirming what the empty input schema already indicates without redundant elaboration.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose with specific verbs ('discovery endpoint', 'returns a ranked overview') and resources ('every AXIS tool with pricing, capability tags, and direct install links'). It distinguishes from siblings by emphasizing this is for initial ecosystem exploration before authenticated calls, unlike tools like 'analyze_files' or 'get_artifact' that perform specific operations.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states when to use ('ideal first call for any agent entering the AXIS ecosystem', 'call this to learn what AXIS can do before committing to an authenticated call') and provides clear alternatives (authenticated calls). The guidance is specific about the tool's role in the workflow sequence.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden and does well: it discloses that no authentication is required, describes the return content (tools, readiness score methodology, etc.), includes a call-to-action for next steps, and mentions searchable terms for context. It doesn't cover rate limits or error behaviors, but provides substantial operational context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with core purpose, followed by key details (returns, auth status, usage context). The searchable terms list is slightly verbose but serves as useful context. Overall, most sentences earn their place, though it could be tighter by integrating the searchable terms more seamlessly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with no annotations and no output schema, the description provides strong context: purpose, usage guidelines, behavioral traits (no auth, returns specific outputs), and parameter hints. It doesn't detail output structure or error handling, but given the discovery nature and lack of structured fields, it's largely complete for agent use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The description adds value by contextualizing parameters: it implies 'task_description' should detail a commerce challenge, and the searchable terms (e.g., 'AP2 compliance', 'negotiation playbook') help clarify what 'focus_areas' might include, enhancing understanding beyond the schema's technical descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: to analyze a user's purchasing/commerce task and return specific AXIS tools, readiness methodology, compliance generators, and self-onboarding steps. It distinguishes from siblings by focusing on discovery/assessment rather than execution (e.g., 'prepare_for_agentic_purchasing' is mentioned as a next step).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states when to use ('to understand what AXIS can do for your specific commerce challenge before committing to an authenticated call') and when not to use (no authentication required, implying it's for preliminary assessment). Mentions 'prepare_for_agentic_purchasing' as an alternative for authenticated calls, and the searchable terms help differentiate from other discovery tools like 'discover_agentic_commerce_tools'.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly indicates this is a read operation ('Read the full UTF-8 content'), specifies the encoding (UTF-8), and explains the dependency on prior operations (snapshot_id requirement). However, it doesn't mention potential errors (e.g., invalid paths or snapshot IDs) or performance characteristics.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is efficiently structured in two sentences: the first states the purpose with helpful examples, the second explains prerequisites and related tools. Every sentence adds value with zero wasted words, and key information is front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a read-only tool with 2 parameters and 100% schema coverage, the description provides good context about workflow dependencies and path examples. However, without an output schema, it doesn't describe the return format (e.g., string content structure) or potential error cases, leaving some gaps in completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents both parameters. The description adds some context about path format ('as returned in the artifacts list') and provides concrete examples of valid paths, but doesn't significantly expand beyond what the schema provides. Baseline 3 is appropriate when the schema does most of the work.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the specific action ('Read the full UTF-8 content') and resource ('any generated artifact by path'), with concrete examples of artifact paths. It distinguishes this tool from sibling tools like get_snapshot (which enumerates artifacts) and analyze_repo/analyze_files (which create snapshots).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly states when to use this tool ('Requires snapshot_id from a prior analyze_repo or analyze_files call') and provides an alternative for discovering available paths ('Use the artifacts list from get_snapshot to enumerate all available paths'). It clearly defines prerequisites and related workflows.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden and discloses key behavioral traits: it explains the referral program's financial incentives ($0.001 per conversion, caps, discounts), promotional details (5th paid call free), and prerequisites ('Requires API key'), though it lacks information on response format or error handling.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is appropriately sized and front-loaded with the core purpose in the first sentence, followed by relevant details. While efficient, it could be slightly more structured by separating program rules from tool usage, but all sentences add value without waste.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (0 params, no annotations, no output schema), the description is quite complete, covering purpose, program rules, and prerequisites. It could improve by specifying the return value format, but for a straightforward retrieval tool, it provides sufficient context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has 0 parameters with 100% schema description coverage, so no parameter details are needed. The description appropriately focuses on context and usage without redundant parameter information, meeting the baseline for zero-param tools.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose with specific verb ('Get') and resource ('your agent's unique referral code for the Share-to-Earn program'), distinguishing it from siblings like 'check_referral_credits' or 'list_programs' by focusing on code retrieval rather than credit checking or program listing.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context for when to use this tool ('Share this code with other agents') and mentions the program's purpose, but does not explicitly state when not to use it or name specific alternatives among sibling tools, though it implicitly differentiates from 'check_referral_credits'.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key traits: the tool retrieves status and listings (read-only implied), snapshots persist (durability), and sharing snapshot_id avoids duplicate costs (performance/efficiency consideration). It doesn't cover rate limits or error conditions, but provides substantial context beyond basic functionality.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is perfectly concise with three sentences that each earn their place: first states core functionality, second explains usage context, third adds important behavioral details about persistence and cost avoidance. No wasted words, front-loaded with the main purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's moderate complexity (retrieving persisted analysis results), no annotations, and no output schema, the description does well by explaining what the tool returns (status and artifact listing), persistence characteristics, and cost implications. It could mention the return format or error cases, but covers the essential context for agent decision-making.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% for the single parameter snapshot_id, which is already documented in the schema. The description adds minimal value by noting that snapshot_id comes from analyze_repo or analyze_files, but doesn't provide additional syntax or format details beyond what the schema states. Baseline 3 is appropriate when schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the specific action ('Retrieve status and full artifact listing') and resource ('a prior analysis by snapshot_id'), distinguishing it from siblings like analyze_files (which creates snapshots) and get_artifact (which retrieves individual artifacts). It explicitly mentions the purpose of re-enumerating artifact paths without re-running analysis.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit guidance on when to use this tool ('to re-enumerate artifact paths without re-running analysis') and when not to use it (avoid duplicate analysis costs). It also distinguishes from siblings by noting that snapshot_id comes from analyze_repo or analyze_files, making the workflow clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It discloses that the tool returns a 'hardening report' with specific artifacts, mentions it requires an API key, and implies it performs analysis. However, it lacks details on rate limits, error handling, authentication specifics beyond the API key, or whether the operation is idempotent. For a meta-tool with no annotation coverage, this leaves behavioral gaps.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the core purpose in the first sentence, followed by details on returns and usage. It avoids redundancy, but could be slightly more concise by integrating the 'Essentially' clause more smoothly. Overall, it's efficient with minimal waste.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (meta-analysis with 2 parameters) and lack of annotations and output schema, the description does a fair job by outlining purpose, returns, and prerequisites. However, it doesn't fully compensate for the missing output schema (no details on report structure or error formats) and sparse behavioral transparency, leaving room for improvement in completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents both parameters ('files' and 'project_name'). The description adds context by explaining that 'files' are 'source files of the agent to analyze' and implies 'project_name' is used for the 'agent/project to improve', but doesn't provide additional syntax, format, or constraints beyond what the schema offers. Baseline 3 is appropriate when schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description explicitly states the tool's purpose: 'analyze your own agent's codebase and get back a hardening report with specific AXIS artifacts that will improve your agent's capabilities.' It uses specific verbs ('analyze', 'get back') and resources ('codebase', 'hardening report', 'AXIS artifacts'), and clearly distinguishes from siblings like 'analyze_files' or 'analyze_repo' by focusing on agent improvement with AXIS-specific outputs.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit guidance on when to use this tool: 'Pass your source files and get back a prioritized improvement plan.' It distinguishes from alternatives by specifying the AXIS context and output types (e.g., 'recommended programs', 'missing context files'), and mentions prerequisites: 'Requires API key.' This clearly defines the tool's niche among siblings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure. It successfully communicates key behavioral traits: the tool requires no authentication, enumerates a fixed set of 18 programs with 86 generators, and returns specific data fields (tier and artifact paths). However, it doesn't mention potential limitations like rate limits or error conditions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise with only two sentences that each serve a distinct purpose: the first defines the tool's function and output, the second provides usage guidelines. There is zero wasted language and it's perfectly front-loaded with the core functionality.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (0 parameters, no output schema, no annotations), the description provides excellent coverage of what the tool does, when to use it, and key behavioral aspects. The only minor gap is the lack of output format details, but for a simple enumeration tool with no output schema, this is acceptable.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 0 parameters with 100% coverage, so the baseline would be 3. However, the description adds value by explicitly stating 'No authentication required' and clarifying that this is a parameterless enumeration tool, which compensates for the lack of parameter documentation and elevates the score.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the specific action ('List all 18 AXIS programs') and resources involved (programs, generators, tier, artifact paths). It explicitly distinguishes this tool from its sibling 'search_and_discover_tools' by contrasting 'complete enumeration' versus 'keyword-based discovery', providing clear differentiation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit guidance on when to use this tool ('for complete enumeration') and when to use an alternative ('Use search_and_discover_tools for keyword-based discovery'). It clearly defines the appropriate context and excludes the alternative use case.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden and does an excellent job disclosing behavioral traits. It explains pricing ('Single $0.50 call ($0.15 lite)'), referral economics, output structure ('returns COMPLETE self-contained bundle'), and requirements ('Requires API key'). It details what the tool produces (artifacts, configs, scores) and its comprehensive nature. The only minor gap is lack of explicit rate limits or error handling details.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is information-dense but somewhat verbose with marketing language and tag lists. While front-loaded with core purpose, it includes extensive feature listings and referral details that could be more streamlined. Every sentence adds value but could be more efficiently structured for an AI agent.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a complex tool with 11 parameters, no annotations, and no output schema, the description does remarkably well. It explains the comprehensive output bundle, pricing model, referral system, and positioning relative to other tools. The main gap is lack of explicit output schema documentation, but the description details what's returned. Given the complexity, it's nearly complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents all 11 parameters thoroughly. The description adds some context about referral_token economics and implies relationships between parameters like budget_per_run_cents and compliance depth, but doesn't provide significant additional parameter semantics beyond what's in the schema. Baseline 3 is appropriate when schema does heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description explicitly states the tool's purpose: 'One-and-done agentic commerce hardening for any codebase. Computes Purchasing Readiness Score (0-100) across 7 weighted categories...' It clearly distinguishes from siblings by emphasizing this is 'The definitive first call before any autonomous agent spends money' and 'No downstream tool required — output is sufficient for full agentic commerce autonomy.' The verb 'hardens' and resource 'any codebase' are specific, with comprehensive scope details.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit usage guidance: 'The definitive first call before any autonomous agent spends money' tells when to use it. It distinguishes from siblings by stating 'No downstream tool required' and positioning this as the starting point. It also mentions pricing tiers based on budget and focus areas, giving clear context for parameter choices.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key traits: the tool is 'context-efficient' for token-saving, 'No authentication required' clarifies access needs, and it specifies that results include 'ranked matches with capability tags, artifact paths, and example API calls'. However, it doesn't mention rate limits or error handling, leaving some behavioral aspects uncovered.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured and front-loaded with the core purpose. Every sentence adds value: the first defines the tool, the second provides usage guidance, the third gives examples, and the fourth covers authentication. While slightly dense due to example lists, it avoids redundancy and efficiently communicates essential information without unnecessary elaboration.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's moderate complexity (2 parameters, no output schema, no annotations), the description is largely complete. It covers purpose, usage, parameters, authentication, and examples. However, without an output schema, it could benefit from more detail on result structure (e.g., format of 'ranked matches'), and it doesn't address potential limitations like search scope or performance. Still, it provides sufficient context for effective use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The description adds significant value beyond the schema by providing semantic context: it explains that 'q' accepts keywords or phrases with concrete examples ('checkout payment', 'debug logs'), clarifies that omitting 'q' lists all programs, and lists searchable terms like 'AP2 compliance' and 'Visa Intelligent Commerce'. This enhances understanding of parameter usage beyond basic schema definitions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description explicitly states the tool's purpose: 'Keyword search across all 18 AXIS programs and 86 generators. Returns ranked matches with capability tags, artifact paths, and example API calls.' This is a specific verb ('search') with clear resources ('AXIS programs and generators') and output details. It distinguishes itself from siblings like 'list_programs' by emphasizing search functionality rather than simple listing.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit guidance on when to use this tool: 'call this before loading full tool schemas to find the right program without wasting tokens.' It also distinguishes usage from alternatives by noting that omitting 'q' lists all programs alphabetically, which contrasts with more targeted sibling tools like 'discover_agentic_commerce_tools'. Examples further clarify appropriate contexts.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.