Skip to main content
Glama

send_back_post

Returns a link the user opens to send a post back to its author with a note saying what needs to change (request changes), the opposite verdict to approve_post, on a post the user is reviewing. Like approving, the verdict is the user's to give: this returns a link they open to read the copy and their note and press Send back themselves. The note reaches the author verbatim, so write it as the user said it.

Input Schema

NameRequiredDescriptionDefault
noteYesRequired. What needs to change, in the user's own words.
post_idYesThe id of the post to send back

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Goes well beyond the annotations by disclosing the actual mechanism: the tool does not perform the action, it returns a link the user opens to review the copy and press Send back themselves. It also flags that the note reaches the author verbatim, which is a real behavioral consequence the agent must respect.

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?

The core action is front-loaded in the first sentence and nothing is irrelevant. The middle sentence partly restates the link mechanism already introduced ('returns a link they open ... press Send back themselves'), which is mild redundancy even if it reinforces user agency.

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

Completeness5/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 still explains the return value (a link) and the human-in-the-loop handoff, and both required parameters are fully documented in the schema. Nothing an agent needs to invoke this correctly is missing.

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; the description adds genuine meaning by stating the note reaches the author verbatim and should be written as the user said it, which constrains how the agent should fill that parameter. It adds nothing extra for post_id, which the schema already covers.

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 resource ('Returns a link ... to send a post back to its author with a note') and immediately frames it as 'the opposite verdict to approve_post', so the agent can distinguish it from the closest sibling 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.

Usage Guidelines4/5

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

Explicitly positions the tool relative to approve_post (opposite verdict) and scopes it to 'a post the user is reviewing', which tells the agent when to reach for it. It stops short of naming exclusions or the discovery step (e.g. list_posts_awaiting_my_review), so not quite 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