ellmos-controlcenter-mcp
OfficialServer Quality Checklist
Latest release: v0.7.1
- Disambiguation2/5
Several tool pairs have almost indistinguishable boundaries: controlcenter_list_tools and controlcenter_list_available_tools both start servers and read their tool lists, while controlcenter_find_capability and controlcenter_tool_overview both report native-binding claims from system-explorer resolutions. controlcenter_list_governance also overlaps controlcenter_list_decisions on the decision index, so an agent must read detailed descriptions carefully to avoid selecting the wrong tool.
Naming Consistency4/5The controlcenter_ prefix and verb_noun pattern (list_*, describe_*, suggest_*, resolve_*) are applied consistently for the vast majority of tools. A few outliers such as controlcenter_actual_self_receipt, controlcenter_tool_overview, and controlcenter_status break the pattern, but they are rare enough that the naming remains predictable overall.
Tool Count2/5At 34 tools the surface is too large for an agent to navigate efficiently and is well above the 25-tool threshold. The broad domain explains some breadth, but the presence of several near-duplicate tools inflates the count and makes the set feel over-engineered.
Completeness4/5For a read-only, advisory control plane, the surface is fairly complete: server discovery, stacks, profiles, resources, locks, permissions, decisions, skills, plugins, and invocation are all represented. Minor gaps remain, such as no detail view after listing skills, plugins, or bundles, but agents can usually work around these.
Average 3.9/5 across 34 of 34 tools scored. Lowest: 1.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 67 commits in the last 12 weeks
- Last stable release on
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
This repository includes a glama.json configuration file.
This server has been verified by its author.
Add related servers to improve discoverability.
How to sync the server with GitHub?
Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.
To manually sync the server, click the "Sync Server" button in the MCP server admin interface.
How is the quality score calculated?
The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).
Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.
Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).
Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.
Tool Scores
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description contradicts the annotations by claiming 'this tool grants no execution authority' and mentions 'fuzzy candidates are never promoted automatically' – but annotations declare readOnlyHint=true and destructiveHint=false. Since readOnlyHint already implies no execution or mutation, these statements are redundant and confusing. The description adds no new behavioral context (e.g., what happens if candidate not found, side effects, rate limits) and instead introduces misleading language about authority when annotations already cover safety. This is a contradiction as it misstates the tool's effect.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, dense, 36-word sentence that is packed with unnecessary jargon like 'provider-neutral routing map' and 'semantic/source signal'. It is not front-loaded with the core action; instead, it leads with validation steps and constraints. This is over-specification without clarity, hurting scannability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 10 parameters and no output schema, the description carries the burden of explaining the tool's purpose and return values. It fails to mention what the tool returns (e.g., ranked skill candidates), how it handles errors, or what 'resolve' means. The description is inadequate for an agent to correctly invoke this complex tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all 10 parameters have descriptions in the schema. However, some descriptions are in German (e.g., 'Maximale Anzahl gerankter Skill-Kandidaten') which may hinder comprehension. The description itself adds no parameter-level semantics, but since coverage is high, the baseline of 3 applies. The extra credit is for the description's mention of 'limit' and 'deployedOnly' indirectly via context, but overall it doesn't compensate for the lack of clarity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5Does the description clearly state what the tool does and how it differs from similar tools?
The description is a convoluted definition that never states a clear action. It mentions 'semantic role/expert/persona' and 'routing map' but fails to say what the tool actually does or returns. It reads like a jargon-filled abstract and does not differentiate it from the many sibling tools like controlcenter_find_capability or controlcenter_resolve_profile.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Implicit usage is suggested by the description of validating a caller-selected role and verifying endpoints, but there is no explicit when-to-use or when-not-to-use guidance. Similarly, no alternatives are mentioned, and the distinction between this resolver and controlcenter_resolve_profile or controlcenter_list_skills is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
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.
Conciseness4/5Is 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.
Completeness2/5Given 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.
Parameters3/5Does 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.
Purpose4/5Does 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.
Usage Guidelines2/5Does 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.
- Behavior3/5
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.
Conciseness4/5Is 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.
Completeness2/5Given 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.
Parameters3/5Does 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.
Purpose4/5Does 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.
Usage Guidelines2/5Does 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.
- Behavior3/5
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.
Conciseness5/5Is 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.
Completeness3/5Given 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.
Parameters3/5Does 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.
Purpose4/5Does 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.
Usage Guidelines2/5Does 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.
- Behavior3/5
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 source file (mcps.catalog.v1.json) but no further behavioral context such as output format or potential errors, which is acceptable given the annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the purpose (describes a local MCP server) and free of any superfluous wording. Every word contributes to the meaning, making it optimally concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a describe tool with no output schema, the description lists the aspects covered (type, namespace, sovereignty, wrapping, composition), giving the agent a clear expectation of what will be returned. It does not detail the output format, but annotations cover safety and the schema covers parameters, leaving only the return structure unspecified – a minor gap for a read-only describe operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters (serverId and mcpRoot) fully documented in the schema. The description does not add any parameter-specific semantics beyond what the schema provides, 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.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'beschreibt' (describes) and the resource: a local MCP server from mcps.catalog.v1.json, listing the specific aspects covered (type, namespace, sovereignty, wrapping, composition). This differentiates it from sibling describe tools like controlcenter_describe_resource and controlcenter_describe_stack, though it does not explicitly name them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention exclusions, prerequisites, or related describe tools, leaving the agent to infer usage purely from the name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as readOnly/idempotent/non-destructive. The description adds meaningful context: results are advisory, provenance is unverified, and results never authorize execution. This goes beyond the annotations and is consistent with them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: one core-purpose sentence plus a trust caveat. No filler, though the dense technical jargon slightly reduces immediate readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only find tool, it covers purpose, read-only nature, and result reliability. It does not explain what callers should do with the advisory results, how limit behaves, or what a capability candidate looks like, especially since there is no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and parameter descriptions already explain the query and the resolution path with its trust caveat. The description adds only a slight framing ('hash-konsistente System-Explorer-Auflösung') but does not materially exceed the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb (Bewertet/Evaluates) and names a clear resource: Native-Binding-Behauptungen aus einer hash-konsistenten System-Explorer-Auflösung. The title adds the intent 'Fähigkeitskandidaten finden'. It is specific, but does not explicitly differentiate from sibling tools like controlcenter_find_skill.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus sibling tools such as controlcenter_resolve_semantic_route or controlcenter_evaluate_permission. The advisory, unverified nature is implied but no workflow context or alternative selection hint is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark it read-only, idempotent, and non-destructive. The description adds behavioral value by stating that it separates declared, installed, configured, running, healthy, and observed states, and the parameter description clarifies that the source check remains an untrusted assertion until an external receipt. This goes beyond the 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single compact sentence with no filler. It front-loads the main action and then lists the state categories. The jargon is dense, but every phrase carries information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter read-only tool, the description plus schema covers the input well. However, with no output schema, the description does not explain the return format or what a 'Tool-Übersicht' concretely contains, and it omits any usage context relative to the large sibling set.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The parameter description adds meaningful detail about the expected file type and trust caveat, but the main description contributes no additional parameter semantics beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Zeigt') and names a concrete resource (native-binding assertions of a self-consistent resolution), plus it enumerates the separated state categories. The title adds that this is a tool overview. However, it does not explicitly differentiate itself from siblings like controlcenter_list_tools or controlcenter_resolve_semantic_route.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus any of the 34 siblings. There is no mention of alternatives, exclusions, or prerequisites beyond the schema's required resolutionPath. The agent is left to infer appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
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.
Conciseness5/5Is 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.
Completeness3/5Given 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.
Parameters3/5Does 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.
Purpose5/5Does 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.
Usage Guidelines3/5Does 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.
- Behavior3/5
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.
Conciseness5/5Is 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.
Completeness4/5Given 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.
Parameters3/5Does 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.
Purpose4/5Does 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.
Usage Guidelines3/5Does 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.
- Behavior3/5
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.
Conciseness5/5Is 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.
Completeness4/5Given 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.
Parameters3/5Does 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.
Purpose5/5Does 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.
Usage Guidelines3/5Does 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.
- Behavior3/5
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.
Conciseness5/5Is 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.
Completeness4/5Given 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.
Parameters3/5Does 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.
Purpose5/5Does 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.
Usage Guidelines3/5Does 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.
- Behavior4/5
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.
Conciseness5/5Is 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.
Completeness4/5Given 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.
Parameters3/5Does 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.
Purpose4/5Does 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.
Usage Guidelines3/5Does 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.
- Behavior4/5
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.
Conciseness5/5Is 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.
Completeness4/5Given 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.
Parameters3/5Does 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.
Purpose5/5Does 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.
Usage Guidelines3/5Does 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.
- Behavior4/5
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.
Conciseness5/5Is 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.
Completeness4/5Given 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.
Parameters3/5Does 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.
Purpose5/5Does 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.
Usage Guidelines3/5Does 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.
- Behavior4/5
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.
Conciseness5/5Is 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.
Completeness4/5Given 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.
Parameters3/5Does 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.
Purpose5/5Does 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.
Usage Guidelines3/5Does 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.
- Behavior4/5
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.
Conciseness5/5Is 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.
Completeness4/5Given 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.
Parameters3/5Does 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.
Purpose5/5Does 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.
Usage Guidelines3/5Does 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.
- Behavior4/5
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.
Conciseness5/5Is 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.
Completeness4/5Given 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.
Parameters3/5Does 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.
Purpose5/5Does 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.
Usage Guidelines3/5Does 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.
- Behavior3/5
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.
Conciseness5/5Is 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.
Completeness4/5Given 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.
Parameters4/5Does 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.
Purpose5/5Does 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.
Usage Guidelines3/5Does 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.
- Behavior3/5
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.
Conciseness5/5Is 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.
Completeness4/5Given 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.
Parameters3/5Does 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.
Purpose5/5Does 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.
Usage Guidelines4/5Does 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.
- Behavior3/5
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.
Conciseness5/5Is 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.
Completeness5/5Given 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.
Parameters4/5Does 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.
Purpose5/5Does 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.
Usage Guidelines3/5Does 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.
- Behavior3/5
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.
Conciseness5/5Is 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.
Completeness5/5Given 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.
Parameters3/5Does 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.
Purpose5/5Does 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.
Usage Guidelines4/5Does 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.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, and the description adds meaningful context: the native check via list_tools, the short-lived Ed25519 signature, and the safe-abort behavior when configuration is missing. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two compact sentences in German; the first front-loads the verb, resource, and key characteristics, while the second adds the prerequisite. There is no filler, repetition, or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter read-only tool without an output schema, the description conveys the purpose, output type, signature, short lifetime, and failure mode. It does not detail the exact return structure, but that is minor given the simple contract and the read-only annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and schema description coverage is 100%, so there is no parameter documentation gap. The description adds useful context about an external configuration requirement that affects whether the call succeeds.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
States a precise verb and resource: it checks the ControlCenter server read-only via list_tools and produces an Ed25519-signed short-lived Actual-Self-Receipt. This distinguishes it from sibling inspection tools like list_tools or describe_mcp because the focus is on generating a signed receipt.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a clear precondition (explicit host-local configuration required, otherwise safe abort) and notes the read-only nature. However, it does not explicitly state when to prefer this tool over alternatives or name a sibling that should be used instead, so usage context is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
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.
Conciseness5/5Is 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.
Completeness4/5Given 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.
Parameters3/5Does 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.
Purpose5/5Does 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.
Usage Guidelines3/5Does 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.
- Behavior4/5
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 covered. The description adds valuable behavioral context beyond annotations: it clarifies this is a report not enforcement ('grants no authority and blocks nothing'), and it explains the precedence order (deny > ask > allow > default) and the 'unknown' fallback when no register exists. This is meaningful behavioral disclosure that helps an agent understand what the tool actually does and doesn't do.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with zero waste. The core purpose is front-loaded ('Reports what a LOCK.permissions register allows'), followed by the critical non-enforcement clarification, and the fallback behavior. Every sentence earns its place and the structure is logical.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only evaluation tool with 100% schema coverage and no output schema, the description is quite complete. It covers the lookup mechanism (nearest register), the precedence order, the non-enforcement nature, and the fallback behavior. The only minor gap is that it doesn't describe the exact return format (e.g., what the response looks like), but since there's no output schema and the tool is simple, this is a minor omission.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all three parameters (path, agent, action) with examples. The description adds context about how the parameters relate to the register lookup (nearest register, precedence), but doesn't add new parameter-level semantics beyond what the schema provides. Baseline 3 is appropriate since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Reports'), a resource ('LOCK.permissions register'), and the exact scope ('at a path, using the nearest register found in the path or any parent'). It also distinguishes itself from enforcement tools by explicitly saying 'This is a report, not enforcement'. This clearly differentiates it from siblings like controlcenter_check_lock and controlcenter_list_locks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly explains when to use this tool: when you need to know what a permissions register allows at a path. It also explains the fallback behavior when no register exists ('unknown' rather than 'allow'). However, it doesn't explicitly name alternative tools to use instead (e.g., controlcenter_check_lock for checking a specific lock, or controlcenter_list_locks for listing registers), so it misses the explicit alternatives guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond annotations. Annotations already say read-only/idempotent/non-destructive; the description adds detail about parent-lock inheritance, the special never-expiring lock types, and crucially the fail-closed behavior: unreadable paths, missing config, or errors yield 'unknown' and safe-to-proceed=false, never a false 'free'. This is exactly the behavioral transparency agents need.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the essential answer (whether one path may be modified), then lock inheritance behaviormatic: fail-closed detail. Slightly dense but every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only check with no output schema, the description covers the verdict semantics, fail-closed behavior backlog and lock-scope inheritance. It doesn't spell out the full response object fields, but describes the key reported items (lock type/scope/expiry).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents the sole parameter. The description adds context (the path is checked including parent-directory locks) but doesn't need to add syntax since the schema is complete. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource ('Answers whether one path may be modified') and adds the key distinguishing detail of inherited locks from parent directories. This clearly separates it from sibling tools like controlcenter_list_locks, which merely list locks rather than evaluating a specific path. Scope, expiry, and lock-prefix behavior are also named.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies when to use it: before modifying a path, to check whether it is locked. It explains the semantics (inheritance from parents, effective lock reporting), which helps an agent select it over list_locks. It does not explicitly name alternatives or exclusion conditions, but the context is clear enough for correct selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is already known. The description adds valuable context about the tool's side effects: it starts each server, reads list_tools output, and shuts it down, which is a behavioral trait (temporary server startup) not captured by annotations. This is useful beyond annotations, though it doesn't detail performance implications or specific error handling beyond fail-closed semantics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loads the core purpose and side effect (starting servers), then details fail-closed behavior and scope. Every sentence adds unique information, and the guidance on controlcenter_invoke is placed at the end for depth. No waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 6 parameters, but 0 are required/resolved, and schema coverage is 100%. Given no output schema, the description doesn't detail the return format, which could be a gap for an agent needing to parse results. However, the description explains fallback behavior and scope, which is helpful, but it lacks pagination or return structure for the list. This is a moderate gap given complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema describes all parameters, including the note that schemas dominate output for includeSchemas. The description references 'profile' and 'local MCP root' but doesn't add deeper semantics beyond what the schema already provides (e.g., how 'server' matches multiple identifiers is described in schema). As with the calibration example, baseline 3 is appropriate when the schema covers all parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'lists' and the resource 'tools of MCP servers that this host has NOT loaded', and explicitly distinguishes itself from controlcenter_list_tools (which presumably lists loaded tools) and controlcenter_invoke. It also specifies the fail-closed behavior for unreachable servers, making the tool's scope and purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool ('when the tool name is already known') and says it is not required before controlcenter_invoke, directing the agent to call controlcenter_invoke directly in that case. This provides clear guidance on when to avoid this tool, which is more than basic usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
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.
Conciseness5/5Is 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.
Completeness5/5Given 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.
Parameters3/5Does 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.
Purpose5/5Does 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.
Usage Guidelines4/5Does 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.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already state read-only/idempotent/non-destructive. The description adds that this is a mirror of the same register as controlcenter_list_resources and points to that tool for the authority note, which is useful behavioral context 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single well-structured sentence that front-loads the core purpose and only adds the cross-reference to the list tool. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple single-resource lookup and annotations covering read-only behavior, the description is sufficiently complete: it conveys scope, input source, and a pointer to the authority note. There is no output schema, but 'full row detail' is an adequate expectation for this simple operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema already covers id and type at 100% coverageهار, but the description adds that the numeric id comes from controlcenter_list_resources and that resources are systems or software, helping disambiguate what identifier to supply.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Uses a specific verb ('describe') and resource ('one resource' / 'single system or installed software entry'), and ties the identifier to controlcenter_list_resources. This clearly distinguishes the tool from sibling describe tools like describe_mcp and describe_stack.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Clearly signals that the tool is for fetching full row detail for one resource by its numeric inventory id from controlcenter_list_resources. It does not explicitly name alternative tools or exclusion cases, but the scope is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
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.
Conciseness5/5Is 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.
Completeness4/5Given 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.
Parameters3/5Does 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.
Purpose5/5Does 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.
Usage Guidelines4/5Does 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.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the destructiveHint annotation, the description discloses connection lifecycle (opened/closed per call), policy enforcement, error categorization, self-correction on unknown tool names, and audit logging with argument names only. This is a rich behavioral contract.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but every sentence carries distinct value: core function, lifecycle, policy, error handling, self-correction, audit. It is well-structured and front-loaded with the main purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's dynamic nature (invokes arbitrary tools) and 7 params with no output schema, the description covers key aspects: addressability, policy, error handling, and audit. The return shape is undefined but that's expected; the description could add expected result structure, but it's acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All 7 parameters have schema descriptions, so the baseline is 3. The description adds context on server resolution (MCP root/profile) and args passthrough, but doesn't go into depth per parameter. It's sufficient given the schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
States exactly what it does: runs one tool of an unloaded backend MCP server and returns the result. The verb+resource is specific and distinguishes it from all sibling tools, which manage or describe but do not invoke.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes clear this is for invoking tools on servers not part of the current session. It notes constraints (discoverable from MCP root or profile, policy can deny) but doesn't explicitly contrast with in-session invocation. However, the title and content imply when to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already signal read-only, idempotent, non-destructive behavior, and the description adds real value beyond that: it states the tool cannot answer or close a decision, reports when its index is stale relative to source files, and explicitly distinguishes 'register unconfigured' from 'zero open decisions'. These are meaningful behavioral disclosures not present in 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with no waste: the primary result is front-loaded, exclusions follow immediately, and edge-case behavior is stated last. Every sentence contributes essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Even without an output schema, the description covers return fields, deliberate exclusions, read-only guarantees, staleness reporting, and unconfigured-register behavior. Given the two optional parameters are fully documented in the schema, nothing critical is missing for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameters limit and status are already fully documented with defaults and allowed values. The tool description adds no parameter-specific semantics beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: it lists pending decisions from the host's decision register, and enumerates exactly which fields are returned (identifier, date, title, status, scope). This clearly distinguishes it from sibling list tools like controlcenter_list_locks or controlcenter_list_governance.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when to use the tool: when decision metadata is needed, not question texts, options, or recommendations. It explicitly notes that those deeper details are deliberately not returned and should be read in the register itself, but it does not name an alternative sibling tool for that purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Even though annotations already declare readOnlyHint, idempotenceHint, and safe operation, the description adds substantial behavioral detail: partial results never claim completeness, unconfigured/ unreadable/invalid registry statuses are reported, data is loaded only via the canonical PolicyRegistry API, and BYUM rows remain advisory pointers that are never dereferenced. This goes well beyond what the annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but efficiently organized, front-loading the purpose in the first sentence and then layering caveats and non-behaviors. Every sentence carries unique information; there is minimal repetition of the schema or annotations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool aggregates three distinct sources with nuanced results (available, unconfigured, unreadable, invalid; honest zero) and the description fully explains these semantics. It also addresses what is not projected and what side effects are absent, which is exactly the context needed given there is no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All four parameters are already documented in the schema with defaults and descriptions, so the baseline is 3. The description does not add parameter-specific meaning, such as how limits interact across the three registries or what the status values like OFFEN mean in context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and object: 'Returns one read-only, allowlist-only metadata view' across three named sources. It sharply distinguishes the tool's scope by listing exactly what is not projected and what the tool never does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The read-only, listing-oriented framing makes it clear this is the governance-metadata inspection tool rather than a mutation tool like apply_governance. It does not explicitly contrast with sibling list tools such as list_registries, but the source-specific wording provides clear context for when it applies.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, it discloses the wall‑clock budget behavior, including that roots not started within the budget are reported as unscanned, and that an incomplete scan says nothing about unreached roots. This is critical non-obvious behavior not visible in any structured field. It also discloses a hard prerequisite (ENVIRONMENT variable) that would otherwise be an invocation guess.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, front-loaded with the core purpose, then a clear read-only reassurance, a behavioral caveat, a prerequisite, and the sibling alternative. Each sentence earns its place; no filler or redundancies.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description still conveys the output's content (path, type, scope, owner, remaining time) and explicitly reports when roots were left unscanned. Combined with the prerequisites, performance caveats, and sibling routing, nothing an agent needs to decide whether and how to call it is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already explains both parameters (rootsFile's fallback chain and budgetSeconds' overshoot semantics) at 100% coverage, so the description adds no extra parameter-level detail beyond mentioning a 'wall-clock budget' in prose. Baseline 3 is appropriate under high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource ('Lists every active LOCK*.txt across the configured roots'), enumerating the returned fields, and closes by naming the sibling it is not ('For a single path use controlcenter_check_lock'). An agent can immediately tell this is the broad scan tool and not a point query.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states when to prefer this tool (listing locks over configured roots) and provides the alternative with the deciding condition: 'For a single path use controlcenter_check_lock, which is far faster and also sees inherited locks.' It also warns about the long scan profile, letting the agent decide whether a full scan is worth it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, but the description adds meaningful behavioral context: it states it is a read-only mirror, mentions the source of authority, notes that it returns only summary columns, and discloses the 'unconfigured' edge-case behavior. These go beyond the structured annotations and help an agent predict output 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences with no fluff. The primary purpose and filters are front-loaded in the first sentence, the authority/read-only caveat is second, and the distinction from describe_resource plus the unconfigured behavior is last. Every sentence earns its place and the structure is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a list tool with optional filters and no required parameters, the description is complete. It explains the output granularity (summary columns), points to the alternative for full rows, clarifies authority, and covers the edge case of an unconfigured inventory. An agent has enough information to call it correctly and interpret results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides complete descriptions for all three parameters (host, type, limit), so the schema already carries the semantics. The description does not add parameter-specific details beyond what the schema says, so a baseline score of 3 is appropriate given the 100% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Lists'), a clear resource ('resource inventory' of systems/software), and the optional filters. It distinguishes itself from controlcenter_describe_resource by noting it returns only summary columns, making its purpose and scope unambiguous even without reading the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly names the alternative tool (controlcenter_describe_resource) and the condition for choosing it ('for the full row'). It also notes the authority caveat, which clarifies that this tool is a non-authoritative mirror, guiding an agent to seek authoritative data elsewhere if needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
GitHub Badge
Glama performs regular codebase and documentation scans to:
- Confirm that the MCP server is working as expected.
- Confirm that there are no obvious security issues.
- Evaluate tool definition quality.
Our badge communicates server capabilities, safety, and installation instructions.
Card Badge
Copy to your README.md:
Score Badge
Copy to your README.md: