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

With no annotations, the description carries the burden. It states it removes a marker and stops a warning, disclosing a write operation. No additional behavioral details beyond what is implied.

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?

Three concise sentences front-load the purpose and add usage context. 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 tool with one parameter and no output schema, the description covers purpose and usage but lacks parameter explanation, which is a 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?

There is one parameter (projectRoot) with no description in the schema (0% coverage). The description does not explain its meaning or usage, leaving the agent uninformed.

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: acknowledge IDE restart after kit:auto-install by removing a marker. It distinguishes from sibling tools like auto-install and kit by focusing on the acknowledgment step.

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 explains when to use the tool: automatically by the harness after reload or manually. It does not explicitly exclude other contexts but the intent is 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?

With no annotations, the description carries the full burden of behavioral disclosure. It clearly states idempotency ('re-running is a no-op'), the action of writing files, and the need for an IDE restart. It does not cover error cases or permission requirements, but the core safety and behavior are well-explained.

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

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

The description is front-loaded with an IMPORTANT note and covers all key points in a single paragraph. While it includes specific numbers (86, 103, 99) that add detail, it is still concise and well-structured, with no unnecessary repetition.

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 4 parameters, no output schema, and no annotations, the description provides solid context for the main use case (first contact install) but omits explanation of the 'check' action and does not elaborate on parameter behavior like 'force'. The completeness is adequate for a simple installation tool but leaves minor gaps.

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

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

Schema coverage is 100%, so baseline is 3. The description does not add significant meaning beyond the schema; for example, it mentions the 'install' action but not the 'check' action. The parameter details (force, target, projectRoot) are adequately documented in the schema, and the description does not explain them further.

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: installing the project kit into the host's native layout to make agents, skills, and commands available. It uses specific, actionable language ('project kit/ into the host's native layout') and distinguishes its role from sibling tools like 'ack-restart' by describing the follow-up steps.

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 explicit usage instructions: run once per project on first contact, restart IDE, then call ack-restart. It notes idempotency, implying re-use is not harmful. However, it does not directly differentiate from the sibling 'install' tool or cover when not to use this tool.

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 explains the algorithm (gap detection, 5h windows) and output shape, which is sufficient for a read-only compute tool. However, it lacks explicit statement about not modifying data or behavioral side effects; with no annotations, some minor gaps exist.

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 relatively concise, includes key behavior, and front-loads the purpose. It includes trigger phrases which add slight redundancy but are acceptable. It could be more structured but overall efficient.

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

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

Given 5 undocumented parameters, no output schema, and sibling tools, the description is incomplete. It fails to specify parameter roles, and the return shape description ('shape canônico agregado') is vague. The agent lacks information 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 0%, and the description does not explain any of the 5 parameters (config_dirs, tz, refresh_pricing, persist, projectRoot). The agent has no guidance on what these parameters do, making correct invocation impossible.

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 explicitly states the tool computes Claude Code cost by sliding 5h windows with gap detection, returns blocks with specific fields, and distinguishes from siblings by advising to use cost-today for day and cost-session for session. The verb and resource are clear, and trigger phrases help discovery.

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

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

The description provides explicit when-to-use guidance: for block-based cost analysis with sliding windows. It also names alternative tools (cost-today, cost-session) for different granularities, effectively telling when not to use this tool.

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 provided, so description carries full burden. It discloses the heuristic (chars/4 with ±30% range), return fields, and known limitation (debt in SKILL.md). This provides good transparency about what the tool does and its accuracy.

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

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

The description is a single sentence that efficiently packs purpose, algorithm, limitations, return values, and triggers. Every clause adds value without redundancy.

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

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

Given 4 well-documented parameters, no output schema, and no annotations, the description provides sufficient context: algorithm, return values, and limitation. It is nearly complete, though the disclaimer content is not elaborated.

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 baseline is 3. Description adds meaning by explaining the heuristic (chars/4) and mentioning that return values include estimated tokens and costs. The output_ratio parameter context is indirectly covered by the return description.

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

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

The description clearly states the tool estimates USD cost of a prompt before sending to Claude, using a heuristic. It distinguishes from sibling cost tools (cost-blocks, cost-phase, etc.) by specifying it's for a single prompt. The list of triggers further clarifies the purpose.

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

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

The description implies use before sending to Claude and lists trigger phrases. It does not explicitly state when not to use or compare with siblings, but the heuristic and limitation ('sem tokenizer real') guide appropriate use for rough estimates.

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

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

