Finance canon lookup plus 30 deterministic formulas, each with a verifiable receipt.
Run up to 50 computes in one call, for scenario grids and sensitivity tables. Each item returns its own receipt; the batch receipt id is sha256 over the sorted item receipt ids, so a whole table can be cited by one hash.
| Name | Required | Description | Default |
|---|---|---|---|
| items | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool readOnly and idempotent; the description adds genuinely useful behavioral detail by revealing that each item returns its own receipt and the batch receipt id is a sha256 over sorted item receipt ids. This explains deterministic output/reference behavior beyond the annotations.
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 dense sentences with the key detail ('up to 50 computes', per-item receipts, batch hash) front-loaded. Every sentence adds information and there is no filler.
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 tool with a nested items array, formula enum, and no output schema, the description covers the essential output/citation semantics without explaining error behavior. It is complete enough for correct invocation, though a note on partial failures or per-item validation would make it fully robust.
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 0% schema description coverage, the description partially compensates by explaining that items are computes, up to 50, and each yields a receipt. It does not, however, break down the required formula/inputs structure, leaving the agent to infer those from the schema field names and sibling tools.
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 batch operation: run up to 50 computes in one call for grids/sensitivity tables. The description distinguishes the tool from single-compute siblings (canon_compute) by emphasizing batching and the single hash for a whole table.
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?
Describes when to use it: scenario grids and sensitivity tables requiring many computes. It does not explicitly name canon_compute as the alternative for a single compute, but the guidance is clear enough for an agent to pick the right tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Aggregated dated change events across every vertical, newest first. Poll this instead of re-crawling.
| Name | Required | Description | Default |
|---|---|---|---|
| since | No | ISO date; only events on or after this date |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool read-only and open-world, and the description adds useful behavioral details: results are aggregated, dated, span every vertical, and are returned newest first. This gives an agent a solid expectation of the response without contradicting the annotations.
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 with no filler: the first delivers the core behavior and ordering, and the second gives actionable usage guidance. Every word earns its place, and the description is appropriately sized for a simple single-parameter tool.
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 polling tool with one optional parameter, read-only and open-world annotations, and a fully documented schema, the description provides enough context to select and call the tool correctly. It does not detail the shape of individual change events or pagination, but those are minor gaps given the strong annotations and 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 description coverage is 100%, with the 'since' parameter fully documented as an ISO date filtering to events on or after that date. The description does not add extra parameter nuance, but it does not need to because the schema already covers semantics.
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 identifies the resource: aggregated dated change events across every vertical, ordered newest first. It stops short of an explicit verb like 'list' or 'retrieve', but the intent is unambiguous and the tool is distinct from its 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?
'Poll this instead of re-crawling' gives direct guidance on when to use the tool as a change-polling mechanism rather than performing heavier data collection. It does not name specific alternatives or exclusion cases, but the primary usage context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Ready-to-paste citation strings (markdown, plain, apa, bibtex) for one entry, with the reviewed date. Use when writing a report that quotes the canon.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| site | Yes | ||
| format | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With readOnlyHint=true, the safety profile is pre-declared; the description adds the useful behavioral context that the tool returns preformatted citations (markdown, plain, apa, bibtex) and includes the reviewed date, rather than returning entry content.
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 focused sentences with no filler; the output promise is front-loaded and the usage sentence earns its place.
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 three simple parameters, enum constraints in the schema, and no output schema, the description adequately conveys the tool's output and purpose. It lacks only explicit notes on edge cases or how site/id combine to identify the entry.
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 0%, so the description must carry parameter meaning. It mentions citation formats, which helps the format parameter, and 'one entry' hints at id, but it does not explain what id/site refer to or how to choose a site.
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 identifies a specific verb and resource: producing ready-to-paste citation strings for a single canon entry. It is distinct from sibling retrieval/search tools, though it doesn't explicitly name an alternative.
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 gives an explicit use case: 'Use when writing a report that quotes the canon.' It doesn't discuss when not to use it or contrast with canon_get_entry/canon_search, so it stops short of full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run one formula from the registry on validated inputs. Returns outputs, the convention used, citations, and a receipt whose id is sha256 over formula, version, canonical inputs and outputs. Invalid inputs return an explicit problem list and a working example instead of nulls.
| Name | Required | Description | Default |
|---|---|---|---|
| inputs | Yes | Inputs keyed by name; see canon_describe_formula | |
| formula | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint and idempotentHint, but the description adds meaningful behavioral details: the receipt id is sha256 over formula, version, canonical inputs and outputs, and invalid inputs return a problem list plus a working example rather than nulls. This goes well beyond the annotations and explains failure behavior and return semantics.
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 information-dense sentences with no filler. The main action is front-loaded, followed by return artifacts and invalid-input behavior. Every clause contributes useful guidance for an agent deciding whether and how to invoke the tool.
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 has only two required parameters, and the description covers the core invocation flow, return contents, receipt construction, and error response behavior. Since there is no output schema, the description does the necessary work of telling the agent what to expect. It also points to canon_describe_formula for input details, making the definition complete for the tool's complexity.
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 50%; the schema documents the 'inputs' property and points to canon_describe_formula, while the formula enum is self-explanatory as a list of registered formulas. The description adds the concepts of 'validated inputs' and 'canonical inputs' but does not explain specific parameter formats or how inputs map to formulas. It maps to the schema and augments it somewhat without fully compensating for the missing details.
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 opens with a specific verb and resource: 'Run one formula from the registry on validated inputs.' It clearly identifies what the tool computes and differentiates itself from the sibling canon_batch by emphasizing 'one formula' rather than batch operations. It also conveys the distinctive return artifacts (outputs, convention, citations, receipt), making the purpose unmistakable.
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 sets clear context: use this tool to run a single registered formula with validated inputs. The phrase 'one formula from the registry' implies a scope and avoids confusion with batch or listing tools. It does not explicitly name alternatives or conditions for when not to use it, but the context is clear enough for correct selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch one Kalshi (ticker) or Polymarket (slug or condition id) contract and return rules text, close time, resolution source and status in one shape. For a paid cross-venue identity check with a snapshot receipt, call GET /v1/contracts/compare over REST.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| venue | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint and openWorldHint, so the safety profile is covered. The description adds useful behavioral context by naming the returned fields, the accepted identifier forms per venue, and the 'one shape' normalization behavior. It does not discuss errors or staleness, but the annotation coverage 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?
Two sentences, no filler. The core action and output are front-loaded, and the alternative routing is placed second where it belongs. Every clause earns its place.
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 read-only two-parameter tool with no output schema, the description is complete: it explains what inputs are accepted, what outputs will appear, and when to use a different endpoint. Nothing essential for invoking the tool 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?
With schema description coverage at 0%, the description carries the full burden and succeeds: it explains that 'id' is a Kalshi ticker or a Polymarket slug/condition id depending on the venue, and that 'venue' is the selector between them. Both parameters are given meaningful domain semantics beyond the raw 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 opens with a specific verb and resource: 'Fetch one Kalshi (ticker) or Polymarket (slug or condition id) contract' and names the exact returned fields. This makes it immediately distinguishable from the sibling canon_batch, canon_search, and canon_compare alternatives.
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 explicitly routes a different need to 'GET /v1/contracts/compare over REST' when a paid cross-venue identity check with snapshot receipt is required. It does not explicitly contrast with all siblings, but the singular 'one contract' and the compare alternative provide clear enough context for most agents.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Input schema with ranges and defaults, output names, stated convention, citations and test vectors for one formula.
| Name | Required | Description | Default |
|---|---|---|---|
| formula | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, which the description does not contradict. The description adds useful context about what the tool returns (ranges, defaults, output names, convention, citations, test vectors), but it does not disclose other behavioral traits such as error handling, authentication needs, or limiting behavior beyond the read-only nature.
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 a short single sentence with no wasted words, but it is a sentence fragment rather than a full grammatical sentence. The key action verb is missing, and the most important information ('for one formula') is placed at the end, making it less immediately scannable than it could be.
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 the lack of an output schema, the description's list of returned contents is helpful. However, it omits the core action the tool performs and provides no connection to sibling tools or guidance on input selection. An agent can infer the basic operation from the title, but the description is not complete enough on its own for confident invocation.
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 input schema has one parameter with 0% description coverage, so the description must compensate. It only says 'for one formula' and does not explain how to specify the formula, what the enum values represent, or how to select among them. The schema's enum names are self-descriptive, but the description adds little beyond what the schema already provides.
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 conveys that the tool provides details for a single formula, including input schema, output names, convention, citations, and test vectors. The title 'Describe a formula' supplies a clear verb and resource, and the phrase 'one formula' distinguishes it from listing all formulas, though not from computing or citing formulas explicitly.
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?
There is no guidance on when to use this tool versus siblings like canon_compute, canon_list_formulas, or canon_cite. The description does not mention use cases, exclusions, or alternatives, leaving the agent to infer when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Map a ticker (AAPL, BRK.B), a CIK, or a company name to one issuer id with every ticker and exchange, plus EDGAR filing locations. Use before joining prices, filings and news so identifiers line up; source is the SEC public ticker file.
| Name | Required | Description | Default |
|---|---|---|---|
| q | Yes | ||
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint, so the description only needs to add context. It adds the SEC public ticker file as the source and specifies the output scope, which is useful behavioral context beyond what annotations provide.
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 action and accepted input forms, with no filler. The second sentence earns its place by explaining when to call the tool and identifying the data source.
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 resolver with no output schema, the description covers accepted inputs, output content, source, and usage timing. Adding explicit no-match or ambiguity behavior would improve it, but that is a minor gap.
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 has no parameter descriptions, but the description compensates with concrete examples for q: AAPL, BRK.B, CIK, or company name. The optional limit parameter is not described, though its name and numeric constraints make its effect inferable.
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 uses a specific verb, 'Map', and names the exact inputs and outputs: ticker, CIK, or company name to one issuer id with every ticker/exchange and EDGAR filing locations. This makes the tool clearly distinct from sibling tools like canon_search or canon_batch.
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?
'Use before joining prices, filings and news so identifiers line up' gives concrete guidance on when to invoke this tool. It does not explicitly state exclusions or name alternatives, so it misses the top criterion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full definition and notes for one entry, by site and id (ids come from canon_search).
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Entry id or slug, e.g. "modified-duration" | |
| site | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint, so safety is covered. The description adds that the operation returns the full definition and notes, which is useful, but it does not detail return shape, missing-entry behavior, or site-specific quirks.
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 sentence with no filler. The resource, lookup keys, and input provenance are all front-loaded.
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 two-parameter read-only lookup, the description is largely complete: it names the inputs, identifies the output scope, and points to the search tool for id discovery. Minor gaps remain around exact response contents and error conditions.
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 50%; id is documented with an example, while site relies on its enum. The description adds the important note that ids originate from canon_search, but site semantics are still left almost entirely to the schema enum.
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 ('get'), a specific resource ('one entry'), and the scope ('full definition and notes'). It also distinguishes itself from canon_search by noting that ids come from search, and the singular 'one entry' separates it from batch or list siblings.
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 phrase 'ids come from canon_search' gives clear context for when this tool is appropriate: after search results have produced a site and id. It doesn't explicitly name alternatives or exclusions, so it isn't a perfect 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The deterministic formula registry: id, site, summary, input names and citations. Call canon_describe_formula for a schema.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already signals safety; the description adds deterministic behavior and the exact fields the list will contain, which is useful context. There is no contradiction and no hidden mutation risk.
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 short, purposeful sentences with no filler. The core content is front-loaded and the pointer to canon_describe_formula is placed second, making the definition easy to scan.
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 parameterless read-only list, the description provides enough orientation: what is returned, that it is deterministic, and where to go for schema details. No important calling context 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?
The tool has no parameters and the schema is an empty object, so there is no parameter semantics to explain. The 0-parameter case is the baseline 4, and the description needs no additional parameter detail.
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 resource (deterministic formula registry) and what it returns: id, site, summary, input names, and citations. It also distinguishes itself from canon_describe_formula by explicitly pointing to that sibling for schema details.
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?
Names the relevant alternative canon_describe_formula and the exact condition for choosing it ('for a schema'). The first sentence establishes the list use case, so an agent knows when to call this tool rather than its sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search defined terms and reference tables across all canon sites (options, fixed income, quants, PE, M&A, private credit, venture, hedge funds). Returns ranked hits with a citable url and the JSON source.
| Name | Required | Description | Default |
|---|---|---|---|
| q | Yes | Search phrase, e.g. "modified duration" or "option pool shuffle" | |
| site | No | Restrict to one site | |
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the description does not need to discuss mutation or scope. It adds useful output behavior by stating that results are 'ranked hits' with 'a citable url and the JSON source', which is valuable since there is no output schema.
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 carry a precise scope, a domain list, and the return shape with no filler. Every clause adds information an agent needs, and the description is front-loaded with the action and resource.
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 search tool with clear parameters and no complex side effects, the description covers the important context: what is searched, where, and what is returned. It could add explicit alternative-tool routing or edge-case behavior like empty results, but those are not critical for correct invocation.
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 67%, with q and site described; limit lacks a semantic description. The description adds meaning by clarifying that omitting site searches 'all canon sites', but it does not explain the limit parameter or any ranking details beyond the schema. This is adequate but not deeply enriched.
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 uses a specific verb and resource: 'Search defined terms and reference tables across all canon sites', which makes the tool's purpose immediately clear. It also lists the domains covered, distinguishing it from more specific sibling tools like canon_get_entry or canon_sites, though it does not explicitly name those alternatives.
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 when to use the tool: when a broad search across canon sites is needed, as opposed to retrieving a specific entry. However, it does not explicitly state when not to use it or which sibling tools to prefer for narrower lookups, so the guidance is mostly implied rather than direct.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The sites in the .wiki finance canon with live entry counts and review dates.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as read-only and open-world, covering the safety profile. The description adds that entry counts are live and that review dates are included, but it does not disclose return format, ordering, pagination, or other runtime behavior. There is no contradiction with the annotations.
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 a single sentence that conveys the resource and the returned information without unnecessary detail. It is front-loaded with the key subject and contains no filler.
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 zero-parameter listing tool with no output schema, the description adequately conveys what will be returned: sites with live entry counts and review dates. It lacks explicit guidance about choosing among sibling tools, but for such a simple read-only list operation this is a minor gap.
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 input schema declares zero parameters, and the schema description coverage is 100% trivially. With no parameters to document, the description does not need to add parameter semantics, so the baseline of 4 applies.
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 precisely identifies the resource: sites in the .wiki finance canon. It also states the key returned information: live entry counts and review dates. It is distinct from siblings like canon_get_entry or canon_search, which clearly target different resources or operations.
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 intended use is implied by the title and description: the agent should call this when it needs an overview or enumeration of canon sites. However, it does not explicitly state when to use this tool instead of a sibling, nor does it mention any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reference 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 |
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.
Recompute a receipt from its inputs and confirm its id and outputs. Use it to check a number another agent or document claims came from this service.
| Name | Required | Description | Default |
|---|---|---|---|
| receipt | Yes | The receipt object returned by canon_compute |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark it read-only and idempotent, so the description's added behavior — recomputing from inputs and confirming id/outputs — is meaningful and consistent. It gives the agent a concrete sense of what the tool does beyond the safe-operation hints, without contradicting them.
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 short sentences, with the core behavior front-loaded and no filler. The purpose and the intended usage are each stated in one efficient sentence.
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 one-parameter, read-only verification tool with full schema coverage, the description covers the invocation reason and core behavior. The main gap is not spelling out the return value on success or failure, but this is relatively minor given the simple, annotation-safe context.
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 input schema fully describes the only parameter, the receipt object returned by canon_compute. The description adds only a minor clue that the receipt contains the inputs needed for recomputation, which does not materially go beyond schema coverage.
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 action — recompute a receipt and confirm its id and outputs — and clarifies it is for checking values claimed to have come from the service. It is clear, though it does not explicitly differentiate from canon_compute or other siblings by name.
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 gives an explicit use case: checking a number another agent or document claims came from this service. It does not state when not to use it or name alternative tools, but the context is clear enough for selection.
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. Dates show when Glama detected each change.
canon_batchcanon_changescanon_citecanon_computecanon_contractcanon_describe_formulacanon_entitycanon_get_entrycanon_list_formulascanon_searchcanon_sitescanon_thresholdscanon_verifyClaiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such as io.github.acme/server also needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
Deterministic signed verification of numeric & financial claims for AI agents & spreadsheets.
90+ pure finance calculators: loans, investing, bonds, options, tax. Stateless, stores nothing.
Crypto price-event settlement verdicts and US building-permit data, paid per call in USDC.
Evidence-backed crypto due diligence with sources, freshness, and a runtime receipt on every call.
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.
