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 only states that a TODO is created ('Create a new TODO item') and gives setup prerequisites, but it does not mention potential side effects, required permissions, response behavior, or failure modes. For a mutation tool, this is a significant gap—nothing indicates what happens after creation or what constraints apply.

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 long and front-loaded with the core action, followed by an important setup note in all caps for emphasis. Every sentence earns its place; the second sentence provides critical workflow context. There is zero redundancy 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?

The tool has 7 parameters and nested objects, but no output schema. The description gives useful setup context (calling list_projects and switch_project) and clarifies the tool's role, but it does not explain return values, error handling, or the impact of creating a TODO (e.g., does it appear in list_todos immediately?). For moderate complexity, this description is partial 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?

The input schema has 100% description coverage for all 7 parameters, so the schema already documents each parameter's meaning. The description adds no additional parameter-specific information beyond the phrase 'optional metadata,' which is vague and not tied to a specific parameter. Since schema coverage is high, the baseline 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 tool's function: 'Create a new TODO item with optional metadata.' It uses a specific verb (create) and resource (TODO), and the optional metadata mention adds nuance. This distinguishes it from siblings like update_todo and delete_todo, which also act on TODOs but with different actions.

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 explicit pre-requisite guidance: 'Before creating your first TODO, call list_projects to check existing workspaces, then call switch_project to set up your project workspace.' This tells the agent when and in what order to use related tools. However, it does not explicitly contrast with alternatives like update_todo or search_todos, so it lacks full exclusionary guidance.

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 disclosing behavioral traits. It does not mention that deletion may fail if dependencies exist, that 'force' overrides this, or what the outcome/return value is. It only states the action itself, leaving important behavior undisclosed.

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 short sentence with no filler or repetition. It front-loads the verb and resource, making it maximally concise.

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?

The schema covers parameters well, but the lack of annotations and output schema means the description should provide more behavioral context, such as dependency handling and return behavior. It is adequate for a simple delete but has clear gaps in completeness.

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 already documents both parameters (id and force) with clear descriptions, covering 100% of parameters. The description adds no additional parameter context beyond what the schema provides, so a 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 uses the specific verb 'Delete' with the resource 'TODO item', clearly distinguishing it from sibling tools like create_todo, update_todo, and get_todo. The action is unambiguous.

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 only states the basic action; it does not provide guidance on when to use it versus other tools, nor does it mention the dependency/force behavior that might affect usage. Usage is implied but not explicitly guided.

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 must disclose behavioral traits. It does not reveal whether the tool is read-only, if it computes aggregate data, or if it has side effects. The word 'comprehensive' adds no behavioral detail. This is a significant gap for a tool that likely reads data and produces a report.

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 sentence, concise and front-loaded. However, it is under-specified, using vague language like 'comprehensive.' While it earns points for brevity, the lack of structure or elaboration makes it less helpful than a slightly longer, information-dense description.

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?

The tool has no annotations and no output schema, so the description must explain return values and scope. It only says 'Generate a comprehensive progress report,' leaving the agent to guess what data is included, how it is grouped, and how it differs from stats or list outputs. The sibling context suggests a reporting tool for TODOs, but the description is incomplete.

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 each parameter having a description and default values. The description adds no parameter-specific meaning beyond the schema. As per the rubric, the baseline is 3 when the schema covers all parameters, and the description does not compensate or add extra context.

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 states a verb ('Generate') and resource ('progress report'), but the resource is vague—it doesn't specify what the report covers (e.g., TODOs). This makes it difficult to distinguish from sibling tools like get_stats, which might also summarize progress. A more specific description like 'Generate a progress report of TODOs grouped by status, priority, or tag' would clarify purpose.

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?

There is no guidance on when to use this tool versus alternatives like get_stats or search_todos. No exclusions or alternatives are mentioned. The description implies a report-generation use case but does not state any context or prerequisites.

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, the description carries the full burden. It only says 'Get,' implying a read operation, but does not disclose whether any permissions are needed, whether it is side-effect free, or what exact data is returned. No context about return format or potential restrictions is provided.

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, concise sentence with no redundant wording. It is front-loaded with the action and resource, making it 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?

