Skip to main content
Glama

Save the founder's voice

notes_voice
Destructive

Store how the founder writes on one platform, learned from their own posts (X: their profile in their Chrome; Reddit: posts or comments they paste, since Claude cannot open Reddit). Kept and reused for every note; saving again replaces it. Free.

Input Schema

NameRequiredDescriptionDefault
rulesNoDo and do not, one line each: 'all lowercase', 'no emoji', 'no hashtags'
handleNoTheir handle or username
sampleYesHow many of their own posts you read
summaryYesHow they write, in a few lines: length, casing, tone, what they talk about
examplesNoUp to 5 of their own posts, verbatim
platformYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A3.7/5.0
Behavior4/5

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

Annotations confirm it is a write with destructiveHint=true, and the description substantively explains the destruction: 'saving again replaces it' tells the agent prior saved voice is overwritten. It also notes persistence ('kept and reused for every note') and cost ('Free'), adding context beyond the annotation flags.

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 tight sentences, front-loaded with what it does, then the platform caveats, then persistence and cost. The parenthetical platform detail is dense but earns its place; nothing is wasted.

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?

For a 6-param mutation tool with no output schema, the description covers purpose, per-platform sourcing, overwrite behavior, and cost. It lacks only an explicit note on what a first save requires or returns, which is minor given no output schema exists.

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 coverage is 83%, so the schema already documents most parameters (rules, handle, sample, summary, examples). The description clarifies the platform enum's sourcing behavior but adds no syntax or format detail for the required 'sample'/'summary' fields, so the baseline 3 holds.

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 resource: 'Store how the founder writes on one platform'. The purpose (capturing writing voice) is clear and distinct from note-saving siblings like notes_save/notes_context, though it never names a sibling to route the agent explicitly.

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?

Adds real operational guidance on how to source samples per platform (X profile in Chrome, Reddit paste because Claude cannot open Reddit), but gives no explicit when-to-use vs when-to-skip signals or alternatives among siblings.

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