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 doesn't disclose what the return value looks like, whether it returns a boolean or throws an error, whether it follows symlinks, or whether it requires any permissions. For a status-check tool, the return format is important behavioral context.

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

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

One short sentence that is front-loaded with the verb and resource. No wasted words.

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

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

For a simple one-parameter tool, the description is minimal but lacks return-value information. With no output schema and no annotations, the agent doesn't know what 'check' returns (boolean, status object, error). This is a clear gap for a status-checking 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 coverage is 100%, so the schema already documents the single parameter. The description adds no additional meaning beyond what the schema provides, so baseline 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 states a specific verb ('check') and resource ('a specific file'), and the concept of 'locked' is clear. It doesn't explicitly distinguish from sibling tools like lock_file or unlock_file, but the verb 'check' makes it clear this is a read-only status query rather than a mutation.

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 when to use it: when you need to know if a file is locked. It doesn't explicitly state when not to use it or mention alternatives like list_locks, but the context of sibling tools makes the use case reasonably clear.

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

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

No annotations are present, so the description must carry the full behavioral transparency burden. It only says 'tree view' and provides no details about default path behavior, handling of excluded patterns, hidden files, symlinks, or return format.

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?

A single concise sentence with no wasted words. It communicates the core purpose immediately and stays appropriately minimal for a simple read-only tool.

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

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

For a simple tool with optional parameters and no output schema, the description plus schema covers the basics. However, it lacks guidance on default roots, exclusion pattern semantics, or how the tree is rendered, and it fails to mention sibling alternatives.

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 parameters are already well documented with 'Root path', 'Patterns to exclude', and 'Maximum depth (default: 3)'. The description adds little beyond the schema, which is acceptable given the high coverage.

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

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

The description uses a specific verb and resource ('Get a tree view of the project directory structure'), which clearly distinguishes it from a flat file list. However, it does not explicitly contrast it with sibling tools like list_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 gives no guidance on when to use this tool versus alternatives such as list_files or search_files. It does not state when a tree view is preferred or when another sibling should be used.

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 responsibility for disclosing behavior. It only states the action and mechanism, not what happens on a failed search, whether the edit is atomic, whether replacement requires unique matches, or whether any locking protocol is relevant. For a mutation tool this is a significant transparency gap.

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

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

One short sentence that is front-loaded with the verb and resource before explaining the mechanism. Every word earns its place, and there is no redundancy or filler.

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

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

The tool is a mutation with no annotations and no output schema, so more behavioral context is needed than what is provided. There is no mention of failure behavior when no match is found, whether replace_all replaces across the whole file by default, or how success is reported. The schema covers parameters, but operational context is missing.

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

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

Schema description coverage is 100%, and the parameter descriptions already explain 'path', 'search', 'replace', and 'replace_all'. The tool description adds no per-parameter information, but the schema already does the heavy lifting, so a baseline score of 3 is appropriate.

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

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

The description uses a specific verb ('edit') with a resource ('file') and the exact mechanism ('search and replace'). The word 'targeted' distinguishes this from write_file, which would replace or create an entire file. This is a clear, unambiguous purpose statement.

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

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

There is no explicit guidance on when to use this tool instead of write_file or when a targeted edit is appropriate. The phrase 'targeted edit' implies a contrast with full-file writes, but it does not state prerequisites, exclusions, or alternative conditions. The agent is left to infer usage from the sibling tool names.

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 says 'search file contents,' omitting whether results are file paths or matching lines, whether the search is recursive, or whether any limits apply. This leaves important behavioral traits undisclosed.

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

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

The description is a single, efficient sentence that front-loads the core action. It avoids filler, though it is slightly terse and could benefit from a clarifying detail about output or scope.

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 overlap with search_files, lack of annotations, and absence of an output schema, this minimal description is not fully complete. It leaves uncertainty about path defaults, include patterns semantics, recursion, and return format, which an agent would need to invoke it confidently.

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 no extra meaning beyond what the schema provides, except aligning the regex pattern with the purpose, which is sufficient for 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 states a specific verb ('search') and resource ('file contents') using a regex pattern, which clearly conveys the core operation. It does not explicitly distinguish grep_content from the sibling search_files, but the purpose itself is identifiable.

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

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

