Server Quality Checklist

Tool Scores

• git_statusB
  3/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is established. The description adds 'fixed' (implying no custom arguments) and 'authorized' (implying a prerequisite), which are useful contextual details beyond the annotation. However, it does not disclose what the status output contains (e.g., modified, staged, untracked files) or whether it includes branch information, so it adds only modest 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.

  Conciseness4/5

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

  The description is a single, front-loaded sentence with no wasted words. It is compact and readable. However, it could add a brief clause about what status returns without losing conciseness, so it is not a perfect 5.

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

  Completeness2/5

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

  For a one-parameter read-only tool, the description is thin. It does not explain the projectId parameter, does not mention the need to have a project authorized (despite implying 'authorized'), and provides no information about the return value or output format. There is no output schema, so the description carries the full burden, which is left unmet.

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

  Parameters1/5

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

  The schema has a single parameter, projectId, with no description and zero schema coverage. The description only says 'in an authorized project,' which hints that projectId should reference an authorized project, but it does not explain what the parameter format is, how to obtain a valid ID, or that it might be listed via list_projects. Since schema coverage is 0%, the description must compensate, and it fails to do so.

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

  Purpose5/5

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

  The description clearly states the action ('Run') and the resource ('a fixed, read-only Git status command'), and the 'read-only' plus 'fixed' qualifiers distinguish it from mutation tools like git_commit and git_push, and from comparison tools like git_diff. It is unambiguous what this tool does.

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

  Usage Guidelines2/5

  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 its siblings. It does not mention that git_status is the go-to for checking working tree state, nor does it warn against using it for diffs or staging. It only mentions 'in an authorized project,' which is a prerequisite, not a usage comparison.

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

• create_text_fileB
  3.1/5.0
  Behavior3/5

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

  The description adds the non-overwrite behavior, which is useful and not fully captured by the annotations (which only mark readOnly and destructive hints). However, it does not disclose other behavioral traits such as error handling when the path exists, whether parent directories are created, or any permission requirements. Given the annotations cover the readOnly/destructive baseline, the description provides moderate added value but lacks deeper context.

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

  Conciseness5/5

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

  The description is a single, compact sentence that front-loads the action and the critical constraint. Every word earns its place, and there is no fluff or redundancy.

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

  Completeness2/5

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

  The tool has three required parameters and no output schema, and the description does not explain the parameter format, expected inputs, or how the tool interacts with the project. It also lacks guidance on prerequisites or alternatives. For an agent to call it correctly, it would need the schema (which has no descriptions) or external knowledge, making this definition incomplete.

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

  Parameters1/5

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

  Schema description coverage is 0%, so the description must compensate for parameter meaning, but it does not. It provides no explanation of projectId, path, or content beyond their names. An agent has to infer that projectId identifies the project, path is the file location, and content is the text to write, which could be ambiguous.

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

  Purpose5/5

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

  The description states a specific verb (create), resource (text file), and a key constraint (without overwriting an existing path), which clearly distinguishes it from siblings like delete_text_file and apply_patch. It is not a tautology and leaves no ambiguity about what the tool accomplishes.

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

  Usage Guidelines2/5

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

  No guidance is provided on when to use this tool versus alternatives. It does not mention that it should be used for creating new files, or that apply_patch or other write mechanisms would be inappropriate. The description only states what it does, not the context or preconditions (e.g., project must be connected) for using it.

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

• read_fileB
  3.1/5.0
  Behavior3/5

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

  Annotations already cover readOnlyHint=true and destructiveHint=false, which the agent knows. The description adds the behavioral detail that it returns a SHA-256 edit precondition, which is useful context but does not fully disclose behavior like error conditions, encoding assumptions, or effect on file state. Given the annotations, a score of 3 is appropriate.

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

  Conciseness5/5

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

  The description is two sentences, front-loads the core action, and wastes no words. Every phrase contributes to the meaning, making it highly concise and well-structured.

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

  Completeness3/5

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

  For a read-only tool with annotations covering safety and no output schema, the description is adequate but not complete. It does not explicitly mention that the returned hash is intended for later edit precondition checks, nor does it note that the tool reads only text files. An agent could call it correctly but might miss the intended workflow integration with sibling patch tools.

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

  Parameters2/5

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

  Schema description coverage is 0%, so the description carries the full burden of explaining parameters. It mentions 'bounded line range' but does not explain startLine and endLine semantics, defaults, or how they interact. For a 4-parameter tool with zero schema coverage, the description falls short of even the baseline minimal value.

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

  Purpose4/5

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

  The description states a specific verb ('Read'), a resource ('a text file'), and a bounded line range, plus the return value (SHA-256 edit precondition). This is clear enough for an agent to know what the tool does, though it does not differentiate it from sibling read-like tools such as search_text or list_files.

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

  Usage Guidelines2/5

  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. It does not mention that it is likely a pre-edit step for apply_patch, nor does it specify any conditions or exclusions. An agent would have to infer the use case from the return value, which is not ideal.

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