The tool is simple with no parameters and no output schema, but the description still lacks specificity about what 'workspace information' includes. It could benefit from an example or list of typical return fields. It is minimally adequate but leaves gaps for an agent to infer behavior.

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 tool has zero parameters, and the schema coverage is trivially 100% since the schema is empty. According to baseline, a 0-parameter tool receives a 4 even without parameter descriptions, and no compensation is needed.

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 states the verb 'Get' and the resource 'current project workspace information,' but 'workspace information' is vague and not further specified. It does not differentiate from sibling tools like list_projects or get_stats, which could also provide project-related data.

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 guidance is given on when to use this tool versus alternatives. It implies usage for retrieving current project info, but there are no explicit when/when-not statements or mentions of sibling alternatives.

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 present, so the description carries the full burden of disclosing behavior. It only says 'Get quick statistics,' implying a read-only operation, but it does not describe what statistics are returned, whether scope is project-wide or workspace-wide, or any other behavioral traits such as performance implications or required 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 a single short sentence, 'Get quick statistics about TODOs,' which is concise and front-loaded. It contains no fluff, but its brevity does leave out important details, though that is captured 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?

Given the absence of an output schema and annotations, the description is the sole source of information about what the tool returns. 'Quick statistics about TODOs' is vague: it does not specify the type of statistics (e.g., counts, statuses), the scope (current project vs all projects), or the output format. This is insufficient for an agent to fully understand the tool's behavior.

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 tool has zero parameters, so the input schema fully covers parameter semantics (vacuously). The description adds nothing about parameters because there are none to describe. This meets the baseline of 4 for 0-parameter tools.

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 states a clear verb 'Get' and resource 'statistics about TODOs', indicating an aggregate summary. It does not explicitly distinguish from sibling tools like generate_report or list_todos, but the term 'quick statistics' suggests a lightweight overview, which differentiates it somewhat.

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 guidance is provided on when to use this tool versus alternatives. The description does not mention when to choose get_stats over generate_report or list_todos, nor does it indicate exclusions. This leaves the agent without direction for tool selection.

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 for behavioral transparency. It only states the intent to 'Get detailed information' but does not disclose return format, error behavior, or confirm that it is a safe read-only operation. The verb 'Get' implies read-only, but it is not explicitly stated.

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, focused sentence that immediately conveys the tool's purpose. Every word is necessary and there is no redundancy or filler.

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 one-parameter get tool, the description combined with the schema is largely sufficient. The only gap is the lack of detail about what 'detailed information' includes, but given the tool's simplicity and the absence of an output schema, the description is complete enough for an agent to understand the tool's function.

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 provides 100% coverage of the single parameter 'id' with a clear description. The tool description adds no extra meaning beyond what the schema already offers, so 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 the resource ('detailed information about a specific TODO'), which distinguishes it from siblings like list_todos and search_todos. It unambiguously indicates single-item retrieval by ID.

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 uses 'specific' to imply this is for retrieving a single TODO, but it does not explicitly state when to use it over list_todos or search_todos, nor does it mention any when-not-to-use conditions. Guidance is only implied by the verb and 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?

With no annotations, the description must carry the burden of behavioral disclosure. It clearly states the operation (List all), but does not explicitly mention that it is read-only, whether it returns a list of names or objects, or any potential performance implications. The 'List all' phrasing implies a read operation, but explicit safety statements are absent.

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, with the main purpose stated first and the usage recommendation second. It wastes no words and is 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?

