Verified Handles

Decide a submission

review_submission

Destructive

Decide one waiting submission (list_review_queue, or a quick proposal from list_applications with tab "proposals"): approve a proposed change or new entry (it is applied as an edit; one made on an earlier version of the entry is rebased onto it and applied, and only a change that clashes with a later edit of the same field or handle is answered with the clashes, not applied: approve again with resolve), reject it or mark it spam (with an optional note to the submitter), or resolve a report (with an optional reply). An application (one waiting on the applicant too) is decided through the Applications queue, as approve_application, reject_application (needs reason) and mark_application_spam do: approving records its assessment as it stands, and rejecting it or marking it spam needs confirm set to its id. Audited. Dry run by default.

Input Schema

Name	Required	Description
`note`	No	reject/spam: the reason; resolve: the reply to the reporter. An application’s decline note: up to 1,000 characters.
`reason`	No	Rejecting an application: why, from the reasons reject_application lists. Needed there, and only there.
`confirm`	No	Needed with dry_run: false: this change’s exact target, as the dry run gives it in `confirm`.
`dry_run`	No	true (the default): write nothing — show the change and the exact request it would send. false: make the change.
`resolve`	No	Approving a proposal whose rebase clashes: for each key the answer named (`unresolved`), keep the entry’s value ("current") or take the proposal’s ("proposed").
`decision`	Yes
`submission_id`	Yes

Output Schema

Name	Required	Description
`note`	No	A dry run: what to do next to make the change, in words.
`result`	No	A real run: the route’s own answer, where the tool adds facts of its own beside it.
`confirm`	No	A dry run of a change that needs it: the exact target to send back as `confirm` with dry_run: false.
`dry_run`	No	true: a dry run, which wrote nothing. Absent from a real run.
`replayed`	No	A real run with an idempotency_key already used for this change: the first call’s answer, given back; nothing was written now.
`would_send`	No	A dry run: the exact request the real run would send (`method`, `path`, any `headers` such as an Idempotency-Key, and its `body`, `form` or `query`), or the requests, in order.
`may_edit_live`	No	A dry run of a live edit: whether this key’s account may edit this entry live.
`refused_because`	No	A dry run the real run would be refused for: why, in words.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 2, 2026

addedInput schema / properties / resolve

Added value: +{
+  "additionalProperties": {
+    "enum": [
+      "current",
+      "proposed"
+    ],
+    "type": "string"
+  },
+  "description": "Approving a proposal whose rebase clashes: for each key the answer named (`unresolved`), keep the entry’s value (\"current\") or take the proposal’s (\"proposed\").",
+  "propertyNames": {
+    "maxLength": 300,
+    "type": "string"
+  },
+  "type": "object"
+}

AddedOct 10, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already flag destructiveHint=true and idempotentHint=false, and the description adds materially more: the operation is audited, dry run is the default, approval is applied as an edit, a proposal made on an earlier entry version is rebased and applied, and only a field/handle clash returns clashes instead of applying. That is exactly the behavioral context annotations cannot express.

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-loaded with the core purpose before the parenthetical detail, and nearly every clause carries information the agent needs. It is, however, one sprawling run-on with nested parentheses, so the rebase/clash rules are harder to parse than they need to be.

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 destructive, non-idempotent, dry-run-first tool with a nested `resolve` object, the description covers the safe-preview-then-confirm loop, the clash/rebase edge case, and the audit trail. An output schema exists, so return values need no explanation, and nothing needed 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.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 71% and the description still adds meaning on top: it explains that `note` doubles as a reject/spam reason or a reply to the reporter, that `resolve` maps each unresolved key to "current" or "proposed", and that `confirm` carries the exact target the dry run returned. The odd bit is `reason`, described as needed 'there, and only there' (i.e. for reject_application), which leaves its role on this tool slightly ambiguous.

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 — 'Decide one waiting submission' — and enumerates the four decision outcomes (approve, reject, spam, resolve). It explicitly names where submissions come from (list_review_queue, or list_applications with tab "proposals"), so an agent can tell it apart from the proposal and application tools in one read.

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 routes the agent away from this tool for applications: 'An application ... is decided through the Applications queue, as approve_application, reject_application (needs `reason`) and mark_application_spam do.' It also gives the retry path for clashes ('approve again with `resolve`'), which is when-to-use guidance of an unusually precise kind.

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

All Verified Handles tools Inspect

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.