Serena MCP Server

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 the action ('activates') but doesn't explain what activation entails (e.g., does it start a process, load configurations, or change project state?), potential side effects, permissions required, or error conditions. This leaves significant gaps in understanding the tool's behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, clear sentence that efficiently conveys the core action without unnecessary words. It's front-loaded with the key verb and resource, making it easy to parse quickly, which is ideal for conciseness in tool descriptions.

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 that performs an action ('activate') with no annotations or output schema, the description is incomplete. It doesn't clarify what activation means operationally, what happens after activation, or potential dependencies, making it inadequate for an agent to use this tool confidently in varied contexts.

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 parameter 'project' documented as 'The name of a registered project to activate or a path to a project directory.' The description adds no additional meaning beyond this, as it only references 'the project with the given name.' Since the schema fully covers the parameter, 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 ('activates') and the target resource ('the project with the given name'), making the purpose immediately understandable. However, it doesn't distinguish this tool from sibling tools like 'remove_project' or 'switch_modes', which might also affect project states, leaving some ambiguity about its specific role in the toolset.

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 (e.g., whether the project must be registered or inactive), exclusions, or related tools like 'remove_project' or 'switch_modes', leaving the agent to infer usage context from the tool 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It implies this is a read-only check (non-destructive) and suggests it's a prerequisite step, which adds useful context. However, it doesn't describe potential outcomes (e.g., returns a boolean, error handling) or performance aspects like rate limits, leaving some behavioral traits unclear.

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 highly concise and well-structured, consisting of two sentences that efficiently convey purpose and usage guidelines. Every sentence adds value without redundancy, making it easy to parse and front-loaded with 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 (0 parameters, no output schema, no annotations), the description is largely complete. It explains what the tool does and when to use it, which is sufficient for a simple check operation. However, it doesn't mention what the output might be (e.g., a boolean result), which could be helpful despite the lack of an output schema.

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 0 parameters, and schema description coverage is 100%, so no parameter documentation is needed. The description appropriately doesn't discuss parameters, focusing instead on usage context. A baseline of 4 is applied since it avoids unnecessary details while being complete for a parameterless tool.

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: 'Checks whether project onboarding was already performed.' It uses a specific verb ('Checks') and identifies the resource ('project onboarding'), making the function unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'onboarding' or 'initial_instructions', 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 explicit usage guidelines: 'You should always call this tool before beginning to actually work on the project/after activating a project, but after calling the initial instructions tool.' It specifies when to use it (before work, after activation and initial instructions) and references sibling tools ('initial_instructions'), offering clear context and sequencing without misleading information.

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 effectively communicates that this is a destructive write operation (overwrites existing files completely), specifies constraints (content must be complete, no partial changes), and mentions the return value (success/failure message). It doesn't cover permissions, rate limits, or error details, but provides solid operational 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 appropriately sized and front-loaded with the core purpose. Every sentence earns its place by providing essential guidance about alternatives, constraints, and return values. It could be slightly more concise by combining some of the alternative tool recommendations, but overall it's well-structured and efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given this is a destructive write operation with no annotations and no output schema, the description does an excellent job of providing necessary context. It explains the tool's behavior, constraints, alternatives, and return value. The main gap is the lack of detail about specific error conditions or permission requirements, but for a file creation tool with good sibling differentiation, it's quite 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?

Schema description coverage is 100%, so the schema already documents both parameters thoroughly. The description doesn't add any parameter-specific information beyond what's in the schema (relative_path and content). However, it does provide important context about how the content parameter must represent complete file content, which adds semantic value beyond the schema's basic description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose with specific verbs ('write', 'overwrite') and resource ('file'), distinguishing it from sibling tools like replace_lines, insert_at_line, and symbolic editing tools. It explicitly defines the scope as creating new files or completely overwriting existing ones.

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 guidance on when to use this tool versus alternatives. It specifies that for existing files, symbolic operations (replace_symbol_body, insert_after_symbol, insert_before_symbol) or insert_at_line are recommended instead, and for partial replacements, replace_lines or symbolic editing tools should be used. This clearly differentiates it from all relevant sibling 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?

No annotations are provided, so the description carries the full burden. It discloses the prerequisite verification step, which is a key behavioral trait beyond basic deletion. However, it lacks details on permissions, error handling, or what happens if lines are out of bounds, leaving some behavioral aspects unclear for a destructive 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 two sentences with zero waste: the first states the core purpose, and the second adds crucial usage guidance. It is front-loaded with the main action and appropriately sized, making every sentence earn 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 the tool's complexity (a destructive file operation with 3 parameters) and no annotations or output schema, the description is mostly complete. It covers purpose, usage guidelines, and a key behavioral trait, but lacks details on return values or error conditions, which could be important for an agent invoking this 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?

Schema description coverage is 100%, so the schema fully documents the three parameters (relative_path, start_line, end_line). The description does not add any additional meaning or context about the parameters beyond what the schema provides, such as format examples or constraints, meeting 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 specific action ('deletes') and resource ('lines in the file'), distinguishing it from sibling tools like 'replace_lines' or 'delete_memory'. It precisely defines what the tool does without being vague or tautological.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly states when to use this tool by specifying a prerequisite: 'Requires that the same range of lines was previously read using the `read_file` tool to verify correctness of the operation.' This provides clear guidance on the necessary context and distinguishes it from alternatives that might not require such verification.

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. While it mentions this is a deletion operation (implying destructive action), it doesn't specify whether the deletion is permanent/reversible, what permissions are required, or what happens if the file doesn't exist. For a destructive operation with zero annotation coverage, 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 efficiently structured in two sentences: the first states the core action, the second provides crucial usage guidelines. Every sentence adds value with zero wasted words, 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?

