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

Annotations already disclose readOnlyHint=true, idempotentHint=true, and destructiveHint=false, which cover the safety profile. The description adds that assignment is based on metadata but does not clarify whether the result is persisted or just returned, leaving mild ambiguity. It does not contradict 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 single, focused sentence that is front-loaded with the action and subject. Every word earns its place, with no redundancy or filler.

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

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

While the schema covers parameters and annotations cover safety, the description does not mention what the tool returns (no output schema) or how the optional parameters like profileName or mcpRoot alter the assignment. For a tool with 6 optional parameters, a bit more context about the outcome would improve completeness, but the core functionality is still understandable.

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?

All 6 parameters have descriptions in the schema, so the description adds no additional parameter-level meaning. Since schema description coverage is 100%, the description does not need to compensate; a 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 action ('ordnet zu' / assigns) and the resource (MCP tools to capability bundles). It is specific enough to distinguish from 'suggest_bundles' by using 'assign' rather than 'suggest', though it doesn't explicitly address the difference.

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

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

No guidance is provided on when to use this tool versus alternatives like 'suggest_bundles' or 'list_bundles'. The description solely states the function without context, exclusions, or alternatives.

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

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

Annotations already mark the tool as read-only, idempotent, and non-destructive, and the description does not contradict them. It adds value by specifying the exact categories of policy hints checked (npx starts, env secrets, invalid server configurations), giving the agent concrete expectations about the tool's behavior.

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

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

The description is a single, focused sentence that conveys the tool's purpose and scope without any extraneous information. It front-loads the verb and resource, making it effective for quick scanning.

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

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

The tool is a simple read-only audit with one required parameter; the description covers the purpose and key check categories. However, with no output schema, it does not explicitly state the return format, though the mention of 'Policy-Hinweise' gives a hint that the result is a list of findings. Overall, it is sufficient for the tool's 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?

The input schema already provides detailed descriptions for all three parameters, including examples and default values, with 100% coverage. The tool description does not add further parameter semantics beyond the schema, so a baseline score of 3 is appropriate.

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

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

The description uses the specific verb 'Prüft' (audits) with the resource 'aufgelöstes Claude-Profil' and enumerates what it checks: npx starts, env secrets, invalid server configurations. This clearly distinguishes it from sibling tools like resolve_profile or list_profiles, which have different operations.

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

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

The description implies a prerequisite by saying 'aufgelöstes Claude-Profil' (resolved profile), suggesting the user should resolve the profile first, but it does not explicitly state when to use this tool versus alternatives. There is no mention of exclusions or other ways to audit, but the context of a policy audit is clear enough for an implied usage.

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?

Annotations state readOnlyHint=false, idempotentHint=true, destructiveHint=false, and openWorldHint=false. The description only says 'creates a catalog', which aligns with these annotations but adds no additional behavioral context such as side effects (e.g., starting local MCP servers when includeTools=true), file writes, or potential resource usage. The description does not contradict annotations but also does not go beyond them.

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

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

The description is extremely concise—one sentence with no filler or redundancy. It effectively front-loads the core purpose. However, given the tool's complexity (8 parameters, no output schema), this level of brevity sacrifices necessary context, though that is more of a completeness issue than a conciseness issue. It earns a 4 for efficient wording.

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

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

The tool has 8 parameters, no output schema, and non-trivial behavior (e.g., starting servers, writing files). The description only provides a high-level statement of output, leaving the agent without understanding of return values, side effects, or when to invoke it. The schema covers parameter details, but the description fails to tie them together or explain the overall workflow, making it incomplete for an AI agent.

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

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

The input schema has 100% description coverage across all 8 parameters, so the schema already explains each parameter's meaning. The tool description adds no parameter-level semantics; it doesn't mention any parameters or their roles. With such high schema coverage, a baseline score of 3 is appropriate.

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

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

The description clearly states the verb 'Erzeugt' (creates) and the resource 'JSON-Katalog der lokal gefundenen MCP-Server'. It identifies the tool's purpose as generating a catalog, which is distinct from siblings like controlcenter_list_local_servers. However, it doesn't explicitly differentiate itself from that sibling or other related tools, so it misses the highest level of clarity.

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

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

