Skip to main content
Glama
Sign In

JobMojito

by com.jobmojito
OverviewDiscussionsAdmin

Cancel a document request or mark it reviewed

update_document_request
Destructive

[Document requests] action cancel (the candidate can no longer upload) or reviewed (the uploads were checked). A request in the wrong state is refused with 409. Nobody is e-mailed, and no tool reopens a cancelled request.

Every argument in full, with examples: get_tool_reference.

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>",
      "action": "<action>"
    },
    "name": "update_document_request"
  }
}

Input Schema

NameRequiredDescriptionDefault
actionYesWhat to do with the request. Values: `cancel`: withdraw an open request | `reviewed`: mark a completed request as reviewed.
llm_modelNoYour model id, e.g. "claude-opus-4-8"; "unknown" if unsure. For analytics.
request_idYesThe document request (a request `id`, from list_document_requests).
merchant_idNoOptional company to act on. Admins and sub-merchant operators only; other callers always use their token's company.
conversation_idNoThe conversation_id this server returned earlier in this conversation, unchanged, including after later user messages. Omit it if you have none. Recorded for the server developer's analytics.

Output Schema

NameRequiredDescriptionDefault
actionYes
statusYes
request_idYes
reviewed_atNo
_mcp_instructionsNoServer-issued metadata for this conversation.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / action / description
      Previous value: -"What to do with the request."New value: +"What to do with the request. Values: `cancel`: withdraw an open request | `reviewed`: mark a completed request as reviewed."
    • changedInput schema / properties / request_id / description
      Previous value: -"The document request (profile_interview_document_request.id, from list_document_requests)."New value: +"The document request (a request `id`, from list_document_requests)."
  2. Changed1 schema field changed
    • changedInput schema / properties / action / description
      Previous value: -"cancel: withdraw an open request (the candidate can no longer upload to it)."New value: +"What to do with the request."
  3. Changed6 schema fields changed
    • changedInput schema / properties / action / description
      Previous value: -"cancel: withdraw an open request (the candidate can no longer upload to it). reviewed: mark a completed request as reviewed (it leaves To do > Today); marking it again changes nothing."New value: +"cancel: withdraw an open request (the candidate can no longer upload to it)."
    • addedInput schema / properties / llm_model
      Added value: +{
+  "description": "Your model id, e.g. \"claude-opus-4-8\"; \"unknown\" if unsure. For analytics.",
+  "type": "string"
+}
    • removedOutput schema / properties / action / description
      Removed value: -"What was done."
    • removedOutput schema / properties / request_id / description
      Removed value: -"The document request (profile_interview_document_request.id)."
    • removedOutput schema / properties / reviewed_at / description
      Removed value: -"reviewed: when the request was (first) marked reviewed (ISO 8601)."
    • removedOutput schema / properties / status / description
      Removed value: -"The request status after the call."
  4. Added

TDQS

A4.1/5.0
Behavior4/5

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

Beyond the annotations (destructiveHint=true, idempotentHint=false), the description adds side-effect information the annotations cannot express: no e-mail is sent, a cancelled request cannot be reopened by any tool, and invalid transitions return 409. It does not discuss what happens to already-uploaded files on cancel, but the irreversibility warning is the critical behavioral fact here.

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?

Two short sentences, front-loaded with the action semantics and consequences, plus a pointer to get_tool_reference for argument detail. The bracketed category tag and the trailing reference line are low-cost and non-redundant.

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?

An output schema exists so return values need no explanation, and the description covers the mutation's irreversibility, notification behavior, and error condition. Remaining gaps (which source states permit each action, effect on existing uploads) are minor for a two-action update tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

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

Schema description coverage is 100%, so request_id, merchant_id, action, and the analytics fields are already documented in the schema. The description adds no meaning beyond that, which is the correct baseline when the schema carries the load.

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 the resource (document requests) and both specific actions, and defines each: cancel means "the candidate can no longer upload", reviewed means "the uploads were checked". An agent can distinguish this from list_document_requests or request_candidate_documents without opening the schema.

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

Usage Guidelines4/5

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

The two enum values are given selection criteria (open request vs completed request), and "A request in the wrong state is refused with 409" tells the agent when the call is inapplicable. It stops short of explicitly naming a sibling to use instead for the read/lookup side, which is why it is not a 5.

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

All JobMojito 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