arsenkin_request_hash_lookupCheck if an identical request already exists in the ledger before resubmitting after an unknown outcome, helping avoid duplicate submissions.
Look up whether an identical request is already in the ledger. Use before resubmitting after an unknown outcome. Cost: free.
| Name | Required | Description | Default |
|---|---|---|---|
| request_hashes | Yes |
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections.
v0.2.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, and closed-world behavior, so the safety profile is covered. The description adds genuinely non-structured context: the cost is free, which matters in a paid-API toolset, and that the check is against a persistent ledger. It does not discuss rate limits or return semantics, but an output schema exists to cover the latter.
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?
Three short sentences that are front-loaded with the core purpose, followed by the trigger condition and the cost note. Every sentence carries information an agent needs; there is no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Purpose, timing, and cost are covered, and the existing output schema handles return values. However, for a tool whose only parameter is completely undocumented, the missing link between 'request_hashes' and the submit response an agent must have previously received leaves a real gap in invocation readiness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description is silent on the sole parameter. It never explains what a request hash is, where an agent obtains one (presumably from a prior submit response), or that multiple hashes may be passed in one call. With one undocumented parameter, the description fails to compensate for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: look up whether an identical request is already in the ledger. The 'ledger' framing makes it naturally distinguishable from siblings like arsenkin_submit, arsenkin_get_result, and arsenkin_status without needing to name them explicitly. It stops short of 5 because no sibling is referenced by name to sharpen the boundary.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Use before resubmitting after an unknown outcome' gives a concrete, actionable trigger condition rather than vague context. It does not name an alternative tool or state a when-not case, so it falls short of the explicit routing that would earn a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.