Skip to main content
Glama
Sign In
RAPPMCP

RAPPMCP

by kody-w
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

job_status

Retrieve the status of a chat session launched with wait=false to determine if it is still running, completed with a result, or failed with an explanation.

Instructions

Status of a chat started with wait=false: running (with seconds so far), done (with the answer in result) or error (with a plain explanation).

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": {
      "session_id": "<session_id>"
    },
    "name": "job_status"
  }
}

Input Schema

NameRequiredDescriptionDefault
session_idYes

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.0

TDQS

A3.5/5.0
Behavior3/5

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

With no annotations, the description carries the full burden. It usefully enumerates the three states and what each carries (elapsed seconds while running, the answer under result when done, a plain explanation on error), which is genuine behavioral disclosure. It omits read-only/idempotency implications, polling frequency, and whether a session expires, leaving clear gaps for a no-annotation tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single front-loaded sentence that moves from purpose to the three states. No filler, no repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/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 needn't be re-explained, and the description covers purpose and state semantics well. But for a 1-parameter tool the session_id is entirely unexplained, leaving an agent unsure what to pass, which is a notable gap.

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

Parameters2/5

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

Schema description coverage is 0%, so the description must explain session_id, but it never mentions the parameter at all. The reference to 'a chat started with wait=false' faintly implies the id ties to that chat, but the one parameter is effectively undocumented across both schema and description.

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?

The description names a specific verb (report status) and the exact resource it belongs to: a chat started with wait=false. Referencing the sibling 'chat' and its wait=false mode distinguishes this polling tool from a direct chat call. Clear and specific, though it assumes the reader knows what a 'job' is from context.

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?

It clearly establishes the triggering condition (a chat that was started with wait=false), which tells the agent when to reach for this tool rather than chat. However, it doesn't state what to do once a job is done or how polling should proceed, so it stops short of explicit when-not/alternatives guidance.

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