numguard
Server Quality Checklist
Latest release: v0.1.0
- Disambiguation3/5
Tools are generally distinct in purpose, but several share the 'verify_' prefix and target overlapping concepts (e.g., verify_backtest vs verify_backtest_series, verify_receipt vs scan_for_receipts). The detailed descriptions and the triage tool mitigate confusion, but agents may still hesitate when selecting among the many verification-related options.
Naming Consistency2/5Naming follows no single pattern: most tools use verb_noun (e.g., verify_backtest, audit_leaderboard), but some are bare nouns (balance, triage, why, pricing) or noun_noun (receipt_spec, commitment_status). The mix of verbs (verify, audit, check, reconcile, open, report, anchor, attest) is broad and inconsistent, making it harder to guess tool names without reading descriptions.
Tool Count2/534 tools is excessive for most MCP servers, even one with a broad mandate. Several tools (why, pricing, receipt_spec) are informational and could be consolidated or omitted. The sheer number risks overwhelming agents and increases the cost of selection, even with triage assistance.
Completeness4/5The tool surface covers the stated domain thoroughly: backtest verification, receipt lifecycle (issue, verify, scan, anchor), commitment and precommitment tracking, on-chain attestation, and agent-level audits. Minor gaps exist (e.g., no explicit tool to revoke a receipt or update a commitment), but these are rarely required and do not create dead ends.
Average 4.1/5 across 34 of 34 tools scored. Lowest: 2.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 122 commits in the last 12 weeks
- Last stable release on
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
This repository includes a glama.json configuration file.
This server has been verified by its author.
Add related servers to improve discoverability.
How to sync the server with GitHub?
Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.
To manually sync the server, click the "Sync Server" button in the MCP server admin interface.
How is the quality score calculated?
The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).
Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.
Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).
Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.
Tool Scores
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations indicate a safe read-only, idempotent operation, but the description adds almost no behavioral detail. It fails to disclose what the tool returns, whether it produces an explanation, proof, or comparison, or what side effects (if any) occur. The line about 'what numguard does' is too abstract to inform an agent about invocation behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only one sentence and has no structural waste, but it achieves brevity at the cost of clarity. It is under-specified rather than genuinely concise because the sentence fails to convey actionable meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the simplicity (0 params, read-only annotations), the description is not complete enough for an agent to know what invoking this tool accomplishes. No output schema exists, so the description should at least clarify the return value or purpose, but it does not.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema already fully covers parameter semantics. The baseline of 4 applies because there is nothing for the description to add regarding parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description is cryptic: 'What numguard does that computing the number yourself, or a lesser checker, does not.' It never states a concrete action like 'returns' or 'explains,' nor does it specify what resource or result is involved. It distinguishes numguard from alternatives but does not define what the 'why' tool actually does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool versus alternatives. The description implies a unique value proposition relative to 'computing the number yourself' or 'a lesser checker,' but it does not name sibling tools, prerequisites, or concrete use cases. An agent has no basis to choose this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral traits beyond the annotations, which already declare readOnlyHint, idempotentHint, and destructiveHint false. No additional context about rate limits, authentication, or side effects is provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that directly conveys the tool's purpose without any filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple nature of the tool, the presence of an output schema, and annotations indicating a safe read-only operation, the description is largely complete. It could slightly benefit from an explicit verb, but the overall context is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents the single parameter 'api_key' with a description. The tool description adds nothing about parameters, but with 100% schema coverage, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states what the tool provides: remaining free calls and prepaid credit balance. It identifies a specific resource and differentiates from the sibling verification/receipt tools, though it lacks an explicit verb like 'check' or 'get'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given regarding when to use this tool versus alternatives. The description simply states what the balance is, without mentioning any context for use or excluding other scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description says 'Open a commitment', which implies a state change, but annotations declare readOnlyHint: true. This is a contradiction. The description does add useful behavioral details (O(1) folding, no raw storage, honesty check), but the contradiction forces a score of 1.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the core purpose, and each sentence adds value—purpose, resource characteristics, and an important caveat. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains the return value (commitment_id), the follow-up tool (report_returns), and resource behavior (constant memory, no background compute). It lacks error conditions or authentication details, but those are covered by annotations and schema. The readOnly contradiction slightly detracts, but completeness itself is strong.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds minimal extra meaning beyond the schema; it mentions claimed_sr as the promise but doesn't provide additional context for parameters like api_key or periods_per_year.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool opens a commitment tracked over time and returns a commitment_id. It specifies the resource (commitment) and the action (open), but doesn't differentiate from sibling open_precommitment, so not a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by explaining the flow: open a commitment, then report returns with report_returns. However, it doesn't explicitly state when to use this tool versus alternatives like open_precommitment, so it's implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description says 'Write a numguard verification' which contradicts the annotation readOnlyHint=true, as writing an attestation is a state-changing operation. This is a serious inconsistency and violates the annotation contract. The description also fails to disclose other behavioral aspects like gas costs or whether the attestation is immediately visible.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description front-loads the core action but includes excessive marketing language like 'Reputation as a real-world asset, industry-standard, no token' that adds little operational value. It is somewhat verbose for the amount of practical information conveyed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (creating an on-chain attestation) and lack of output schema, the description explains the purpose and benefits well but does not cover return values, failure modes, or prerequisite conditions such as needing a funded wallet. It is adequate for basic understanding but leaves several operational gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers all parameters with descriptions, including the nested receipt object and optional recipient. The description adds minimal extra meaning, mainly reinforcing that only valid receipts are attested, which is already implied by 'valid vcr/1 receipt'. With 100% schema coverage, a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool writes a numguard verification as an EAS attestation on Base, specifying the action (write), resource (attestation), and context (Ethereum Attestation Service). It distinguishes this from siblings like check_attestation and issue_receipt by emphasizing the on-chain composable credential aspect.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool: to create a queryable, composable on-chain credential that protocols can use for gating or allocation. It does not explicitly mention alternatives or exclusions, but the use case is well implied through the description of the beneficiary protocols.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description describes an on-chain write operation that costs gas and creates a persistent attestation, but the annotations mark the tool with readOnlyHint=true. This directly contradicts the described side effects. Per the rubric, any contradiction between description and annotations forces a score of 1 and an annotation_contradiction flag.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core action and then explains the purpose, constraints, and non-token nature. It uses some marketing-style flourishes like 'reputation as a real-world asset' and em-dashes, which slightly reduce conciseness, but it is still tight enough for a complex tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the main purpose, validity constraint, immutability, public-checkability, and gas cost. However, it does not explain what the tool returns, how invalid receipts are handled, or how to verify the resulting attestation later. The annotation contradiction also undermines the tool's side-effect clarity, and the lack of an output schema increases the need for more complete behavioral context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers both parameters with descriptions, so 100% coverage is present. The description adds that only valid receipts are anchored, but this mostly mirrors the schema's 'valid vcr/1 receipt' phrasing. It does not add deeper parameter-level semantics like format, validation rules, or examples, so the baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description states a specific verb and resource: 'Anchor a signed receipt's digest on Base' and clarifies the outcome as an immutable, timestamped, publicly-checkable on-chain proof. It also distinguishes from siblings by emphasizing anchoring an existing valid receipt rather than verifying, issuing, or backtesting.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when to use the tool: when you have a valid receipt and want a portable, on-chain credential. It also includes important caveats such as 'Only VALID receipts are anchored' and 'you pay the gas once'. It does not explicitly name alternative tools or state when not to use it, so it misses a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description says 'Append' and 'timeline can't be rewritten', indicating a write operation, while annotations declare readOnlyHint=true (and idempotentHint=true). This is a direct contradiction. Although the description adds useful context about hash-chaining and non-storage, the contradiction overrides any positive value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, ~30 words, front-loaded with the core action and outcome. No fluff or repetition. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers core behavior (append, hash-chaining, verdict) but lacks detail on the structure of the returned verdict, especially since there is no output schema. The annotation contradiction also leaves side effects unclear. It is adequate but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents each parameter. The description adds a small insight that raw returns aren't stored, which helps understand the new_returns parameter's fate, but it doesn't add further parameter-specific meaning. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Append') and resource ('pre-commitment's tamper-evident chain') and clearly states the outcome ('get the current verdict'). This distinguishes it from siblings like report_returns by emphasizing the pre-commitment context and hash-chaining.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for appending returns to a pre-commitment and notes key behavioral aspects (hash-chained timeline, raw returns not stored). It does not explicitly name alternatives or exclusions, but the context is clear enough to guide tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds that this is a statistical calculation (Deflated Sharpe Ratio) and explains the multiple-testing context, but it does not disclose additional behavioral details like output shape or edge cases.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences and reasonably concise. The opening rhetorical question is not strictly functional but helps frame the tool's purpose, and the rest is directly useful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the rich schema (100% parameter descriptions) and existing output schema, the description sufficiently explains the tool's method, inputs, and audience. It could be stronger by referencing alternatives or assumptions, but it is not incomplete for a competent agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and every parameter already has a meaningful description. The tool description repeats and lightly reframes sr, T, n_trials, and skew/kurt, but adds little beyond the schema, especially for api_key.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as computing a Deflated Sharpe Ratio to check whether an observed Sharpe is genuine or a product of multiple testing. It specifies the resource (backtest) and the core method, but it does not explicitly distinguish this from sibling tools like verify_backtest_series.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: it is intended for agent traders verifying backtest data before trusting or publishing it. It implies when to use the tool, but it does not explicitly state when not to use it or name alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds valuable behavioral context: it is a single snapshot and flash-loanable for one block, warns about the 'lie surface' of price oracles, and notes 'Keyless on Base' (no auth needed). These go beyond the annotations and help the agent understand the result's fragility and access requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively concise (three sentences) and front-loaded with the core formula. The information about snapshot, USD avoidance, and keyless access is useful, but the 'lie surface' editorializing is a bit colorful and not strictly necessary. Overall it earns its place but could be slightly tighter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 7-parameter schema with full coverage and strong annotations, the description completes the picture by explaining the unit system, snapshot nature, and keyless access. It does not explicitly describe the return format, but the formula and 'the verdict says so' give enough context. There is no output schema, so the description partly compensates. A small gap is the lack of an explicit statement of what the return value represents (e.g., a ratio number).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides descriptions for all 7 parameters, giving 100% coverage. The description adds the formula connecting reserve_asset, reserve_holders, and token supply, which clarifies how the parameters relate. However, it does not add per-parameter detail beyond the schema, so the description adds moderate value only. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('re-derive') and resource ('backing ratio') with an explicit formula. It distinguishes from sibling verify tools by focusing on token backing in asset units, not USD. The phrase 'deliberately NOT converted to USD' adds precision and sets it apart from other verification tasks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool (to check backing ratio in units, on Base, keyless) but does not explicitly state alternatives or exclusions. It mentions the snapshot limitation and lack of USD conversion, which helps set expectations, but it does not reference sibling tools or say 'when not to use' beyond the USD caveat. This is adequate but not fully explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, which establishes the safety profile. The description adds behavioral insight by specifying the exact binomial test and the classes of artifacts considered (longer/first/same-family), which is valuable beyond the annotations. No contradiction present.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exceptionally concise: two sentences that immediately frame the problem and provide usage instructions. There is no wasted text, and the exact binomial method is stated in a compact phrase. It is front-loaded with the core question, making it easy for an agent to understand.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple statistical tool with full schema descriptions and an output schema, the description covers the input requirements and method. It does not explain edge cases or prerequisites, but the output schema handles return values. The only minor gap is not elaborating on the 'longer/first/same-family' artifacts, but this is not critical for usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions cover all 4 parameters with 100% coverage (wins, n, p0, api_key). The description rephrases wins as 'count of verdicts the tested side won' and n as 'total,' which adds context but no new constraints or format details. Baseline 3 is appropriate when schema documents parameters well.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly conveys the tool's purpose: to determine whether an LLM-judge/metric preference is real or an artifact (longer/first/same-family) using an exact binomial test. The verb 'verify' is implied via the tool name and title, and the resource is specifically judge bias, distinguishing it from sibling verify_* tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is implied: pass wins and total count when you want to test a preference against chance. However, it does not explicitly state when to use this tool versus alternatives among the many verify_* siblings, nor does it mention exclusions or prerequisites. The instructions are present but not contrasted with other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint; description adds useful context beyond that: free of charge, no api_key, no gas, on-chain via EAS, and specifies the returned fields (attester, recipient, verdict, revoked status). No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences and front-loaded with the primary action. The final sentence ('This is how any protocol or agent trusts...') is slightly promotional but adds usage context. Overall concise with minimal waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with one parameter and no output schema, the description covers what the tool does, what it returns, and the network/cost context. It lacks error-handling details, but that is not essential given low complexity. Good enough to select and invoke.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the single parameter 'uid' is already well documented. The description does not add significant extra meaning for the parameter beyond implying it references a numguard attestation, which is aligned with the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the specific action ('Look up a numguard verification credential on-chain via EAS on Base'), identifies the resource and method, and distinguishes itself from sibling verify_* tools by focusing on EAS attestation lookup. The value proposition is explicit, making the tool's purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use: 'This is how any protocol or agent trusts a numguard track record.' However, it does not mention alternatives or exclusions, so it lacks explicit guidance on when not to use or which sibling tool to prefer.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover read-only and idempotent safety, so the bar is lower. The description adds valuable transparent behavior: it's free, and a leaked commitment ID alone cannot be used without the originating api_key. This is security-relevant context that goes beyond the structured annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the purpose and followed by a necessary caveat. No fluff or repetition—every word contributes.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only status tool with no output schema, the description adequately covers return values (the possible verdicts), the free nature, and auth requirements. It could add a tiny bit about response format, but the verdict list is sufficient for a basic status check.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, providing baseline 3. The description adds relational meaning by specifying that the api_key must be the one that opened the commitment, and indirectly links commitment_id to that key. It clarifies a contextual constraint not obvious from the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as returning a current verdict (HELD/DECAYED/BROKEN/PENDING) for a user's tracked commitment, distinguishing it from sibling verify/open tools by emphasizing 'YOUR' and the api_key requirement. It lacks an explicit action verb like 'retrieve' or 'get', but the meaning is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides specific context: it's for your own tracked commitment and requires the api_key that opened it. It doesn't explicitly name alternatives or exclusions, but the context makes it clear this is for checking one's own commitment status, not for other verification tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so safety is covered. The description adds that the entry is 'immutable' and includes the 'current chain head', giving useful context about data persistence and response composition without contradicting annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence packed with information: free/public status, immutability, field list, and chain head inclusion. No filler words, and the structure front-loads the most salient attribute (FREE, public).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description compensates by enumerating the returned fields and clarifying that the registration entry is immutable. It adequately covers the response content for a simple read tool, though it does not mention error handling or response format details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter 'pid' has a schema description ('The pid from open_precommitment') covering 100% of the schema. The description does not add any parameter-specific details, so the schema carries the burden, yielding the baseline score for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as retrieving a precommitment's immutable registration entry, listing the specific fields (strategy id, claimed Sharpe, horizon, signed digest, created_at, on-chain anchor) plus the current chain head. This distinguishes it from siblings like verify_backtest or open_precommitment, as it's a direct read of the public registry entry.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description notes 'FREE, public', indicating this is the open and costless way to access the registration entry, which implies when to use it. It does not explicitly name alternatives or exclusions, but the context makes it clear this is for reading the registry entry, not for verification or opening commitments.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint, idempotentHint, destructiveHint), the description adds critical behavioral details: 'O(1) per return' and 'the raw returns are not stored.' This helps the agent understand side effects and performance. It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences that front-load purpose, then provide essential behavioral context (O(1), not stored), then usage timing. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is sufficient for an agent to use the tool correctly: it explains what happens, what is returned conceptually (verdict), and when to call. It lacks an explanation of what HELD/DECAYED/BROKEN mean, but that is domain knowledge likely covered by other tools. No output schema exists, but the description names the verdict types.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 repeats the high-level meaning of 'new_returns' ('new live returns') and 'commitment' but adds no syntax or format details. The schema already handles this adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Fold new live returns into a commitment') and a specific outcome ('get the current HELD / DECAYED / BROKEN verdict'). This clearly distinguishes it from sibling tools like open_commitment (which creates) or commitment_status (which reads). The title annotation reinforces this.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
'Call it whenever you have new live data — daily, weekly, whenever' explicitly states when to use the tool. It mentions the trigger condition (new live data) but does not explicitly name alternatives or exclusions, which would merit a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description goes beyond by explaining exactly what the tool does behaviorally: recomputing the hash-chain, validating monotonic timestamps, and what it detects. It also adds cost/access constraints ('FREE, public', 'no api_key'), which is useful context beyond the structured annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, information-dense sentence. It front-loads with 'FREE, public' and then packs the core purpose, security guarantee, and access requirement without any filler or repetition. Every phrase earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no nested objects, no output schema), the description covers the essential context: what it computes, the guarantee it provides, and the public access model. The lack of an output schema is not a significant gap because the description implies an audit/verification result. Slightly more detail on the return value could push it to 5.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage for the single parameter (pid) is 100%, and its description is already adequate ('The pid from open_precommitment'). The tool description does not add further parameter-level detail, but since the schema carries the full burden, a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('recompute') and resource ('pre-commitment's report hash-chain') and defines the exact purpose: checking timestamp monotonicity to detect backfill, reorder, edit, or deletion. This distinguishes it from sibling verify_* tools, which audit other aspects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description establishes clear context for use: 'Anyone can audit that a track record's timeline was never rewritten, with no api_key.' It implies this tool is for public auditing, but does not explicitly mention when to use it instead of alternatives or when not to use it. The context is strong, but exclusions are absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so safety is covered. The description adds valuable behavioral context by explaining the statistical interpretation (real vs. below test-set resolution) and the specific outputs returned, which goes beyond the structured annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise, front-loaded sentences. The first sentence frames the decision, and the second gives direct input/output instructions. There is no filler or redundant elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, required inputs, and high-level outputs, while the output schema handles detailed return structure and annotations cover safety. It could explicitly state assumptions such as using the same test set or the statistical test employed, but for a read-only verification tool with strong schema coverage, it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with clear descriptions for every parameter: n as items per model, p1/p2 as accuracies in [0,1], and api_key as a metering key. The description's input guidance ('items-per-model n and the two accuracies') simply restates what the schema already provides, adding no new semantic detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a question that defines the exact purpose: determining whether an accuracy gap between two models is real or below test-set resolution. It names the required inputs (n, p1, p2) and the outputs (gap, significance, minimum detectable effect), and it clearly distinguishes this tool from sibling verify_* tools that target backtests, judges, or receipts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The question-format clearly frames when to use the tool: when you have two model accuracies and items-per-model counts and need to know if the gap is meaningful. It gives direct instructions for inputs, but it does not explicitly mention when not to use it or name alternative sibling tools, so it stops short of full guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds behavioral context beyond annotations by specifying that it applies a multiple-comparisons correction and expects a raw (uncorrected) p-value. It does not mention edge cases or return format, but the annotated safety profile plus the statistical behavior described is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, no filler, and front-loads the core purpose. Each sentence adds useful information: the first explains what the tool does, the second tells the user what inputs are needed. It is appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is low-complexity, with full schema coverage, a rich annotation set, and an output schema present. The description sufficiently explains the scenario and inputs, and the presence of output schema covers return-value expectations. It does not explain the statistical method (e.g., Bonferroni vs FDR), but that is likely not necessary for an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions already provide full coverage (100%) for all three parameters, including the meaning of p and n_tests. The description repeats the instruction to pass p and n_tests but does not add new semantic detail beyond what the schema already explains. This aligns with the baseline score of 3 for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states what the tool does: it corrects a 'we lead on subset/metric/checkpoint X' claim for the number of comparisons (look-elsewhere effect). It explicitly mentions passing raw p-value and number of tests, making the operation unambiguous. This distinguishes it from sibling verification tools by focusing specifically on subset/metric/checkpoint multiple-comparison correction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool: when you have a subset/metric/checkpoint claim and need to correct for multiple comparisons. It does not explicitly name alternatives or exclusions, but the scenario is well-defined, so an agent can infer when this tool is appropriate. No when-not-to-use guidance is given, preventing a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, and the description adds critical context beyond those: survivorship bias is not controlled, an agent can hide losing wallets, and the tool certifies each address's number rather than 'the best agent'. This is valuable behavioral disclosure that helps an agent set expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is about three sentences and front-loads the core action. The second and third sentences partly overlap in reinforcing the no-ranking point, but the caveat about survivorship is essential and non-redundant. Overall it is efficient and structured for quick understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With a moderate-complexity tool, rich annotations, and 100% schema coverage, the description adds important caveats (survivorship, no discovery/ranking) and states the return shape ('each verdict'). It is complete for an audit tool, though it does not detail potential errors or rate limits, which are not critical given the annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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's mention of 'explicit address list' reinforces the addresses parameter but adds no additional syntax or format details beyond what the schema already provides. The params remain well-documented by the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb+resource pair ('Run verify_agent across an EXPLICIT address list and return each verdict') that clearly states what the tool does. It also distinguishes itself from ranking/discovery tools by explicitly saying 'no discovery, no ranking implied' and 'never the best agent'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly communicates it is for auditing an explicit list of wallets rather than discovering or ranking agents, which differentiates it from siblings like audit_leaderboard or verify_agent. It implies when to use this tool—when you already have addresses—but does not explicitly name alternatives or state exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds behavioral context by explaining that results are interpreted as per-item solved sets and that the tool computes bootstrap-based confidence intervals (via n_boot), which goes 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary purpose in the first sentence, and contains no filler. Every clause adds value—input format, output, and the nuance of the 'results' parameter are all covered without waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity, the presence of a full output schema, and annotations that cover safety, the description is complete. It explains what the tool does, what input it expects, and what it returns. The agent can confidently invoke it without needing additional clarification.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all three parameters (n_boot, api_key, results) are already documented. The description reinforces the 'results' format ('list of item-ids or {item: score} dict') but does not add new semantic details beyond what the schema provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Audit a whole leaderboard from per-item results,' a specific verb ('audit') and resource ('leaderboard') that clearly differentiates this from sibling tools like verify_subset_win or verify_model_gap. It also states the concrete outputs—'rank confidence intervals + whether #1 is statistically real'—making the tool's purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly indicates the tool is for auditing a whole leaderboard, not for individual subset checks or gap verifications. It lacks an explicit when-not-to-use statement or named alternatives, but the context is clear enough that an agent can distinguish it from the sibling verification tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is known. The description adds value by explaining the output semantics (agreement and directional error trend) and clarifies that over-crediting indicates the length/self-preference failure mode, which is non-obvious behavior not in annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, immediately states the main purpose, and avoids redundancy with schema/annotations. Every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers what the tool does, what inputs to provide, and what output to expect (agreement and bias direction). Combined with a complete schema and output schema, the agent has enough to select and invoke correctly. No critical gaps are evident.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All three parameters have thorough schema descriptions, so the schema carries the semantic load. The description adds only a brief restatement that the booleans are aligned, but it does not provide new parameter-level detail beyond the schema's 'aligned 1:1' note.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb ('Check an LLM judge against ground truth') and identifies the required inputs (aligned booleans). It distinguishes from siblings by focusing on calibration against ground truth and explaining the over-crediting failure mode, which is unique among the sibling list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: use this when you have a labelled slice and want to compare judge verdicts to ground truth. However, it does not explicitly mention when not to use it or name alternative tools such as verify_judge_bias, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint, idempotentHint), the description discloses that it returns a signed immutable digest, that the timeline is hash-chained and tamper-evident, and honestly states the limit about self-reported values. This adds substantial behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is five sentences but each adds value: purpose, return type, follow-up tools, anchoring option, and honest limitations. It is somewhat dense but well-structured and front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Even without an output schema, the description communicates the return type (signed digest) and the overall workflow. It could specify the exact digest format or error behavior, but for a tool of this complexity, it provides sufficient context for correct invocation and follow-up.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides descriptions for all 6 parameters (100% coverage). The description mentions claimed_sr and horizon_periods in context but adds no new parameter-specific meaning beyond what the schema gives, matching the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool pre-registers a forward claim before outcomes are known, using the 'clinicaltrials.gov for backtests' analogy. It specifies the action (pre-register), resource (strategy's forward claim), and differentiates from related tools by emphasizing the pre-outcome timing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use it (before outcomes) and outlines the follow-up workflow (report_precommit, anchor_receipt). It does not explicitly exclude alternatives like open_commitment, but the pre/post distinction is implicit and sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds context that this is a specification/reference (not an operational verifier), clarifying it provides instructions rather than performing verification. This goes beyond the annotation basics 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that packs essential information: the standard name, scope (schema/algorithms/canonical form/how-to-verify), and purpose (issue and verify compliant receipts). No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters, no output schema, and strong annotations, the description fully covers what it is and what it offers: the complete standard reference for vcr/1. It provides enough context for an agent to select it appropriately alongside the many sibling verification tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, so the schema requires no description. The description adds value by explaining what the returned spec content covers, though it doesn't address specific parameters because none exist. Baseline of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool exposes the Verifiable-Claim-Receipt open standard (vcr/1), including schema, algorithms, canonical form, and verification guidance. This is a specific resource and distinctly separates it from sibling verification/issuance tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for learning or obtaining the spec, but it does not explicitly say when to use it versus alternatives like verify_receipt or issue_receipt. No 'when not to use' or alternative guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds significant behavioral context beyond the annotations: it discloses that the receipt is signed with Ed25519, recomputed server-side, tamper-evident, and verifiable with a public key. This goes beyond the readOnlyHint and idempotentHint annotations, providing the agent with important details about the tool's behavior and trust model. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is tightly written in two sentences, front-loading the core purpose ('Issue a portable, signed attestation'), then adding essential context (live track record, verifiability, tamper-evidence). Every sentence contributes value with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's role as a receipt issuer, the description explains what it does, how the output is protected, and how it can be verified. There is no output schema, but the description implies the return is a verifiable attestation. It does not explicitly state the exact return format or any edge cases (e.g., what happens if commitment_id is invalid), leaving minor room for ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers both parameters (api_key and commitment_id) with full descriptions, so schema coverage is 100%. The description does not add any parameter-specific semantics beyond what the schema already provides, justifying the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Issue') and resource ('attestation of your commitment's LIVE track record'), clearly distinguishing it from siblings like verify_receipt (which verifies) and issue_receipt (which may issue a different receipt). It also explains the portable, verifiable nature of the output, making the tool's purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: use this tool to issue a portable, signed attestation of a commitment's live track record. It also references verify_receipt as the way to verify the output, implying an alternative action. However, it does not explicitly state when NOT to use this tool or how it differs from sibling tools like issue_receipt or scan_for_receipts, so it falls short of full guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint and idempotentHint annotations, the description adds substantial context: it returns dry-run calldata, requires gas for broadcasting, encodes +1/-1 value, and links the receipt as proof. This gives the agent a clear mental model of the tool's side effects and outputs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is largely focused but includes promotional filler like 'FREE:', 'live on Base + 40 chains', and 'numguard joins the trustless-agents infra as a reputation provider'. These extra phrases do not aid tool selection and could be trimmed without losing essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With two well-described params and no output schema, the description covers the return value (args + calldata), the on-chain destination, the dry-run nature, and the value semantics. It is complete for a user to invoke correctly, though it omits edge-case handling like invalid receipts, which is acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters. The description adds context by calling the receipt a 'numguard vcr/1 receipt' and identifying agent_id as the 'subject the verdict is ABOUT', which clarifies the role of each parameter beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'build' and the resource 'ERC-8004 Reputation Registry giveFeedback call', with a specific outcome: return exact args and calldata. It distinguishes itself from the verify_* siblings by focusing on constructing on-chain feedback, not verification.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It implies when to use: when you have a numguard receipt/verdict and want to make it portable on-chain reputation. It also clarifies this is a dry-run builder and broadcasting is the caller's step, contrasting with tools that execute on-chain actions. However, it does not explicitly name an alternative tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds valuable behavioral context beyond annotations: it recomputes the verdict (never signs supplied results), uses Ed25519, and produces a receipt verifiable by anyone with the public key. This significantly exceeds the basic readOnly/idempotent hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three dense sentences with no filler. The first sentence immediately states the action and key differentiator, and each subsequent sentence adds meaningful context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema (not shown but present), so return values are covered. The description explains the core guarantee and self-contained nature well. Minor gap: could reference receipt verification or related tools like verify_receipt, but not required.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with detailed explanations for all three parameters. The description itself does not add parameter-specific meaning, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool verifies a claim server-side and issues a portable signed receipt, using specific verbs and resources. It distinguishes itself from verify_* siblings by focusing on the receipt issuance rather than just verification.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context that this tool is for obtaining a signed receipt after verification, and explains the key guarantee of recomputation. However, it does not explicitly name alternatives or state when-not-to-use scenarios, though the context is strong enough for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this as read-only, idempotent, and non-destructive. The description adds valuable behavioral context: it performs offline verification, requires no authentication, and checks the Ed25519 signature against the receipt's embedded public key. This goes beyond annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the core function, followed by the mechanism and a clear usage directive. Every sentence provides distinct value with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema), the description sufficiently covers what it does, how it works, and when to use it. It lacks explicit return-value formatting, but the purpose is clear enough for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the parameter description is adequate. The tool description adds meaningful extra detail about how the receipt is used (embedded public key, signature check) and clarifies the receipt format (vcr/1), enhancing understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool verifies any compliant claim receipt, specifies the method (structure + Ed25519 signature against embedded public key), and distinguishes itself from sibling tools by being issuer-agnostic, free, and offline. It also explains the exact use case: checking if a number an agent provided was actually verified.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use (before trusting a number from an agent) and highlights distinguishing factors (no api_key, no account, issuer-agnostic). However, it does not explicitly mention alternatives or when not to use this tool, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds substantial behavioral context beyond the annotations: it discloses refusal behavior (survives=None, reconstruction='unreliable') and specific triggers (donation/flash-loan attack, short history, APY outside sane band). It also mentions 'Keyless on Base,' revealing operational requirements. This goes well beyond the readOnly/idempotent hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core action, and every clause adds value: the derivation method, the 'no self-report' distinction, the refusal conditions, and the keyless operational factor. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity and lack of output schema, the description covers the main behavior, refusal modes, and operational context. It explains what happens in failure cases but does not specify the success output shape (e.g., what the derived APY looks like). The annotations and schema fill many gaps; the description is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% parameter description coverage (chain default, vault address, api_key). The description adds no additional parameter-specific meaning beyond the schema, so baseline 3 is appropriate. It does not elaborate on parameter formats or constraints not already in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: fetching price-per-share history from Deposit/Withdraw events and re-deriving realized APY. It distinguishes itself from siblings by focusing on vaults and on-chain derivation ('no self-report'). The verb 'RE-DERIVE' is specific and the resource (vault APY) is explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for verifying a vault's APY independently of self-reporting. It provides explicit conditions under which the tool refuses to sign, which guides when results may be unreliable. However, it does not explicitly mention alternatives or when to choose this over sibling tools, though the 'no self-report' phrasing suggests a contrast with self-reported data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, but the description adds meaningful behavioral context: it returns a machine-readable price list with specific credit conversion, free-tier size, and the wallet-native x402 rail. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose, and every phrase earns its place—credit conversion, free-tier size, decision usage, and payment rail. No fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and an output schema exists, the description covers the essential return content (prices, free tier, x402 rail) and the intended use-case timing. It is complete for an informational tool in this sibling context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the description carries no burden for parameter semantics. The baseline of 4 applies, and the description adds context about the purpose (decision-making before calls) that complements the empty input schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides a machine-readable price list, free-tier size, and payment rail, using specific verbs and resource types. It distinguishes itself from sibling verification/audit tools by focusing on pricing and payment-info lookup.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: use it 'before it calls' to decide based on pricing and free tier, and to determine the x402 rail when free tier is exhausted. It does not explicitly mention alternatives or exclusions, but the context is sufficient for a simple informational tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint, idempotentHint, destructiveHint false, and the description adds transparency about the statistical test (Mertens/Lo SE), the classification output (HELD/DECAYED/BROKEN), and the optional 'forward_check' receipt kind. This goes well 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is about 3 sentences, front-loaded with a question, and each sentence contributes: the core question, the inputs and outputs, and the receipt capability. Slightly verbose but not wasteful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With output schema present and annotations, the description covers the use case, the input contract, the decision categories, and the receipt aspect. It lacks explicit error handling or prerequisites, but overall it's sufficiently complete for a 4.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%. The description adds conceptual meaning to claimed_sr and realized_returns (the promised Sharpe vs live returns) and mentions periods_per_year implicitly through 'per-period'. It doesn't add syntax details but reinforces the purpose of the main parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('reconcile') and clearly identifies the resource: comparing a backtest's claimed Sharpe against live returns. It distinguishes from siblings like verify_backtest by focusing on live return consistency, not backtest verification. The metaphor 'accountability oracle' adds clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the exact input scenario: feed claimed per-period Sharpe and realized live returns. It implies the tool is for post-backtest accountability and is receipt-able, but doesn't explicitly state when not to use it or name alternatives. Clear context, no exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses offline verification, issuer-agnostic behavior, no API key requirement, and the exact return shape: {found, verified, unverified, all_valid, results}. It also covers the critical no-receipt case, adding value beyond the readOnlyHint and idempotentHint annotations by explaining what the read actually proves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three tight sentences front-load the purpose, then give the return structure and the no-receipt edge case. No filler; every sentence adds meaningful information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With one well-documented parameter and rich annotations, the description covers the output fields and the crucial interpretation of a zero-found result. Since there is no output schema, the description successfully fills that gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single 'message' parameter is already fully described in the input schema with 100% coverage, including accepted types (str/dict/list) and embedded receipts. The tool description reinforces the inbound-message semantics but 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.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'finds every vcr/1 receipt inside it and verifies each offline' with a specific verb-resource pair and scope ('inbound message'). It also distinguishes itself from the verify_* siblings by framing itself as the 'RECEIVER half' and noting it is 'FREE, no api_key'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear when-to-use context: 'When another agent hands you a message' and explains the no-receipt edge case. It does not explicitly name alternatives like verify_receipt for single-receipt verification, so it misses the 'when-not' guidance needed for a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint, idempotentHint, destructiveHint), the description adds rich behavioral context: how trades are fetched and matched, that prices derive from swaps (no oracle), that results are deflated, and that it returns a signed receipt digest and ERC-8004 shape. It also discloses the dependency on an Etherscan key and the error behavior without one.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, dense run-on sentence. While it packs valuable information, the 'THE WIRED PATH:' prefix and the stream-of-consciousness structure make it less concise and harder to parse than necessary. It could be broken into clearer, shorter sentences without loss of content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity and lack of an output schema, the description adequately covers inputs, process, outputs (verdict, receipt digest, ERC-8004 shape), prerequisites (Etherscan key), and error behavior. It is complete enough for an agent to invoke the tool correctly without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides 100% coverage with detailed parameter descriptions. The tool description goes further by explaining the algorithm (FIFO matching, deflation for arena size), which clarifies how parameters like arena_size and address are used semantically. This adds value beyond the schema, though it does not map each parameter individually.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's specific verb and resource: it fetches an on-chain agent's public trades, pairs them into swaps, applies FIFO matching to compute round-trip returns, re-derives Sharpe, deflates for arena field, and returns a verdict plus receipt digest and ERC-8004 shape. This distinguishes it from sibling verification tools by emphasizing a one-call, operator-independent fetch-and-compute pipeline.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear usage context: it's a one-call verification leveraging public data, and it explicitly notes the prerequisite of a free Etherscan key. It does not explicitly name alternative tools for exclusion, but the context implies it is the integrated on-chain verification path.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With annotations declaring readOnly, idempotent, and non-destructive, the description adds rich behavioral detail: it reconstructs P&L via a formula, binds to a data hash, composes a Deflated Sharpe, and catches mismatches. It also discloses limitations ('NOT that the data is the real market', 'NOT that positions weren't overfit') and clearly states it does not run strategy code.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long and uses all-caps headers, but every sentence earns its place, explaining the algorithm, the honest scope, and exclusions. It is front-loaded with the core idea. Slightly verbose but appropriate for a complex tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description thoroughly explains the verification logic and limitations, but it does not state the return value format or behavior on mismatch (e.g., what the tool returns when verification fails). Since there is no output schema, this is a notable gap for an agent to fully understand invocation results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3, but the description significantly enhances parameter meaning by providing the exact formula (r_t = pos_{t-1}·assetret_t − costs), explaining how positions and asset returns interact, and clarifying the roles of reported_sharpe, n_trials, and canonical_hash. This goes well beyond the schema's field-level descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool re-derives a Sharpe ratio from positions and asset returns, recomputes it from an explicit formula, and checks it against the claimed value. It distinguishes itself from siblings by emphasizing 'instead of trusting a reported Sharpe' and by honestly scoping what it proves vs. does not prove (data authenticity, overfitting).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: it is used when you want to verify a Sharpe claim from decisions-on-committed-data, and explicitly says it does not run strategy code or prove data is real market (suggesting canonical_hash for that). It does not name specific sibling tools but enough exclusions and scope to guide selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint/idempotentHint annotations, the description adds critical behavioral detail: it never signs a user-supplied verdict, the receipt is verifiable by anyone with only the public key, and it catches cross-call exfiltration and prompt-injection consequences. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the purpose, includes illustrative examples and a clear usage section, and every sentence adds value. It is longer than a single sentence but each clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists and the input schema fully documents parameters, the description sufficiently covers what the tool does, when to use it, and its security properties. It is complete for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description reinforces the purpose of the trace (action-trace, exfiltration examples) but doesn't add parameter-specific details beyond what the schema already provides for api_key and task.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific action: 'Recompute the BEHAVIOURAL-guard verdict over an agent's action-trace and hand back a portable, signed receipt (Ed25519)'. This clearly identifies the tool's function and distinguishes it from sibling verify tools by emphasizing the recomputation and signing behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes an explicit 'Use when' section: 'an agent needs to PROVE a run passed the behavioural guard (compliance, audit, handing verified work to another party)'. This provides clear context, but it doesn't name specific alternatives or state when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the tool 'Returns a combined verdict + the checks that flagged' and lists the specific analyses it performs. Annotations already indicate read-only, idempotent, and non-destructive behavior, but the description enriches this with detail about the checks and output format. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences long, each packed with useful information: the first distinguishes the tool, the second lists checks, and the third explains output and param usage. There is no fluff or redundancy, and the main purpose is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 7 parameters and an existing output schema, the description covers the essential behavioral contract: what checks are performed, what parameters enable what, and what the return value looks like. The existence of the output schema means detailed return fields need not be described. It also clearly positions the tool within the verify_* family, making it complete for agent selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description synthesizes the roles of optional parameters: 'Pass positions+asset_returns for the leakage check, turnover for cost, candidates (a matrix) for PBO.' While the schema descriptions already state this, the description adds value by grouping parameters and linking them to checks, aiding the agent in constructing a correct invocation. With 100% schema coverage, the baseline is 3; this extra synthesis earns a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Run the checks a Deflated-Sharpe pass STILL misses — on the actual returns series,' which names a specific verb, resource, and scope. It then enumerates concrete checks (same-bar look-ahead, HAC, regime dependence, etc.), clearly distinguishing it from sibling tools like verify_backtest.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit conditional guidance: 'Pass positions+asset_returns for the leakage check, turnover for cost, candidates (a matrix) for PBO.' It also implies the tool is for in-depth checks beyond a Deflated-Sharpe pass, giving context for when to use it. However, it does not explicitly name alternatives or state when not to use it, so it falls just short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (read-only, idempotent, non-destructive), the description discloses deterministic behavior and no LLM usage, and specifies the output format (call + one-line reflex). This adds valuable context for the agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Despite being longer, the description is front-loaded with 'THE FRONT DOOR' and every sentence adds value: examples, determinism note, and a direct usage directive. No filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a routing tool with one parameter and no output schema, the description fully explains what it does, when to use it, what input to provide, and what output to expect (the call and a reflex). Complete in context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3, but the description greatly enriches the intent parameter with concrete examples, clearly defining what constitutes a valid intent. This is highly actionable guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool routes the user to the exact check to run first, acting as a front door across the trust layer. It distinguishes itself from sibling verification tools by being the entry point for unknown intents, with specific examples of intents.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'When you don't know which tool, call this' and describes the scenarios (doing or asserting) with examples. This provides clear when-to-use guidance and implies alternatives are the specific check tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
GitHub Badge
Glama performs regular codebase and documentation scans to:
- Confirm that the MCP server is working as expected.
- Confirm that there are no obvious security issues.
- Evaluate tool definition quality.
Our badge communicates server capabilities, safety, and installation instructions.
Card Badge
Copy to your README.md:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/ipezygj/numguard'
If you have feedback or need assistance with the MCP directory API, please join our Discord server