Skip to main content
Glama
Swih

Ritoko

by Swih
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Local

Resolve a review item

run_resolve
DestructiveIdempotent

Records a review item's outcome after the user checks the destination record: done to skip it on resume, failed to resubmit it. Requires user confirmation before resolving.

Instructions

Records a review item's outcome once the user checked the business record at the destination. done: the effect exists; later runs skip the row. failed: it did not happen; the run will submit that row again on resume, creating a duplicate if the record does exist. First ask the user to check the destination; pass confirmChecked: true only after they confirm, never on your own. The note describes the evidence; reports mark the item resolved by hand (unverified). Otherwise leave it in review. A duplicate-held item is resolved in its original run first.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
keyYes
noteYes
runIdYes
statusYes
confirmCheckedNotrue only once the user confirmed checking the record at the destination.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / confirmChecked
      Added value: +{
+  "default": false,
+  "description": "true only once the user confirmed checking the record at the destination.",
+  "type": "boolean"
+}
  2. First observedv0.1.0

TDQS

A4.4/5.0
Behavior5/5

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

Adds rich behavior beyond the annotations: done causes later runs to skip the row, failed re-submits on resume and can create a duplicate, and hand-resolved items are marked unverified. These downstream consequences flesh out the destructiveHint=true profile with concrete mechanics rather than repeating it.

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?

Front-loads the core action and the outcome semantics before the confirmation rule. Dense but mostly earning its place, though the trailing sentences about reports marking items unverified and duplicate-held items are somewhat compressed and harder to parse.

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 5-param mutation with no output schema, the description supplies the key decision logic (status effects, confirmation gating, resume consequences) an agent needs. It could still clarify how runId and key are sourced, but it is close to complete for correct invocation.

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 only 20%, so the description must carry the load, and it does for the high-risk params: it defines status semantics (done vs failed) and the confirmChecked gating rule, and explains that note carries evidence. runId and key are left unexplained, so it is not fully compensating.

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+resource (records a review item's outcome) tied to a clear precondition (once the user checked the destination). This is distinct from siblings like run_reconcile or run_resume, though it never explicitly names an alternative, so it falls short of a 5.

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 states when to use each outcome: done when the effect exists, failed when it did not, and 'otherwise leave it in review.' It also gives the operational condition for confirmChecked (only after the user confirms, never on your own), so the when/when-not decision is fully covered.

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

Deploy Server

Other Tools