No annotations are provided, so the description must fully disclose behavioral traits. It describes data crossing and inference but does not clarify side effects (e.g., whether persist modifies state), error conditions, or prerequisites. Parameters like refresh_pricing and persist hint at mutability, yet the description leaves their impact ambiguous, which is a significant gap for a tool with no annotation safety cues.

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 moderately concise and front-loaded with the core purpose and data sources, but it is a single dense paragraph without clear separation of concerns (e.g., no parameter breakdown, no usage examples). The trigger list at the end is helpful, but overall structure could be improved for readability.

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

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

Given 5 parameters, no output schema, and no annotations, the description is incomplete. It lacks details on the return format ('canonical shape'), parameter interplay, and common usage patterns. It does not explain how to use optional parameters like config_dirs or persist, leaving significant gaps for an agent to invoke the tool correctly.

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

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

With only 40% schema coverage, the description should compensate for undocumented parameters, but it does not. It explains phase_id conceptually, but config_dirs, refresh_pricing, and persist are not mentioned in the description at all. Users receive no guidance on their meaning or typical values beyond the minimal schema hints.

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 correlates cost with a specific phase of the kit-mcp framework, detailing data sources (mtime, completed_at, git log) and output (canonical shape with confidence levels). It differentiates from ccusage via workflow context and lists trigger phrases, making the purpose highly specific and distinguishable from sibling tools like cost-session or cost-today.

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 trigger phrases ('custo da fase', 'phase cost') indicating when to use, but does not explicitly state when not to use or compare against all relevant siblings (e.g., cost-session, cost-today). The mention of 'Diferencial vs ccusage' offers some context, but it's not a thorough guideline for agent decision-making.

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

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

No annotations are provided, so the description carries the full burden. It discloses auto-deduction and return fields but does not state side effects (e.g., read-only, auth needs, rate limits). The tool appears to be a read operation, but behavioral details are incomplete given the lack of annotations.

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

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

The description is a few lines with trigger phrases, which is adequate but not highly structured. It could be more concise by omitting trigger phrases (which are not standard for tool descriptions) or integrating them more cleanly. Overall, acceptable length but room for improvement.

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 7 parameters, no output schema, and no annotations, the description should be more comprehensive. It lacks explanations for most parameters, does not describe the exact return structure beyond 'canonical shape', and omits error handling or edge cases. The description is incomplete for a tool of this complexity.

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 only 43%, and the description does not compensate. It adds context only for max_idle_ms (the 30-minute window) but fails to explain config_dirs, refresh_pricing, persist, or projectRoot. Most parameters remain undocumented in the description, leaving a gap.

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 it returns the cost of a specific (or auto-deduced active) session, lists the returned fields (canonical shape, session_id, etc.), and distinguishes from sibling cost-today by explicitly directing to use that tool for daily totals. The trigger phrases further clarify purpose.

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

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

The description explains when to use (for session cost) and explicitly names an alternative (cost-today for entire day). It also describes the auto-deduction logic based on recent JSONL file mtime, giving clear context. No explicit 'when not to use' but the alternative serves as exclusion.

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

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

No annotations are provided, so the description carries the full burden. It explains the tool reads JSONL files, uses timezone defaults, and returns a canonical shape. It does not mention whether it modifies data or has side effects, but the description implies a read-only operation. The level of detail is good but could explicitly state non-destructive behavior.

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

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

The description is reasonably concise, front-loading the core purpose. It includes relevant details without being overly verbose. Could be slightly more structured, but it's effective.

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

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

Given no output schema, the description thoroughly explains the return shape (total_usd, by_model, etc.). It covers timezone handling, default configurations, and provides trigger phrases. The tool has 6 parameters and no output schema, and the description addresses all necessary contextual information.

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

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

Schema description coverage is 100%, with each parameter already well-documented. The tool description adds some context (e.g., 'opt-in' for certain params, 'paridade ccusage' for tz) but does not significantly enhance understanding beyond the schema. Baseline of 3 is appropriate.

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

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

The description clearly states the tool's purpose: calculating daily cost of Claude Code from local JSONL files. It specifies the output shape and provides trigger phrases. It distinguishes from sibling tools (cost-session, cost-blocks, cost-phase) by name and usage context.

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

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

The description explicitly tells when to use this tool versus alternatives: 'Use cost-session para a sessão atual, cost-blocks para janelas de 5h, cost-phase para uma fase do framework.' This provides clear usage guidance.

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

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

