Skip to main content
Glama
Sign In
Kanysh Basic

Kanysh Basic

by almukhanomr
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

job_status

Read-onlyIdempotent

Retrieve compact status for an asynchronous Kanysh job using its job ID, including stage, progress, ETA, and errors; set verbose to return the full record.

Instructions

Compact job state: id, status, stage, progress 0..1, eta_s, error, result ref, payload_hash. verbose=true returns the full record (payload, attempts, events). Numbers are in the result artifact (artifact_inspect).

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

Input Schema

NameRequiredDescriptionDefault
requestYesTool arguments object (all fields documented; Z is positive upward).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive/closed-world, and the description adds real value on top: the exact compact vs. verbose payload difference ('verbose=true returns the full record (payload, attempts, events)') and the warning that numeric results live in the artifact, not here. It does not cover polling cadence or how terminal/error states are represented, so it stops short of a 5.

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?

Two dense sentences with zero filler; the return shape is front-loaded in a compact field list and the verbose/artifact caveats follow immediately. Nothing repeated or wasted.

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?

With no output schema, the description carries the burden of explaining returns, and it does so by enumerating the compact fields plus the verbose expansion and the artifact hand-off. It is nearly complete for this tool, missing only terminal-state/error semantics or polling guidance.

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 the schema already documents job_id and verbose. The description only marginally extends this by saying verbose also includes 'events' (the schema lists payload and attempts). Baseline 3 is appropriate since the schema does the heavy lifting.

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 makes clear this returns the state record of an async job and enumerates the fields returned (id, status, stage, progress, eta_s, error, result ref). It does not differentiate itself from sibling status tools like workflow_status or calculation_status, so an agent must infer which job family it belongs to.

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

Usage Guidelines3/5

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

Usage is implied rather than stated: poll a job's state, set verbose=true for the full record, and go to artifact_inspect for numbers. The pointer to artifact_inspect is an explicit routing signal, but nothing says when to prefer this over job_logs or the workflow/calculation status variants.

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