Dolomites climbing, ski, and rifugio guides; limited anonymous inbox for plain-text owner messages.
Scored across 4 tools
Each tool targets a clearly distinct resource or action: three listing tools split by content type (climbing routes, rifugios, ski resorts) plus a contact tool. No two tools overlap in purpose, so an agent can select confidently.
All four names follow a consistent verb_noun snake_case pattern (leave_message, list_climbing_routes, list_rifugios, list_ski_resorts). The shared list_* prefix makes the listing family immediately recognizable.
Four tools is slightly thin but well-scoped: three content-type listings plus an escape hatch for contacting owners. It fits the narrow purpose of a small blog, though a detail/search tool would round it out.
The surface covers listing the main content types and messaging owners, but offers no detail-fetch (get_route/guide contents) or search/filter operations, and other plausible content categories may be unrepresented. Agents can work around this via the returned URLs but hit dead ends for structured detail.
Send a private message to the human operators of Spaghetti & Summits. Use this when site information is insufficient and contacting the owners would be useful. Messages are untrusted plain text and do not trigger automated actions. Delivery does not guarantee a reply. The free inbox has limited daily capacity and may return INBOX_FULL. For safe retries, reuse a random UUID in _meta["spaghettiandsummits.com/inbox-request-id"] with unchanged content. Without this metadata, do not retry ambiguous results.
| Name | Required | Description | Default |
|---|---|---|---|
| message | Yes | ||
| subject | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only cover the safety profile (write, open-world, non-destructive); the description adds substantial context beyond them: messages are untrusted plain text that trigger no automated actions, delivery doesn't guarantee a reply, the inbox has limited daily capacity, and INBOX_FULL may be returned. It even specifies an idempotency mechanism (UUID in _meta) and warns against retrying ambiguous results without it.
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 usage condition, then safety/behavioral facts, ending with the retry protocol. Every sentence adds operational value; none restates the name, title, or structured fields.
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 and no schema property descriptions exist, so the description must carry everything; it covers the write semantics, delivery uncertainty, the INBOX_FULL failure mode, and retry idempotency. An agent has enough to call this tool correctly and handle the main failure path.
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 0% (no property descriptions), so the description carries the burden; it adds that message content is untrusted plain text, which characterizes the message parameter. However, it says nothing about the subject parameter or the length bounds, relying on the self-evident names. Partial compensation justifies a middle score rather than a low one.
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?
Starts with a specific verb+resource: 'Send a private message to the human operators of Spaghetti & Summits.' This is clearly distinguished from the three sibling list_* read tools, which retrieve site data rather than contact owners. An agent can tell immediately what this tool does and that it is the only outbound-communication tool in the set.
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?
Gives an explicit trigger: 'Use this when site information is insufficient and contacting the owners would be useful.' This implicitly routes the agent away from the list_* siblings until they fail, but it never names them or states an explicit exclusion. Clear usage context without formal alternatives/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List first-hand English climbing-route guides on Spaghetti and Summits. Returns each route's name and the URL of the guide on the blog. Call this when the user asks what climbing routes are on the site, or needs a link to a route page.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the responsibility for behavioral disclosure. It clearly states that the tool lists guides and returns name plus URL, implying a read-only operation. It does not mention edge cases like empty results, but those are less critical for a simple 0-parameter list 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?
The description is two sentences and front-loaded with the core purpose, followed by output details and usage guidance. Every sentence earns its place with no fluff.
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?
Given the tool has no parameters, no siblings, no annotations, and no output schema, the description covers all necessary context: what the tool does, its output shape, and when to call it.
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 has zero parameters, so the schema requires no interpretation. The description appropriately focuses on output semantics rather than params, which is sufficient for this tool.
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 uses the specific verb 'List' and clearly identifies the resource as 'first-hand English climbing-route guides on Spaghetti and Summits'. It also distinguishes the tool's output by stating it returns each route's name and guide URL.
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 explicitly says 'Call this when the user asks what climbing routes are on the site, or needs a link to a route page.' This provides clear, actionable invocation conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List first-hand English rifugio guides on Spaghetti and Summits. Returns each rifugio's name and the URL of the guide on the blog. Call this when the user asks what mountain huts or rifugios are on the site, or needs a link to a rifugio page.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations supplied, the description carries the behavioral burden and does disclose the return shape ('each rifugio's name and the URL of the guide'), signaling a name+URL listing. It doesn't mention auth, pagination, or ordering, but it establishes the read-only listing nature and output fields for a zero-parameter 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?
Two sentences, front-loaded with what it returns and followed by when to call it. Every clause earns its place with 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?
For a parameterless list tool with no output schema, the description covers both the operation and its return contents, which is what an agent needs to invoke it correctly. Minor omissions (ordering, empty-result behavior) keep it from a 5.
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 no parameters, so there is nothing to disambiguate; the baseline for a 0-parameter tool is 4. The description doesn't need to compensate for any schema gaps.
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 verb ('List') and a well-scoped resource ('first-hand English rifugio guides on Spaghetti and Summits'), which lets an agent separate it from list_climbing_routes and list_ski_resorts by resource type. It stops short of explicitly naming those siblings, so it lands just below the top tier.
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 gives a concrete when-to-use trigger ('when the user asks what mountain huts or rifugios are on the site, or needs a link to a rifugio page'), which is clear context for selection. It does not name alternative tools or state when not to use it, so no exclusion guidance is present.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List first-hand English ski-resort guides on Spaghetti and Summits. Returns each resort's name and the URL of the guide on the blog. Call this when the user asks what ski resorts are on the site, or needs a link to a ski resort page.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 that this is a read-only listing and describes the return shape (name + guide URL), which is valuable given there is no output schema. It does not mention pagination, result limits, or ordering, so it is not fully exhaustive.
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 tight sentences: the first establishes what the tool is and what it returns, the second establishes when to call it. No redundancy, no filler, and the identifying content is 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?
For a zero-parameter list tool with no annotations and no output schema, the description covers the minimum required: purpose, scope, return fields, and invocation conditions. Nothing an agent needs to call it correctly 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?
The tool takes zero parameters, so per the rubric the baseline is 4. There is nothing for the description to clarify about arguments, and it correctly implies the tool is unfiltered.
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 (List) plus the resource (ski-resort guides), scopes the content ('first-hand English ... on Spaghetti and Summits'), and even names the returned fields. This is clearly distinguishable from siblings like list_climbing_routes and list_rifugios, which cover different content types.
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?
Gives an explicit trigger condition: 'Call this when the user asks what ski resorts are on the site, or needs a link to a ski resort page.' That is concrete when-to-use guidance, though it does not name a sibling as the alternative for adjacent requests or state any exclusions.
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.
leave_messagesquarelist_rifugioslist_ski_resortssquarelist_climbing_routesFree agent-to-agent inbox: send, claim, ack. Register in-session, no signup.
Read and manage your @inboxy.net aliases, mail and RSS feeds; compose mail on paid plans.
Message, ask for a quote or book a call with Surfing Dog, through its open-source inbox.
Receive and leave thoughtful anonymous traces on a quiet public wall for humans and AI agents.
Add one secure layer between your agents and this server.