For a destructive operation with no annotations and no output schema, the description provides good usage guidelines but lacks critical behavioral details (permanence, error handling, permissions). The single parameter is undocumented. While the purpose and usage are clear, the description doesn't fully compensate for the missing structured information.

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 has 0% description coverage for its single parameter 'memory_file_name'. The description doesn't mention this parameter at all, providing no additional semantic context beyond what the schema's title suggests. However, with only one parameter, the baseline is 4, but the complete lack of parameter explanation in the description reduces this to 3.

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 'delete' and the resource 'memory file', making the purpose unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'remove_project' or 'delete_lines', which might also involve deletion 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 explicit guidance on when to use this tool: 'only if a user asks for it explicitly' and gives concrete examples ('information retrieved... no longer correct or no longer relevant'). This clearly defines the triggering conditions and helps distinguish it from other deletion 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 full burden and does so effectively. It discloses critical behavioral traits: safety warnings about dangerous commands, memory prerequisites, output format (JSON with stdout/stderr), and a character limit constraint. It doesn't mention rate limits or authentication needs, but covers the most essential behavioral aspects for a shell execution 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 appropriately sized and front-loaded with the core purpose. Each sentence adds value: purpose, prerequisites, safety warnings, and output format. While slightly verbose due to the safety emphasis, every sentence serves a clear function in guiding proper tool usage.

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 potentially dangerous shell execution tool with no annotations and no output schema, the description provides substantial context: safety constraints, prerequisites, behavioral warnings, and output format. It doesn't specify error handling or timeout behavior, but covers the critical aspects needed for responsible tool invocation given the complexity and risk profile.

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%, providing complete parameter documentation. The description adds minimal parameter-specific information beyond the schema, only mentioning that output includes 'stdout and optionally stderr' which relates to the capture_stderr parameter. This meets the baseline 3 when schema coverage is high.

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 ('Execute a shell command') and the outcome ('return its output'), distinguishing it from all sibling tools which are file operations, memory management, or project utilities. It provides a complete verb+resource+result statement that leaves no ambiguity about its function.

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 guidance on when to use this tool: only after consulting the 'suggested shell commands' memory via `read_memory`, and never for unsafe commands like `rm -rf /`. It also specifies prerequisites (memory must be loaded) and clear exclusions (unsafe deletions), offering comprehensive usage context.

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

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

No annotations are provided, so the description carries the full burden. It discloses key behavioral traits: it filters out gitignored files (a critical constraint), returns a JSON object with a list, and searches within a relative path. However, it doesn't mention performance characteristics (e.g., speed, recursion depth), error handling, or what happens with invalid inputs, leaving gaps for a tool with no annotation support.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, front-loaded with the core purpose and followed by the return format. Every word earns its place—no redundancy or fluff. It's efficiently structured for quick comprehension by an AI agent.

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 (2 parameters, no output schema, no annotations), the description is reasonably complete. It covers the purpose, key constraint (non-gitignored), and return format. However, it lacks details on output structure (e.g., what fields are in the JSON) and error cases, which could be helpful since there's no output schema.

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 fully documents both parameters (file_mask and relative_path). The description adds no additional parameter semantics beyond what's in the schema (e.g., it doesn't explain wildcard syntax further or provide examples). With high schema coverage, the baseline is 3, and the description doesn't compensate with extra 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 specific action ('Finds'), resource ('non-gitignored files'), and scope ('matching the given file mask within the given relative path'), distinguishing it from siblings like list_dir (which lists all files) or search_for_pattern (which searches content). It explicitly mentions what gets excluded (gitignored files), which is a key differentiator.

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 clear context for when to use this tool (searching for files by name/mask in a directory) but doesn't explicitly state when not to use it or name alternatives. For example, it doesn't contrast with list_dir (which lists all files without filtering) or search_for_pattern (which searches within file content), though the purpose implies these distinctions.

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 key behaviors: the result includes metadata and code snippets (with conditions), and it can find subclasses. However, it lacks details on permissions, rate limits, error handling, or the exact structure of returned JSON objects, leaving gaps for a tool with 5 parameters.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is appropriately sized with three sentences. It front-loads the core purpose, adds behavioral details, and clarifies a use case. There's no wasted text, though the mention of 'include_body' (not in schema) could cause confusion, slightly reducing efficiency.

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 5 parameters, no annotations, and no output schema, the description is moderately complete. It covers the tool's purpose and some behaviors but lacks details on output structure, error cases, or integration with siblings. For a complex reference-finding tool, this leaves significant gaps for an AI agent to infer correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents all parameters. The description adds minimal value: it mentions 'include_body' affecting snippet omission, but this parameter isn't in the schema (likely an error or omission). For other parameters, it only references 'same logic as in the `find_symbol` tool,' not providing additional semantics beyond the schema.

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: 'Finds symbols that reference the symbol at the given `name_path`.' It specifies the verb ('finds'), resource ('symbols'), and target ('symbol at the given name_path'). However, it doesn't explicitly differentiate from sibling tools like 'find_symbol' beyond mentioning similar parameter logic.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage by noting it 'can be used to find (direct) subclasses of a class,' providing some context. However, it doesn't explicitly state when to use this tool versus alternatives like 'find_symbol' or 'search_for_pattern,' nor does it mention prerequisites or exclusions beyond parameter references.

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 effectively explains key behaviors: the matching logic for `name_path`, the role of `depth` for retrieving children, and the return format (JSON list of symbols with locations). It also hints at performance considerations with `relative_path` but lacks details on rate limits or error handling.

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 front-loaded with the core purpose but becomes verbose with detailed explanations of `name_path` matching behavior. While informative, some sentences could be more streamlined, and the structure includes repetitive examples that might be condensed for better clarity without losing 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 complexity of 8 parameters, no annotations, and no output schema, the description does a good job of covering key aspects like purpose, usage, and parameter semantics. It explains the return format and provides examples, but could improve by summarizing all parameters briefly or mentioning error cases to be more complete for such a multifaceted 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?