The description provides no guidance on when to use this tool versus alternatives, no context about prerequisites, and no exclusions. It is a single declarative sentence without any usage direction. The schema hints at profile-based scanning and tool inclusion, but the description itself gives no decision support.

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 goes beyond the annotations by disclosing that it 'führt keine Komponenten aus und liest weder Geheimnisse noch Live-Zustände.' This adds critical behavioral context not present in the readOnlyHint or idempotentHint annotations, fully aligning with and enriching them.

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

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

The description is two sentences, front-loads the main purpose, and every clause adds value (purpose, read-only nature, exclusions). It is concise without unnecessary elaboration.

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

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

For a low-complexity tool with two well-documented params and strong annotations, the description sufficiently covers purpose, safety profile, and behavioral exclusions. It does not describe return format, but the term 'Kontextpaket' and the level parameter (in schema) provide reasonable context, making it adequately complete.

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

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

The schema covers 100% of parameters with descriptions, so the baseline is 3. The description does not add parameter-specific details, but it clarifies the stack manifest source for stackId, which is consistent with schema. No additional semantic value is provided 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 clearly states a specific action ('Erstellt ein kompaktes, rein lesendes Kontextpaket') with a specific resource ('aus einem registrierten Stack-Manifest'). It differentiates from sibling tools by emphasizing read-only behavior and non-execution, making the tool's function unambiguous.

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

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

The description implies the tool is for safe, read-only context retrieval without executing components, which suggests when to use it. However, it does not explicitly name alternative tools (e.g., controlcenter_describe_stack) or provide exclusion criteria, leaving usage context somewhat vague.

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?

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior. The description adds that the tool returns validation warnings, which gives a hint about the output and potential failure modes, but it does not go into depth about error handling or prerequisites beyond 'registrierten Stack'.

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

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

The description is a single, front-loaded sentence that enumerates the output categories without any redundant words or filler.

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

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

For a read-only describe tool with a simple parameter set and no output schema, the description adequately explains what the tool returns by listing four output categories. It covers the essential purpose and output, though it omits any edge-case behavior or extended details about how to use stacksRoot.

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?

Both parameters have full descriptions in the schema (100% coverage), and the tool description does not add any additional parameter meaning. The description implies stackId refers to a registered stack, but that is already in the schema description. Therefore, it does not exceed the schema baseline.

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

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

The description uses the verb 'Zeigt' and specifies the exact content (typisierte Komponenten, Pflichtrollen, Policies, Validierungswarnungen) for a registered stack, making the action and resource clear. It does not explicitly differentiate from sibling tools like list_stacks, but the describe-versus-list distinction is evident.

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 alternative guidance is provided. The context is implied from the tool's purpose: an agent would use it to get detailed stack information, but there is no exclusionary language or comparative reference to sibling tools.

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

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

Beyond the readOnly/idempotent annotations, the description reveals important behavioral traits: the search is lexical (not semantic), the catalog is scanned across specific fields (name, aliases, tags, category, description), and scores are only comparable within a single query. This adds significant context about the tool's internal workings and limitations.

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

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

The description is efficiently structured in three sentences: purpose, critical usage warning, and supplementary details about scoring. Every sentence adds value, and the most important instruction (use keywords) is highlighted with 'WICHTIG' to draw attention. No redundant wording.

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

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

Given the tool's moderate complexity (5 parameters, no output schema), the description adequately covers purpose, input query format, matching logic, and a caveat about score comparability. It briefly indicates the return includes best candidates with matched terms, but lacks detail on result structure (e.g., fields like score, name). This is a minor gap, not a critical omission.

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

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

The input schema already provides 100% parameter descriptions, including the intent parameter's keyword guidance. The description reinforces the lexical matching behavior but does not add new semantic details about individual parameters beyond what the schema already specifies. Therefore, 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's purpose: recognizing which skills match a task or intent. It distinguishes itself from sibling tools like list_skills by emphasizing that it evaluates and ranks skill candidates based on lexical matching over name, aliases, tags, category, and description, rather than simply listing all skills.

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 concrete usage guidance: query with keywords/technical terms, not whole sentences, because the search is purely lexical and full sentences attract false hits. It gives context on how to formulate the intent parameter and warns about score comparability across queries, though it does not explicitly name alternative tools or state 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description does not need to repeat safety traits. It adds useful context about the output content (current language and supported codes), but no additional behavioral details such as side effects, permissions, or rate limits.

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 direct and front-loaded. Every word contributes meaning, with no redundant or extraneous 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?

For a simple getter with no parameters and no output schema, the description adequately discloses what it returns (current output language and supported language codes). It is complete enough for an agent to understand the tool's functionality without further elaboration.

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

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

The tool has no parameters, and schema coverage is 100% (vacuously). Per calibration, 0 parameters receives a baseline of 4. The description does not need to add parameter semantics since none exist.

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 'Zeigt die aktuelle ControlCenter-Ausgabesprache und die unterstützten Sprachcodes' uses a specific verb (zeigt/shows) and names the resource (ControlCenter output language). It clearly differentiates from sibling tool controlcenter_set_language, which presumably modifies the language.

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 states what the tool does but does not explicitly specify when to use it or how it differs from alternatives. The context of a read-only getter is implied but no exclusions or alternative tools are mentioned, leaving usage guidance implicit.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the conceptual context that bundles group local MCP servers into task categories, which helps interpret results, but it does not disclose mechanics like whether it scans the filesystem or depends on configuration paths.

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

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

The description is a single concise sentence with no fluff, and it front-loads the key concept of grouping MCP servers. It loses a point because the verb choice is slightly inconsistent with the tool's listing function, which could confuse.

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?

There is no output schema, and the description does not specify what the tool returns (e.g., a list of bundle names, associated servers, or metadata). While the examples of bundle types give some orientation, the description is incomplete for a list operation without output schema or usage context.

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% for the two optional parameters (mcpRoot, bundleConfigPath), so the schema already documents them. The description adds no extra meaning or usage details about these parameters, maintaining the baseline.

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

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

The description names the resource (capability bundles) and gives concrete examples (Software, Filesystem, Automation, Control Plane), which distinguishes it from sibling list tools. However, the verb 'gruppiert' (groups) does not directly say 'list' or 'shows', so the operation is implied rather than explicitly stated.

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

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

No guidance is provided on when to use this tool versus alternatives like list_stacks or list_profiles. There is no mention of prerequisites, context, or exclusion criteria, leaving the agent to infer usage from the tool name alone.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, establishing a safe, non-destructive operation. The description adds behavioral context by stating it scans the local MCP root and lists found repos with metadata. No contradictions, but no additional side-effect or permission information is provided.

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 front-loads the action and result. It contains no wasted words and perfectly communicates the tool's purpose.

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 read-only listing tool with full schema coverage and appropriate annotations, the description is complete enough. It explains what is scanned, what is returned (repos with metadata), and the optionality of the root. No output schema exists, so the description does not need to detail return fields.

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

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

The schema fully describes the single optional parameter mcpRoot, including its default value. The description does not add parameter-level detail beyond what is already in the schema, so the baseline of 3 applies.

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

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

The description uses specific verbs ('scans' and 'lists') with a clear resource (local MCP repos with metadata). It distinguishes from siblings which target stacks, tools, profiles, and plugins. No other sibling lists MCP servers, so the purpose is unambiguous.

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

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

The description clearly implies when to use this tool (when you need to discover local MCP servers). It does not explicitly name alternatives or exclusions, but since no sibling performs the same function, the context is sufficient. Score 4 because it lacks explicit 'when not to use' 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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the description does not need to restate safety. It adds the detail that the tool inventories capabilities, which is a minor addition beyond annotations. No contradictions detected.

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

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

The description is a single, front-loaded sentence with no redundant words. Every phrase adds meaning, making it very concise and well-structured.

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

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

For a simple listing tool with full parameter schema and strong annotations, the description provides sufficient context. It could explicitly mention that both plugins and modules are returned by default, but the schema defaults make that inferable.

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

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

