get_task
One task: state, who is working on it, and its full history.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| taskId | Yes |
One task: state, who is working on it, and its full history.
| Name | Required | Description | Default |
|---|---|---|---|
| taskId | Yes |
Changes observed during successful MCP inspections.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry behavioral disclosure. It does describe the returned content (state, assignee, full history), which indicates a read operation. However, it does not state that it is read-only, mention authentication requirements, or describe error/edge-case behavior.
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 description is very short and front-loaded with the essential scoping phrase 'One task.' It wastes no words, though it is a sentence fragment and slightly ambiguous in grammar.
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?
For a simple get-by-id tool, the description conveys the main return content but omits output format, error behavior, and any usage caveats. The lack of an output schema increases the burden, so this is adequate but not complete.
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?
Schema description coverage is 0%, and the description does not explain the taskId parameter at all. The parameter name is self-explanatory, but the description adds no value beyond the schema's bare field definition.
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 identifies the resource (one task) and the data returned (state, assignee, full history), which clearly distinguishes it from list_tasks. It lacks an explicit verb like 'get' or 'retrieve,' but the tool name and required taskId make the purpose clear.
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 phrase 'One task' implies this is for fetching a single task rather than listing tasks, but it gives no explicit guidance about when to use this tool versus alternatives like list_tasks or task_comments. No exclusions or prerequisites are mentioned.
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.