Verified, citable world numbers right now, each with a public tick and SHA-256 fingerprint.
Scored across 3 tools
The three tools have entirely distinct purposes: hashing/comparing text, escalating an unhandled request, and fetching real-time world snapshots. There is no overlap an agent could misselect between.
All names use snake_case and are readable, but fingerprint_text and request_service follow a verb_noun pattern while world_now is more of a noun+adverb phrase, a minor deviation.
Three tools is on the lean side but each covers a clearly separate function, so none feels gratuitous. It sits at the low end of a well-scoped set rather than being under-provisioned.
Each tool is self-contained for its stated purpose (fingerprinting, escalation, world data), with no dead ends given the tools explicitly disclaim storage. The surface is small but covers the described intents adequately.
Use when the user wants to know whether two texts are exactly identical, or wants a fingerprint to compare a document against later. Returns the SHA-256 fingerprint of the exact text, and whether it matches an expected fingerprint if one is given. It does not store the text or prove when it was written.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | The exact text to fingerprint | |
| expected | No | Optional fingerprint (64 hex characters) to compare against |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, non-destructive, closed-world). The description goes beyond them by disclosing the return contents (SHA-256 fingerprint and match verdict) and two important limitations: it does not store the text and does not prove when it was written, which steers the agent away from misuse as a timestamping tool.
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 tight sentences with zero filler, ordered by importance: when to use, what it returns, and what it does not do. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although there is no output schema, the description fully explains the return values (fingerprint and match result) and the tool's boundaries. With both parameters documented and low tool complexity, an agent has everything needed to invoke it correctly.
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%, so the schema already documents both 'text' and 'expected' (including the 64-hex-character constraint). The description only restates that a match is returned when an expected fingerprint is supplied, adding marginal meaning over the schema; 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?
States a specific verb (fingerprint) and resource (a piece of text) and precisely what it returns: the SHA-256 fingerprint plus an optional match result. The function is unambiguous and easily distinguished from the unrelated siblings request_service and world_now.
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?
Front-loads the trigger condition clearly: 'Use when the user wants to know whether two texts are exactly identical, or wants a fingerprint to compare a document against later.' It also implicitly frames a when-not (proving timestamps/provenance). No alternative tool is named, but the siblings are not viable substitutes, so this is close to complete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use when the person wants something none of these tools can do and says yes to passing the request on. Records only the request text they agree to send (no name or contact). Ask before calling it.
| Name | Required | Description | Default |
|---|---|---|---|
| request | Yes | What they want, in a sentence, as they agreed to send it |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare a non-read-only, non-destructive, closed-world write, and the description adds meaningful context beyond that: only the request text is stored, no name or contact data, and user consent must be obtained first. It stops short of describing what happens after the request is recorded or any confirmation behavior.
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, front-loaded with the usage condition, then the privacy scope, then the consent gate. Nothing is redundant and every sentence carries actionable 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 single-parameter write tool with no output schema, the description covers trigger, consent, and data scope adequately. Only minor gaps remain, such as what the agent should do if the person says no or what happens after the request is recorded.
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 single parameter's description already says 'as they agreed to send it.' The description's phrasing mirrors that constraint rather than adding format, length, or fidelity details beyond the schema, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool records a request the person agrees to send, which is a specific verb+resource, and implicitly distinguishes it from siblings by framing it as the fallback when none of 'these tools' can fulfill the need. It is clear, though the purpose is conveyed through usage framing rather than a direct statement.
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?
Explicitly gives the trigger condition ('wants something none of these tools can do and says yes to passing the request on') and a prerequisite ('Ask before calling it'). The agent knows exactly when to invoke it and what consent gate must be cleared first.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use when the user asks what is happening in the world right now and wants numbers they can trust and cite: Bitcoin and crypto market, currency exchange rates, earthquakes in the past hour, space weather, where the International Space Station is, and more. Every snapshot carries its public tick number, time and SHA-256 fingerprint so anyone can check it later.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true and destructiveHint=false, so safety is covered. The description adds genuinely new behavioral context beyond them: every snapshot carries a public tick number, timestamp and SHA-256 fingerprint for later verification, which tells the agent the output is auditable and point-in-time rather than a live stream.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the usage trigger before the content list and the verification metadata. Every clause earns its place: the enumeration of domains sets expectations, and the fingerprint sentence explains a property an agent could not infer elsewhere.
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?
With no output schema and no parameters, the description carries the full burden and meets it: it names the data categories returned and the verification envelope (tick number, time, SHA-256), which is exactly what an agent needs to decide whether the numbers are citable. Nothing material is missing for a zero-arg, open-world read 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?
The tool takes zero parameters, which is the baseline-4 case per the rubric. The description correctly adds nothing about inputs because there are none to describe, and the schema is fully self-explanatory.
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 combination ('verified snapshot of the world right now') and enumerates the concrete data domains returned: Bitcoin/crypto, FX rates, earthquakes in the past hour, space weather, ISS location. An agent can tell instantly what this tool yields, and no sibling (fingerprint_text, request_service) competes for the same intent.
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?
Explicitly states the triggering condition: 'Use when the user asks what is happening in the world right now and wants numbers they can trust and cite.' That is a clear use context. It stops short of a 5 because it names no when-not condition or alternative, though the sibling tools are unrelated enough that none is needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
fingerprint_textrequest_serviceworld_nowFree: ed25519 hash timestamps, randomness tests, lottery data. Open falsification challenge.
Daily indexes of what people do, from public data. On-chain in Bitcoin, so nobody can edit them.
Attested risk scores for stablecoins, DeFi protocols and wallets, with receipts.
Ed25519-signed market open/close receipts for NYSE, NASDAQ, LSE, JPX, Euronext, HKEX, and SGX.
Add one secure layer between your agents and this server.