Schema description coverage is 100%, with all four parameters well-documented in the input schema. The description itself adds no parameter-level detail, but the schema carries the full burden, so the 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 uses the specific verb 'Inventarisiert' and clearly identifies the resource: installed Claude Code plugins and local ellmos modules with their capabilities. This distinguishes it from sibling listing tools like list_skills or list_tools.

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

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

The description does not explicitly mention alternatives or when-not-to-use guidance. While the purpose implies use when an inventory of plugins/modules is needed, it lacks explicit exclusions or comparisons to sibling tools, leaving usage somewhat implied.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering safety. The description adds value by disclosing that the tool outputs server count, inheritance, and file paths, which tells the agent what to expect from the return value. No contradictions 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.

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

The description is a single concise sentence that front-loads the action and specifies the key output information without unnecessary words. It earns its place and is easy to parse.

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

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

The tool is simple (1 optional param, read-only), annotations cover safety, and the description conveys the essential output. The schema documents the parameter default. It lacks explicit usage guidance, but that is more of a usage guideline issue. Overall, it is complete enough for an agent to invoke correctly.

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

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

The single optional parameter profileRoot is fully documented in the schema with a description and default (~/.claude/profiles). Since schema description coverage is 100%, the baseline is 3, and the tool description adds no additional parameter meaning beyond what the schema already 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?

The description uses a clear verb ('liest' = reads) and resource ('lokalen Claude-Profile' = local Claude profiles), and it specifies what is shown (server count, inheritance, file paths). This distinguishes it from sibling tools like list_local_servers or list_stacks, which target different resources.

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 states what the tool does but gives no explicit guidance on when to use it versus alternatives like controlcenter_list_local_servers or controlcenter_list_stacks. Usage context is implied from the name and description, but no exclusions or alternative recommendations are provided.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds context about scanning both sources and the default behavior, but does not disclose details like recursion or output format. This is 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.

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

The description is a single, front-loaded sentence with no wasted words. It directly states the action and scope, 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.

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

For a simple read-only listing tool, the description is adequate: it identifies the two sources and the optional parameter behavior is handled by the schema. However, without an output schema, it does not mention what the return value looks like, which is a minor gap.

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

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

The input schema covers all three parameters with descriptions (100% coverage), so the schema carries the parameter semantics. The description does not add further meaning beyond mentioning the two source directories, which is already reflected in the schema.

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

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

The description uses a specific verb 'Inventarisiert' (inventories) and clearly identifies the resource (Claude Code Skills) and scope (deployed folder and source library). This distinguishes it from sibling tools like list_tools and list_plugins.

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 listing skills but does not explicitly state when to use this tool over alternatives such as find_skill or list_tools. No exclusions or alternative recommendations are provided, so guidance is only implicit.

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?

Annotations already declare readOnly, idempotent, and non-destructive behavior. The description adds the meaningful detail that the tool reads the 'neutral' stack catalog and manifests without executing components, providing context beyond the safety 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 single, concise sentence that front-loads the action and includes the important non-execution qualifier. No unnecessary words or 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?

The tool is simple with one optional parameter and a clear read-only purpose. The description adequately explains what is read and the non-executive behavior. Without an output schema, it could mention what is returned, but for a list operation this is largely implied.

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

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

The only parameter, stacksRoot, is fully described in the JSON schema (100% coverage), so the description does not need to add parameter details. It adds no new parameter semantics, but the schema is sufficient.

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 function: it reads the stack catalog and its ellmos.stack.v2 manifests. It also explicitly notes that it does not execute stack components, distinguishing it from tools that might run or apply stacks.

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

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

The description implies the tool is for reading/listing stack metadata from the catalog, but it does not explicitly state when to prefer this over siblings like describe_stack or build_catalog. The 'without executing' caveat provides some usage context but no direct comparison.

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 goes beyond annotations by disclosing that the tool actively starts servers, a behavioral side effect not captured by readOnlyHint or idempotentHint. It also clarifies that it retrieves the 'real' tool list, adding useful context about the operation's outcome.

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 front-loads the primary action and result. No redundant or filler content exists, and every word contributes meaning.

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

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

