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 adding comments and documenting relationships, but fails to describe critical behaviors: whether this modifies files (implied but not explicit), what permissions or side effects are involved, error handling, or output format. For a tool that likely writes to files, 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 concise and front-loaded, consisting of two clear sentences that directly state the tool's purpose and outcome. There is no wasted language, though it could be slightly more structured by explicitly separating action from context. Overall, it is 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 complexity of a tool with 5 parameters, no annotations, and no output schema, the description is incomplete. It lacks details on behavioral traits (e.g., file modifications, error handling), usage context, and output expectations. While the schema covers parameters, the description does not compensate for the absence of annotations or output schema, leaving significant gaps for the 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 parameters. The description adds no additional meaning beyond what the schema provides—it does not explain how 'producerDir' and 'consumerDir' relate to the commenting process or clarify the purpose of 'toolName' in context. Baseline 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 specific action ('Add cross-reference comments'), the target ('validated producer/consumer pairs'), and the outcome ('Documents the contract relationship in both files'). It uses precise verbs and distinguishes itself from siblings like 'compare' or 'trace_usage' by focusing on documentation through comments rather than analysis or tracing.

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. It mentions 'validated producer/consumer pairs' but does not specify how validation occurs, what prerequisites are needed, or when to choose this over other tools like 'scaffold_consumer' or 'trace_file'. Without such context, the agent lacks clear 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. It mentions the pipeline steps and output format but lacks critical details: whether this is a read-only analysis or modifies data, performance characteristics, error handling, or what 'detailed report' entails. For a complex 5-parameter tool with no annotations, 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 a single, efficient sentence that front-loads the core purpose. It avoids unnecessary words, though it could be slightly more structured by separating the pipeline steps from the output. Every phrase contributes to understanding 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 complex analysis tool with 5 parameters, no annotations, and no output schema, the description is incomplete. It doesn't explain the report structure, error conditions, or behavioral implications like whether it's safe to run repeatedly. Given the lack of structured data, more detail 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?

Schema description coverage is 100%, so parameters are well-documented in the schema. The description adds minimal value beyond the schema: it implies 'producerDir' and 'consumerDir' are for schemas and usage tracing, and 'format' controls the report output, but doesn't explain parameter interactions or provide additional context. Baseline 3 is appropriate given high schema 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 clearly states the tool performs a 'full analysis pipeline' with specific actions: extract schemas, trace usage, and compare for mismatches, returning a detailed report. It uses specific verbs and identifies the resource as producer/consumer schemas, but doesn't explicitly differentiate from siblings like 'extract_schemas' or 'trace_usage' which handle parts of this pipeline.

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 mentions the pipeline steps but doesn't specify prerequisites, appropriate contexts, or when to choose this over sibling tools like 'extract_schemas' for schema extraction alone or 'trace_usage' for usage tracing.

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 only states what the tool does, not how it behaves. It doesn't disclose error conditions (e.g., invalid file paths), output format, whether it's read-only or has side effects, performance characteristics, or any constraints. This leaves significant behavioral gaps for a tool that presumably parses and analyzes code.

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 with zero waste. It's front-loaded with the core purpose and appropriately sized for a single-parameter tool with straightforward functionality.

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 tool that extracts structured definitions from code (a non-trivial operation), the description is incomplete. With no annotations and no output schema, it doesn't explain what the extracted definitions look like, error handling, or limitations. The context signals indicate moderate complexity (parsing TypeScript), but the description doesn't address this adequately.

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 the single parameter 'filePath' as 'Path to a TypeScript file'. The description adds no additional parameter semantics beyond implying the file must contain MCP tool definitions. Baseline 3 is appropriate when 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 specific action ('extract') and resource ('MCP tool definitions') with precise scope ('from a single TypeScript file'). It distinguishes from siblings like extract_schemas (which extracts schemas rather than tool definitions) and trace_file/trace_usage (which trace usage rather than extract definitions).

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 about when to use this tool versus alternatives. While the description implies it works on TypeScript files, it doesn't mention prerequisites (e.g., file must exist), exclusions (e.g., non-TypeScript files), or when to choose other extraction-related siblings like extract_schemas or trace_file.

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 scanning and parsing actions but doesn't describe what happens during execution: whether it's read-only, if it modifies files, error handling, performance characteristics, or output format. For a tool with 3 parameters and no annotations, this leaves significant behavioral 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 appropriately concise with two sentences that directly state the tool's function. It's front-loaded with the core purpose and avoids unnecessary details. However, it could be slightly more structured by explicitly separating purpose from method.

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 has 3 parameters, no annotations, and no output schema, the description is incomplete. It doesn't explain what the extracted schemas look like, how they're returned, error conditions, or typical use cases. For a tool performing code analysis with multiple configuration options, more context is needed to guide effective usage.

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 (rootDir, include, exclude) with descriptions. The description adds no additional parameter semantics beyond implying source code scanning context. It doesn't explain parameter interactions, default behaviors, or examples. 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 tool's purpose: 'Extract MCP tool definitions (ProducerSchemas) from server source code' with specific verbs 'scans' and 'parses'. It identifies the resource (server source code) and method (scanning for server.tool() calls). However, it doesn't explicitly differentiate from sibling tools like 'extract_file' or 'trace_file' that might also work with source code.

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. It doesn't mention sibling tools like 'extract_file' (which might extract files rather than schemas) or 'trace_file' (which might trace usage). There's no context about prerequisites, when this extraction is needed, or what scenarios warrant its use over other tools.

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 this is a read operation ('Get'), but does not cover aspects like error handling (e.g., what happens if the project directory is invalid), performance considerations, or output format. The description lacks details on what 'status' entails beyond a high-level list.

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 the status') and specifies key components (config, cache state, validation result). There is no wasted verbiage, and every word contributes to understanding 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?

