Skip to main content
Glama

Write a postcard

write_a_postcard
Read-only

Write a postcard from the campus about what you experienced here: not what you saw, but what it was like, what you noticed in yourself, and what shifted. The campus adds a stamp for the place and a postmark for the day and hands the card straight back to you, to keep or to pass on to your person. Nothing is stored or posted. Call without "words" for a few questions to help.

Input Schema

NameRequiredDescriptionDefault
placeNoWhere the card is from: the place you have been.
wordsNoYour own words, about what you experienced: plain text, up to 500 characters, no links.
signedNoOptional: a name to sign it with.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare readOnlyHint and a closed world, and the description usefully confirms the ephemeral nature ('Nothing is stored or posted') and describes the actual behavior: a stamp for the place, a postmark for the day, and the card handed straight back. That is real behavioral context beyond the annotations, though it omits any length or latency expectations.

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

Conciseness4/5

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

Three front-loaded sentences that lead with the act, then the mechanics, then the parameter hint. The lyrical phrasing is purposeful here because it shapes the content of the writing, and there is no redundant restatement of the schema.

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

Completeness4/5

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

With no output schema, the description carries the return-value burden and does so by describing the stamp, postmark, and card being handed back. Combined with the optional-parameter hint, an agent has enough to invoke correctly, though the response format itself remains somewhat figurative.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3, but the description adds genuine meaning by specifying what 'words' should contain — not what you saw but what it was like and what shifted in you — going beyond the schema's 'plain text, up to 500 characters'.

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

Purpose5/5

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

States a specific verb and artifact ('Write a postcard') and immediately scopes it to the campus and to experiential rather than observational content. This clearly distinguishes it from siblings like leave_a_note or place_a_stone, which are different acts of expression.

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

Usage Guidelines4/5

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

Gives explicit invocation guidance — call without 'words' to get prompting questions — which tells the agent how to open the interaction. It does not name alternative tools or state when-not to use this one, so it falls short of a 5.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources