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. 'Create a new task' implies a write operation but doesn't specify permissions needed, whether tasks are unique, what happens on duplicate titles, or the response format. It lacks critical behavioral details for a mutation tool.

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 extremely concise at three words, with zero wasted text. It's front-loaded with the core action, though this brevity comes at the cost of completeness. Every word serves a purpose in stating the tool's function.

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 mutation tool with no annotations and no output schema, the description is incomplete. It doesn't explain what a 'task' entails in this system, what the creation response includes, or any side effects. Given the complexity of creating a resource, more context is needed for effective use.

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%, with all parameters (title, status, assignedTo) documented in the schema. The description adds no additional parameter semantics beyond what the schema provides, so it meets the baseline for high schema coverage without adding value.

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 'Create a new task' clearly states the verb ('create') and resource ('task'), but it's vague about what constitutes a task in this system and doesn't distinguish it from sibling tools like 'create_user' or 'update_task'. It provides basic purpose but lacks specificity about the domain or scope.

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 no guidance on when to use this tool versus alternatives like 'update_task' or 'get_task', nor does it mention prerequisites or context for task creation. It's a bare statement with no usage context, leaving the agent to infer when this is appropriate.

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 for behavioral disclosure. 'Create a new user' implies a write operation but lacks critical details: it doesn't specify required permissions, whether the operation is idempotent, what happens on duplicate emails, or what the response contains. This leaves significant behavioral gaps for a mutation tool.

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 extremely concise at just three words, with zero wasted language. It's front-loaded with the core action and resource, making it efficient for quick understanding, though this brevity contributes to gaps in other dimensions.

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 user creation tool with no annotations and no output schema, the description is insufficient. It doesn't address behavioral aspects like authentication needs, error conditions, or return values, nor does it provide usage context relative to sibling tools. The 100% schema coverage helps with parameters but doesn't compensate for other missing context.

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%, with all parameters well-documented in the schema itself. The description adds no additional parameter information beyond what's already in the structured data, so it meets the baseline for high schema coverage without compensating value.

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') and resource ('new user'), making the tool's purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'create_task' beyond the resource type, missing explicit distinction that would warrant 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 no guidance on when to use this tool versus alternatives. There's no mention of prerequisites, when not to use it, or how it relates to sibling tools like 'get_user' or 'get_users', leaving the agent without contextual usage instructions.

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 but offers minimal insight. It doesn't specify if this is a read-only operation, what happens if the ID is invalid (e.g., error handling), or any rate limits or authentication requirements. The description is too brief to adequately inform an agent about behavioral traits beyond the basic action.

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 extremely concise and front-loaded, consisting of a single sentence that directly states the tool's purpose without any unnecessary words. Every part of the sentence ('Get a specific task by ID') contributes essential information, making it efficient and easy to parse.

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 lack of annotations and output schema, the description is insufficient for a tool that retrieves data. It doesn't explain what information is returned (e.g., task details, status, metadata) or potential errors, leaving the agent with incomplete context for proper invocation and response handling. This is a significant gap for a data retrieval tool.

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 input schema has 100% description coverage, with the 'id' parameter clearly documented as 'Task ID'. The description adds no additional meaning beyond this, as it only restates that the tool retrieves a task 'by ID' without elaborating on ID format or constraints. This meets the baseline score since the schema handles parameter documentation effectively.

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 ('Get') and resource ('a specific task by ID'), making the purpose immediately understandable. It distinguishes from sibling tools like 'get_tasks' (plural) by specifying retrieval of a single task. However, it doesn't explicitly mention what 'get' entails (e.g., fetching details vs. metadata), which prevents 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 no guidance on when to use this tool versus alternatives like 'get_tasks' (for listing multiple tasks) or 'search' (for finding tasks by criteria). It also doesn't mention prerequisites such as needing a valid task ID or whether the ID must exist in the system, leaving usage context unclear.

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 'Get all tasks' but doesn't mention whether this is a read-only operation, if it requires authentication, how results are returned (e.g., pagination, format), or potential rate limits. For a retrieval tool with zero annotation coverage, this leaves significant gaps in understanding its 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 directly states the tool's purpose without unnecessary words. It's front-loaded with the core action and resource, making it easy to parse. Every part of the sentence earns its place by conveying essential information.

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 low complexity (simple retrieval with two optional filters), no annotations, and no output schema, the description is minimally adequate. It covers the basic purpose but lacks details on behavioral traits, usage context, and return values. For a tool with no output schema, it should ideally hint at the response format, but it doesn't, leaving room for improvement.

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 input schema has 100% description coverage, with clear documentation for both parameters ('status' with enum values and 'assignedTo' as user ID). The description doesn't add any meaning beyond the schema—it doesn't explain parameter interactions, default behaviors, or usage examples. With high schema coverage, the baseline score of 3 is appropriate as the 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 ('Get') and resource ('all tasks from the mock database'), making the purpose immediately understandable. However, it doesn't distinguish this tool from its sibling 'get_task' (singular) or 'search', which could also retrieve tasks. The description is specific but lacks sibling differentiation.

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 no guidance on when to use this tool versus alternatives like 'get_task' (for a single task), 'search' (for more complex queries), or 'create_task' (for adding tasks). It mentions 'all tasks' but doesn't clarify if this is the default listing tool or when filtering via parameters is appropriate.

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 states it retrieves a user by ID but doesn't mention whether this requires authentication, what happens if the ID doesn't exist (e.g., error handling), or the format of the return data. This leaves significant gaps for a read operation.

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 ('Get a specific user by ID') with zero wasted words. It's appropriately sized for a simple retrieval tool.

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 simplicity (one parameter, no output schema, no annotations), the description is minimal. It lacks context on authentication needs, error cases, or return format, which are important for a read operation. While concise, it doesn't provide enough completeness for reliable agent use.

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%, with the single parameter 'id' documented as 'User ID' in the schema. The description adds no additional meaning beyond this, such as ID format or constraints. Since the schema does the heavy lifting, the baseline score of 3 is appropriate.

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 ('Get') and resource ('a specific user by ID'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'get_users' (plural) or 'search', which might also retrieve user information, so it doesn't achieve full sibling differentiation.

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 no guidance on when to use this tool versus alternatives like 'get_users' (for multiple users) or 'search' (for broader queries). It lacks explicit when/when-not instructions or named alternatives, leaving usage context implied at best.

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 states it retrieves data ('Get'), implying a read-only operation, but doesn't mention potential behaviors like pagination, rate limits, authentication requirements, or what happens if the database is empty. This leaves significant gaps for a tool that interacts with a database.

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, direct sentence with no wasted words. It front-loads the core action and resource, making it efficient and easy to parse. Every part of the sentence contributes essential information.

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 lack of annotations and output schema, the description is incomplete for a database query tool. It doesn't explain the return format (e.g., list of user objects), error conditions, or any limitations (like maximum result size). For a tool with one parameter and no structured behavioral hints, more context is needed to guide effective use.

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 input schema has 100% description coverage, with the 'role' parameter fully documented including its enum values. The description doesn't add any parameter-specific information beyond implying retrieval of 'all users', which aligns with the optional filtering via 'role'. Since the schema does the heavy lifting, the baseline score of 3 is appropriate.

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 ('Get') and resource ('all users from the mock database'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'get_user' (singular) or 'search', which might also retrieve user data, so it doesn't reach the highest 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 no guidance on when to use this tool versus alternatives like 'get_user' (for a single user) or 'search' (which might offer more flexible filtering). It mentions retrieving 'all users' but doesn't clarify if this is the preferred method for bulk retrieval or if there are performance considerations.

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. 'Search users and tasks' implies a read operation but doesn't disclose behavioral traits like whether it's paginated, what fields are searchable, if it requires authentication, or how results are returned. For a search tool with zero annotation coverage, 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 extremely concise with just three words, which is efficient and front-loaded. However, it may be overly terse given the lack of other context, bordering on under-specification rather than optimal conciseness. It earns a 4 for zero waste but could benefit from slightly more detail.

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 of a search operation, no annotations, and no output schema, the description is incomplete. It doesn't explain what the tool returns, how results are structured, or any behavioral nuances. For a tool that likely returns complex data, this minimal description leaves significant gaps for the agent to infer.

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%, with the single parameter 'query' documented in the schema. The description doesn't add any meaning beyond what the schema provides, such as explaining query syntax, examples, or limitations. With high schema coverage, the baseline score of 3 is appropriate as the description doesn't compensate but also doesn't detract.

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 'Search users and tasks' states the general purpose but lacks specificity. It mentions the resources (users and tasks) but doesn't specify the verb beyond 'search' or differentiate from sibling tools like get_users or get_tasks. The purpose is clear but vague about what kind of search operation this performs.

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 no guidance on when to use this tool versus alternatives like get_users, get_tasks, or other search-related tools. It doesn't mention prerequisites, context for usage, or any exclusions. The agent must infer usage from the name alone.

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 states 'update' implies mutation but fails to disclose critical traits like required permissions, whether updates are reversible, error handling, or rate limits. This is a significant gap for a mutation tool.

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 'Update an existing task' is a single, efficient sentence with zero waste. It's appropriately sized and front-loaded, making it easy to parse without unnecessary details.

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 as a mutation tool with no annotations and no output schema, the description is incomplete. It lacks behavioral context, usage guidelines, and details on what happens post-update, making it inadequate for safe and effective use by 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 100%, so the schema fully documents all 4 parameters (id, title, status, assignedTo) with descriptions and enum for status. The description adds no additional meaning beyond what the schema provides, 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 'Update an existing task' clearly states the verb ('update') and resource ('task'), but it's vague about what aspects can be updated and doesn't distinguish it from potential sibling tools like 'create_task' or 'get_task'. It meets the basic requirement but lacks specificity.

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 no guidance on when to use this tool versus alternatives such as 'create_task' for new tasks or 'get_task' for viewing. There's no mention of prerequisites, context, or exclusions, leaving usage entirely implied from the tool name.

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