connector_linear_fetchFetch a single Linear resource by its native ID to retrieve issues, projects, or related records for your workflow.
Fetch a single resource from Linear by its ID.
| Name | Required | Description | Default |
|---|---|---|---|
| resource_id | Yes | Native resource ID to fetch |
Changes observed during successful MCP inspections.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations declare readOnlyHint=false and destructiveHint=true, but "Fetch" describes a read-only retrieval. A tool named and described as a fetch should be non-destructive, so the description directly contradicts the structured safety metadata. This is a serious inconsistency that could mislead the agent about side effects.
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?
A single, front-loaded sentence with no filler. It is efficient, though its brevity is partly under-specification rather than disciplined trimming.
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?
There is no output schema, so the description carries the burden of describing what is returned, yet it says nothing about the returned resource shape, supported resource types, or error behavior. Combined with the annotation contradiction, the definition leaves key gaps for correct invocation.
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 100% and there is a single parameter, so the baseline is 3. "by its ID" restates what the schema already documents as "Native resource ID to fetch" and adds no format, example, or type-of-resource detail beyond it.
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?
"Fetch a single resource from Linear by its ID" gives a clear verb (fetch), the source system (Linear), and the addressing mode (by ID). The term "resource" is generic and doesn't say which Linear entity type (issue, project, team) is returned, and it doesn't distinguish itself from connector_linear_search or connector_linear_act. Clear but not sibling-differentiating.
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?
No when-to-use guidance is given. It doesn't state that this is for retrieving a known ID (vs. connector_linear_search for discovery) or that connector_linear_act should be used for writes. The agent must infer the relationship to sibling tools on its own.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.