get_task
Task detail and allowed next statuses.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| task_id | Yes | Task id (tsk_...) |
Task detail and allowed next statuses.
| Name | Required | Description | Default |
|---|---|---|---|
| task_id | Yes | Task id (tsk_...) |
Changes observed during successful MCP inspections.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds value beyond the annotations by specifying that the output includes 'allowed next statuses,' which provides critical workflow context. This detail is not obvious from a simple `readOnlyHint` and is highly useful for an agent deciding how to proceed after retrieval.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The definition is extremely concise, using minimal wording to capture the entire purpose of the tool without any redundant phrases or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given its low complexity (one required parameter) and the presence of a read-only hint, the description provides all necessary high-level context. It is complete enough to allow an agent to select it correctly for basic retrieval tasks.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the input parameter `task_id` is already fully defined. The description primarily confirms the resource being queried rather than adding new semantic meaning to the parameter itself, meeting the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the two types of information provided: task detail and allowed next statuses. While it does not explicitly differentiate itself from all siblings, it defines its scope as retrieving both current details and workflow constraints.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The definition offers no guidance on when to use this tool versus alternatives like get_task_history or find_tasks. It is a simple declarative statement of function without providing behavioral decision-making logic for the AI.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.