With no annotations, the description must fully disclose behavior. It only mentions 'failure dataset' and 'replays' but not whether the tool is read-only, destructive, or requires specific permissions.

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

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

The description is a single short phrase, which is concise but not a full sentence. It lacks structured information like what actions are available.

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 7 parameters and 8 action enums and no output schema, the description is severely incomplete. It does not explain the purpose of each action or the expected outcome.

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 57%, but the description adds no parameter-level details. Parameters like 'replayId' and 'projectRoot' lack descriptions in both schema and description.

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

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

The description 'Failure dataset & replays — close the learning loop on failed agent runs' gives a vague sense of purpose but lacks a clear verb and resource. It does not differentiate from siblings like 'metrics-snapshot' or 'sync'.

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 on when to use this tool versus alternatives. The description implies it's for failed agent runs but gives no context on prerequisites or when to avoid.

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

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

No annotations are provided, so the description must disclose behavioral traits. It minimally mentions actions like 'run' with autoSpawn sidecar, but lacks details on side effects, permissions, or state changes. The description is insufficient for a tool with 5 parameters and 2 enums.

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 conveys the core purpose. However, it could be structured with more detail on actions and parameters.

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 presence of 5 parameters and 2 enums, the description is too brief. It does not explain return values, combined parameter usage, or behavior for each action, leaving significant gaps for the AI agent.

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

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

Schema description coverage is 80%, so the schema already documents most parameters. The description adds general context ('reusable workflow gates') but does not enhance understanding beyond the schema.

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

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

The description clearly states the tool lists, fetches, or executes reusable workflow gates, with four explicit actions. However, it does not differentiate from sibling tools like 'kit' or 'sync', which could overlap in function.

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

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

No guidance on when to use this tool versus alternatives. The description lists actions but does not specify scenarios for each action or 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.

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

No annotations provided; the description only states the action without disclosing behavioral traits such as side effects (e.g., config file modification), required permissions, or reversibility. This lacks sufficient transparency.

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

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

The description is a single, concise sentence that is front-loaded with the core purpose. No extraneous 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?

With 8 parameters, no output schema, and no annotation support, the description is too brief. It omits important context such as what 'dry-run' does, how to list targets, or default behaviors for optional parameters.

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 75%, but the description adds no information about parameters. It does not explain the meaning, defaults, or relationships of 'action', 'target', 'scope', etc., beyond what the schema provides.

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 clearly states the verb 'Register' and the resource 'kit-mcp server into an IDE's MCP config', listing specific IDEs. This distinguishes it from sibling 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?

The description implies usage for IDE registration but does not explicitly specify when to use this tool versus alternatives like 'auto-install' or other tooling. Context is clear but exclusions are missing.

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 bears full responsibility for behavioral disclosure. It describes the read-only browse/search/get actions clearly. It does not claim any side effects or destructive behavior, which is consistent with the tool's apparent purpose. Explicitly stating 'read-only' would improve transparency, but the current text is adequate.

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 structured with the core purpose first, then context triggers, then action guidelines. It is slightly verbose but each sentence adds value. Removing the specific counts (86, 99, 103) might improve conciseness without loss of 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 tool has 6 parameters, no output schema, and no annotations, the description covers the core functionality, usage contexts, and parameter usage adequately. It does not describe return values explicitly, but that is acceptable when no output schema exists. The description is sufficiently complete for an agent to invoke the tool correctly.

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

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

Schema description coverage is 83%, so the baseline is set to 3. The description adds context for when to use which parameter combinations (e.g., 'action=search to discover, action=get to read the full prompt/skill'), but the schema already enumerates parameters with descriptions. The added value is moderate.

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 'Browse the personal kit' and lists the components (agents, commands, skills). It distinguishes actions (list, get, search) and provides a specific verb-resource pairing. No sibling tool has an equivalent purpose, so differentiation is clear.

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

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

Explicit when-to-use guidance is given: 'Call this when the user mentions Supabase...' and a list of relevant topics. It also explains which action to use for different intents (search, get). However, it does not explicitly state when not to use it or mention alternative tools, though sibling names are provided for reference.

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?

Description states it reads in-memory metrics, implying read-only, no destructive effects. With no annotations, the description provides basic transparency but could add more about behavior.

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

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

Single sentence, front-loaded with action, no wasted words. Efficient and clear.

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 zero parameters and no output schema, the description fully specifies the tool's purpose and output data. No gaps.

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

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

No parameters, so baseline is 4. The description adds value by explaining what the tool returns (counters, latency percentiles) beyond the empty schema.

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

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

