canon_thresholdsReference table of the regulatory figures agents get wrong: 13F, 13D and 13G, Form 4, Form PF tiers, adviser registration, 3(c)(1) and 3(c)(7), accredited investor, qualified client, Form D, CFTC 4.13(a)(3), ERISA 25 percent, AIFMD, HSR, Reg T. Each row carries the rule, authority, effective date, primary source and a confidence label. Filter by words or authority.
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | ||
| authority | No |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds useful context: each row carries rule, authority, effective date, primary source, and confidence label, and filters are by words or authority. It does not contradict annotations. There is still no detail about limits, formatting, or how filtering behaves with no args, but the read-only hint lowers the burden.
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 dense but well-organized: it lists what the table contains, what each row carries, and how to filter. Every sentence earns its place and no fluff is present.
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 reference lookup tool with a clear resource and filter interface, the description is largely complete. It does not explain what happens with no query (whether all thresholds are returned) or how results are sorted/limited, but those are minor gaps because the tool is essentially a table lookup with an obvious use model.
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 0%, so the description must compensate. It explains the two filter dimensions: q (words) and authority (regulatory body), and names the row attributes. It doesn't give detailed syntax but it does meaningfully explain what filtering by each parameter achieves.
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 a specific resource — a reference table of regulatory thresholds — and lists exact figures it resolves (13F, 13D/13G, Form 4, etc.). It clearly distinguishes itself from sibling tools by presenting itself as a lookup/filter reference for numeric regulatory thresholds, not a search, compute, or document 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?
It clearly states when to use it: when agents need accurate regulatory figures and thresholds. It implies it should be used over alternatives for threshold/numeric regulatory lookups. However, it does not explicitly state when NOT to use it or name sibling alternatives, though the sibling list makes the contrast reasonably clear.
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 clearly distinct job: searching, fetching entries, mapping entities, running formulas, batching computations, verifying receipts, citing, listing sites, monitoring changes, and looking up regulatory thresholds. Even the related compute/batch/verify tools are cleanly separated by single vs. batch execution and verification responsibility.
All tools share the canon_ prefix and use lowercase snake_case, which makes the set feel consistent and predictable. However, the suffixes mix bare resource nouns (canon_sites, canon_thresholds, canon_entity) with verb phrases (canon_describe_formula, canon_list_formulas, canon_get_entry), so the naming convention is not perfectly uniform.
Thirteen tools is well within the ideal range for a reference-and-computation API, and each tool covers a distinct capability without redundancy. The count feels proportionate to the breadth of the finance canon domain.
The surface is complete for a read-only reference service: search, entry retrieval, entity resolution, contract lookup, formula inspection, computation, batch execution, receipt verification, citations, change monitoring, site stats, and regulatory thresholds. There are no obvious dead ends or missing core operations.