• git_diffB
  3.2/5.0
  Behavior3/5

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

  Annotations already cover read-only and non-destructive nature. The description adds that the command is 'fixed' (non-customizable) and requires authorization, which is useful context. However, it does not clarify the effect of the 'staged' parameter or output behavior, so it adds limited value beyond annotations.

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

  Conciseness5/5

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

  A single sentence with no redundancy. The key constraint 'fixed, read-only' is front-loaded, and every word earns its place.

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

  Completeness2/5

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

  The tool is simple, but the description omits how the 'staged' parameter changes behavior (diff against index vs working tree) and does not describe the output format. Given no output schema, this is a notable gap for an agent to invoke it correctly.

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

  Parameters2/5

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

  With 0% schema coverage, the description should explain parameters, but it only mentions 'Git diff command' without clarifying 'projectId' or 'staged'. The 'staged' boolean is self-evident from Git knowledge, but the description adds no explicit meaning, leaving a gap.

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

  Purpose4/5

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

  The description clearly states the action (run) and resource (Git diff command), and specifies 'fixed, read-only' and 'authorized project'. It is distinct from siblings like git_status by focusing on diff, 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.

  Usage Guidelines3/5

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

  Mentions 'authorized project' as a contextual requirement, but provides no guidance on when to use this tool versus git_status or other read-only tools. No exclusions or alternatives are listed, leaving usage to inference.

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