No guidance is given on when to use this tool versus alternatives like search_files or list_files. The description neither states preferred use cases nor excludes cases where another sibling would be more appropriate.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It discloses that the tool creates an invite link but omits meaningful side effects: whether an email is sent to the invitee, whether permissions apply immediately, whether the link expires silently, or what the response format is. For a tool with side effects (granting access), this is a notable gap.

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

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

A single, efficient sentence with zero filler. It is appropriately front-loaded with the core action. It's concise but borders on under-specification given the tool's side effects, so a 4 rather than a 5.

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

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

The tool has meaningful side effects (inviting a member and granting permissions) yet has no annotations and only a one-sentence description. There is no coverage of return values, side effects, or edge cases. For a tool of this complexity, the description is too thin to be considered 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 coverage is 100%, so the schema already documents all three parameters clearly, including the enum options (read/write/admin) and the default for expires_in_days (7). The description adds no parameter-level information beyond the schema, which is acceptable at the baseline of 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 states a specific verb ('Generate') and resource ('invite link for a new team member'), making the tool's function clear. It is inherently distinguishable from siblings like revoke_access and list_members, though it doesn't explicitly name them. A 4 is appropriate since the purpose is unambiguous even without explicit sibling differentiation.

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

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

No explicit when-to-use or when-not-to-use guidance is provided. However, the purpose is self-evident from the description and the sibling set (revoke_access, who_is_online) makes the intended context inferable. Usage is implied rather than stated, so a 3 is fair.

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

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

With no annotations, the description carries the full burden of behavioral disclosure, but it only restates the verb and resource. It does not mention default recursion behavior, hidden-file handling, output shape, or whether this is strictly a read-only operation beyond what the word 'List' implies.

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, compact sentence with no filler. It front-loads the action and resource, and the length is appropriate for a simple two-parameter listing tool.

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

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

For a low-complexity tool with only two fully documented parameters, the description is minimally adequate: it tells the agent that the tool lists files and directories in the shared project. However, with no output schema and no annotations, it leaves gaps around recursive defaults and result format that an agent might need for correct 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?

Schema description coverage is 100%, so both path (with its root default) and recursive are already documented in the schema. The description adds no additional parameter-level meaning, keeping this at the baseline.

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

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

The description states a clear verb ('List') and resource ('files and directories') within a defined scope ('shared project'), so an agent can understand the core function. However, it does not differentiate from the sibling tool directory_tree, which likely serves a similar listing 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?

No guidance is provided on when to use this tool over alternatives like directory_tree, search_files, or grep_content. The description explains only what the tool does, not the conditions that make it the right choice among its 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?

With no annotations provided, the description fully shoulders the burden of behavioral disclosure. 'List' implies a non-destructive read operation, but it never explicitly states that no side effects occur, whether permissions are required, or what constitutes an 'active' lock (e.g., does it show locks held by the current user only, or all users?). The description lacks explicit transparency about its behavior beyond the action itself.

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

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

The description is a single, efficient sentence with the verb and resource front-loaded. It contains no filler or redundancy, making it maximally concise while conveying the core functionality.

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

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

For a tool with no output schema and no parameters, the description should ideally specify what the returned data contains (e.g., lock paths, owners, timestamps). It only says 'list all ... file locks,' which leaves the return format unspecified. An agent might need additional context to parse the results correctly, though the tool's simplicity mitigates the severity of this gap.

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

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

