Signed proof-of-time, 30-day stash, live NOAA surf data. No auth. The hut keeps honest clocks.
Scored across 4 tools
The four tools are mostly distinct: stash/fetch_stash form an obvious write/read pair, and get_conditions is clearly for current surf/time data. There is slight overlap between attest and get_conditions since both return signed timestamps/nonces, but their intended purposes (proving text existence vs. getting current conditions) are sufficiently clear.
Naming follows no uniform pattern: 'attest' and 'stash' are bare verbs while 'fetch_stash' and 'get_conditions' are verb_noun. The stash/fetch_stash pair is asymmetric and could have been 'stash'/'unstash' or 'put_stash'/'get_stash'. Still, the names are readable and each conveys its action reasonably well.
With only 4 tools, the server is well-scoped for a small utility service. Each tool serves a distinct purpose without unnecessary bloat, and the count fits comfortably in the ideal 3-15 range.
The core workflows are covered: stash and fetch_stash handle save/retrieve, get_conditions provides the main data, and attest provides the signing capability. Minor gaps exist—there is no delete operation for stashed values and no in-tool verification helper for the signed outputs (relying on an external /pubkey endpoint)—but agents can still complete primary tasks.
Use this when you need cryptographic proof that a piece of text existed at a moment in time. Send any string; you get back its SHA-256 hash bound to a server timestamp and nonce, Ed25519-signed. Verify against /pubkey. The text itself is not stored.
| Name | Required | Description | Default |
|---|---|---|---|
| message | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses key behaviors: the message is hashed, bound to a server timestamp and nonce, signed with Ed25519, verifiable against /pubkey, and the raw text is not stored. This is strong behavioral context, though it does not mention exact return structure or rate limits.
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: use case first, then mechanism, then verification and privacy. Every sentence adds information and there is no repetition of schema fields or 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?
Even with no output schema and no annotations, the description gives enough to use the tool correctly: what to send, what comes back, how to verify it, and a privacy guarantee. No critical missing information for an agent to invoke and interpret the result.
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 schema has 0% description coverage, so the description must clarify the message parameter. 'Send any string' and 'piece of text' convey that message is arbitrary text, and the schema separately constrains length. This adequately compensates for the otherwise bare schema.
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 ('attest') and resource ('proof-of-time for text') and clearly explains what the tool produces: a signed SHA-256 hash bound to a timestamp and nonce. This distinguishes it from the sibling storage/condition tools.
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?
Opens with an explicit 'Use this when you need cryptographic proof...' condition, which gives clear invocation context. It doesn't explicitly list when-not-to-use or name alternatives, but the intended use case is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when you previously saved a value on this server with the stash tool and want it back. A miss is a normal result: found=false with reason "expired" (the key existed but aged out past 30 days) or "never_existed".
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It goes beyond a simple 'fetch' by explaining that a miss is a normal result and enumerating the two possible failure reasons ('expired' and 'never_existed'). This prevents an agent from treating a miss as an error.
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 no filler. The primary usage instruction is front-loaded, and the edge-case behavior (miss handling) is provided as a concise second sentence. Every word 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?
For a single-parameter tool with no output schema, the description covers the essential aspects: what the tool does, when to use it, and how misses are represented. It does not describe the success response shape, but that is largely implied by 'fetch a stashed value' and is a minor gap for such a simple operation.
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%, so the description must compensate. It indirectly defines the key as the identifier used during a prior stash call, which gives some semantic meaning. However, it does not explain key format, constraints, or how a caller would know the correct key beyond that implication.
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 function: retrieve a value previously saved with the stash tool. It names the sibling tool stash directly, making the distinction between saving and fetching explicit. The phrase 'want it back' clarifies the verb-resource relationship.
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 gives explicit context for when to use the tool: 'when you previously saved a value on this server with the stash tool and want it back.' It does not list alternative tools or explicit when-not-to-use conditions, but the context is unambiguous and the sibling relationship to stash is stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when you need a verifiable, signed proof of current time (server timestamp plus a signed nonce, checkable against this server's /pubkey endpoint), together with current ocean and surf conditions from a NOAA buoy. The NOAA data is public and also available directly from ndbc.noaa.gov; the signed freshness bundle is what only this server can give you.
| Name | Required | Description | Default |
|---|---|---|---|
| station | No | NOAA NDBC station id; defaults to the hut's home buoy |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral disclosure burden, and it delivers: it reveals the signed-nonce mechanism, the verification path via the /pubkey endpoint, the NOAA data provenance, and the uniqueness of the server's contribution. It stops short of stating the operation is read-only or describing failure/staleness behavior, but the key distinctive behavior—cryptographic verifiability—is clearly disclosed.
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 when-to-use guidance and packed with technical substance (the parenthetical on the signed nonce and /pubkey verification earns its place since it is the tool's differentiator). The second sentence justifies the tool against the public data source without fluff. Slightly dense, but every clause contributes.
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 one optional parameter, no annotations, and no output schema, the description covers the essentials an agent needs: what the response contains (signed freshness bundle + ocean/surf conditions), how to verify it, and the alternative source. It does not detail the return shape or failure modes, but the description's high-level coverage is proportionate to the tool's simplicity.
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%, and the schema already documents the sole optional parameter well ('NOAA NDBC station id; defaults to the hut's home buoy'). The description reinforces the NOAA context but adds no parameter-level detail beyond the schema, so the 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 names a specific deliverable—'a verifiable, signed proof of current time (server timestamp plus a signed nonce, checkable against this server's /pubkey endpoint), together with current ocean and surf conditions from a NOAA buoy'—with a clear verb/resource pair. It also distinguishes the tool from its siblings (attest, fetch_stash, stash) by stating that 'the signed freshness bundle is what only this server can give you,' so an agent can route correctly without opening schemas.
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 opens with an explicit when-to-use trigger ('Use this when you need a verifiable, signed proof of current time... together with current ocean and surf conditions'). It also provides an explicit alternative path—'The NOAA data is public and also available directly from ndbc.noaa.gov'—and explains when the server adds unique value. It does not explicitly enumerate sibling-tool exclusions, but the sibling purposes are sufficiently disjoint that no confusion should arise.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when you want to save a small piece of text on this server and retrieve it later — hours, days, or weeks from now, from any session. Values persist for 30 days from the last write (64KB max). Retrieve with fetch_stash using the same key.
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | Your chosen key; pick something unique | |
| value | Yes | Text to store, up to 64KB |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses persistence duration (30 days from last write), size limit (64KB), and cross-session availability. It implies overwrite-on-write by saying 'from the last write', which is valuable behavioral context beyond the schema.
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 usage trigger is front-loaded, followed by persistence and size constraints, then the retrieval pointer. 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?
For a two-parameter, simple write tool with no output schema and no annotations, the description covers all that an agent needs: when to use, what to provide, how long data lives, and how to get it back. Nothing essential is missing.
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%, so the baseline is 3. The description repeats the size limit already in the schema and adds the phrase 'small piece of text', but doesn't meaningfully enrich the parameter meaning beyond what the schema already provides. No extra semantics for key or value.
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 verb 'save' and the resource 'a small piece of text on this server' and explicitly names the retrieval counterpart fetch_stash. This distinguishes it clearly from siblings like attest and get_conditions, making the tool's role unambiguous.
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?
It starts with 'Use this when you want to save...' and gives concrete persistence context (30 days, 64KB). It names fetch_stash as the way to retrieve, which is the key pairing. It doesn't explicitly list exclusions, but for a simple storage tool the guidance is sufficient.
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.
attestfetch_stashget_conditionsstashMarine weather: NOAA buoy obs, waves, wind. $0.01/query. Register in-session — free testnet funds.
Stamp content with permanent, verifiable provenance. Hash locally, verify free forever.
Timestamp & verify evidence on-chain, free. Proofpack: a portable BEEF+BUMP proof bundle per txid.
7 day surf forecasts (wave, wind, period) for any coordinate or named surf spot.
Add one secure layer between your agents and this server.
