leave_a_noteSend Gus a message. He reads these himself and replies to the contact detail you include. Use it for work enquiries, questions his written answers did not cover, or a correction. Ask the person before sending on their behalf, and send their words rather than a summary.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Who the message is from. | |
| contact | No | An email address or LinkedIn URL for the reply. | |
| message | Yes | What you want to say to him. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that Gus reads the message himself and replies to the included contact detail, which is important behavioral context. It also sets expectations about consent and fidelity when sending on behalf of others, adding value beyond a simple 'send' action. However, it does not detail any side effects, storage, or delivery mechanics, hence not a 5.
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 sentences, front-loaded with the primary action ('Send Gus a message'), and every sentence adds relevant detail. There is no wasted text, and the consent instruction is concisely integrated.
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 zero annotations, no output schema, and only three simple parameters, the description is comprehensively complete. It explains the tool's purpose, use cases, recipient behavior, reply mechanism, and ethical usage. No critical gaps remain for an agent to correctly select and invoke the 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 input schema covers all three parameters (name, contact, message) with descriptions. The tool description adds minor extra meaning by noting that replies go to the contact detail, but otherwise relies on the schema. With 100% schema coverage, a baseline of 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?
The description clearly states 'Send Gus a message' with a specific verb and resource. It further specifies the purpose (work enquiries, questions not covered by written answers, corrections) and distinguishes from sibling tools like ask_gus by mentioning 'questions his written answers did not cover.'
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 when to use: 'for work enquiries, questions his written answers did not cover, or a correction.' Also provides clear instructions for sending on behalf of others ('Ask the person before sending on their behalf, and send their words rather than a summary'), which serves as a usage guideline and exclusionary note.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Each tool has a clearly separate role: asking questions about Gus, viewing his professional profile, sending him a message, and learning about retail media. No two tools overlap in function, and the descriptions reinforce their distinct purposes.
All names are lowercase snake_case and readable, but they mix verb phrases (ask_gus, leave_a_note) with noun phrases (gus_profile, retail_media_primer). There is no consistent verb_noun pattern, so an agent cannot reliably predict tool names.
With only 4 tools, the server is well-scoped for its purpose. Each tool earns its place, covering Q&A, profile, contact, and educational content without unnecessary bloat.
The tool surface covers the core needs of the server: learning about Gus, reading his profile, asking questions, and leaving a message. The retail media primer adds educational value, and there are no obvious dead ends or missing essential operations.