The tool has zero parameters and schema coverage is 100%, so there is nothing for the description to clarify. Baseline for zero parameters is 4; the description adds no parameter info, but none is needed. It correctly implies no input is required.

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 verb 'List' with resource 'file locks' and scope 'all currently active' gives a specific, unambiguous purpose. It clearly distinguishes from siblings like lock_file and unlock_file, which perform mutations, and check_lock, which targets a specific lock. The agent can identify this as the 'list all locks' tool without ambiguity.

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 the tool is for retrieving the full set of active locks, which is clear context. However, it does not explicitly state when to use this tool versus alternatives like check_lock (for a single lock) or view_changes (for modifications). No exclusion or alternative routing is provided, so the agent must infer usage from sibling names.

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 must carry the behavioral disclosure burden. It conveys that the operation is read-only and scoped to all members and their permissions, but it does not mention authorization requirements, output shape, or any caveats. 'List' implies safety, yet details are thin.

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?

A single, front-loaded sentence says exactly what the tool does with no filler or repetition. Every word contributes to the agent's 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?

For a zero-parameter, read-only listing tool, the description is largely complete: it states the resource and the data returned (members and permissions). It could be slightly richer about output format or team scope, but nothing essential is missing for invoking this simple tool.

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

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

The tool has zero parameters, so there is no parameter-level semantics to document. Per the rubric, a zero-parameter tool receives a baseline of 4 since the description has no parameter burden to meet.

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?

Description uses a specific verb ('List') and resource ('all team members and their permissions'), making the tool's function immediately clear. It is easily distinguished from sibling tools like invite_member, revoke_access, and who_is_online.

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 gives no guidance on when to use this tool versus alternatives such as who_is_online or list_locks, and it names no exclusions or prerequisites. The intended context is implied but never stated explicitly.

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 action (acquire an exclusive lock) without explaining what happens if the lock is already held, whether it blocks, what the side effects are, or that it should be followed by unlock_file. This is a significant gap for a mutating 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, front-loaded sentence that communicates the core action without waste. It is appropriately short, though it could benefit from a brief note about lock release or contention behavior without sacrificing 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?

For a mutating tool with no annotations and no output schema, the description is incomplete. It does not specify the return value, failure modes (e.g., lock already taken), or the expectation to later unlock. Given the sibling unlock_file exists, a minimal mention of this would improve completeness. The description leaves an agent guessing about critical call outcomes.

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 coverage is 100%, with both 'path' and 'reason' already described in the input schema. The tool description adds no additional meaning about these parameters (e.g., format, constraints, or examples). Baseline 3 applies because the schema handles parameter documentation adequately.

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 ('Acquire an exclusive lock on a file') and the context ('before editing'). It is specific and distinguishes from read/write operations, though it doesn't explicitly differentiate from sibling tools like check_lock or list_locks. The resource and purpose are 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 implies when to use this tool ('before editing') but does not explicitly mention when not to use it or provide alternatives. It doesn't reference sibling tools such as check_lock (for checking status) or unlock_file (for releasing), leaving some inference required.

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 carry the behavioral burden on its own. It implies a read-only operation, but it does not disclose line-range defaults, behavior when no start_line/end_line is supplied, error handling for missing paths, or output format.

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

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

The description is a single sentence with no filler. It front-loads the core action ('Read') and clearly names the resource, making it appropriately sized for a simple read tool.

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

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

The tool is low complexity and the schema documents all parameters, but there are no annotations and no output schema. The description omits return format, line-range behavior, and failure modes, leaving a partial information gap for an agent invoking the tool correctly.

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

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

Schema description coverage is 100%, with all three parameters documented in the input schema. The description adds no extra parameter-level meaning, so the baseline score of 3 is appropriate.

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

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

The description uses the verb 'Read' and a specific resource ('a file in the shared project'), clearly identifying the operation. It does not explicitly contrast with siblings like grep_content or search_files, but its scope is clear enough to avoid confusion with directory/list tools.

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

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

No guidance is given about when to use read_file versus alternative content-access tools such as grep_content or search_files. The description states only what the tool does, not when to pick it over siblings or when not to use it.

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 carry the full burden of behavioral disclosure. It only signals mutation through the word 'Revoke' and does not mention permanence, reversibility, side effects on the member's data, or required permissions, all of which matter for an access-revocation 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 short sentence with no redundant wordscars, and the core action is front-loaded. It is concise, though adding one or two sentences about consequences would improve balance without hurting 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?

