Skip to main content
Glama
Sign In
subtask

subtask

by tedin7
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

result

Retrieve a background job's summary and evidence-backed outcome, with options for full detail and a JSON envelope.

Instructions

Job summary; full=True for all; evidence=True for the JSON envelope.

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": {
      "id": "<id>"
    },
    "name": "result"
  }
}

Input Schema

NameRequiredDescriptionDefault
idYes
fullNo
evidenceNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

D1.9/5.0
Behavior2/5

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

With no annotations, the description carries the entire burden of disclosure, and it says nothing about read-only vs. mutating, permissions, or what a job that does not exist returns. "evidence=True for the JSON envelope" hints at an output shape but is too cryptic to count as real behavioral context, and it never clarifies what "full" expands to.

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

Conciseness2/5

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

At roughly twelve words the text is short but telegraphic, using fragments that are ambiguous rather than efficient. This is under-specification for a three-parameter tool, not disciplined conciseness.

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

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No annotations, no output schema, 0% schema description coverage, and a required id parameter all go undocumented. For a three-parameter tool the description supplies almost nothing an agent needs in order to call it correctly.

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 coverage is 0% across three parameters, so the description must compensate, and it only glosses two of them: "full=True for all" leaves "all" undefined, and "evidence=True for the JSON envelope" does not explain what evidence contains or in what form. The required id parameter is never mentioned at all, so the single mandatory input has zero semantics anywhere.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose2/5

Does the description clearly state what the tool does and how it differs from similar tools?

"Job summary" names a resource of sorts, but the tool name is "result" and no title exists, so the two never connect into a single identifiable operation. Nothing distinguishes it from near neighbours such as status or inspect, leaving an agent to guess what object it returns.

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

Usage Guidelines2/5

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

There is no statement of when to call this versus status, inspect, or wait. The mention of full=True and evidence=True reads as parameter notes, not routing guidance, so an agent gets no cue for choosing this tool over alternatives.

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