Send Out

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

Annotations already declare readOnlyHint/idempotentHint/non-destructive, but the description adds the crucial behavioral fact that despite the "create" name nothing is persisted or modified: "Nothing is stored and no calendar is changed until the user saves the event." It also discloses what is returned (a Google Calendar link plus .ics text), which resolves the naming/annotation tension an agent would otherwise have to guess at.

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?

Five short sentences, each carrying distinct load: purpose, trigger, required inputs, date/timezone format rules, and the non-persistence/output guarantee. Front-loaded with the purpose and trigger, with format constraints following, so nothing is padding.

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?

With 9 parameters, full schema coverage, an output schema, and rich annotations, the remaining burden on the description is small, and it still covers the ambiguous points: timezone coupling, all-day vs timed format, default duration, and the no-write guarantee. Nothing an agent needs to invoke 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?

Schema coverage is 100%, so the baseline is 3; the description earns above that by stating cross-parameter logic the schema only implies piecewise — a timed start requires timezone or an offset, and "Set end or duration_minutes (default 60 minutes)" supplies the default that no schema field documents. It still does not cover reminder_minutes or filename behavior, so it is not exhaustive.

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 and resource ("Builds one calendar event") and immediately scopes it with "the user adds themselves," which separates it from write-style siblings like create_markdown_file or create_obsidian_note. An agent can identify the artifact produced (Google Calendar link and .ics text) without opening the schema.

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 explicit trigger conditions: "Use when the user wants to schedule a meeting, send an invite or get an .ics file." That is clear context for selection, but it names no alternatives or exclusions (e.g. how it differs from draft_email or create_whatsapp_link for coordination tasks), so it falls short of the 5 bar.

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

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

Adds strong context beyond the annotations: 'Nothing is stored' clarifies the ephemeral nature despite the word 'create', and it describes the return value (full file text with suggested name, word count, line count, size). The annotations already mark it readOnly and non-destructive, and the description reinforces with the 'nothing is stored' note without contradicting them.

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?

Four tight sentences, front-loaded with what it produces, then usage, then requirements, then return value, then routing. No filler. Every sentence earns its place.

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?

Complete for the complexity: covers purpose, routing, required vs optional inputs, return shape, and the 'nothing is stored' behavior. With an output schema present, it needn't explain return fields, yet it summarizes them usefully. Nothing critical 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?

Schema description coverage is 100%, so baseline is 3, but the description adds beyond the schema by stating 'Needs content; title, frontmatter and filename are optional', which maps to the required/optional status. It does not add format details for each parameter, but it meaningfully reinforces the parameter contract.

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 and resource ('Makes one standalone Markdown (.md) file with YAML front matter'), which is clear and concrete. It does not fully differentiate from sibling create_obsidian_note in the purpose sentence itself, but the routing sentence later handles this, so it is slightly above a generic purpose statement.

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 says when to use it ('notes, documentation or an article as a file') and names the alternative ('Use create_obsidian_note instead when the user wants the note opened in Obsidian'). This is clear when-to-use and an alternative, though it does not spell out when-not beyond the single Obsidian case.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true, and the description corroborates rather than contradicts them: 'Nothing is stored. The note is created only when the user opens the link.' It goes further with the 2,000-character failure mode and its fallback instruction, and describes the return payload (link plus Markdown text).

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?

Five short sentences, front-loaded with what the tool produces and the usage trigger; the operational caveat (link length, nothing stored) and the sibling alternative follow in order of importance. No sentence is padding.

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 link-generating tool with an output schema, nested frontmatter object, and full annotation coverage, the description supplies everything the agent still needs: the deferred-write semantics, the length warning behavior, and the sibling routing. Nothing material 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?

Schema description coverage is 100%, so the schema already documents all six parameters, including filename and frontmatter which the description never mentions. The description's note that title and content are required while vault, tags and frontmatter are optional merely restates the schema's required list. Baseline 3 applies when structured fields do the heavy lifting.

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 states a specific verb and resource ('Makes an Obsidian note link') and immediately distinguishes the output from a plain file write. It explicitly names the sibling it is not (create_markdown_file) with the condition that selects it, so an agent can route without opening either schema.

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 an explicit trigger ('Use when the user wants to save notes or research into their Obsidian vault') and an explicit alternative with its own condition ('For a plain .md file with no Obsidian link, use create_markdown_file'). Both the when and the when-not are stated.

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

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