For a destructive access-control action with no annotations and no output schema, this description is too sparse. It omits information about reversibility, what happens to the member's existing access or data, and what response the agent should expect, leaving the agent under-informed.

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

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

The input schema already documents both parameters with 100% coverage, including 'user_id' and 'reason', so the description does not need to repeat them. The description adds no extra parameter context, which matches 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 names a specific action, 'Revoke', and a specific resource, 'a team member's access', so a model can tell what the tool does. It semantically contrasts with invite_member, but it does not explicitly define what kind of access is being revoked or differentiate itself from related tools beyond the verb.

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

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

There is no guidance on when to use this tool versus alternatives. The description is only a bare action phrase, so the agent is left to infer the use case without any mention of prerequisites, exclusions, or when to prefer another tool like invite_member.

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

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

With no annotations, the description must carry the burden of behavioral disclosure. It only says 'Search for files matching a glob pattern' and does not mention whether the search is recursive, how hidden files are handled, what the return format is, or whether max_results has implications. This is a significant gap for a 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, front-loaded sentence with no wasted words. It efficiently communicates the core action and resource.

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

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

For a simple tool with no output schema and no annotations, the description is incomplete. An agent would lack information about default behaviors, return structure, or edge cases. It is minimal to the point of being under-specified for reliable 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?

Schema description coverage is 100%, so both parameters are already documented in the schema. The description adds minimal value beyond repeating the pattern concept; it does not clarify glob syntax or provide examples. Baseline of 3 is appropriate given high schema coverage.

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

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

The description states a specific verb (search) and resource (files) with a clear method (glob pattern). It is distinct from siblings like list_files (which lists files in a directory) and grep_content (which searches file contents), though it does not explicitly name 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?

No guidance is provided on when to use this tool versus siblings such as list_files or grep_content. The description only states the basic function without any context on selection criteria, prerequisites, or exclusions.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the action without mentioning side effects, error conditions (e.g., what happens if the file is not locked), or permissions required. This is a significant gap for a mutation tool, making it insufficiently transparent.

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

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

The description is a single, efficient sentence with zero fluff. It front-loads the core action and context, making it easy to parse quickly. No unnecessary words.

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

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

For a tool with no output schema and no annotations, the description should explain what happens on success/failure and any prerequisites. It does not mention idempotency, behavior on missing locks, or whether the lock must be owned by the caller. Given the sibling tools and the need for safe invocation, this is incomplete.

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

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

The schema fully describes the single parameter 'path' as 'File path to unlock' (100% coverage). The description adds no additional meaning beyond that, so it meets the baseline of 3 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 action ('Release a lock') and the resource ('on a file'), with an explicit temporal context ('after editing'). It distinguishes itself from sibling tools like lock_file, list_locks, and check_lock by naming the release action, making its 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 gives a clear usage context: use after editing a file. However, it does not explicitly state when NOT to use it, nor does it mention alternatives (e.g., check_lock to verify a lock exists first). The guidance is implied rather than explicit, earning a 4 rather than a 5.

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

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

With no annotations, the description carries the behavioral burden; 'View' does indicate a non-mutating operation, but no details are given about ordering, pagination, or the exact meaning of 'all team members'. The description is not misleading, but it is thin on 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 a single, front-loaded sentence with no filler. It clearly states the action, the target resource, and the scope, making every word 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?

For a simple tool with three optional parameters, the description is minimally adequate, but with no output schema it does not say what the returned change entries contain. It also leaves ambiguity about whether 'changes' means file modifications, permissions changes, or another audit trail.

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 even though the description itself adds no parameter-level guidance. The schema already documents limit, user_id, and file_path, but the description does not explain how these filters interact.

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

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

The description uses a specific verb ('view') and identifies the resource as 'recent changes made by all team members', which separates it from file read/write siblings. However, it does not specify whether these changes are file edits, access changes, or some other kind of history.

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

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

