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

No annotations are provided, so the description carries full burden. It states the tool 'adds a comment' (implying a write/mutation operation) but doesn't disclose behavioral traits like authentication requirements, rate limits, error handling, or whether comments are editable/deletable. This is inadequate for a mutation tool with zero annotation coverage.

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 appropriately sized (two sentences) and front-loaded with the core purpose. The second sentence adds useful context without being redundant. It could be slightly more concise by merging ideas, but it's efficient overall.

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 this is a mutation tool (adding comments) with no annotations, no output schema, and 3 parameters, the description is incomplete. It doesn't cover error cases, response format, or side effects, leaving significant gaps for an AI agent to use it correctly.

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%, so the schema already documents all parameters (ticketId, comment, debug). The description adds no additional meaning beyond what's in the schema (e.g., no examples, format details, or constraints). Baseline 3 is appropriate when schema does the heavy lifting.

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 action ('Add a comment') and target resource ('to a specific Linear ticket'), distinguishing it from sibling tools like create_issue or get_issue. However, it doesn't explicitly differentiate from hypothetical comment-related siblings (none exist in the provided list), so it's not a perfect 5.

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 description provides implied usage context ('useful for providing feedback, status updates, or additional information on existing tickets'), which suggests when to use it. However, it lacks explicit guidance on when not to use it (e.g., vs. updating ticket fields directly) or alternatives, and doesn't mention prerequisites like needing write permissions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states 'Create a new issue,' which implies a write operation, but doesn't disclose permissions required, whether it's idempotent, rate limits, or what happens on failure. For a mutation tool with zero annotation coverage, this is a significant gap in behavioral context.

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 two sentences, front-loaded with the core purpose and followed by a usage hint. It avoids redundancy and wastes no words, though it could be slightly more structured by explicitly separating purpose from guidelines.

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 the complexity (8 parameters, 2 required), no annotations, and no output schema, the description is moderately complete. It covers the basic purpose but lacks details on behavioral traits, error handling, and output format. For a creation tool with no structured safety or output information, it should do more to compensate, but it's not entirely inadequate.

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%, so the schema already documents all 8 parameters with clear descriptions. The description adds no parameter-specific information beyond the general purpose. According to the rules, when schema coverage is high (>80%), the baseline is 3 even with no param info in the description, which applies here.

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 action ('Create a new issue') and resource ('in Linear'), with specific examples of what can be created ('tasks, bugs, or feature requests'). It distinguishes from siblings like 'add_comment' or 'get_issue' by focusing on creation rather than modification or retrieval. However, it doesn't explicitly differentiate from other creation-related tools if they existed.

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 description implies usage by stating 'This tool is useful for adding new tasks, bugs, or feature requests,' which suggests when to use it. However, it doesn't provide explicit guidance on when to choose this over alternatives like 'list_issues' for viewing or 'add_comment' for updating, nor does it mention prerequisites or exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions retrieving 'detailed information' and comments, but fails to address critical aspects like whether this is a read-only operation (implied but not stated), error handling for invalid issue IDs, rate limits, authentication needs, or what 'detailed information' includes beyond comments. This leaves significant gaps for an agent to understand the tool's 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 a single, efficient sentence that front-loads the core purpose. It avoids unnecessary words, though it could be slightly more structured by explicitly separating purpose from parameter guidance.

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 the complexity (3 parameters, no output schema, no annotations), the description is incomplete. It doesn't explain what 'detailed information' entails, how to handle the issueId format, the purpose of the debug parameter, or the response structure. For a tool with undocumented parameters and no annotations, this leaves the agent with insufficient context to use it effectively.

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%, so the schema provides no parameter descriptions. The description only mentions 'comments if requested,' which loosely relates to the includeComments parameter but doesn't explain its purpose, default behavior, or the other parameters (issueId and debug). It adds minimal value beyond the bare schema, failing to compensate for the lack of schema descriptions.

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 verb ('Get') and resource ('detailed information about a specific Linear issue'), distinguishing it from siblings like list_issues (which lists multiple issues) and create_issue (which creates new issues). However, it doesn't explicitly differentiate from get_project or other get_* tools beyond the resource name.

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 description implies usage context by specifying 'a specific Linear issue' and mentioning comments, suggesting this tool is for retrieving details of a known issue rather than listing or creating. However, it lacks explicit guidance on when to use this versus alternatives like list_issues or when not to use it (e.g., for bulk operations).

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