The description explains what the tool does and what it returns (the tool list), which is sufficient given the annotations and full parameter documentation. It does not detail error behavior or pagination, but those are not essential for a read-only listing tool with 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 description coverage is 100%, so all five parameters have descriptions in the schema. The tool description does not add any extra parameter-level meaning beyond what the schema already provides, so the baseline of 3 applies.

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

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

The description clearly states the tool starts local or profile-defined MCP servers and reads their tool lists via MCP list_tools. This specific verb+resource combination distinguishes it from sibling tools like controlcenter_list_local_servers or controlcenter_list_stacks.

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 context (when you need to start servers and retrieve their actual tool lists) but does not explicitly mention when to use alternatives or any exclusions. Sibling tools exist for related but distinct purposes, yet no comparison or guidance is provided.

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?

Annotations already declare the tool as read-only, idempotent, and non-destructive, reducing the burden. The description adds valuable context by explaining the resolution process (including optional inheritance) and what the output shows (resulting MCP servers). This provides behavioral insight beyond the annotations, though it does not mention potential errors or exact output format.

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

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

The description is a single, well-structured sentence that is front-loaded with the action and includes the key outcome. It contains no redundancy or filler, and every word contributes to understanding the tool's function.

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

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

Given the tool's simplicity (2 params, no output schema) and strong annotations, the description is sufficiently complete. It explains the core behavior and result ('shows resulting MCP servers'), which provides the necessary return-value context given the absence of an output schema. It does not elaborate on edge cases or inheritance rules, but that is not critical for this level of 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?

The input schema has 100% coverage with clear descriptions for both parameters: 'profileName' includes format and example, and 'profileRoot' explains optionality and default. The description does not add further parameter details beyond what the schema provides, so a baseline score of 3 is appropriate.

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

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

The description clearly states what the tool does: it resolves a Claude profile including optional inheritance and shows the resulting MCP servers. The verb 'Löst' (resolves) and the specific outcome ('zeigt die resultierenden MCP-Server') make the purpose unambiguous. It also distinguishes itself from siblings like switch_profile (which activates) or list_profiles (which lists) by focusing on resolution/inheritance.

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 context: use this when you need to resolve a profile and see the effective MCP servers after inheritance. However, it does not explicitly state when to use this over alternatives or provide exclusions. The sibling tools are listed, but the description itself offers no comparative guidance, so it remains at 'implied usage' rather than explicit recommendations.

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?

Annotations declare idempotentHint=true and readOnlyHint=false; the description is consistent. It adds the key behavioral fact that the setting is scoped to the current instance, implying non-persistence. This goes beyond the 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?

Single sentence, front-loaded with the action, no redundant language. Every word earns its place.

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

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

For a simple setter with one parameter and strong annotations, the description is complete. It conveys the action, the scope, and the effect without needing to explain output (no output schema).

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

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

The input schema already has 100% coverage with the parameter description 'Sprachcode für die ControlCenter-Ausgaben.' The tool description adds no additional parameter details, so baseline 3 applies.

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

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

Clear verb+resource: 'Setzt die ControlCenter-Ausgabesprache' identifies exactly the action (set output language) and target. The scope 'für diese laufende MCP-Serverinstanz' adds specificity. It is distinct from the sibling getter controlcenter_get_language.

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 clear context: the change applies to the current running MCP server instance. It does not explicitly mention alternatives (like the getter tool), but the setter/getter distinction is obvious from the name. No exclusions are stated.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is known. The description adds the scope of the overview (local MCP stack, servers, profiles), which provides some context beyond annotations, but it does not describe the output format or whether the status is aggregated in a particular way.

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

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

The description is a single, front-loaded sentence that is concise and free of any waste. It directly states the tool's purpose without redundancy or filler.

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

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

The tool is simple (no params, no output schema) and the description covers the main content areas (local MCP stack, local servers, Claude profiles). While a bit more detail about the output would improve completeness, the description is sufficient for a status-overview tool given the annotations and simplicity.

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

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