No guidance is provided on when to use this tool instead of sibling tools like view_stats, list_files, or read_file. There are no stated exclusions, alternatives, or contextual hints beyond the implied purpose of viewing activity.

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 indicates a read operation ('View') but does not state whether it is read-only, what side effects (if any) exist, how statistics are aggregated, or what the response format looks like. Critical behavioral details are absent.

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

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

The description is a single, concise sentence with no filler. It is front-loaded with the core action and resource. However, it is so brief that it misses opportunities to add useful context, though it does not waste words.

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

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

For a tool with no output schema and no annotations, the description is the sole source of information about what the agent will receive. Saying 'statistics about the project' is vague; it does not enumerate which metrics, how they are grouped, or any formatting. An agent cannot predict the tool's behavior accurately from this description alone.

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

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

The tool has zero parameters, so the schema trivially covers 100% of them. Per the baseline for 0-parameter tools, a score of 4 is appropriate. The description adds no parameter-specific meaning because none exists; no compensation is needed.

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

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

The description uses a specific verb ('View') and a resource ('statistics about the project'), which is distinct from the sibling tools focused on files, locks, members, and changes. However, it lacks specificity about what kind of statistics are provided, so it is clear but not fully descriptive.

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

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

There is no guidance on when to use this tool versus alternatives. The description does not mention any conditions, prerequisites, or exclusions. An agent must infer that 'viewing statistics' is the purpose, but there is no explicit routing away from siblings or context for selection.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool shows currently connected members, implying a real-time or snapshot view, but does not disclose whether authentication is required, how 'connected' is defined, whether the list is ordered, or what happens if no one is online. It also doesn't mention any limitations (e.g., staleness, permissions). This is a minimal disclosure for a read-only presence 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 a single, concise sentence that directly states the purpose. It is front-loaded with the action and object, containing no filler or redundancy. It earns a high score for brevity and clarity.

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

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

Given the simplicity of the tool (no parameters, no output schema), the description is nearly sufficient, but it leaves the return format unspecified. It does not state whether the result is a list of names, a count, or a structured object. The description implies the output lists connected members but doesn't confirm it. For a presence tool, this ambiguity is a minor but notable gap.

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

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

The tool has zero parameters, and the schema has 100% coverage (trivially). With no parameters to document, the description does not need to explain parameter semantics. The baseline of 4 for zero parameters is appropriate; the description adds no parameter-related meaning because none exists, and that is acceptable.

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 see which team members are currently connected. It uses a specific verb ('see') and resource ('team members'), and the meaning is distinct from siblings like list_members (which likely lists all members regardless of presence) and check_lock (which checks lock status). While it doesn't explicitly name a sibling, the purpose is unambiguous and informative.

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 list_members or other presence-related tools. It does not state any conditions, exclusions, or mention of when this tool is preferred. The usage context is implied (checking online status) but not made explicit.

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

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

The description discloses the key destructive behavior ('overwrite') and scopes the operation to the shared project. With no annotations provided, it does not cover directory creation behavior, permissions, failure modes, or what happens to existing content beyond the overwrite implication.

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?

A single sentence that front-loads the core action, resource scope, and overwrite behavior. It earns its place, though a brief note about directory creation behavior would have made it slightly more useful.

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 low-complexity tool with fully documented parameters, the description provides the essential contract: create or overwrite a file. It omits return behavior and any handling details for missing parent directories, but schema and sibling context cover most selection needs.

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 path, content, and create_dirs are already documented. The description adds no additional parameter nuance, but it also does not introduce ambiguity, so the baseline of 3 applies.

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?

States a specific verb and resource: 'Create or overwrite a file' in the shared project. This clearly separates it from sibling read/edit/search tools by emphasizing file creation and full overwrite.

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?

Provides no explicit guidance on when to use write_file versus edit_file or other file tools. It does not mention alternatives, prerequisites, or conditions that would route an agent to a different sibling.

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