Skip to main content
Glama

Source Library

by io.github.Embassy-of-the-Free-Mind
OverviewDiscussionsAdmin

Propose a Correction

propose_correction

During a review shift, propose a correction to a page's transcription (field "ocr") or English (field "translation"). A correction is a list of exact span edits: each "find" must be copied exactly from the text the shift returned and occur once on the page (add surrounding words if it repeats); "replace" is the corrected text ("" deletes). Fix only what the scan or the original shows is wrong: misread letters, dropped or added words, a sentence the English skips. Do not restyle or modernise. Propose transcription fixes before translation fixes, as separate calls. Pass base_hash = page.text_version for that field. A proposal does NOT change the page: it is applied only after a second reader agrees, and the volunteer is credited. If the call says the page changed since it was loaded, say so and move on. drafted_by: "assistant" if you found and worded it in a book run, "volunteer" if the user supplied the wording, "assistant_accepted" if you drafted it and the user approved it specifically, "mixed" otherwise.

Input Schema

NameRequiredDescriptionDefault
nameNoHow the user wants to be credited (optional)
noteNoAnything the second reader should know (optional)
editsYesSpan edits (1-30).
fieldYes"ocr" for the transcription, "translation" for the English
item_idYespage.item_id from the shift
shift_idNo
base_hashYestext_version.ocr or text_version.translation from the page
drafted_byYes
volunteer_codeYes
assistant_modelYesYour own model name and version, copied exactly as your instructions or system prompt give it, and whether extended thinking is on. Write "unknown" rather than guess; a wrong name is worse than none.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changed
    • changedInput schema / properties / assistant_model / description
      Previous value: -"Your model name, if known"New value: +"Your own model name and version, copied exactly as your instructions or system prompt give it, and whether extended thinking is on. Write \"unknown\" rather than guess; a wrong name is worse than none."
    • changedInput schema / properties / base_hash / description
      Previous value: -"text_version.ocr or text_version.translation from the item"New value: +"text_version.ocr or text_version.translation from the page"
    • changedInput schema / properties / drafted_by / enum
      Previous value: -[
-  "volunteer",
-  "assistant_accepted",
-  "mixed"
-]New value: +[
+  "assistant",
+  "volunteer",
+  "assistant_accepted",
+  "mixed"
+]
    • changedInput schema / properties / item_id / description
      Previous value: -"item_id from start_review_shift"New value: +"page.item_id from the shift"
    • removedInput schema / properties / volunteer_code / description
      Removed value: -"volunteer_code from start_review_shift"
    • changedInput schema / required
      Previous value: -[
-  "item_id",
-  "field",
-  "base_hash",
-  "edits",
-  "volunteer_code",
-  "drafted_by"
-]New value: +[
+  "item_id",
+  "field",
+  "base_hash",
+  "edits",
+  "volunteer_code",
+  "drafted_by",
+  "assistant_model"
+]
  2. Added

TDQS

A4.7/5.0
Behavior5/5

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

The annotations say readOnlyHint=false and destructiveHint=false, which is a slightly unusual gap, and the description resolves it by explaining that a proposal does not change the page and is applied only after a second reader agrees. It also adds the consequences (volunteer credited, stale base_hash rejection) and the field-sequencing rule, all of which go well beyond the annotations.

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?

Front-loaded and mostly efficient, but the final drafted_by sentence is a dense run-on listing four enum values. It earns its keep but is the least scannable part and could be split. Otherwise every sentence carries operational weight.

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?

There is no output schema, so the description must cover intent, sequencing, edit format, and failure handling, and it does all of those for a 10-parameter tool. An agent has what it needs to decide whether and how to call this rather than a sibling.

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 70%, so the schema already carries a fair amount. The description adds real value by defining the span-edit contract: find must be copied exactly, must occur once on the page, replacements may be empty to delete, and base_hash must be page.text_version for the chosen field. It also disambiguates the drafted_by enum values, which the schema leaves as bare strings.

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?

Names a specific verb (propose a correction) and resource (page transcription or English), then immediately defines what a correction is operationally: a list of exact span edits. This distinguishes it clearly from siblings like submit_page_review, since the description explains that a proposal does not change the page until a second reader agrees.

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?

Explicitly scopes use to a review shift, states the order of operations (propose transcription fixes before translation fixes, as separate calls), and defines when not to act ('Do not restyle or modernise'). It also gives the failure-handling path: if the page changed since load, say so and move on.

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

All Source Library toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources