stillos-notary-mcp

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

No annotations provided, so description carries full burden. Discloses signing (Ed25519, hash-chained), never returns forced guess, lists supported resolvers. Does not detail error conditions or rate limits, but overall transparent.

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

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

Concise, front-loaded with key action and result. Every sentence adds value with no redundancy.

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

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

Describes return values (CONFIRMED, REFUTED, ERROR) and cryptographic signing. No output schema, but covers core behavior. Open resolver additionalProperties lack guidance, but overall sufficient for an AI agent to use.

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

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

Schema coverage is 100%, but description adds context like 'public reputation ledger' for agent, clarifies claim format, and mentions resolver types including 'multi-exchange price consensus' not in schema. Open additionalProperties in resolver not explained.

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

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

Clearly states it submits a claim and returns a signed verdict against external ground truth, with specific outcomes. Distinct from sibling tools (distress_score, file_dispute, screen_entity, verify_receipt) which handle different functions.

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

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

Mentions free tier with no account needed, guiding when to use. Lacks explicit when-not-to-use or alternatives, but sibling tools are clearly different in purpose.

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

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

With no annotations, description fully carries burden: details computation source, performance stats, signing, payment model, and failure mode. Excellent disclosure.

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

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

Front-loaded with purpose, then details. Slightly verbose with performance stats, but all sentences add value. Could be trimmed slightly without loss.

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

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

No output schema, but description explains return behavior with and without payment. Inferred successful return is a signed score. Adequate for a paid API tool.

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

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

Schema coverage is 100% with descriptions for both parameters; description adds no significant new information beyond schema, only minor context (e.g., agent on public ledger).

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

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

Clearly states it computes a validated Altman Z-score for a single equity ticker, with specific metrics. Distinct from sibling tools (claim_verdict, file_dispute, screen_entity, verify_receipt).

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

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

Mentions paid nature and payment requirement, but does not explicitly contrast with siblings or provide alternative scenarios. However, the purpose is clear enough for an agent to decide when to use.

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

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

No annotations provided, so the description fully describes behavioral traits: the dispute triggers an independent re-run, overturns verdict on uphold, triggers slashable payout, and is paid (no free tier). It also explains behavior without payment. Rate limits or auth are not covered, but the description is thorough.

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

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

The description is concise and well-structured. It front-loads the purpose, then explains behavior and consequences in efficient sentences, with no redundant or irrelevant information.

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

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

For a tool with 2 parameters and no output schema, the description is quite complete. It explains the dispute process, side effects (overturning verdict, slashing payout), payment requirement, and behavior without payment. Slightly more could be said about return values, but it suffices.

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

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

Schema descriptions cover both parameters (agent and receipt_hash) clearly. The tool description adds context about the dispute process and payment but does not add new meaning to the parameters beyond what the schema already provides. With 100% schema coverage, baseline 3 is appropriate.

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

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

The description clearly states the tool files a bonded dispute against a verdict receipt, explains the process (re-resolution, not re-vote), and distinguishes from siblings like claim_verdict by its specific action and consequences.

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

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

The description tells when to use the tool (to dispute a verdict receipt) but does not explicitly state when not to use it or compare with alternatives like claim_verdict. Usage context is implied but not clarified.

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

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

With no annotations, the description carries full burden. It discloses key behavioral traits: payment requirement, x402 protocol, Ed25519-signed results with a freshness timestamp, and that unpaid calls return a payment requirement. It does not describe rate limits or error handling, but covers the critical payment and signature aspects well.

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

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

Two sentences with zero wasted words. The first sentence states purpose and key features (OFAC, freshness, signed). The second explains the payment model. Efficient and front-loaded.

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

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

The description covers the payment requirement and what happens without payment, but does not describe the output format of a verdict (e.g., a match/mismatch or the structure of the signed result). Since there is no output schema, a brief output description would improve completeness.

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

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

Schema description coverage is 100% (both parameters have descriptions). The tool description does not add parameter-specific details beyond the schema; it adds overall context (payment, signature) but not parameter semantics. Baseline is 3.

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

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

The description clearly states the tool's purpose: 'OFAC SDN sanctions name screen: matches a legal name against the OFAC Specially Designated Nationals list'. It specifies the verb 'screen' and the resource 'legal name against OFAC SDN list', and the mention of payment and signature distinguishes it from siblings like claim_verdict or file_dispute.

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

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

The description provides clear usage context: it is a paid tool ($0.001 USDC via x402) with no free tier, and explains that an unpaid call returns the payment requirement. It does not explicitly list when not to use it or compare to alternatives, but the sibling tools are distinct enough that this is not a major gap.

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

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

No annotations provided, but description fully discloses behavioral traits: read-only, free, no auth, and the two-step verification process (hash chain integrity and Ed25519 signature).

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

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

Two concise sentences: first explains function, second adds behavioral context. No wasted words.

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

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

For a simple single-parameter tool with no output schema, the description covers purpose, behavior, and references sibling tools in the parameter description. Complete.

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

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

Schema coverage is 100% and the description adds no extra meaning beyond what the schema already provides ('by its hash' versus schema's 'the receipt_hash').

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

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

Clear verb 'verifies' and specific resource 'StillOS notary receipt by its hash'. Distinguishes itself from siblings like claim_verdict by stating 'independently verifies'.

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

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

States 'Read-only, free, no auth' providing clear context for safe, cost-free usage. No explicit when-not or alternatives, but the context is sufficient.

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