• list_filesB
  3.2/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile, so the description's burden is lighter. It adds the 'authorized project path' context, hinting at an access-control consideration, but reveals nothing about traversal behavior, error cases, or how max entries/depth limits surface.

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

  Conciseness5/5

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

  A single, readable sentence that front-loads the action and object with no filler. Every word earns its place; the 'authorized' qualifier is the only mildly extraneous addition.

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

  Completeness2/5

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

  For a 4-parameter tool with 0% schema coverage and no output schema, this description is minimal. It leaves unaddressed how pathPrefix relates to 'authorized project path', what the depth/entry limits imply about returned data, and how results are structured. An agent gets enough to attempt a call but not to call it correctly on the first try.

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

  Parameters2/5

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

  Schema description coverage is 0% and the description names none of the 4 parameters (projectId, pathPrefix, maxDepth, maxEntries). It does not clarify what 'authorized project path' maps to in terms of pathPrefix or projectId, so the agent gets no help beyond the raw schema.

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

  Purpose4/5

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

  States a specific verb ('List') and a clear resource ('files and directories beneath a project path'), which clearly differentiates it from siblings like read_file (reads content) and search_text (searches content). The qualifier 'authorized' is slightly vague but does not obscure the core purpose.

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

  Usage Guidelines3/5

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

  The purpose implies when to use it (browse a project's file tree), and the sibling list makes the alternative obvious. However, there is no explicit when-to-use vs when-not-to-use guidance, no mention of the relationships to discover_projects or read_file, and no stated exclusions.

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

• git_commitB
  3.3/5.0
  Behavior3/5

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

  The description adds useful behavioral context beyond the annotations by revealing that the tool performs concurrency validation, whitespace checks, and sensitive-content scanning. However, it does not explain what happens if these checks fail, the consequences of the commit, or the role of the expectedStatusSha256 parameter in the concurrency mechanism. The description is partially transparent but lacks depth for this complex operation.

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

  Conciseness5/5

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

  The description is a single, well-constructed sentence that immediately conveys the core action and its constraints. It is front-loaded with the primary verb ('Stage and commit') and scope ('only explicit relative paths'), followed by the key validation steps. There is no redundant or superfluous language, making it highly concise and effective.

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

  Completeness2/5

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

  For a mutation tool with concurrency checks and four required parameters, the description is incomplete. It does not explain how to compute the expectedStatusSha256, the semantics of paths relative to the project root, or the expected output/behavior after a successful commit. Given the tool's complexity and the lack of parameter documentation, the description is insufficient for an agent to invoke it correctly without additional knowledge.

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

  Parameters2/5

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

  The input schema has zero description coverage for its four required parameters, and the description does not explain any of them. While the description mentions 'explicit relative paths' which loosely maps to the `paths` parameter, there is no clarification of the expected format, the meaning of `expectedStatusSha256`, or how `projectId` and `message` should be used. The description adds no parameter-level meaning beyond the schema, which is a significant gap.

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

  Purpose5/5

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

  The description clearly states the tool stages and commits only explicit relative paths after performing several checks. It identifies the specific action (stage and commit), the resource (project changes), and the scope (explicit relative paths), which is specific and unambiguous. It also subtly differentiates from a generic commit by emphasizing the selective path requirement.

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

  Usage Guidelines2/5

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

  The description does not provide any guidance on when to use this tool versus alternatives like git_push, git_unstage, or git_status. Although it mentions 'after status review,' it does not explicitly state the conditions for invoking this tool or when to avoid it. There is no mention of alternative tools or exclusions, leaving the agent to infer usage context.

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

• git_pushA
  3.5/5.0
  Behavior4/5

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

  Annotations already indicate non-read-only, non-destructive, and open-world behavior. The description adds meaningful context: the destination must be allowlisted, force push is disallowed, and local per-project enablement is required. These details go beyond the annotations and help the agent understand operational constraints.

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

  Conciseness5/5

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

  Two sentences, 22 words, with zero fluff. The core action and constraints are front-loaded, and the prerequisite (local enablement) is stated efficiently. Every word earns its place.

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

  Completeness2/5

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

  For a mutation tool with no output schema and no parameter descriptions, the description is too thin. It does not explain what happens if the remote is not allowlisted, what 'enabled locally per project' means in practice, error scenarios, or the return value. The agent cannot fully predict the tool's behavior or know if it can call it correctly without additional information.

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

  Parameters1/5

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

  Schema description coverage is 0%, and the description does not reference any parameters. The tool has 3 parameters (remote, projectId, expectedCommitSha), but the description never explains their meaning, relationships, or how they relate to the action (e.g., 'current commit' vs expectedCommitSha). The agent must rely solely on the schema, which provides only names and patterns, not semantic guidance.

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

  Purpose5/5

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

  The description states a clear, specific action: push the current commit without force to an allowlisted remote/branch. It distinguishes itself from sibling git tools (e.g., git_commit creates, git_push pushes) and adds constraints (without force, allowlisted). No tautology or ambiguity.

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

  Usage Guidelines3/5

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

  The usage context is implied (when you have a reviewed commit and need to push it) but not explicitly stated. No exclusions, alternatives, or prerequisites beyond the 'must be enabled locally per project' note. There is no guidance on when not to use this tool or when another tool would be more appropriate, but the purpose is clear enough.

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

• run_taskA
  3.5/5.0
  Behavior3/5

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

  Annotations already indicate the operation is not read-only and not destructive, so the bar for behavioral disclosure is lower. The description adds the crucial context that the task is 'allowlisted' and user-configured, implying security sensitivity. However, it does not mention potential side effects, output format, or error behavior, leaving some behavioral ambiguity.

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

  Conciseness5/5

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

  A single sentence that conveys the core function without verbosity. Every word adds value, and the critical 'allowlisted' qualifier is front-loaded. Perfectly concise for a tool of this simplicity.

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

  Completeness2/5

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

  Despite the tool's low complexity, the description does not specify what the tool returns (e.g., output of the task), whether it blocks until completion, or how errors are surfaced. Since there is no output schema and annotations give minimal guidance, the agent is left guessing about the call behavior. A sentence on return format or side effects would meaningfully improve completeness.

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

  Parameters2/5

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

  Schema description coverage is 0% and the description does not explicitly define the two parameters. It only implies that taskName refers to the configured task and projectId to the project. An agent without prior knowledge would not know what values to supply for these parameters, making this a weak point.

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

  Purpose5/5

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

  The description clearly states a specific verb 'Run' with a clearly bounded resource: 'one task' that is 'allowlisted' and whose executable/arguments were pre-configured. This distinguishes it from all siblings (none of which execute tasks) and leaves no ambiguity about what the tool does.

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

  Usage Guidelines3/5

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

  The description implies usage: run a pre-configured task, but provides no explicit guidance on when to prefer this over alternatives, nor any exclusions (e.g., 'do not use for ad-hoc commands'). Since no sibling does anything similar, the lack of named alternatives is acceptable, but the description could be clearer about when to invoke it.

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

• search_textA
  3.5/5.0
  Behavior3/5

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

  Annotations already provide readOnlyHint=true and destructiveHint=false, so the description's burden is reduced. It adds 'bounded text files' and 'authorized project' scope, but does not disclose whether the search is substring or exact, the result format, or performance characteristics. These details remain unspecified.

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

  Conciseness5/5

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

  A single sentence that is front-loaded with the action ('Search') and scope ('literal string across bounded text files'). Every word adds value, with no redundancy or filler.

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

  Completeness2/5

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

  Despite having six parameters and no output schema, the description is extremely brief. It does not explain what 'bounded text files' means, the default behavior of parameters, or what the tool returns. While annotations cover safety, an agent would be uncertain about output structure and edge cases, making the description insufficiently complete.

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

  Parameters2/5

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

  Schema description coverage is 0%, and the description makes no mention of parameters. While parameter names like 'query', 'extensions', and 'caseSensitive' are self-explanatory, the description fails to compensate for the absence of schema descriptions, offering no additional meaning for any of the six parameters.

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

  Purpose5/5

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

  The description clearly states a specific action, 'Search for a literal string', on a bounded resource, 'bounded text files in an authorized project'. This distinguishes it from siblings like read_file and list_files, and no ambiguity exists about its core function.

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

  Usage Guidelines3/5

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

  The description implies its use case (finding a literal string) but provides no explicit guidance on when to choose it over alternatives or when not to use it. The phrase 'bounded text files' hints at scope but does not clarify which files qualify, leaving the usage context implied rather than stated.

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

• diagnosticsA
  3.6/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds the usage context 'before starting local project work' but does not elaborate on what the tool actually checks or how it behaves beyond that. It does not contradict the annotations and provides minimal additional behavioral detail.

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

  Conciseness5/5

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

  The description is a single, front-loaded sentence with no wasted words. It states the purpose and usage timing efficiently, making it easy for an agent to parse quickly.

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

  Completeness3/5

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

  Given the tool has no parameters and no output schema, the description could still be more complete by specifying what 'configuration and safety capabilities' refers to and what the result looks like (e.g., a pass/fail report, a list of issues). As written, it leaves the agent without a clear expectation of the output, though it is sufficient to invoke the tool.

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

  Parameters4/5

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

  The tool has 0 parameters and the schema coverage is 100% (empty schema). Per the rubric, a baseline score of 4 applies for 0 parameters. The description does not need to explain parameters since there are none.

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

  Purpose4/5

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

  The description clearly states the verb 'Check' and the resource 'configuration and safety capabilities' within the context of the local project workspace. It is distinct from sibling tools like list_projects or read_file because it focuses on diagnostics rather than project listing or file operations, though it does not explicitly name siblings.

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

  Usage Guidelines3/5

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

  The description provides a clear usage context: 'before starting local project work.' However, it does not explicitly mention alternatives or exclusion conditions (e.g., when not to use this tool or which sibling tool to use instead). The guidance is implied rather than explicit.

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

• apply_patchA
  3.7/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=false and destructiveHint=false. The description adds the guard context (verification step) which is useful, but it does not disclose what happens on patch failure, SHA mismatch, or non-existent file. No contradiction with annotations.

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

  Conciseness5/5

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

  A single, front-loaded sentence that communicates the core action and the guard with zero wasted words. Exemplary conciseness.

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

  Completeness3/5

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

  Adequate for a guarded mutation tool but incomplete: it does not describe failure behavior, whether changes are reversible, or what happens on SHA mismatch. Given the potential consequences of applying patches, more detail would strengthen completeness.

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

  Parameters3/5

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

  The description adds meaning to expectedSha256 (the hash returned by read_file) and patch (unified diff format), which helps beyond the bare schema. However, projectId and path are left to inference, and with 0% schema coverage, more compensation would be expected.

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

  Purpose5/5

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

  The description states a specific verb ('apply'), resource ('unified diff to one existing text file'), and a distinctive guard (SHA-256 verification). It clearly distinguishes itself from sibling tools like create_text_file and delete_text_file.

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

  Usage Guidelines3/5

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

  The description implies the prerequisite of calling read_file first (to obtain the SHA-256) but does not explicitly state when to use this tool versus alternatives like create_text_file. It lacks explicit 'when not to use' or alternative routing.

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

• discover_projectsA
  3.7/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds a meaningful behavioral detail beyond annotations: the search is limited to approved parent folders and includes non-Git folders. This tells the agent the tool will not scan arbitrary paths, which is important for setting expectations. It doesn't describe return format or performance, but given annotation coverage, this is acceptable.

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

  Conciseness5/5

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

  The description is a single, front-loaded sentence that immediately states the verb and resource, then adds the key scope constraint. No wasted words; every part contributes to the tool's purpose. It is efficient and clear, though brevity comes at the cost of parameter explanation.

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

  Completeness2/5

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

  With no output schema, 0% parameter schema coverage, and four parameters, the description is insufficient. It explains only the scope (approved folders) and a hint at non-Git inclusion, but omits what maxDepth/maxProjects/maxDirectories do, what the return shape is, or any pagination/concurrency behavior. For a tool with this parameter complexity and no schema descriptions, the description should do much more to make the tool callable correctly.

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

  Parameters2/5

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

  Schema description coverage is 0%, so the description must compensate for the four parameters (maxDepth, maxProjects, includeNonGit, maxDirectories). The description only hints at includeNonGit via 'non-Git project folders' but doesn't name or explain any parameter. Depth limits, count limits, and directory limits are entirely undocumented. This leaves the agent with no meaning for the parameters beyond defaults and types.

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

  Purpose5/5

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

  The description states a specific verb ('Find') and resource ('Git repositories and common non-Git project folders'), and adds a critical scope constraint ('only beneath parent folders that the user approved locally during setup'). This clearly distinguishes it from siblings like list_projects, which presumably lists known projects without that restriction. The purpose is unambiguous and actionable.

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

  Usage Guidelines3/5

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

  The description implies usage context by restricting to approved parent folders, but does not explicitly name alternatives or when to use another tool. It lacks guidance on when not to use this (e.g., when a user needs to see all projects regardless of approval status). The constraint hints at a filtering role, but no alternatives are referenced, so an agent has to infer the boundary between this and list_projects.

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

• git_unstageA
  3.7/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=false and destructiveHint=false. The description adds the behavioral nuance that the working tree remains unchanged, which is valuable and not fully captured by the annotations. It does not contradict the annotations and clarifies the scope of the mutation.

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

  Conciseness5/5

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

  The description is a single, tightly written sentence that front-loads the action and scope. Every word earns its place; there is no fluff or redundancy.

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

  Completeness2/5

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

  For a tool with three required parameters, no output schema, and zero parameter descriptions, the description does not provide enough detail for correct invocation. It omits parameter semantics, expected input formats, and the role of the concurrency guard. The core purpose is clear, but the operational details are missing.

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

  Parameters1/5

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

  Schema description coverage is 0%, so the description must explain the three parameters (paths, projectId, expectedStatusSha256). It does not mention any of them, their format, or their purpose. The agent receives no guidance on what values to provide, especially for expectedStatusSha256, which is not self-evident.

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

  Purpose5/5

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

  The description clearly states the verb 'Remove' and the resource 'Git index', specifies 'explicit paths', and adds a crucial qualifier that working-tree contents are untouched. This distinguishes it from siblings like git_status, git_diff, and git_commit, which deal with other aspects of staging.

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

  Usage Guidelines4/5

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

  The phrase 'Remove explicit paths from the Git index' provides clear context that this is for unstaging operations. However, it does not explicitly mention when not to use it or point to alternative tools, though the context is sufficiently distinct given the sibling set.

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

• connect_projectA
  3.8/5.0
  Behavior4/5

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

  Annotations indicate readOnlyHint=false and destructiveHint=false, but the description adds the key behavioral detail that non-Git projects have commit and push automatically disabled. This is useful context beyond the annotations and helps the agent anticipate side effects. However, it does not detail permission requirements or what happens to existing connections.

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

  Conciseness5/5

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

  Two concise sentences that immediately capture the primary purpose and a critical behavioral condition. No redundant phrases or filler; every clause earns its place.

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

  Completeness3/5

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

  For a tool with 5 parameters and no output schema, the description covers the main purpose and a key behavioral nuance but misses parameter semantics and clear usage steps. It does hint at the workflow (authorize before editing), but does not fully prepare the agent for correct invocation.

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

  Parameters2/5

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

  Schema description coverage is only 20% (just allowCommit). The description does not explain any of the parameters such as projectPath, label, writable, or projectId. With such low coverage, the description should compensate by describing parameter meanings, but it does not. The only implied hint is that allowCommit relates to the commit/push behavior, but it's not explicit.

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

  Purpose5/5

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

  The description clearly states a specific action (authorize a directory) and resource (one directory beneath a locally approved discovery root), and distinguishes it from siblings like disconnect_project and list_projects. The verb 'authorize' is precise and the scope is defined.

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

  Usage Guidelines3/5

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

  The description implies usage context (connecting a project before editing) but does not explicitly state when to use this tool versus alternatives such as discover_projects or list_projects. No exclusions or alternatives are mentioned, so it relies on inference.

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

• list_projectsA
  3.8/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds the scope of listing only what is authorized, which is useful context. However, it does not discuss output format, ordering, or potential errors, so it adds moderate value beyond annotations.

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

  Conciseness5/5

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

  A single, front-loaded sentence states the core action and scope without any fluff. Every word contributes to understanding the tool's purpose.

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

  Completeness4/5

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

  As a simple read-only listing tool with no parameters and no output schema, the description adequately conveys its purpose and output components. However, it could mention whether results are filtered or sorted, and it does not describe error cases, which is a minor gap. The absence of a return schema is compensated by listing the types of information returned.

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

  Parameters4/5

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

  With no parameters, the schema is trivially fully covered. The description does not need to explain any parameters, and per baseline for 0 params, a score of 4 is appropriate. It does clarify that the tool returns write permissions and task names, which are not parameters but output content.

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

  Purpose5/5

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

  The description uses the specific verb 'List' and clearly identifies the resource 'local projects' plus additional elements 'write permissions, and task names'. The qualifier 'authorized by the user' differentiates it from the sibling discover_projects, 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.

  Usage Guidelines2/5

  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 its sibling discover_projects. The description lacks any conditional context or exclusions, leaving the agent to infer when it should be preferred.

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

• disconnect_projectA
  3.9/5.0
  Behavior4/5

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

  Annotations already indicate destructive behavior, but the description adds important context by clarifying that only authorization is removed, not files. This goes beyond the annotations and prevents misinterpreting the destructiveness as file loss.

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

  Conciseness5/5

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

  A single, word-efficient sentence that front-loads the core action and includes a critical caveat. No waste.

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

  Completeness4/5

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

  For a simple one-parameter tool with no output schema, the description covers the main effect and clarifies non-destructiveness to files. It omits potential error cases or how to find projectId, but these are minor for this simplicity level.

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

  Parameters2/5

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

  Schema description coverage is 0%, so the description should explain the projectId parameter. It does not. The tool name and schema property name imply it identifies a project, but no format, source, or how to obtain it is provided. The description fails to compensate for the missing schema detail.

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

  Purpose5/5

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

  The description states a specific action ('Remove') on a specific resource ('one project from the MCP authorization list') and explicitly clarifies it does not delete project files. This clearly distinguishes it from siblings like connect_project (which adds) and file-deletion tools.

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

  Usage Guidelines3/5

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

  The description implies usage by stating what it does and what it avoids (file deletion), but it does not explicitly contrast with alternatives like connect_project or give conditions for when to use it. The differentiation is implicit, not explicit.

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

• delete_text_fileA
  4.1/5.0
  Behavior4/5

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

  Annotations already flag destructiveHint and readOnlyHint, so the description adds value by specifying the file type ('regular text file') and the safety requirement (SHA-256 verification). This goes beyond the flags, though it does not disclose behavior on SHA mismatch or irreversibility beyond what 'delete' implies.

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

  Conciseness5/5

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

  A single sentence that front-loads the action and the condition with zero redundancy. Every word earns its place, and the structure is optimally concise for an agent to parse.

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

  Completeness4/5

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

  For a destructive operation, the description covers the essential prerequisite (SHA-256 check) and limits the scope (regular text file). It relies on annotations for destructiveness and omits failure behavior, but the provided context is sufficient for correct invocation in most cases.

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

  Parameters2/5

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

  Schema description coverage is 0%, requiring the description to explain parameters. Only expectedSha256 is implicitly referenced via the verification condition; path and projectId are left to name inference. This does not compensate sufficiently for the missing schema descriptions.

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

  Purpose5/5

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

  The description states a precise verb ('Delete'), a specific resource ('one regular text file'), and a conditioning prerequisite (verifying the latest SHA-256). This clearly differentiates it from sibling tools like apply_patch (modifies) and create_text_file (creates), leaving no ambiguity about its scope.

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

  Usage Guidelines4/5

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

  The description provides a clear condition for use: 'only after verifying the latest SHA-256 returned by read_file.' This explicitly defines a prerequisite but does not name alternatives or exclusions (e.g., when to prefer apply_patch), so the guidance is strong but not fully explicit about when not to use the tool.

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