Schema description coverage is 100%, so the baseline is 3. The description adds significant value by elaborating on `name_path` semantics, including examples and matching rules, and clarifies `depth` usage. It also mentions `relative_path` for restricting searches, enhancing understanding beyond the schema. However, it does not cover all parameters like `include_kinds` or `max_answer_chars` in detail.

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: 'Retrieves information on all symbols/code entities (classes, methods, etc.) based on the given `name_path`.' It specifies the resource (symbols/code entities), the verb (retrieves information), and distinguishes it from siblings like 'find_file' or 'find_referencing_symbols' by focusing on symbol tree navigation within files.

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 clear context on when to use this tool, such as for retrieving symbol locations for edits or queries, and mentions using the `relative_path` parameter to restrict searches. However, it does not explicitly state when not to use it or name specific alternatives among siblings, though it implies differentiation from file-based searches.

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. It states this is a read operation ('Print') but doesn't mention whether it requires permissions, has side effects, returns structured vs. textual data, or has any limitations. The description is minimal on behavioral context beyond the basic 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 and provides specific details about what's included. Every word earns its place with no 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 zero-parameter read tool with no annotations and no output schema, the description provides adequate but minimal context. It specifies what configuration elements are included, but doesn't address format, structure, or potential limitations of the output. Given the complexity is low (no parameters), this is minimally viable but could be more 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 tool has 0 parameters with 100% schema description coverage, so the baseline is 4. The description appropriately doesn't discuss parameters since none exist, and the schema already fully documents this.

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: 'Print the current configuration of the agent' with specific details about what's included (active/available projects, tools, contexts, modes). It uses a specific verb ('Print') and resource ('configuration'), though it doesn't explicitly distinguish from siblings like 'switch_modes' or 'activate_project'.

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. The description doesn't mention prerequisites, timing considerations, or relationships to sibling tools like 'switch_modes' or 'activate_project' that might affect configuration state.

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 discloses key behavioral traits: it analyzes files, lists top-level symbols with name_path and kind, and returns a JSON object mapping relative paths to symbol info. However, it doesn't mention potential limitations like performance impact, file size constraints, or error conditions. The description adds useful context but lacks comprehensive behavioral 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 with four sentences that each serve distinct purposes: stating the tool's function, explaining what it lists, providing usage guidance, and describing the return format. It's front-loaded with the core purpose. While efficient, the final sentence could be slightly more concise by integrating return format details earlier.

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 (symbol analysis), no annotations, and no output schema, the description does a good job covering the essentials: purpose, usage context, and return format. However, it could better address behavioral aspects like what happens with invalid paths or large directories. For a read-only analysis tool, it's mostly complete but has minor gaps.

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 fully documents both parameters. The description doesn't add any parameter-specific information beyond what's in the schema (e.g., it doesn't explain relative_path conventions or max_answer_chars implications). With high schema coverage, the baseline is 3 even without param details in the description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose with specific verbs ('gets an overview', 'list the top-level symbols') and resources ('file or directory', 'code symbols'). It distinguishes itself from siblings like 'read_file', 'find_symbol', and 'list_dir' by focusing specifically on symbol extraction rather than file content, symbol location, or directory listing.

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 guidance on when to use this tool: 'Calling this is often a good idea before more targeted reading, searching or editing operations on the code symbols.' This gives clear context for its role as a preparatory step for other operations, distinguishing it from direct manipulation or search 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It describes the tool's role in workflow sequencing (must be called first) and its dependency on project activation, which adds useful context. However, it lacks details on what the instructions contain, potential errors, or response format, leaving some behavioral aspects unclear.

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 well-structured, using three sentences that each add value: the first states the purpose, the second provides the primary usage rule, and the third covers the exception. There is no redundant or filler content, 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 simplicity (0 parameters, no annotations, no output schema), the description is largely complete. It explains the purpose, usage rules, and exception handling. However, without an output schema, it could benefit from hinting at what the instructions might include (e.g., project goals, constraints) to better set expectations 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?

The tool has 0 parameters, and schema description coverage is 100%, so no parameter information is needed. The description appropriately does not discuss parameters, focusing instead on usage context. A baseline of 4 is applied as it efficiently handles the lack of parameters without unnecessary details.

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 ('Get') and resource ('initial instructions for the current coding project'). It distinguishes itself from sibling tools by focusing on retrieving project-specific instructions rather than performing actions like file manipulation or project activation.

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 usage guidelines: it specifies when to use this tool ('always call this tool before starting to work on any programming task') and when not to use it (exception: 'when a user asks you to activate a project, call `activate_project` first instead'). It names the alternative tool (`activate_project`) for the exception case.

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 discloses that the tool inserts content after a symbol's definition and that the inserted code begins on the next line, adding useful behavioral context. However, it does not cover permissions, error handling, or side effects, leaving gaps for a mutation tool with no annotation coverage.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the core purpose in the first sentence, followed by a concise typical use case. Both sentences earn their place by clarifying intent and context without any wasted words, making it efficiently structured 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 no annotations and no output schema, the description provides adequate purpose and usage context but lacks details on behavioral traits like error handling or side effects. For a mutation tool with 3 parameters and 100% schema coverage, it is minimally viable but has clear gaps in completeness, especially around operational transparency.

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. The description adds minimal value by implying that 'name_path' refers to a symbol's location and 'body' is the content to insert, but it does not provide additional syntax or format details beyond what the schema provides. 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 verb 'inserts' and specifies the resource 'body/content' after the definition of a given symbol via its location. It distinguishes from sibling tools like 'insert_before_symbol' by specifying 'after' and from 'insert_at_line' by focusing on symbol-based positioning. The typical use cases (class, function, method, field, variable assignment) further clarify the 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?

The description provides clear context for when to use this tool: for inserting content after a symbol's definition, with typical use cases listed. It implicitly distinguishes from 'insert_before_symbol' by specifying 'after' and from 'insert_at_line' by using symbol-based positioning. However, it does not explicitly state when not to use it or name alternatives, missing full explicit 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. It explains the insertion behavior ('pushing existing content down') and mentions use cases, but lacks details on error handling (e.g., what happens if the line index is out of bounds), file permissions, or whether the operation is atomic. It provides basic behavioral context but misses advanced operational traits.

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 efficiently structured in three sentences: the first states the core functionality, the second provides usage guidance relative to alternatives, and the third adds a specific use case. Every sentence adds value without redundancy, making it front-loaded and 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 tool's moderate complexity (file editing with line-based insertion), no annotations, and no output schema, the description does well by explaining the operation, comparing to siblings, and suggesting use cases. However, it lacks details on error conditions or return values, leaving some gaps in full contextual understanding.

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 semantics beyond what the schema provides (e.g., no clarification on line numbering conventions or content formatting). The baseline score of 3 reflects adequate coverage via the schema alone.

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 ('inserts the given content at the given line') and resource ('in the file'), with precise mechanics ('pushing existing content of the line down'). It explicitly distinguishes from sibling tools like 'insert_after_symbol' and 'insert_before_symbol', making the purpose 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 provides explicit guidance on when to use alternatives ('symbolic insert operations... should be preferred if you know which symbol you are looking for') and when this tool is appropriate ('small targeted edits of the body of a longer symbol without replacing the entire body'). This clearly defines the tool's niche relative to siblings.

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 describes the insertion action but lacks details on permissions needed, error handling (e.g., if the symbol is not found), whether the operation is idempotent, or what happens to existing content. For a mutation 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 appropriately sized with three sentences that are front-loaded: the first sentence states the core action, and the following sentences provide use cases without redundancy. Every sentence adds value, though it could be slightly more concise by combining the use case examples into one sentence.

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 (a mutation operation with 3 parameters), no annotations, and no output schema, the description is moderately complete. It covers the purpose and usage but lacks behavioral details like error handling or return values. For a tool with no structured safety or output information, it should do more to compensate, but it meets a minimum viable level.

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 (name_path, relative_path, body) with clear descriptions. The description adds minimal value beyond the schema by implying the parameters' roles in the insertion process but does not provide additional syntax, format, or constraints details. 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 verb 'inserts' and the resource 'body/content' before 'the definition of the given symbol', specifying the action and target. It distinguishes from siblings like 'insert_after_symbol' by specifying 'before' and from 'insert_at_line' by using symbol-based positioning, making the purpose specific and differentiated.

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 clear context for when to use this tool: 'to insert a new class, function, method, field or variable assignment' or 'to insert a new import statement before the first symbol in the file'. It implies usage based on symbol-based insertion needs but does not explicitly state when not to use it or name alternatives like 'insert_at_line' for line-based insertion, though the context is sufficient for typical cases.

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 key behavioral traits: it filters out gitignored files, returns JSON structure with directory/file names, and mentions recursion. However, it doesn't address important aspects like performance implications of recursion, error handling for invalid paths, or what happens when max_answer_chars is exceeded.

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 efficiently structured in two sentences: the first states the core functionality, the second describes the return format. It's appropriately sized for the tool's complexity, though it could be slightly more front-loaded by mentioning the JSON return earlier.

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 read-only directory listing tool with no output schema, the description provides adequate but incomplete context. It covers what the tool does and the return format, but lacks information about error conditions, performance characteristics, and the practical implications of the max_answer_chars parameter. The absence of annotations increases the need for more behavioral disclosure.

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%, providing solid documentation for all parameters. The description adds minimal value beyond the schema - it mentions recursion but doesn't elaborate on its effects, and doesn't explain the interaction between parameters. The baseline of 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 verb ('Lists'), resource ('all non-gitignored files and directories'), and scope ('in the given directory'). It distinguishes itself from siblings like 'find_file' by focusing on directory listing rather than searching, and from 'read_file' by returning metadata rather than content.

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 its functional description but doesn't explicitly state when to use this tool versus alternatives like 'find_file' or 'search_for_pattern'. It mentions recursion as an option but doesn't provide guidance on when to enable it versus using other tools for deeper searches.

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 only states the basic action ('List available memories') without mentioning any behavioral traits such as permissions required, rate limits, pagination, or what 'available' means in context. This leaves significant gaps for a tool that likely interacts with stored data.

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: 'List available memories.' The second sentence adds useful context without redundancy. Every sentence earns its place, making it efficient and well-structured with zero waste.

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 listing stored data (memories), no annotations, and no output schema, the description is incomplete. It doesn't explain what 'memories' are, how they're formatted in the output, or any constraints on availability. For a data-listing tool in this context, more detail 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?

The tool has 0 parameters, and the schema description coverage is 100%, so there are no parameters to document. The description doesn't need to add parameter semantics, and it appropriately avoids unnecessary details. A baseline of 4 is applied as it meets expectations for a parameterless tool.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'List available memories.' This is a specific verb+resource combination that tells the agent what the tool does. However, it doesn't explicitly differentiate from sibling tools like 'read_memory' beyond mentioning it, 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 implied usage guidance by mentioning that 'Any memory can be read using the `read_memory` tool,' which suggests this tool is for listing rather than reading. However, it lacks explicit when-to-use instructions, alternatives, or exclusions, leaving some ambiguity about its specific context compared to other list/search 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?

No annotations are provided, so the description carries the full burden. It discloses that the tool returns instructions (not performing the onboarding itself) and has a usage limit (once per conversation), which adds useful behavioral context. However, it doesn't cover potential side effects, error conditions, or what 'instructions' entail, leaving gaps for a mutation-related 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 highly concise and well-structured with two sentences: the first states when to use it, and the second covers usage frequency and return value. Every sentence adds essential information without redundancy, making it front-loaded and efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (likely low, with 0 parameters) and no annotations or output schema, the description is somewhat complete but has gaps. It explains when and how often to use it and what it returns, but doesn't detail the format of 'instructions' or potential errors. For a tool that might involve setup or configuration, more context on outcomes 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?

The tool has 0 parameters, and schema description coverage is 100%, so no parameter documentation is needed. The description doesn't discuss parameters, which is appropriate. A baseline of 4 is applied since it compensates adequately for the lack of parameters by focusing on usage 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 clearly states the tool's purpose: to be called when onboarding hasn't been performed yet, and it returns instructions for creating onboarding information. It uses specific verbs ('call', 'returns') and identifies the resource (onboarding information). However, it doesn't explicitly differentiate itself from sibling tools like 'check_onboarding_performed' or 'initial_instructions', 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 explicit usage guidelines: 'Call this tool if onboarding was not performed yet' and 'You will call this tool at most once per conversation.' This clearly defines when to use it (onboarding not done) and includes a usage constraint (once per conversation), though it doesn't mention alternatives like 'check_onboarding_performed'.

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. The description mentions 'preparing for a new conversation' but doesn't explain what this entails behaviorally—whether it clears memory, resets state, requires specific permissions, has side effects, or what the expected outcome is. For a tool with zero annotation coverage, 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 two short, clear sentences with zero wasted words. It front-loads the purpose and immediately follows with a critical usage guideline. Every sentence earns its place by providing essential information efficiently.

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 0 parameters, no annotations, and no output schema, the description provides basic purpose and strong usage guidelines but lacks details on what the preparation involves or what happens after invocation. For a tool that likely resets or initializes conversation state, more context on behavior and outcomes would be helpful, making it minimally adequate but with gaps.

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 0 parameters, and the input schema has 100% description coverage (though empty). The description doesn't need to add parameter semantics since there are none. Baseline for 0 parameters is 4, as the description appropriately doesn't discuss parameters and focuses on usage.

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 'Instructions for preparing for a new conversation' which is a tautology that essentially restates the tool name 'prepare_for_new_conversation'. It doesn't specify what the preparation actually involves (e.g., clearing context, resetting state, initializing settings) or what resource it operates on. The purpose remains vague rather than specific.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly states 'This tool should only be called on explicit user request', providing clear guidance on when to use it (only when the user explicitly asks) and implying when not to use it (automatically or without user request). This is a strong, explicit usage rule that distinguishes it from 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 provided, so the description carries the full burden. It discloses some behavioral traits: it can read chunks of files (via start_line/end_line), has a character limit (max_answer_chars), and returns full text. However, it doesn't cover important aspects like error handling (e.g., what happens if file doesn't exist), performance implications, or whether this is a read-only operation (though implied by 'Reads'). The description adds value but lacks comprehensive behavioral context for a tool with no annotations.

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 with three sentences that each serve a distinct purpose: stating the core function, providing usage guidelines, and specifying the return value. It's front-loaded with the main action. While efficient, the third sentence could be slightly more concise by integrating the return information earlier.

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 (file reading with chunking and limits), no annotations, and no output schema, the description does reasonably well. It covers the core purpose, usage guidelines, and return value. However, it lacks details about error conditions, performance characteristics, or what exactly 'Returns the full text' means in practice (e.g., formatting, encoding). For a tool with no annotations or output schema, it's mostly complete but has some gaps.

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 4 parameters thoroughly. The description adds minimal parameter semantics beyond the schema: it mentions reading 'a chunk of it' (hinting at start_line/end_line) and the character limit warning. However, it doesn't provide additional syntax, format, or usage details that aren't already in the schema descriptions. 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 with specific verbs ('Reads', 'Returns') and resource ('the given file or a chunk of it'). It distinguishes from sibling tools by explicitly mentioning alternatives like 'find_symbol' or 'find_referencing_symbols' should be preferred when possible, making the purpose specific and differentiated.

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 guidance on when to use this tool vs alternatives: 'Generally, symbolic operations like find_symbol or find_referencing_symbols should be preferred if you know which symbols you are looking for. Reading the entire file is only recommended if there is no other way to get the content required for the task.' This clearly defines when to use and when not to use this tool, naming specific 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 provided, so the description carries the full burden. It discloses behavioral traits like the relevance requirement and the prohibition on repeated reads, which are useful. However, it doesn't cover critical aspects such as error handling (e.g., what happens if the file doesn't exist), performance characteristics, or output format. For a read operation with no annotation support, this leaves significant gaps in behavioral understanding.

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 highly concise and well-structured, consisting of three sentences that each serve a clear purpose: stating the tool's function, providing usage criteria, and setting a behavioral constraint. There is no wasted language, and key information is front-loaded, making it easy to parse 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 moderate complexity (reading files with relevance checks), lack of annotations, no output schema, and 0% schema description coverage, the description is incomplete. It covers usage guidelines well but misses details on parameters, error handling, and output format. For a tool that interacts with file content, more context is needed to ensure reliable 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 0%, so the schema provides no parameter details. The description adds no explicit information about the parameters, such as what 'memory_file_name' refers to or how 'max_answer_chars' affects the output. It implies relevance from the file name but doesn't explain parameter usage. With two parameters and no schema descriptions, the description fails to compensate adequately, resulting in a baseline score.

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 as 'Read the content of a memory file,' which is a specific verb+resource combination. It distinguishes itself from sibling tools like 'list_memories' (which lists files) and 'write_memory' (which writes content), though it doesn't explicitly name these alternatives. The purpose is unambiguous but could be more specific about what constitutes a 'memory file' in this context.

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 guidance on when to use the tool ('only if the information is relevant to the current task') and when not to use it ('should not read the same memory file multiple times in the same conversation'). It also implies relevance can be inferred from the file name. However, it doesn't name specific alternative tools (e.g., 'read_file' for non-memory files) or detail edge cases, keeping it from a perfect score.

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 states 'Removes' implying a destructive mutation, but doesn't disclose critical behavioral traits such as whether removal is irreversible, requires specific permissions, affects other configuration elements, or has side effects like data loss. This is inadequate for a mutation tool with zero annotation coverage.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, clear sentence with zero wasted words. It's front-loaded with the core action and resource, making it highly efficient and easy to parse, 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 tool's complexity as a destructive mutation with no annotations and no output schema, the description is incomplete. It lacks details on behavior, usage context, and return values, making it insufficient for safe and effective tool invocation 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?

The description adds no parameter semantics beyond what the input schema provides. With 100% schema description coverage (the 'project_name' parameter is fully documented in the schema), the baseline is 3. The description doesn't explain the parameter's role or constraints, so it doesn't add 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 ('Removes') and resource ('a project from the Serena configuration'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'delete_memory' or 'delete_lines', which also perform deletion operations on different resources, 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. It doesn't mention prerequisites (e.g., whether the project must exist or be inactive), consequences (e.g., if removal is permanent), or related tools like 'activate_project' for context, leaving the agent with no usage context.

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

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

No annotations are provided, so the description carries full burden. It discloses the critical behavioral trait that prior reading with 'read_file' is required for correctness, which is essential for safe operation. However, it doesn't mention potential side effects like file locking, error handling, or whether changes are reversible, 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 sentences, front-loaded with the core purpose and followed by a crucial prerequisite. Every sentence earns its place with no wasted words, 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?

For a mutation tool with no annotations and no output schema, the description is mostly complete: it clearly states the purpose, usage guidelines, and a key behavioral requirement. However, it lacks details on return values or error conditions, which could be important given the tool's complexity and potential for data loss.

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. The description adds no additional meaning beyond the schema, such as explaining how 'start_line' and 'end_line' define the range or how 'content' interacts with the replacement. 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 specific action ('replaces'), the resource ('range of lines in the given file'), and distinguishes it from siblings like 'delete_lines', 'insert_at_line', and 'replace_symbol_body' by specifying it replaces a range with new content rather than deleting, inserting at a single line, or replacing symbol bodies.

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?

It explicitly states when to use this tool: 'Requires that the same range of lines was previously read using the `read_file` tool to verify correctness of the operation.' This provides clear prerequisites and distinguishes it from alternatives like 'insert_at_line' or 'replace_symbol_body' by emphasizing the need for prior verification.

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 and does well by explaining key behavioral aspects: it's a destructive operation (replaces content), handles multiple occurrences (with the allow_multiple_occurrences parameter), and provides practical advice about regex patterns. However, it doesn't mention error handling or file permissions.

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 but has structural issues. The first paragraph is well-structured, but the second paragraph with ALL CAPS and emotional language ('I WILL BE VERY UNHAPPY') is unprofessional and redundant with the first paragraph's advice about wildcards.

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 destructive file operation with no annotations and no output schema, the description provides good context about when to use it, behavioral characteristics, and practical regex advice. It could be more complete by mentioning error conditions or what happens when the file doesn't exist, but covers the essential aspects well.

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 thoroughly. The description adds some context about regex patterns ('beginning.*?end-of-text-to-be-replaced') and wildcard usage, but doesn't provide additional parameter-specific semantics beyond what's in the schema.

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: 'Replaces one or more occurrences of the given regular expression' and specifies it's for file content replacement. It distinguishes from siblings like 'replace_lines' and 'replace_symbol_body' by emphasizing regex-based replacement when symbol-level tools aren't appropriate.

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 guidance on when to use this tool ('whenever the symbol-level tools are not appropriate') and offers specific usage advice about preferring wildcards over long regexes. It also distinguishes from sibling tools by mentioning the alternative symbol-level approaches.

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 fully disclose behavioral traits. It states the tool 'replaces' the body, implying a mutation operation, but doesn't cover critical aspects like whether this is destructive (e.g., overwrites existing content), requires specific permissions, or has side effects. The mention of 'name_path' logic hints at dependencies but lacks detail on error handling or response format, leaving significant gaps 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 a single, direct sentence that efficiently conveys the core action without unnecessary words. It front-loads the key information ('replaces the body of the symbol') and avoids redundancy, making it highly concise and well-structured for quick understanding.

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 mutation tool with no annotations and no output schema, the description is incomplete. It lacks details on behavioral traits (e.g., destructiveness, error cases), usage context, and what the tool returns. While the schema covers parameters well, the overall context for safe and effective use is insufficient, especially for a tool that modifies symbols.

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 input schema already documents all parameters thoroughly. The description adds minimal value by referencing 'name_path' logic from 'find_symbol', which provides some contextual meaning beyond the schema. However, it doesn't elaborate on parameter interactions or usage examples, staying at the baseline level where 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 action ('replaces') and target ('body of the symbol'), making the purpose understandable. It specifies the 'name_path' parameter as the identifier, which adds specificity. However, it doesn't explicitly differentiate from sibling tools like 'replace_lines' or 'insert_after_symbol', which could involve similar symbol modifications, so it falls short of 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, such as 'replace_lines' or 'insert_before_symbol', which might handle similar tasks. It mentions 'name_path' logic from 'find_symbol', implying a prerequisite but not explicitly stating when this tool is preferred. Without clear usage context or exclusions, it offers minimal practical 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 behavioral disclosure. It effectively explains the tool's purpose (restarting), the triggering condition (outdated state from external edits), and the impact (resolving errors). However, it lacks details on side effects, such as whether the restart is disruptive or temporary.

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 well-structured: it front-loads the primary usage rule, explains the rationale, and provides actionable guidance. Every sentence adds value without redundancy, making it efficient for an AI agent.

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 (a restart operation with no parameters and no output schema) and lack of annotations, the description is mostly complete. It covers the purpose, usage rules, and context, but could benefit from mentioning potential side effects or confirmation details to be fully comprehensive.

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 0 parameters with 100% schema description coverage, so no parameter documentation is needed. The description appropriately focuses on usage context without redundant parameter details, meeting the baseline for this scenario.

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: restarting the language server when its state becomes outdated due to external edits, which helps resolve editing errors. It specifies the verb ('restart') and resource ('language server'), though it doesn't explicitly differentiate from sibling tools like 'activate_project' or 'switch_modes'.

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 usage guidelines: use only on explicit user request or after confirmation, and suggest it when editing errors occur due to outdated language server state. It clearly defines when to use the tool, though it doesn't mention specific alternatives among siblings.

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?

Since no annotations are provided, the description carries the full burden of behavioral disclosure. It thoroughly explains the pattern matching logic (e.g., DOTALL compilation, handling of multi-line matches, advice on greedy vs. non-greedy quantifiers), file selection logic (e.g., glob patterns, precedence rules), and output format ('Returns A JSON object mapping file paths to lists of matched consecutive lines'). This goes well beyond basic functionality.

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 well-structured with clear sections (Pattern Matching Logic, File Selection Logic) and front-loaded key information. Most sentences earn their place by providing essential guidance, though some parts could be slightly more concise (e.g., the explanation of DOTALL and quantifiers is detailed but necessary).

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 the tool (8 parameters, no annotations, no output schema), the description is highly complete. It covers purpose, usage guidelines, behavioral details, parameter semantics, and output format. The only minor gap is the lack of an output schema, but the description compensates by specifying the return value structure.

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?

With 100% schema description coverage, the baseline is 3. The description adds significant value by explaining the semantics of parameters like restrict_search_to_code_files ('useful if you are only interested in code symbols'), relative_path ('only subpaths of this path'), and glob patterns ('matched against relative file paths from the project root'). However, it doesn't cover all parameters equally (e.g., max_answer_chars is only briefly mentioned).

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: 'Offers a flexible search for arbitrary patterns in the codebase, including the possibility to search in non-code files.' It specifies the verb ('search'), resource ('codebase'), and scope ('non-code files'), and distinguishes it from siblings like find_symbol and find_referencing_symbols by noting when to prefer those alternatives.

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 guidance on when to use this tool versus alternatives: 'Generally, symbolic operations like find_symbol or find_referencing_symbols should be preferred if you know which symbols you are looking for.' It also explains when to use specific parameters, such as restrict_search_to_code_files for code symbols or False for non-code files.

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 timing ('after you have fully completed any non-trivial coding task') and dependencies ('only after the think_about_whether_you_are_done call'), which adds some context. However, it doesn't describe what the tool actually does behaviorally (e.g., how it summarizes changes, what format the summary is in, whether it modifies anything, or if it's read-only). For a 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 two sentences, both of which earn their place: the first states the purpose, and the second provides critical usage guidelines. It's front-loaded with the core function and avoids any redundant or unnecessary information, making it highly efficient and well-structured.

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 (a summary tool with no parameters and no output schema), the description is partially complete. It covers purpose and usage guidelines well, but lacks details on behavioral aspects (e.g., what the summary includes, how it's formatted, or if it's a read operation). Without annotations or an output schema, the description should do more to explain what the tool returns or how it behaves, leaving some contextual gaps.

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 0 parameters with 100% schema description coverage, so the schema fully documents that no inputs are required. The description doesn't need to add parameter information, and it correctly doesn't mention any parameters. Since there are no parameters, the baseline is 4, as the description appropriately focuses on usage rather than parameter details.

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: 'Summarize the changes you have made to the codebase.' This is a specific verb ('summarize') and resource ('changes to the codebase'), making it easy to understand what the tool does. However, it doesn't explicitly differentiate from sibling tools like 'think_about_task_adherence' or 'think_about_whether_you_are_done' that might involve reflection on changes.

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 usage guidelines: 'This tool should always be called after you have fully completed any non-trivial coding task, but only after the think_about_whether_you_are_done call.' This clearly states when to use it (after non-trivial coding tasks) and includes a prerequisite (call 'think_about_whether_you_are_done' first), offering strong 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool 'Activates' modes, implying a state change, but doesn't describe what activation entails (e.g., immediate effect, persistence, side effects), permissions required, or error conditions. This is insufficient for a mutation tool with zero annotation coverage.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence that front-loads the core action ('Activates') and includes illustrative examples. There is no wasted text, 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 complexity of a mode-switching tool with no annotations and no output schema, the description is incomplete. It lacks details on behavioral traits (e.g., what activation does, side effects), usage context, and return values, leaving significant gaps for the agent to operate effectively.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, with the parameter 'modes' clearly documented as an array of strings for mode names. The description adds value by providing examples like ['editing', 'interactive'] or ['planning', 'one-shot'], which clarify the expected format and possible values, but doesn't go beyond what the schema already covers in terms of semantics.

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 ('Activates') and the target ('desired modes'), with specific examples provided. However, it doesn't explicitly differentiate this tool from potential sibling tools that might also manage modes or configurations, such as 'get_current_config' or 'restart_language_server', leaving some ambiguity about its unique role.

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 for activation, or how it relates to other tools like 'get_current_config' or 'restart_language_server', which could involve mode changes. This lack of usage context leaves the agent without clear 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It describes the tool as a cognitive evaluation step ('think about'), which implies it's a read-only, non-destructive operation that doesn't modify data. However, it lacks details on what the 'thinking' entails (e.g., internal processing vs. output generation), potential side effects, or any performance considerations. The description adds basic context but is vague on behavioral specifics.

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 well-structured: two sentences that efficiently convey purpose and usage guidelines. The first sentence defines the tool's function, and the second provides critical contextual instructions. There is no wasted text, and information is front-loaded, making it easy for an agent to parse and apply.

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 (a cognitive step with no parameters) and the absence of annotations and output schema, the description is reasonably complete. It explains what the tool does and when to use it, which is sufficient for a zero-parameter tool focused on internal evaluation. However, it could be more complete by clarifying the output or result of the 'thinking' process, as there's no output schema to guide the agent on what to expect after invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has 0 parameters, with 100% schema description coverage (empty schema). The description doesn't need to explain parameters, as there are none. It appropriately focuses on usage context without redundant parameter details, earning a baseline score of 4 for zero-parameter tools that avoid unnecessary complexity.

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: to 'think about the collected information and whether it is sufficient and relevant.' It specifies a cognitive evaluation function rather than a data manipulation action, which distinguishes it from most sibling tools that perform file operations, searches, or memory management. However, it doesn't explicitly differentiate from similar cognitive tools like 'think_about_task_adherence' or 'think_about_whether_you_are_done' beyond the specific focus on 'collected information.'

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 and strong usage guidelines: it states the tool 'should ALWAYS be called after you have completed a non-trivial sequence of searching steps' and lists examples like 'find_symbol, find_referencing_symbols, search_files_for_pattern, read_file, etc.' This clearly defines when to use it (after search operations) and implies when not to use it (e.g., as a standalone step or after non-search tasks), offering practical context for the agent.

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

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