Description specifies verb 'Read' and resource 'in-memory golden-signals metrics' with detailed metrics (counters + latency p50/p95/p99 per tool), clearly distinguishing from sibling tools like install, sync, etc.

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 alternatives; usage is implied as the sole tool for reading server metrics, but lacks guidance on 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 carries full burden. It discloses that add/remove write a lockfile ('.kit-mcp-packs.json') and gives behavioral hints for actions. Could elaborate more on side effects (e.g., read/write behavior), but adequate.

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 paragraph but well-structured: general function, then action list with explanations, then trigger examples. It is concise and front-loaded with key information. Minor improvement: could be broken into bullet points for 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 tool has 6 parameters and complex action logic, the description covers actions, triggers, and side effects. No output schema exists, so completeness is adequate. It provides enough context for an agent to select and invoke the tool correctly.

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

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

Schema coverage is 83% (5 of 6 parameters described). The description adds value beyond the schema by explaining each action's purpose and context, such as 'action=list catálogo com contagens'. This helps agents understand parameter usage beyond enum labels.

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

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

The description states the tool manages 'Content Packs' and explicitly lists six actions (list, info, resolve, doctor, add, remove) with brief explanations. It distinguishes from sibling tools like 'install' and 'sync' by focusing on pack-level management.

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 usage context by explaining when to use each action (e.g., 'resolve mostra o fecho de dependências') and lists common triggers ('instalar pack', 'remover pack'). However, it does not explicitly exclude scenarios or compare to alternatives like 'install'.

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 full burden. It reveals the tool is read-only ('consome'), describes validation outputs, and lists triggers. It lacks explicit statements about side effects, but the detail on actions compensates.

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 in a single paragraph but remains concise, covering purpose, actions, and triggers in about 150 words. It could benefit from bullet points or clearer separation, but it's not excessive.

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

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

Given no output schema and no annotations, the description provides solid context: what each action returns and validation details. It lacks return format or error handling, but for a simple registry tool, this is sufficient.

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 67%, and the description adds meaning by explaining action-specific behaviors and the role of the name parameter in get. projectRoot is adequately described in both schema and description. The actions' implications go beyond enum values.

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 consumes the project registry (PROJETOS.md) and details three specific actions (list, get, doctor) with precise outcomes. It differentiates from siblings by focusing on project registry management, a niche not covered by other 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?

The description provides explicit trigger phrases and action-specific behaviors, guiding when to use the tool. However, it does not specify when not to use it or contrast with sibling tools like sync, leaving some ambiguity.

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 provided, so description should disclose behavior. It mentions detecting and applying edits but does not describe side effects, destructive actions, permissions, or other traits. The description is too minimal.

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

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

The description is a single sentence, concise but lacking structure. It front-loads the core purpose but does not elaborate or organize information.

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

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

With 7 parameters, 2 required, no output schema, and moderate complexity, the description is insufficient. It does not explain key aspects like the 'action' parameter, 'target', or how 'detect' and 'apply' work.

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 57%; some parameters have descriptions in schema (e.g., 'only', 'strategy', 'autoSpawn'), but the overall description adds no extra parameter semantics. 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 clearly states the tool detects and applies IDE edits back to the canonical kit/, using specific verbs and resource. It distinguishes from sibling 'sync' by specifying the reverse direction (IDE to canonical).

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 on when to use this tool versus alternatives like 'sync', or when to use 'detect' vs 'apply'. The description lacks context for appropriate use cases.

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

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

No annotations provided, so description carries full burden. It only mentions projection and default mode, but does not disclose whether actions are destructive, if it requires network, or what happens to existing data. Behavioral traits like install/remove actions are not explained.

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?

Single 12-word sentence is very concise and front-loaded. However, it cuts off critical information, earning a 4 rather than 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?

With 6 parameters, no output schema, and no annotations, the description is insufficient to fully understand the tool's behavior and constraints. It does not cover actions, dryRun, autoSpawn, etc.

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 67%, so baseline is 3. The description adds some value by noting default mode (markdown references), but does not elaborate on action enums, target, or other parameters meaningfully beyond schema.

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

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

The description uses specific verb 'Project' with resource 'kit' into 'IDE-specific layout', and mentions default mode (markdown references). It distinguishes from sibling 'reverse-sync' and others by focusing on projecting to IDE layout, but could be more explicit.

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 on when to use this tool versus alternatives like install, reverse-sync, etc. The description does not provide context for when sync is appropriate or what prerequisites exist.

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