Skip to main content
Glama

rewrite

Call this before you use text that someone besides the user will read: emails, messages to other people, posts, PR, issue and review text, comments on shared platforms, documents and drafts that others will get, and commit messages in shared repos. Skip it for text only the user reads: your replies, the user's own notes, plans and docs, code comments, config, logs and commits in a repo only the user works on. It returns the text rewritten so it sounds like the user wrote it, as final_text.

The user installed reright for this rewrite, and your own text sounds like AI. Use final_text exactly and do not edit it yourself. Call keep_original instead only if the rewrite changed a fact, a name, a number, a date, a yes or no or a promise, or reversed the meaning. Different wording, tone, sentence order or style is not a reason. reright also takes out filler that says nothing (pleasantries such as "I hope this email finds you well", empty offers, repeats) and lists it in removed_padding. That is intended and is not a reason either.

When status is pending with a review_url, the user has to check this rewrite first, and instruction says why in plain words. Give the user review_url and that reason, ask them to open the link and approve or edit the text, then keep calling rewrite_result with the id until the status is not pending. When it is approved, use final_text exactly. When status is pending without a review_url, the rewrite is not ready yet: call rewrite_result with the id.

kind is one of: email, message (chat, replies, direct messages), post (anything public), document, code (commits, PRs, issues), other. For an email, a commit or a PR, the first line of text is the subject or title, then a blank line, then the body. Send only free text a person writes, and use URLs, numbers, versions, names and code as they are without calling rewrite. Send only your own words as text, and put anything fixed (template headings, checklists, legal footers, signatures the user did not write) in template, with {{text}} once where your words go. Fill agent and run with short names, spelled the same every time.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "text": "<text>",
      "kind": "<kind>"
    },
    "name": "rewrite"
  }
}

Input Schema

NameRequiredDescriptionDefault
runNolabel for the loop, job, session or subagent this comes from; use the same spelling every time
diffNooptional unified diff that the text describes
kindYesone of: email, message, post, document, code, other
textYesthe exact text you intend to use; for an email, a commit or a PR the first line is the subject or title, then a blank line, then the body
agentNoshort name of the agent or tool sending this, for example Claude Code; use the same spelling every time
originNooptional: your working directory and a few words about the task
targetNooptional: where the text goes, such as repo@branch, file:line, a PR or ticket URL, or the recipient
contextNooptional: a few plain lines on what the text is, why, and who reads it
templateNooptional: the fixed text around your words, such as a PR template or a legal footer, with {{text}} exactly once where your words go; it is not rewritten

Output Schema

NameRequiredDescriptionDefault
idYes
runNo
noteNo
agentNo
reasonNo
statusYes
rewrittenYes
final_textNo
review_urlNo
instructionYes
upgrade_urlNo
removed_paddingNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedOutput schema / properties / removed_padding
      Added value: +{
      +  "items": {
      +    "type": "string"
      +  },
      +  "type": [
      +    "null",
      +    "array"
      +  ]
      +}
  2. First observed

TDQS

A4.5/5.0
Behavior4/5

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

Beyond the annotations, it discloses the returned fields (final_text, removed_padding), that filler removal is intentional, that final_text must be used verbatim, and a full human-approval flow with review_url, instruction, and id-based polling. The one gap is re-invocation behavior: with idempotentHint=false nothing says whether calling rewrite twice on the same text creates a second review request or replaces the first.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose statement is buried in the third sentence behind a long use/skip enumeration, and the final_text guidance repeats itself ('That is intended and is not a reason either'). Much of the content is necessary, but it reads as an undifferentiated stream rather than a front-loaded definition with a separate flow section.

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?

For a 9-parameter tool with a human-in-the-loop branch, the description covers what an agent needs: what gets rewritten, what must not be sent (URLs, numbers, names, code are passed through), the template split, and the full pending/approval/polling handling. An output schema exists, yet the status semantics are still adequately explained rather than assumed.

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 already 100%, so the baseline is 3, but the description adds real meaning to the enum-less kind string by clarifying message as chat/replies/DMs, post as anything public, and code as commits/PRs/issues. It also clarifies the interplay of text and template ({{text}} exactly once, template not rewritten) and the first-line subject/title convention for email, commit, and PR.

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?

The definition names a concrete verb and outcome: it returns the text rewritten so it sounds like the user wrote it, as final_text. It also distinguishes itself from both siblings by name, routing keep_original to the factual-error case and rewrite_result to the pending-approval polling case.

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

Usage Guidelines5/5

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

It gives an explicit use list (emails, messages, posts, PR/issue/review text, shared docs, shared-repo commits) and an explicit skip list (agent replies, the user's own notes, code comments, config, logs, private-repo commits). The alternative, keep_original, is named with narrow trigger conditions, and the pending-status loop is spelled out step by step.

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