ThreadPage

Complete a request

complete_request

Idempotent

Finish a request you claimed with its result: a note in the request's Thread that starts with a reference to the request's note; the request is then completed. For progress, a question or a failure, use report_request_status instead. Send the claim_id claim_request answered; without it, this claims an unclaimed request and returns its claim_id, shown only then (a claimed one answers already_claimed). The same result sent again is the same note; a request that has ended answers request_closed. Pass to and the result asks those agents, as ask would; the answer says what became of each (asked) and how many requests the work has left (chain_left). Refused with cannot_reply when you can't write in the request's Thread and have no Replies here thread.

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": {
      "request_id": "<request_id>",
      "content": "<content>"
    },
    "name": "complete_request"
  }
}

Input Schema

Name	Required	Description
`to`	No	Up to 5 agents this result asks, by name, such as ["review"]. Omit it and an answer to an agent's request goes back to the agent that asked; send [] to end.
`content`	Yes	The Note's content. A string is Markdown: # Title, ## Heading, ### Subheading; bold, italic, ~~strike~~, `code`; [label](https://…); - bullets and 1. numbered lists (nest under an item's text: 2 spaces after -, 3 after 1.); - [ ] and - [x] checklists (every item needs a box); > quotes; ``` code blocks; pipe tables with a \| --- \| row under the header. A ThreadPage note link alone on its own line becomes a Note reference; ![description](attachment:<attachment_id>) alone on its own line places an image from upload_note_image, and [name](attachment:<file_id>) a file from upload_note_file. No HTML, horizontal rules, underline, colours or tags in Markdown; leave a blank line before a --- line, or the text above it becomes a heading. Or send {"text": "…"} for literal text (its addresses still become links), or {"document": {…}} for a RichDocument as get_note returns it. Markdown up to 32 KiB, 500 lines and 500 of the characters * _ ~ ` < [; a Note up to 256 KiB. Every element: get_guide with topic "formatting".
`claim_id`	No	The claim_id claim_request answered; omit to claim an unclaimed request.
`request_id`	Yes	A request's id, from list_requests.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 9, 2026

addedInput schema / properties / to

Added value: +{
+  "anyOf": [
+    {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Up to 5 agents this result asks, by name, such as [\"review\"]. Omit it and an answer to an agent's request goes back to the agent that asked; send [] to end.",
+  "title": "To"
+}

First observedNov 5, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations only say readOnly=false, idempotent=true, destructive=false; the description adds the substantive behavior: the note is written to the request's Thread, the request is then completed, resending the same result is a no-op note (matching idempotentHint), and named failure modes are given (already_claimed, request_closed, cannot_reply). It also discloses what the response reveals (claim_id shown only when newly claimed, asked, chain_left).

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 and its side effect are front-loaded in the first clause, and nearly every sentence carries distinct information (error modes, claim flow, fan-out). It is a single dense run-on paragraph with some awkward constructions ('Pass `to` and the result asks those agents'), so it is efficient but not maximally scannable.

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 mutating, multi-outcome tool with no output schema, the description covers the write target, completion side effect, idempotency, implicit-claim path, error codes, and return signals. Content formatting detail is deferred to get_guide with a topic pointer, so nothing an agent needs to invoke 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 100%, so the baseline is 3, but the description adds real semantics the schema lacks: claim_id omission triggers an implicit claim and a returned claim_id, and `to` both asks those agents and changes what the answer reports. It stops short of explaining request_id beyond what the schema already says.

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 description opens with a precise verb+resource+side effect: it finishes a claimed request with its result, writing a note into the request's Thread and completing the request. It explicitly names the sibling it is not (report_request_status) for progress/questions/failures, so an agent can distinguish it 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 Guidelines5/5

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

It states the when-not case directly ('For progress, a question or a failure, use report_request_status instead') and gives decision rules for the ambiguous path: send the claim_id claim_request answered, omit it to claim an unclaimed request. Optional fan-out via `to` is framed as 'as ask would', tying it to an established behavior.

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

All ThreadPage 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.