For a zero-parameter tool with no output schema, the description adequately covers what the tool does, when to use it, and its relationship to switch_project. No critical information is missing.

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 tool has zero parameters, and the schema is an empty object. The baseline for zero parameters is 4, and the description does not need to explain any parameters.

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 uses the specific verb 'List' and identifies the resource as 'available project workspaces', clearly distinguishing it from sibling tools like switch_project or get_project_info.

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 recommends calling this tool first to see existing projects before using switch_project, providing clear when-to-use guidance and naming an alternative.

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 does not mention pagination, default limits, response format, or any side effects. Listing could imply read-only, but that is not explicitly stated, and there is no detail about how filtering/sorting behaves.

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 concise sentence that is front-loaded with the verb 'List' and the object 'TODOs'. It contains no redundant words and earns its place.

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 a modest 6-parameter list tool with no output schema, the description is sufficient but minimal. It lacks guidance on defaults like sortBy or pagination, and does not address how this tool differs from search_todos, leaving some gaps for an agent deciding which tool to invoke.

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 all six parameters individually described including enums and defaults. The description adds no extra meaning beyond the schema, which is acceptable given the high schema coverage, but it does not compensate for any missing context.

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 uses a specific verb 'List' with resource 'TODOs' and mentions optional filtering and sorting, making the core purpose clear. However, it does not differentiate from the sibling 'search_todos', so it lacks sibling distinction.

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 'optional filtering and sorting' implies when to use (listing with simple filters), but there is no explicit guidance on when not to use it or when to prefer 'search_todos' or other siblings. Context is implied, not stated.

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 only states the searchable fields, but does not disclose return format, pagination, matching behavior (e.g., fuzzy vs exact), or how the caseSensitive parameter affects results. For a search tool, this is a notable gap.

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 is easy to skim and front-loads the key action and resource. Every word contributes meaning with no filler or redundancy.

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 2-parameter search tool with no output schema, the description is minimal but adequate for basic understanding. However, it leaves gaps such as what the response looks like (e.g., a list of TODOs) and any limitations on result size, which would help the agent invoke the tool with correct expectations.

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 both parameters have descriptions in the schema. The tool description repeats the scope already captured by the query parameter description ('searches in title, description, and metadata'), adding little semantic value beyond the schema. Baseline 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 uses a specific verb ('Search') and clearly identifies the resource (TODOs) and the scope (by title, description, or metadata). This distinguishes it from siblings like list_todos (listing all) and get_todo (fetching by ID), making its purpose immediately 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 description implies this tool is for finding TODOs based on text fields, but it does not explicitly state when to prefer it over list_todos or get_todo, nor does it mention any exclusions or alternative tools. The usage context is implied rather than explicitly governed.

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, the description carries the transparency burden. It discloses key behavioral traits: the tool can create a new project if it doesn't exist, it isolates TODO data per project, and it is a mandatory prerequisite for creating TODOs. It does not detail additional effects (e.g., whether switching resets some state), but the disclosed information is valuable and accurate.

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 at three sentences, front-loaded with the primary purpose, and every sentence adds distinct value: purpose, mandatory usage, recommendation, and isolation behavior. No redundant or filler content.

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 single-parameter tool with no output schema, the description covers the essential context: what the tool does, when it must be used, how to avoid duplicate projects, and the isolation guarantee. This is complete enough for an agent to select and invoke the tool 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?

The schema already provides 100% coverage for projectId with a rich description including naming conventions and a pointer to list_projects. The tool description does not add new parameter semantics beyond what is already in the schema, so the baseline 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 tool's function: 'Switch to a different project workspace or create a new one.' It distinguishes itself from the TODO-centric siblings by focusing on project workspace management and explicitly mentions data isolation ('Each project isolates its TODO data completely').

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 explicit when-to-use guidance: 'You must call this tool to set up a project before creating any TODOs.' It also recommends using list_projects first to avoid duplicates, which is a clear alternative/preceding tool. This gives the agent actionable context for sequencing.

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, the description carries the full burden of behavioral disclosure. It merely says 'Update' without detailing whether updates are partial or full replacements, how unspecified fields are handled, or whether there are any side effects. The schema provides some per-field merge semantics (e.g., 'replaces existing' vs 'preserves existing'), but the description itself offers no such 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 a single sentence that states the core action clearly. It is perfectly concise with no wasted words or redundant information, though it is minimal.

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 (14 parameters, no output schema) and lack of annotations, the description is severely incomplete. It does not explain return values, partial update behavior, or whether fields are merged or replaced beyond what the schema hints at. More context is needed for an agent 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?

The input schema provides descriptions for all 14 parameters (100% coverage), making the schema the primary source of parameter semantics. The description adds no additional parameter details, so 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 verb (Update) and resource (existing TODO item), distinguishing it from sibling tools like create_todo, get_todo, and delete_todo. The purpose is immediately unambiguous.

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 guidance is provided on when to use this tool versus alternatives. It does not explain that this is for modifying an existing TODO as opposed to creating a new one, nor does it mention any prerequisites or conditions for use.

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