find_dataDescribe the data you need in plain language (e.g. 'Apple risk factors 2023', 'is this token a honeypot', 'is this email deliverable', 'read this page'). Searches this server's datasets first, then the whole Professor Sausages catalog, and returns matching endpoints with method, URL, price, and how to call them. Free.
| Name | Required | Description | Default |
|---|---|---|---|
| task | Yes | What you're trying to find or do, in your own words |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full transparency burden. It discloses the search order (server datasets first, then catalog) and what the response contains (method, URL, price, call instructions) plus the fact that it is free. It does not mention error handling, rate limits, or authentication, but for a search/discovery tool, this is reasonably transparent and gives the agent a good sense of what to expect.
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 concise: three sentences that front-load examples, state the search behavior, and summarize output. Every sentence earns its place with no filler, and the structure guides the agent from usage examples to process to result format efficiently.
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 a single parameter and no output schema, the description covers the essential context: what to provide, how the search works, and what the response will include. It could mention potential limitations or error cases, but for a tool of this complexity, the description is complete enough for an agent to select and use it correctly. A 5 would require more explicit details on edge cases or failure modes.
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 schema already fully describes the single 'task' parameter with an example. The description adds value by offering multiple plain-language examples ('Apple risk factors 2023', 'is this token a honeypot', 'is this email deliverable', 'read this page') and clarifies that the task can be phrased in any way, expanding the parameter's semantics beyond the schema's minimal description.
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 function: it searches for data endpoints based on a plain-language description and returns matching endpoints with method, URL, price, and call instructions. The verb 'searches' and 'returns' plus resource scope (server datasets + catalog) distinguishes it from sibling tools that each target a specific data type, so an agent can easily tell when to use it for discovery versus direct retrieval.
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 explains the tool's purpose and search process, implying it should be used when you need to locate an endpoint or data source. However, it does not explicitly state when not to use it or mention alternatives like the specific sibling tools. The guidance is clear enough for an agent to infer usage, but it lacks explicit exclusions or contrast with alternatives, so it misses a 5.
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 targets a distinct data area or action: coverage vs find_data vs request_data are clearly separate (metadata, search, and suggestion box), and the three holdings tools (holdings_changes, manager_holdings, security_holders) each address a different question (changes, portfolio, owners). No two tools have ambiguous boundaries.
All tool names use consistent lowercase snake_case (coverage, find_data, fx_rate, request_data, etc.). While some are verb phrases and others are noun phrases, the naming style is uniform and predictable, making it easy to guess tool purposes.
Twelve tools is a well-scoped size for a financial data API server. Each tool covers a distinct data domain, and there is no excessive redundancy or crowding. The count is within the ideal 3-15 range.
The tool set covers a broad range of financial data needs: SEC filings, holdings, insider activity, IPO, macro, and FX. Minor gaps exist (e.g., no direct company fundamentals or full filing text), but the request_data tool provides a path to fill missing datasets, so agents are not at a dead end.