412 finance tools, 56 prompts: quant, SEC and EU filings, fact checks, rates, odds, DeFi, macro.
Scored across 3 tools
The three tools form a clear pipeline: find_tool searches, describe_tool fetches schema, run_tool executes. Each has a distinct, non-overlapping purpose with explicit usage guidance, so an agent can easily select the right one.
All tools follow a consistent verb_tool pattern (describe_tool, find_tool, run_tool). The naming is predictable and readable throughout.
Three meta-tools are minimal but sufficient for a gateway to 383 finance tools. The count is slightly thin—a fourth tool for listing packs or metadata could help—but each earns its place.
The surface covers discovery, description, execution, batch calls, file inputs, and result passing, forming a complete lifecycle. Minor gaps exist (e.g., no explicit tool to list all packs or server metadata), but agents can work around them via find_tool's broad search.
Read one tool's full description and input JSON Schema, between find_tool and run_tool, when find_tool's signature does not settle an argument. An unknown name returns an error.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | The exact tool name, as find_tool returned it. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is covered. The description adds non-obvious behavior the annotations do not: an unknown name produces an error rather than an empty result. It does not describe response shape or size, but the output schema carries that.
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?
One sentence, zero filler, with the core action front-loaded and the workflow placement and error behavior appended as compact clauses. Nothing restates the tool name or title.
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: one required string parameter and an existing output schema, so return values need not be explained. Action, placement among siblings, parameter source, and error behavior are all covered — nothing an agent needs to call it correctly is missing.
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 coverage is 100% and the single name parameter is fully documented in the schema, so the baseline would be 3. The description adds value beyond that by tying the parameter to its source ('as find_tool returned it' semantics) and stating the failure mode for an unrecognized value.
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 and resource — read one tool's full description plus its input JSON Schema — and positions itself relative to find_tool and run_tool. An agent can distinguish it from the siblings without opening any schema.
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 names the workflow position (between find_tool and run_tool) and the triggering condition (find_tool's signature does not settle an argument). That is a when-to-use rule plus the alternative it supersedes, with no inference required.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the 383 finance tools (packs: quant, validation, fundamentals, research, backtest, markets) in plain words, e.g. "deflated sharpe", "revenue as of 2019". Returns the closest matches first, with names, argument signatures and one line each, even when none fits, so check them. Next: run_tool, or describe_tool if an argument is unclear.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | 1 to 50, default 6. | |
| query | Yes | What you need, in plain words. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-open-world, so safety is covered; the description adds genuinely new behavior: results are ranked 'closest matches first', each carries name, argument signature and a one-line summary, and results are returned even when nothing fits. It does not discuss the default result count (limit=6) or how to broaden a weak match set, which is the remaining behavioral gap.
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?
One dense paragraph, front-loaded with scope before examples and routing. Every clause carries information (packs, examples, ranking, no-empty-result caveat, next steps), though the final 'Next:' sentence stacks two alternatives and reads slightly compressed.
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 search tool with a full output schema, the description covers everything an agent needs: corpus size and pack breakdown, how to phrase the query, ranking and result shape, the empty-match caveat, and which sibling to call next. Return-value detail is correctly left to the output schema.
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 coverage is 100% and both parameters are documented there, including the 1-50 range and default 6 for limit, so the baseline is 3. The description reinforces the 'plain words' phrasing of query with examples but says nothing about limit and adds no semantics the schema lacks.
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 and resource plus the exact scope: 'Search the 383 finance tools (packs: quant, validation, fundamentals, research, backtest, markets)'. Concrete example queries ('deflated sharpe', 'revenue as of 2019') make the retrieval model unambiguous and clearly separate it from run_tool and describe_tool.
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 routes the agent forward: 'Next: run_tool, or describe_tool if an argument is unclear', naming both siblings with the condition that selects each. It also pre-empts the main misuse path by warning that matches are returned 'even when none fits, so check them', i.e. do not treat an empty-looking result as failure.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run a tool find_tool named: one ({name, arguments}), or up to 25 ({calls: [...]}). Independent calls run concurrently; a failed call returns its own error and the rest still run. Read-only unless the paper-trading pack is on. Any argument can be {"$file": "path.csv", "column": "close"} (or "columns": [...] / "all") instead of pasted numbers. {"$result": i, "path": "close"} passes batch call i's output into a later call; every result also has a ref ("r1", ...) later calls pass the same way, {"$result": "r1", "path": "close"}, so data never needs copying.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Tool name from find_tool (single call). | |
| view | No | Draw the whole result for the person (charts, comparisons, option chains, yield curves, statements, backtest dashboards, order tickets) and return you a summary, where MCP Apps are drawn. | |
| calls | No | Several calls in one round trip. Calls without $result references run concurrently. | |
| digits | No | Round fractional numbers in the results to this many significant figures (4-6 saves output tokens); whole numbers such as counts, shares and IDs are never changed. Default: as each tool returns them. | |
| return | No | For a batch: every result (default) or only the last one. | |
| select | No | Return only these fields of each result, as dotted paths, e.g. ["verdict", "multiple_testing.best", "rows.0.accession"] (table rows take column names). | |
| receipt | No | Add input and output SHA-256 and pack versions so the result can be recomputed and compared. | |
| arguments | No | The tool's arguments (single call). |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, but the description says 'Read-only unless the paper-trading pack is on,' which implies the tool may perform non-read-only operations under that pack. That directly conflicts with the unconditional readOnlyHint annotation, so the contradiction forces a 1 despite otherwise useful concurrency and failure-isolation 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?
It is compact and front-loads the core run-one/run-batch behavior with no filler. However, the first sentence is syntactically awkward and the final sentence packs multiple reference mechanisms together, slightly reducing readability.
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 proxy-runner with 8 parameters, an output schema, and annotations, it covers the critical execution semantics: single/batch, concurrency, error isolation, file/result substitution, and the read-only caveat. The main remaining gap is that the read-only exception is not reconciled with the annotation.
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 important meaning beyond the schema by documenting the special $file and $result substitution syntax and result refs such as 'r1', which are not captured in the generic arguments 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 states that it runs a tool discovered via find_tool, supporting either one call ({name, arguments}) or a batch of up to 25 ({calls: [...]}), which distinguishes it from the finder sibling. The phrasing 'Run a tool find_tool named' is awkward and it does not explicitly contrast with describe_tool, so it is clear but not perfect.
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?
It explains single vs. batch invocation, concurrent execution for independent calls, and failure isolation, and it points to find_tool as the source of the tool name. It does not explicitly state when to use this versus describe_tool or when a batch is preferable, so it gives clear context but no exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
describe_tool1 field changedInput schema / properties / name / descriptionPrevious value: -"A tool name from find_tool."New value: +"The exact tool name, as find_tool returned it."find_tool1 field changedInput schema / properties / limit / descriptionPrevious value: -"Default 6."New value: +"1 to 50, default 6."run_tool1 field changedInput schema / properties / viewAdded value: +{
+ "description": "Draw the whole result for the person (charts, comparisons, option chains, yield curves, statements, backtest dashboards, order tickets) and return you a summary, where MCP Apps are drawn.",
+ "type": "boolean"
+}describe_toolfind_toolrun_toolSEC filings and financial data for AI agents: 59 tools for statements, valuation and supply chains.
351 read-only tools: stocks since 1926, options, CDS, bonds, private markets, 13F, macro and crypto
75 MCP tools: SEC financials, FRED economics, IRS 990, FDA, FX, UK Companies House.
Compliance-gated stablecoin settlement + x402 macro/ESG/climate intelligence for agents. 115 tools.
Add one secure layer between your agents and this server.