No annotations are provided, so the description carries full burden. It mentions retrieving 'detailed information' and 'comprehensive details,' but lacks behavioral context like whether this is a read-only operation, if it requires authentication, rate limits, or what happens if the projectId is invalid. For a tool with no annotations, this is a significant gap in transparency.

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 two concise sentences that are front-loaded with the core purpose. Every word earns its place, with no redundancy or fluff. It efficiently communicates the tool's intent without unnecessary elaboration.

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 no annotations, no output schema, and a tool that retrieves project details with 6 parameters, the description is incomplete. It doesn't explain the return format, error handling, or behavioral constraints. For a data retrieval tool with moderate complexity, the description should provide more context to be fully helpful.

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?

The schema description coverage is 100%, so the schema fully documents all 6 parameters. The description adds no specific parameter information beyond implying 'detailed information' about a project. Since the schema does the heavy lifting, the baseline score of 3 is appropriate, with no extra value from the description.

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 tool's purpose: 'Get detailed information about a Linear project including team, lead, issues, and members.' It specifies the verb ('Get') and resource ('Linear project'), and lists key data fields. However, it doesn't explicitly differentiate from siblings like 'list_projects' (which likely lists multiple projects vs. getting details of one).

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 description provides some guidance: 'Use this to see comprehensive details of a specific project,' implying it's for detailed views of individual projects. It doesn't explicitly state when NOT to use it or name alternatives (e.g., 'list_projects' for overviews), leaving usage context implied rather than explicit.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

With no annotations provided, the description carries full burden but offers minimal behavioral disclosure. It mentions filtering but doesn't cover pagination (implied by 'limit' parameter), rate limits, authentication needs, or what happens with large result sets. For a list tool with 8 parameters, this leaves significant gaps in understanding how the tool behaves operationally.

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 appropriately concise with two sentences that front-load the core functionality. Every sentence contributes value: the first states purpose and key filters, the second provides usage intent. No wasted words, though it could be slightly more structured for clarity.

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 the tool's complexity (8 parameters, no annotations, no output schema), the description is incomplete. It lacks details on return format, error handling, pagination behavior, and doesn't fully explain parameter usage. For a list tool with filtering and sorting capabilities, this leaves the agent with insufficient context to use it effectively.

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%, so the description must compensate but only mentions three parameters (assignee, status, project) out of eight. It doesn't explain 'assignedToMe', 'debug', 'limit', 'sortBy', or 'sortDirection', leaving most parameters undocumented. The description adds some meaning for the three mentioned but fails to cover the majority.

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 verb ('List') and resource ('Linear issues/tickets'), and mentions filtering capabilities. It distinguishes the tool's purpose from siblings like 'get_issue' (single issue) and 'create_issue' (write operation). However, it doesn't explicitly differentiate from 'list_projects' or 'list_teams' in terms of resource type, which keeps it from a perfect score.

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 description provides implied usage context ('to browse and find issues in your Linear workspace'), which suggests this is for exploration rather than specific retrieval. It doesn't explicitly state when to use this vs. alternatives like 'get_issue' for single issues or mention any exclusions, leaving some ambiguity for the agent.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the tool lists members with filtering and is useful for finding details, but doesn't cover critical behaviors like pagination (implied by 'limit' parameter), authentication requirements, rate limits, error handling, or whether it's read-only (though implied by 'list'). For a tool with 4 parameters and no annotation coverage, this is insufficient.

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 concise and front-loaded, with two sentences that directly state the purpose and utility. There's no wasted text, and it efficiently communicates core information. However, it could be slightly more structured by explicitly separating purpose from usage, but this is minor.

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 the complexity (4 parameters, no annotations, no output schema), the description is incomplete. It lacks details on parameter meanings, behavioral traits (e.g., pagination, auth), and output format. While it states the purpose clearly, it doesn't provide enough context for an agent to reliably use the tool without additional inference or errors.

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%, so the description must compensate for undocumented parameters. It only mentions 'optional filtering by name,' which corresponds to the 'nameFilter' parameter, but ignores 'teamId,' 'limit,' and 'debug.' This adds minimal value beyond the schema, failing to fully address the coverage gap. With 0% coverage, a baseline of 3 is not met due to incomplete parameter explanation.

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 tool's purpose: 'List Linear team members with optional filtering by name.' It specifies the verb ('List'), resource ('Linear team members'), and scope ('optional filtering by name'), which is specific and actionable. However, it doesn't explicitly differentiate from sibling tools like 'list_teams' or 'list_issues', which would be needed for a score of 5.

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 description provides minimal guidance: 'This tool is useful for finding member details including usernames, display names, and emails.' It implies usage for retrieving member information but lacks explicit when-to-use scenarios, prerequisites, or alternatives (e.g., when to use 'list_teams' instead). No exclusions or comparisons to sibling tools are mentioned, leaving gaps in usage context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

