fetchFetch one document or instrument guide returned by search. This is free, read-only content retrieval with no account, credential, payment, or live-price side effects.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Result id returned by the search tool, for example doc:pricing, doc:quickstart, or instrument:crypto:BTCUSD. |
| Name | Required | Description | Default |
|---|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description goes beyond the annotations by explicitly stating there are 'no account, credential, payment, or live-price side effects' and that it is 'free, read-only content retrieval.' This adds valuable behavioral context that readOnlyHint and destructiveHint alone do not convey, such as the absence of hidden costs or authentication requirements.
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 only two sentences, front-loaded with the primary purpose, and contains no redundancy. Every word adds value, making it highly efficient and easy to parse.
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?
The tool is simple (single parameter), has rich annotations and schema descriptions, and also has an output schema available. The description covers purpose, usage context, and side-effect transparency, which is complete for this tool's complexity. No additional details are necessary.
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%, and the parameter 'id' is well-documented with examples in the schema. The description adds no additional parameter semantics, but it does not need to since the schema already explains the expected value format. Baseline 3 is appropriate.
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 a specific action ('Fetch one document or instrument guide') and identifies the source ('returned by search'), distinguishing it from sibling tools like search, list_instruments, and get_pricing_info. It uses a specific verb and resource, leaving no ambiguity about what the tool does.
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 implies this tool is for retrieving a specific result after using the search tool ('returned by search'), which is a clear usage context. It does not explicitly name alternatives or state when not to use it, but the context is sufficient for an agent to choose this over search or other getter tools.
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.
Each tool has a distinct primary purpose, but search and search_pairs overlap in discovery, and get_market_data_endpoint vs get_workflow_endpoint both build endpoints. Descriptions clearly differentiate them, so confusion is unlikely.
All tool names follow a consistent verb_noun pattern with snake_case (get_, list_, search_, fetch). The naming is predictable and uniform across the set.
With 8 tools covering search, catalog, pricing, and endpoint building, the count is well-scoped for a market intelligence discovery server. No redundancy or bloat.
The tools cover documentation search, instrument discovery, product/pricing info, and endpoint construction. The only minor gap is not executing actual paid data fetches, but that is intentionally left to the generated HTTP endpoints.