list_catalogBrowse every stocked error signature, title, tag, confidence label, and free-sample flag without ranking or creating an offer. Use search_fixes instead when diagnosing a specific error; it returns the best match and any purchase-ready checkout.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
| Name | Required | Description | Default |
|---|---|---|---|
| spec | Yes | ||
| tier | Yes | ||
| store | Yes | ||
| entries | Yes | ||
| tagline | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds behavioral context by stating the tool does not rank or create offers, and specifies the exact fields returned, which is beyond annotation data. No contradiction.
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?
Two sentences, front-loaded with the core action and content, followed by a concise alternative routing. No wasted words.
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 simple list tool with no parameters, an output schema, and annotations covering safety, the description fully equips an agent to decide when and how to call it. The only potential missing detail (pagination) is not required given the tool's nature.
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 zero parameters, the schema carries no burden and the description correctly adds no parameter details. The baseline for 0-param tools is 4, and no compensation is needed.
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?
States a specific verb ('Browse') and a clear resource (the fix catalog), lists the fields it returns (signature, title, tag, confidence label, free-sample flag), and explicitly contrasts with search_fixes. This clearly distinguishes it from sibling tools.
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?
Provides explicit routing: 'Use search_fixes instead when diagnosing a specific error' — names the alternative and the condition that selects it. No ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Most tools target clearly distinct resources or actions, and cross-references like 'use get_fix instead' sharply reduce confusion. A minor source of ambiguity is the cluster of redemption/offer tools (get_fix, get_skill, get_offer) and the three status-check tools, but their descriptions disambiguate them well.
All tools follow a consistent lowercase snake_case verb_noun pattern: audit_, check_, get_, list_, order_, request_, search_, submit_. The naming style is uniform and predictable across different domains.
At 17 tools, the surface is slightly above the ideal 3-15 range but remains justified given the server's broad scope: catalog browsing, paid redemption, audits, services, requests, submissions, and checkout support. It is dense but not bloated.
The lifecycle coverage is strong: discover, get, request, submit, check status, order, pay, and redeem are all represented. Minor gaps exist, such as no cancellation/refund path, no way to update a submitted fix, and merch ordering delegated entirely to an external storefront.