No annotations are provided, so the description carries the full burden. It mentions the tool is for 'thinking' and should be called before certain actions, but does not disclose behavioral traits such as what the tool actually does (e.g., internal reflection vs. output), whether it has side effects, or how it affects the agent's state. 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 front-loaded with the main purpose in the first sentence, followed by specific usage guidelines. It is appropriately sized with three sentences that each add value, though the second sentence could be slightly more 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?

Given the tool's abstract nature (a 'thinking' tool with no parameters and no output schema), the description provides basic purpose and usage guidelines. However, it lacks details on what the tool outputs or how it influences the agent's behavior, which is important for such a meta-cognitive tool. With no annotations or output schema, the description is adequate but has clear gaps in explaining the tool's effect.

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 0 parameters, and schema description coverage is 100%, so there are no parameters to document. The description does not need to add parameter semantics, and it appropriately avoids discussing parameters, meeting the baseline for a parameterless tool.

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 tool is for 'thinking about the task at hand and whether you are still on track', which provides a vague purpose. It does not specify a concrete action or resource, and while it distinguishes from siblings by being a 'thinking' tool, the purpose remains abstract rather than specific.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly states when to use this tool: 'Especially important if the conversation has been going on for a while' and 'ALWAYS be called before you insert, replace, or delete code.' It provides clear context and exclusions, distinguishing it from other tools by specifying prerequisites for code modification actions.

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 fails to disclose any behavioral traits such as what the tool returns, whether it has side effects, or how it influences the agent's workflow. The description is minimal and does not add meaningful context beyond the vague purpose.

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 main instruction. It avoids redundancy and is appropriately sized for a tool with no parameters, though it could be slightly more informative without losing efficiency.

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 (low, with 0 params) but lack of annotations and output schema, the description is incomplete. It does not explain what happens after calling the tool (e.g., does it return a status, trigger an action, or provide feedback?), leaving significant gaps in understanding its role in the workflow.

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 0 parameters, and schema description coverage is 100%, so there is no need for parameter details in the description. The baseline for 0 parameters is 4, as the description does not need to compensate for missing param info, and it appropriately avoids unnecessary parameter discussion.

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 tool should be called 'whenever you feel that you are done with what the user has asked for,' which is a tautology of the tool name 'think_about_whether_you_are_done.' It does not specify what the tool actually does (e.g., triggers a completion check, logs status, or returns a decision). The purpose is vague and lacks a clear verb+resource 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 description provides implied usage by stating 'whenever you feel that you are done,' which gives some context for when to call it. However, it does not explicitly differentiate from sibling tools (e.g., 'think_about_collected_information' or 'think_about_task_adherence') or specify alternatives, leaving gaps in 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?