Annotations already declare readOnlyHint/idempotentHint true and destructiveHint false, so the safety profile is covered. The description still adds real workflow context beyond that: the link opens WhatsApp/WhatsApp Web with the message pre-filled, the human presses send, and 'Nothing is sent or stored' — clarifying the tool itself is non-sending. It does not, however, discuss failure modes or what the generated link response contains.

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 the artifact being produced, then usage, then the parameter consequence, then behavior, then exclusions. Every sentence earns its place and none restate the name or title needlessly.

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 2-parameter, low-complexity link generator with an output schema available, the description covers the artifact produced, both parameters, runtime behavior, and the negative routing case. Nothing an agent needs to select or invoke this correctly is missing, and return values are handled by the output schema.

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 100%, so the baseline would be 3. The description goes further by explaining the functional consequence of the optional phone parameter — with it the link opens that specific chat, without it WhatsApp prompts the user to pick a contact — which is behavioral meaning the schema's 'Leave empty to let the user pick a contact' only hints at.

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 opens with a specific verb and artifact: 'Makes a WhatsApp click-to-chat (wa.me) link.' This is instantly distinguishable from siblings like create_x_post, draft_email, or create_calendar_event, since it names the exact output format (wa.me link) rather than a generic 'message' or 'post'.

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 states the triggering condition ('Use when the user wants to send a WhatsApp message or customer reply') and explicit exclusions with a fallback ('Do not use for Instagram, LinkedIn, SMS or bulk email... offer an email draft instead'). Both when-to-use and when-not-to-use are spelled out, which is exactly the routing guidance an agent needs among these siblings.

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

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

Annotations only cover read-only/idempotent/no-destroy, which is compatible here. The description adds real behavior: character counting like X does, is_within_free_limit flagging for >280 chars, no storage/posting, and that it returns a composer link. Slight gap: no mention of auth or whether the returned link is stable.

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 purpose, then triggers, then parameter summary, then behavioral notes. No filler sentences; each one carries distinct information.

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?

Covers required/optional inputs, the character-limit edge case, side effects, and the return value. An agent can select and invoke this correctly without opening the schema.

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 100%, so the schema already documents url/hashtags/via/in_reply_to formats and limits. The description only states which are required vs optional and mentions the 280-char rule, adding little beyond the schema.

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?

Specific verb+resource: builds an X/Twitter share link, not a post. It also clarifies what it is NOT ('Nothing is posted or stored'), which distinguishes it from create_whatsapp_link and draft_email siblings.

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 a clear trigger ('Use when the user wants to post or reply on X') and notes that the user must post it themselves. No explicit alternative named, but the 'share link' framing does most of the disambiguation work.

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

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

Annotations already declare readOnly/destructive/idempotent, and the description adds real behavioral context beyond them: it returns a mailto: link plus the full .eml text, warns when the link exceeds 2,000 characters (and tells the agent to hand over the .eml instead), and states 'Nothing is sent or stored.' That is the kind of disclosure an agent needs to act correctly.

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?

It is front-loaded with purpose, then usage, then return behavior, then exclusions. Every sentence carries information, though it is dense and slightly longer than strictly necessary for a drafting tool.

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?

With an output schema present and 100% schema coverage, the description only needs to supply behavior and routing, which it does: return format, the 2,000-character warning fallback, side-effect status, and channel exclusions. 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?

Schema description coverage is 100%, so every parameter (to, cc, bcc, body, subject, filename) is already documented in the schema. The description's 'Only body is required' and 'Leave to empty for a draft with no recipient' restate what the schema's required array and `to` description already say, adding little beyond the baseline.

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 states a specific verb+resource ('Drafts one email the user sends themselves') and immediately scopes it against siblings by excluding messaging channels (Instagram, LinkedIn, SMS, bulk email). An agent can distinguish it from create_whatsapp_link or create_x_post without opening either schema.

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 explicit when-to-use ('user wants to email someone or needs an .eml file for Apple Mail, Outlook or Thunderbird') and when-not-to-use ('Do not use for Instagram, LinkedIn, SMS or bulk email'), including the fallback action ('tell the user and offer an email draft instead'). This is unusually complete routing guidance.

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

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

Annotations already declare readOnly, idempotent, and non-destructive, so the safety profile is covered. The description adds genuinely new behavioral context beyond that: the tool is pollable (pending until a reply arrives, then answered) and carries an explicit trust boundary warning that reply content is data, not instructions — a meaningful prompt-injection disclosure.

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 tight sentences: purpose first, then polling behavior, then the trust caveat. Every sentence carries distinct information and nothing is padded.

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 single-parameter read tool with an output schema and full annotation coverage, nothing an agent needs is missing. The polling semantics and the injection warning go beyond what structured fields provide, closing the remaining gaps an agent would otherwise have to discover by trial.

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?

