Skip to main content
Glama

check_figure_free

Verify one stated company figure against its named SEC filing without an account and get a clear verdict on whether it matches, differs, or is contradicted.

Instructions

Check one stated figure against its SEC filing with no account; writes no receipt. Limited per address. A verdict compares the stated figure with the SEC filing it names and says nothing about whether the figure or the company is sound. Verdicts: matches_filing, first_filed_differently, contradicted, not_on_file, refused, absent_in_read.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
valueYesUS dollars (shares for diluted_shares)
memberNoWith concept segment_revenue: the XBRL member name as filed
periodNoA quarter or year to date; name period_end with it. Without it the figure is read as a fiscal year.
tickerYes
conceptYes
period_endNo
rounded_toNoThe precision the writer rounded to, for example 1e7
fiscal_yearNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.7/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden and does well: it discloses no-account use, no receipt written (read-only), an address-based rate limit, and explicitly scopes what a verdict does and does not claim ('says nothing about whether the figure or the company is sound'). The enumerated verdict values further clarify behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the core action and scope, then layers constraints and verdicts. The verdict enumeration is long but genuinely informative rather than filler, so every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For an 8-parameter, no-annotation tool with no output schema, the description usefully explains the return semantics through the verdict list and discloses the safety/rate-limit profile. The main remaining gap is how the numerous optional parameters interact.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 50%, so half the parameters (member, period, rounded_to, fiscal_year) depend on either schema text or description for meaning. The description says 'the SEC filing it names' but adds no detail on how ticker/concept/period/fiscal_year combine, so it only partially compensates for the coverage gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: 'Check one stated figure against its SEC filing.' The scope ('one stated figure') and the verdict-based nature are clear. It does not explicitly distinguish itself from the sibling check_claims, so sibling differentiation is left implicit.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives conditions via 'with no account', 'writes no receipt', and 'Limited per address', which imply when the tool is appropriate. However, it never states when to use this versus check_claims or the point_in_time siblings, leaving usage to inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.