No annotations are provided, so the description carries the full burden. It discloses behavioral traits like using markdown formatting, keeping content short, and preferring multiple small memories over large ones. However, it doesn't cover important aspects like whether this is a destructive operation (though implied by 'write'), error conditions, or what happens on success/failure.

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 with the core purpose. However, it includes some redundancy (e.g., explaining why multiple small memories are better could be more concise) and the final sentence about usage scenarios could be integrated more smoothly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no annotations, no output schema, and 3 parameters with 0% schema coverage, the description provides reasonable context for a write operation but has significant gaps. It covers purpose and usage guidelines well, but lacks details about return values, error handling, and complete parameter documentation, making it incomplete for reliable tool invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage and 3 parameters, the description adds minimal semantic value. It mentions 'memory_name' should be meaningful and 'content' should use markdown, but doesn't explain 'max_answer_chars' at all. The description doesn't adequately compensate for the schema's lack of parameter documentation.

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: 'Write some information about this project that can be useful for future tasks to a memory.' It specifies the verb ('write'), resource ('memory'), and content type ('information about this project'), though it doesn't explicitly differentiate from sibling tools like 'read_memory' or 'delete_memory' beyond the obvious action difference.

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 guidance on when to use this tool: 'This tool is either called during the onboarding process or when you have identified something worth remembering about the project from the past conversation.' It clearly defines two specific scenarios for usage, though it doesn't mention alternatives or exclusions.

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