No annotations are provided, so the description carries the full burden. It mentions 'optional filtering' and output details, but lacks critical behavioral traits like pagination (implied by 'limit' param but not described), rate limits, authentication requirements, or whether it's read-only. The description doesn't contradict annotations, but is insufficient for a mutation-free tool with 9 parameters.

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 a single, well-structured sentence that front-loads the core action and key features. Every word earns its place, with no redundancy or fluff, making it highly efficient.

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 9 parameters with 0% schema coverage, no annotations, and no output schema, the description is incomplete. It covers basic purpose and some filtering but misses behavioral context, parameter details, and output format. For a list tool with many options, this leaves significant gaps for an AI agent.

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%, so the description must compensate. It mentions filtering by 'team, name, and archive status', which partially covers 3 of 9 parameters (teamId, nameFilter, includeArchived), but omits details on others like 'state', 'limit', 'fuzzyMatch', 'debug', 'projectId', and 'includeThroughIssues'. The description adds some meaning but leaves most parameters undocumented.

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 verb ('List') and resource ('Linear projects'), and specifies optional filtering criteria (team, name, archive status) and output details (status, lead, progress, dates). It distinguishes from siblings like 'get_project' by indicating it lists multiple projects with filtering, though it doesn't explicitly contrast with 'list_issues' or 'list_teams'.

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 description implies usage for retrieving multiple projects with filtering, but doesn't explicitly state when to use this vs. alternatives like 'get_project' (for a single project) or other list tools. No guidance on prerequisites, exclusions, or specific scenarios is provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. While it mentions what data is included (members, projects, issues), it doesn't describe important behavioral aspects like whether this is a read-only operation, if it requires authentication, rate limits, pagination behavior (beyond the limit parameter), or what the output format looks like. For a list operation with no annotation coverage, this leaves significant gaps.

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 two concise sentences that efficiently convey the tool's purpose and usage. Every word earns its place, with no redundant information. The structure is front-loaded with the core functionality followed by the usage context.

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 that there's no output schema and no annotations, the description should do more to explain what the tool returns and its behavioral characteristics. While it adequately describes the purpose and high-level usage, it lacks details about output format, error conditions, and operational constraints that would be important for an agent to use this tool effectively.

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?

The schema description coverage is 100%, so all parameters are documented in the schema. The description doesn't add any parameter-specific information beyond what's in the schema (like explaining how nameFilter works or when to use debug mode). With complete schema coverage, the baseline score of 3 is appropriate since the description doesn't enhance parameter understanding.

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 verb ('List') and resource ('Linear teams'), specifies the scope ('with details about their members, projects, and issues'), and distinguishes this tool from siblings like list_issues and list_projects by focusing on teams as the primary entity. It provides a high-level view purpose that differentiates it from more specific sibling tools.

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 description explicitly states when to use this tool ('to get a high-level view of all teams'), which provides clear context. However, it doesn't specify when NOT to use it or mention alternatives among the sibling tools (like whether list_members or list_projects might be better for specific needs), so it falls short of the highest score.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.