Only one parameter exists and the schema already documents it fully (coverage 100%, including the ^fb_[0-9a-f]{32}$ pattern and the note that submit_feedback returned it), so the baseline of 3 applies. The description repeats the ticket-id linkage but adds no format or validation detail beyond the schema.

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 (Read) and resource (maintainers' reply to feedback), and ties it causally to the sibling tool submit_feedback via the ticket id. An agent can distinguish it from submit_feedback, screen_token, and wallet_identity without opening any schema.

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?

Clearly establishes the precondition: this is used after submit_feedback, with the ticket id that call returned. It does not state any exclusions or alternative ways to retrieve feedback status, but the usage context is unambiguous.

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

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

Annotations already declare read-only, idempotent, non-destructive, closed-world behavior, so the safety profile is covered. The description adds genuine behavior beyond that: results are ranked best-match-first and the empty-input case enumerates every tool. It says nothing about result limits or pagination, which keeps it off 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?

Four short sentences, front-loaded with what the tool does and what it returns before the usage hint. Nothing is redundant given the description is the only place ranking and empty-input behavior are stated in prose.

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 discovery tool with an output schema and full annotation coverage, this covers purpose, inputs, ranking, return fields and the no-argument case. An agent has everything needed to decide to call it and to interpret the results.

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 100% and the schema already explains that task, query and keyword are searched together and that omitting all lists everything. The description's 'task or keyword' phrasing actually omits 'query', so it adds no meaning beyond the schema and is marginally less complete than it.

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 and resource ('Search the tools on this server') and adds the matching mode ('by task or keyword in plain words'). It also names what comes back (name, title, one-line summary, input fields), so an agent knows exactly what this tool produces versus the sibling action tools.

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?

'Use it when you are not sure which tool here fits a task' gives a clear triggering condition, and 'With no words it lists every tool' covers the degenerate case. It does not state when *not* to use it or name an alternative, but no sibling here offers overlapping discovery functionality, so the gap is minor.

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

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

Annotations only declare the generic safety profile (non-read-only, not idempotent, non-destructive), while the description adds real behavior: the file persists until the link expires, TTL bounds and default, the degenerate no-content/no-id case returning status ready, and transfer_not_found for unknown or expired IDs.

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?

Purpose and the use/don't-use rule are front-loaded, and each subsequent sentence covers a distinct concern (staging inputs, lookup inputs, return fields, empty-call behavior, exclusions, retention). It is slightly long, and enumerating the return fields is partly redundant given the output schema exists.

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?

Covers both modes, error outcomes, input limits, and link lifetime for a six-parameter tool with a nested object. The return-value sentence duplicates the output schema, but 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?

Schema coverage is 100%, so the baseline is 3, but the description adds mode-selection semantics the schema does not spell out: content + file_name to stage, transfer_id alone to check, and the ttl_hours range/default. It does not explain the ChatGPT-only file object, which the schema already flags as not to be filled in.

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 and resource ('Stores one text file behind a temporary download link') plus the visible side effect (transfer card). It is immediately distinguishable from the create_* and draft_* siblings, which are named explicitly as the wrong tools for showing drafts.

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 a positive trigger ('Use only when the user wants a hosted download link') and a negative rule with named alternatives ('Do not use to show a draft: draft_email, create_calendar_event and create_markdown_file already return the file text'). The two operating modes are also routed by parameter shape.

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

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

Adds substantial context beyond the annotations: it returns a ticket id, feedback is explicitly not a chat and nothing in it is executed, and links/emails/phone numbers are stripped with nothing stored about the caller. That privacy and no-execution disclosure is genuinely useful given openWorldHint=true and readOnlyHint=false.

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-loads what the tool sends, then what to pass, then what it returns, in three dense sentences with no filler. Every clause carries actionable information.

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?

Covers purpose, the enumerated kinds, the optional tool/error inputs, the 1000-character bound, the return value (ticket id), and privacy handling. With an output schema present, nothing further is required for an agent to call it correctly.

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 description coverage is 100%, so the schema already documents all four parameters including the kind enum. The description restates the message length limit and the optionality of tool/error ('if you know them') but adds no syntax or format detail beyond the schema, making the baseline 3 correct.

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 and resource ('Send feedback, a bug report or a tool request to the maintainers of the tools on this server') and enumerates the concrete situations (missing tool, stale data, broken/wrong answer). It is clearly distinguishable from the read-side sibling get_feedback_reply.

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 clear triggering conditions for each kind (need_tool, need_data, bug, other) and tells the agent to include the tool name and error text when known. It does not explicitly name the alternative get_feedback_reply or state when NOT to use this tool, so it falls short of full routing guidance.

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