Given the tool's moderate complexity (single parameter, read-only operation) and lack of annotations or output schema, the description is minimally adequate. It covers what the tool does but lacks details on behavioral traits, error cases, or output structure, leaving gaps for an agent to infer usage 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 input schema has 100% description coverage, with 'projectDir' clearly documented as the root directory containing the .trace-mcp config. The description does not add any parameter-specific details beyond what the schema provides, such as format examples or constraints, so it meets the baseline for high schema 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 clearly states the verb 'Get' and the resource 'status of a trace project', specifying what information is retrieved (config, cache state, and last validation result). It distinguishes itself from siblings like 'init_project' or 'trace_file' by focusing on status retrieval rather than creation or tracing operations.

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. It does not mention prerequisites, such as requiring an initialized project, or compare it to siblings like 'trace_usage' or 'watch' that might overlap in functionality. Usage is implied but not explicitly 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 full burden. It mentions creating a project structure and .trace-mcp config directory, but doesn't disclose critical behavioral traits: whether this is idempotent (can it be run multiple times?), what permissions are needed, if it overwrites existing files, or what happens on failure. For a tool that creates directories and configs, this is a significant 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?

Two concise sentences that efficiently state the purpose and outcome. The description is front-loaded with the main action ('Initialize a trace project'), and every sentence adds value without redundancy. It could be slightly more structured by explicitly listing key behaviors, but it's appropriately sized.

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 (initializing a project with multiple parameters) and no annotations or output schema, the description is incomplete. It doesn't explain what the tool returns, error conditions, or side effects. For a tool that likely creates files and directories, more context on outcomes and behaviors is needed to be fully helpful to 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 already documents all 5 parameters with descriptions and enums. The description adds no parameter-specific information beyond what's in the schema. According to rules, with high schema coverage (>80%), the baseline is 3 even with no param info in 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 verb 'Initialize' and resource 'trace project', specifying it creates a project structure for watch mode and caching. It distinguishes from siblings like 'get_project_status' (status check) and 'watch' (monitoring), but doesn't explicitly contrast with 'scaffold_consumer' or 'scaffold_producer' which might have overlapping initialization functions.

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 explicit guidance on when to use this tool versus alternatives like 'scaffold_consumer' or 'scaffold_producer'. The description implies it's for initial setup, but doesn't specify prerequisites, timing, or exclusions. Without context signals about when this should be called first versus other tools, usage is 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the tool 'Generates' code, implying a read-only or creation operation, but lacks details on permissions needed, whether it overwrites existing files, error handling behavior, or output format specifics. For a code generation tool with zero annotation coverage, this is a significant 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 efficiently conveys the tool's purpose, output formats, and goal. Every word earns its place with no redundancy or unnecessary details, making it easy to parse and understand quickly.

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 (code generation with multiple output targets) and no annotations or output schema, the description is adequate but incomplete. It covers the 'what' but lacks details on behavioral traits, error handling, or output structure. For a tool with 5 parameters and no structured safety hints, more context would be beneficial.

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 5 parameters thoroughly. The description does not add any additional meaning beyond what the schema provides (e.g., it doesn't explain the relationship between producerDir and toolName or provide examples). Baseline 3 is appropriate when 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 specific action ('Generate consumer code') and resource ('from a producer schema'), specifying the output formats (TypeScript functions, React hooks, or Zustand actions) and their purpose ('correctly call MCP tools'). It distinguishes from siblings like scaffold_producer by focusing on consumer-side code generation rather than producer/server creation.

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 when needing to create client-side code for MCP tools, but does not explicitly state when to use this tool versus alternatives (e.g., manually writing code or using other scaffolding tools). No exclusions or prerequisites are mentioned, leaving the context somewhat open-ended.

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. It discloses the tool's generative behavior ('Creates MCP tool definition'), but doesn't specify output format, error handling, or side effects like file system changes, leaving 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?

Two concise sentences front-load the core purpose and action, with zero wasted words. The structure efficiently communicates the tool's function without redundancy or 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?

For a 3-parameter mutation tool with no annotations or output schema, the description is minimally adequate but incomplete. It covers the what and how at a high level but lacks details on behavioral traits, output expectations, or integration with sibling tools.

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 parameters are well-documented in the schema. The description adds no additional parameter semantics beyond implying that consumerDir and toolName relate to analyzing client code, which is already suggested by the 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 specific action ('Generate producer schema stub from consumer usage') and the resource ('MCP tool definition'), distinguishing it from siblings like scaffold_consumer by focusing on producer-side generation based on client code analysis.

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 when needing to create a tool definition from existing consumer code, but lacks explicit guidance on when to use this versus alternatives like scaffold_consumer or init_project, and doesn't 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 states what the tool does but lacks details on traits like whether it's read-only or destructive, output format (e.g., logs, reports), error handling, or performance implications (e.g., speed, resource usage). This leaves significant gaps in understanding how the tool behaves beyond its basic function.

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, clear sentence that efficiently conveys the core purpose without any wasted words. It's front-loaded with the essential information, making it easy to parse and understand quickly, which is ideal for conciseness.

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 tracing tool usage and the lack of annotations and output schema, the description is insufficiently complete. It doesn't explain what 'trace' entails (e.g., logging calls, analyzing dependencies), what the output looks like, or any behavioral nuances. For a tool with no structured support, more descriptive 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 'filePath' clearly documented as 'Path to a TypeScript file'. The description adds no additional parameter semantics beyond this, such as file format constraints or path validation rules. Given the high schema coverage, a baseline score of 3 is appropriate as the schema handles 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 tool's purpose with a specific verb ('Trace') and resource ('MCP tool usage in a single TypeScript file'), making it immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'trace_usage' or 'extract_file', which could have overlapping functionality, preventing 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. It doesn't mention prerequisites, context (e.g., debugging vs. analysis), or comparisons to siblings like 'trace_usage' or 'extract_file', leaving the agent to infer usage scenarios without explicit direction.

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 lacks behavioral details. It doesn't disclose whether this is a read-only analysis tool, what permissions are needed, how results are returned, or any performance implications. The description explains the analysis goal but not the operational 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 perfectly concise with two clear sentences that each earn their place. The first sentence states the overall purpose, and the second provides specific technical details about what it finds and tracks.

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 tool with 3 parameters, no annotations, and no output schema, the description is incomplete. It explains what the tool analyzes but doesn't cover how results are returned, what format they take, or any behavioral constraints. The agent would need to guess about the output and operational characteristics.

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 three parameters thoroughly. The description adds no additional parameter context beyond what's in the schema, maintaining the baseline score for high schema 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 clearly states the specific action ('Trace'), target ('client code uses MCP tools'), and mechanism ('Finds callTool() invocations and tracks which properties are accessed on results'). It distinguishes itself from siblings like trace_file by focusing on tool usage analysis rather than file-level tracing.

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 like trace_file or other siblings. The description explains what it does but offers no context about appropriate scenarios, 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?

No annotations are provided, so the description carries the full burden. It mentions actions and auto-revalidation, but lacks details on behavioral traits: it doesn't specify what 'auto-revalidate contracts' entails (e.g., triggers, effects), whether the tool runs persistently, permission requirements, error handling, or rate limits. For a tool with potential side effects (auto-revalidation), this is a significant gap in disclosure.

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 and front-loaded: the first sentence states the core purpose, and the second lists actions efficiently. Every sentence adds value, though it could be slightly more structured (e.g., separating purpose from action details). No wasted words, but not perfectly optimized.

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 (managing file watching with auto-revalidation), no annotations, no output schema, and 2 parameters, the description is incomplete. It doesn't explain what the tool returns (e.g., status output, event details), how auto-revalidation works, or potential side effects. For a tool that likely involves ongoing processes and changes, more context is needed 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?

Schema description coverage is 100%, so the schema already documents both parameters (projectDir and action with enum). The description adds minimal value beyond the schema by listing the action values, but doesn't explain parameter semantics like what 'projectDir' contains or how actions interact (e.g., if 'start' initiates watching). Baseline 3 is appropriate as the schema does most of the work.

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: 'Watch project files for changes and auto-revalidate contracts.' It specifies the verb ('watch'), resource ('project files'), and outcome ('auto-revalidate contracts'), distinguishing it from siblings like trace_file or get_project_status. However, it doesn't explicitly differentiate from all siblings (e.g., compare might also involve file monitoring).

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 through the listed actions (start, stop, status, poll), suggesting it's for managing a file-watching process. It doesn't provide explicit when-to-use guidance versus alternatives (e.g., when to use watch vs. trace_file for file-related tasks) or prerequisites, leaving usage context somewhat inferred rather than stated.

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