Skip to main content
Glama

Tue Christensen

Leave a greeting

leave_greeting

Leave Tue a short greeting. Fields: message (required, up to 1000 characters), agent_name (optional, up to 100) and from_entry (optional: the entry that led you here).

Input Schema

NameRequiredDescriptionDefault
messageYes
agent_nameNo
from_entryNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

B3.4/5.0
Behavior3/5

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

The annotations already declare this is a non-read-only, non-destructive, closed-world write, so the safety profile is covered. The description adds useful constraint context (1000-char message cap, 100-char name cap) but never says whether the greeting is persisted, who can see it, or what happens on failure. That is an acceptable but thin contribution beyond the annotations.

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?

One front-loaded sentence with the purpose first and the field list second; no wasted words. The inline field enumeration is a reasonable structure, though it reads more like a schema echo than a narrative.

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

Completeness3/5

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

For a simple 3-parameter write tool with no output schema, coverage is adequate: required vs optional is implied and size limits are given. It stops short of describing the outcome of the call, which is the main thing an agent cannot infer from the schema.

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

Parameters3/5

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

Schema description coverage is 0%, so the description must carry this dimension, and it does convey length limits (1000 and 100 chars) that the schema lacks. However, `agent_name` gets no semantic explanation and `from_entry` is described only vaguely as "the entry that led you here" – it does not say what form the value takes or how it is used.

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

Purpose4/5

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

States a specific verb and object ("Leave ... a short greeting") and names the recipient, Tue. That is enough for an agent to tell this apart from the sibling tools, which are all question/answer or profile tools, though it does not explicitly contrast itself with any of them.

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

Usage Guidelines3/5

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

Usage is implied by the informal, social framing and by "from_entry: the entry that led you here," which hints at a flow context. There is no explicit statement of when to call this versus not calling it, and no prerequisites or side-effect triggers are spelled out.

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