The tool has zero parameters, and schema coverage is 100% (empty schema). Per the baseline, 0 parameters warrants a 4 since there is nothing for the description to add about parameter semantics. The description correctly does not invent any parameters.

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 shows an overview of the local MCP stack, local servers, and Claude profiles, using the specific verb 'zeigt einen Überblick' (shows an overview). This distinguishes it from sibling tools that list individual components (e.g., controlcenter_list_stacks, controlcenter_list_local_servers) by emphasizing the aggregated status view.

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 getting a high-level overview but provides no explicit guidance on when to use this tool versus the more specific list/describe sibling tools. No exclusions or alternatives are mentioned, only the general purpose.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, providing a safety profile. However, the description adds no additional behavioral context—no mention of how recommendations are computed, what outputs look like, or any other operational details. It merely restates the tool's obvious purpose, offering minimal 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.

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

The description is a single, succinct sentence that immediately conveys the core function with no superfluous words or repetition. It is well-structured and easy to parse.

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

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

For a simple recommendation tool with no output schema, the description covers the basic intent but lacks details on return format, decision criteria, or failure scenarios (e.g., when no bundles match). It is minimally viable but not richly informative.

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%: all three parameters have meaningful descriptions in the input schema. The tool description offers no additional parameter insights, but since the schema is self-sufficient, baseline score of 3 is appropriate.

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

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

The description clearly states a specific function: 'Empfiehlt passende Capability-Bundles für eine Aufgabenbeschreibung' (recommends suitable capability bundles for a task description). Use of the verb 'empfiehlt' (recommends) and the target resource 'Capability-Bundles' distinguishes this from sibling tools like list_bundles (simple listing) or suggest_profile (profile suggestion).

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

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

No explicit guidance is provided on when to use this tool versus alternatives such as list_bundles or assign_tool_bundles. The description implies usage for task descriptions, but does not were-when to use this over similar tools, leading to only implied usage.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, fully covering the safety profile. The description adds no extra behavioral details (e.g., return format or error handling), but it is consistent with the 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 single, focused sentence that states the purpose and input criterion without any fluff. Every word earns its place.

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

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

For a simple one-parameter tool with strong annotations, the description is largely complete. It clearly defines the function and input, but does not explicitly state the return value (e.g., the recommended profile name), which would be slightly more helpful given no output schema.

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

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

The schema provides 100% coverage with a clear description for the only parameter 'task' ('Aufgabenbeschreibung oder Ziel der Session'). The tool description does not add additional parameter semantics beyond what the schema already offers.

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

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

The description clearly states the action (recommends), the resource (Claude profile), and the input basis (task description). This distinguishes it from sibling tools such as switch_profile (which switches) and suggest_bundles (which recommends bundles, not profiles).

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

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

The description implies usage: when a task description is available and a profile recommendation is needed. It provides clear context but does not explicitly mention alternatives or when not to use this tool, though the sibling list makes the niche apparent.

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?

Annotations already indicate non-read-only, idempotent, non-destructive behavior. The description adds useful context: the tool can either write the config or show a preview depending on the `write` parameter, and it resolves a full mcp-config file. This goes beyond the raw annotations without contradicting them.

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, information-dense sentence that front-loads the primary action ('Bereitet einen Profilwechsel vor') and then specifies the key artifact and modes (erzeugt oder als Vorschau). 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?

Given the rich input schema and annotations, the description is sufficient to infer the tool's main behavior. It does not explain return/output format for the preview mode, but this is less critical because no output schema is expected and the preview concept is reasonably transparent.

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?

All five parameters are fully described in the input schema (100% coverage), so the description does not need to compensate. The description's mention of a 'resolved --mcp-config file' reinforces the role of `profileName` and `profileRoot`, but it does not add much beyond the schema.

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

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

The description clearly states the tool's purpose: preparing a profile switch by generating or previewing a resolved --mcp-config file. This distinguishes it from sibling tools like `controlcenter_resolve_profile`, though it does not explicitly name those alternatives.

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

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

The description implies the tool is used when preparing a profile switch, and the `write` flag makes the preview/write distinction clear. However, it does not explicitly contrast this tool with the many sibling profile-management tools, such as `suggest_profile` or `audit_profile`.

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