ControlKeel

Overview Schema Related Servers Score Discussions

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.4.7
Disambiguation5/5
Each tool targets a distinct aspect of governance (validation, filesystem, git, memory, reviews, budget, etc.). Even where names are similar (e.g., ck_memory_search vs ck_memory_record), descriptions clearly differentiate purpose and behavior. No two tools have overlapping responsibilities.
Naming Consistency4/5
All tools use the 'ck_' prefix followed by descriptive snake_case names. However, there is minor inconsistency: some names start with a verb (ck_validate, ck_delegate) while others start with a noun (ck_memory_search, ck_fs_read). The pattern is not perfectly uniform but remains readable and predictable.
Tool Count2/5
With 55 tools, the surface is very large. While the scope of ControlKeel governance is broad, this many tools risks overwhelming agents. A more focused set (e.g., consolidating related operations) would be typical for coherent MCP servers. The count is at the high end of 'too many.'
Completeness5/5
The tool set covers the full lifecycle of governed development: validation, execution, file operations, git, memory, reviews, budget, routing, delegation, deployment, outcome tracking, loops, skills, and more. There are no obvious missing operations for the intended domain of AI governance and session management.
Average 4.3/5 across 55 of 55 tools scored. Lowest: 3.3/5.
See the Tool Scores section below for per-tool breakdowns.
- 1 of 1 community issues answered or closed in the last 6 months
- 402 commits in the last 12 weeks
- Last stable release on August 29, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide destructiveHint: true and readOnlyHint: false, but the description adds little beyond 'Restore'. It does not disclose side effects, whether the restore is additive or replacement, what gets destroyed, or error conditions. For a mutation tool, more behavioral context is needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no redundant words, front-loaded with the primary action. Efficient and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Core action is stated, but missing context such as prerequisites (e.g., checkpoint must exist), behavior on conflict, and effect on current session state. Output schema exists but does not fully compensate for the lack of behavioral details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema already describes 2 of 3 parameters (checkpoint_id and session_id), but 'strict' lacks description. The tool description does not add any additional parameter semantics. Baseline is 3 due to high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies the verb 'Restore', the resource 'session state from a previous checkpoint', and the action 'updating session metadata'. It clearly distinguishes from sibling tools like ck_checkpoint_create and ck_checkpoint_list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives, no prerequisites or conditions mentioned. The description only states what it does without context for decision-making.
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, destructiveHint=false. The description adds minimal context by specifying that it lists checkpoints for a session, but does not disclose any additional behavioral traits like sorting, pagination, or limits on results.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that efficiently conveys the tool's purpose without any superfluous words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the description covers the basic functionality, it omits details such as the behavior of the 'limit' parameter and the structure of the output (though an output schema exists). Given the tool's simplicity and annotation support, it is adequate but not fully comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description only restates the optional type filter from the schema. It does not add meaning for the 'limit' parameter (which lacks a schema description) or elaborate on 'session_id'. With 67% schema coverage, the description fails to compensate for the missing parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and the resource 'checkpoints', with scope 'for a session' and optional filter by type. This distinguishes it from sibling tools like ck_checkpoint_create or ck_checkpoint_restore.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide any guidance on when to use this tool versus alternatives, such as ck_checkpoint_restore or ck_checkpoint_create. There is no mention of when not to use it or what conditions favor this tool.
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?
The description adds context beyond annotations by specifying the output contains failure patterns and eval candidates. Annotations already indicate read-only and idempotent behavior. The description does not contradict annotations. However, it omits details like whether the export is a file download or inline data, which would enrich transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is concise and front-loaded. Every word adds value: it names the action (export), the resource (trace packet), and key contents (failure patterns, eval candidates). No redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and clear annotations, the description is fairly complete. It explains the tool's purpose and output. Minor missing details about the format of the exported data or how parameters affect the result, but overall sufficient for an export-oriented tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 75%, so the schema already documents most parameters. The tool description does not add new meaning or usage tips for parameters beyond what is in the schema. 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/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool exports a structured session or task trace packet with failure patterns and eval candidates. The verb 'export' and noun 'trace packet' are specific. However, it does not explicitly differentiate from sibling tools like ck_context or ck_observability, which may also deal with trace data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. The description implies it is for trace-centered improvement loops, but lacks explicit when-not or comparative context. No usage prerequisites or exclusions are mentioned.
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 and idempotentHint, so description is adequate. It adds that it returns branch, HEAD, status but no extra behavioral context like error handling or definition of 'current repository'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with action, no redundant words. Highly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool is simple with output schema, but description lacks clarity on parameter role and default behavior. Adequate but incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
One optional parameter project_root with 0% schema description coverage. Description does not explain the parameter's purpose or effect. Falls short of compensating for missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it lists all git worktrees with branch, HEAD, and status. Verb 'list' and resource 'git worktrees' are specific. Distinguishes from sibling git tools like ck_git_diff and ck_worktree_switch.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives (e.g., ck_git_status). No mention of prerequisites or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructive nature. Description adds that session metadata is updated, but does not detail what is destroyed or irreversible effects. Could elaborate on side effects like detaching from current worktree.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no unnecessary words, perfectly front-loaded with the action and result.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive tool with low schema coverage, the description is minimal. With output schema present, return values are covered, but behavioral context (e.g., impact on other sessions) is omitted.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50% (only session_id described). The description does not explain worktree_path or how the parameters interact. Lacks compensation for missing parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the action ('Switch'), the resource ('different git worktree'), and the side effect ('update session metadata'). It is distinct from sibling tools like ck_worktree_list, which only lists worktrees.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives (e.g., ck_worktree_list or ck_checkpoint_create). No prerequisites or conditions mentioned.
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?
Description adds moderate behavioral context beyond annotations: it indicates a mutating operation ('Create') and what is captured, but does not disclose side effects, authorization needs, or whether earlier checkpoints are affected. Annotations are minimal, so description carries burden.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, direct and informative with no redundant words. All information is front-loaded and essential.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 5 parameters (1 required, 1 enum) and an output schema, the description is too brief to fully guide usage. It lacks parameter details and usage scenarios, but is adequate for a simple create operation. The output schema likely documents return values, partially compensating.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 80% description coverage (4 of 5 parameters described). The description adds no additional meaning to any parameters, relying on schema. Baseline 3 is appropriate as no further value is provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb 'Create' and specific resource 'workspace checkpoint' with details of contents (git state, workspace context, metadata) and purpose (migration or rollback), distinguishing it from sibling tools like ck_checkpoint_restore.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description implies usage for creating checkpoints but provides no explicit guidance on when to use this tool versus alternatives such as ck_rollback or other snapshot tools, nor any conditions or prerequisites.
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. The description adds that the tool lists read-only artifacts and supports keyword search, which is consistent but not significantly beyond annotations. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the main action. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given an output schema exists and schema coverage is complete, the description covers the core functionality. However, it could briefly mention how other parameters like session_id affect results. Still, it is largely complete for typical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameters are already described. The description adds a use case for the query parameter but does not explain others. This provides some additional meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists recent prior sessions and read-only experience artifacts, using a specific verb ('List') and resource. However, it does not explicitly differentiate from sibling tools like ck_experience_read or ck_experience_search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives an example use case for the query parameter but does not specify when to use this tool versus alternatives, nor when not to use it. The usage is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide no safety profile (all false), so the description carries the full burden. It discloses behavioral traits: the tool modifies state (non-read-only), is not destructive, and not idempotent. It adds context about freezing verifier paths, separating mutable paths, enforcing stop conditions, and requiring audited rollbacks for rejected iterations, which goes 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the core purpose. It is dense but avoids verbosity. Minor improvement could be achieved with bullet points for modes, but overall it is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the tool's high complexity (51 parameters, many enums, nested objects, output schema), the description does not explain return values, mode-specific parameter requirements, or the relationships between parameters. It assumes significant domain knowledge about 'bounded iterative loops,' 'verifier paths,' and 'artifact longevity,' leaving the agent underinformed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 2% (one parameter documented). The description mentions the 'mode' parameter and its enum values but does not explain any other parameter's semantics, meaning for the remaining 49 parameters the agent must rely solely on names and types. The description should compensate for low coverage but does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Create and govern a bounded iterative loop without executing worker code.' It lists specific actions (freeze verifier paths, separate mutable paths, classify artifacts, enforce stop conditions) and modes (create, record, status, stop, promote), making the verb+resource distinct from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context (governing iterative loops) but does not explicitly state when to use this tool versus alternatives among the many sibling tools. No exclusion criteria or comparisons are provided, leaving the agent to infer 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 indicate mutability (readOnlyHint=false). Description confirms write operation and return of an ID. No additional behavioral traits (e.g., side effects, permissions) are disclosed beyond what annotations imply.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Approximately 7 sentences, front-loaded with purpose and usage. Each sentence adds value—purpose, return, parameters, usage context, retrieval alternative. No redundant phrasing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 11 parameters, 4 required, nested objects, and an output schema, the description covers the core purpose, workflow integration, and retrieval. The output schema exists but its details are not described; however, the description mentions the return value.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 91%, so baseline is 3. Description lists required and some optional parameters with minimal elaboration (e.g., 'commit_sha to link results to a specific revision'). Does not add significant meaning beyond the schema's own descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool records external regression-test evidence and that it is a write operation creating a DB record, linking to proof bundles and release-readiness. It distinguishes its role by mentioning related tools (ck_review_submit, ck_memory_search) but does not explicitly differentiate from all 50+ siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance to use after an external test run and before ck_review_submit, plus retrieving past results via ck_memory_search. Does not specify when not to use, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states the tool writes files when install=true, contradicting annotations (readOnlyHint=true). This is a serious inconsistency, so transparency is poor despite description being explicit about writing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two efficient sentences: first states purpose, second explains key parameters. No unnecessary words. Front-loaded and to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 8 parameters, an output schema, and annotations, the description covers core behavior and modes. Missing details on parameter interactions (e.g., both flags set) but schema covers individual params.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is high (88%), so schema already documents most parameters. The description adds meaning for validate_only and install, but for other parameters it provides no additional semantics beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool synthesizes a deduplicated skill-evolution packet from traces and failure clusters, including anti-patterns and a draft. This distinguishes it from siblings like ck_skill_list, ck_skill_load, and ck_skill_validate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains two modes (validate_only and install) and when to set project_root. It provides clear context for using the tool, though it does not explicitly compare to alternatives like ck_skill_validate.
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 provide readOnlyHint, idempotentHint, destructiveHint. Description adds archive context and artifact types, but no additional behavioral traits beyond what annotations convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with main action, no superfluous words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With output schema present and annotations covering safety, description sufficiently explains purpose and scope. Minor omission of source_session_id requirement, but still adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 80% (4 of 5 parameters documented). Description does not add parameter-specific meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb 'read', resource 'prior-run artifact', and lists specific artifact types. Distinguishes from sibling tools like ck_experience_search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage for reading prior-run artifacts, but provides no explicit when-to-use or when-not-to-use guidance, nor mentions alternatives.
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 reveals key behaviors: the existence of a primary agent restriction, modes that modify state (register, update, retire), and the notion of ephemeral agents. It adds context beyond annotations, such as the super-agent concept, and 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph that efficiently conveys the modes and constraints. It is reasonably concise but could be improved by using bullet points or shorter sentences for easier scanning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (11 parameters, nested objects, output schema), the description adequately covers the modes and role constraints. It does not explain return values, but an output schema exists. It provides sufficient context for an AI agent to understand the tool's scope.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds value by explaining the mode semantics and role constraints but does not delve into parameter details beyond what schema already provides. The schema already describes each parameter adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: managing workspace agent roles with specific modes (register, update, list, health, retire). It identifies the resource (workspace agents) and differentiates from sibling tools by focusing on agent lifecycle management.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides some usage guidance by explaining when to use each mode (e.g., 'only one primary per workspace') but does not explicitly contrast with alternatives among the many sibling tools. It implies when to use certain modes but 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.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description claims idempotency ('Idempotent — re-running refreshes artifacts'), but annotations set idempotentHint: false. This is a direct contradiction, warranting a score of 1. Other behavioral details are provided but overridden by the inconsistency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise single paragraph, front-loaded with main purpose. Every sentence adds value, no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Comprehensive description covering use case, idempotency, filesystem impact, and prerequisites. Output schema exists so return values are not needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters. Description adds default values (project_root, scope) but no syntactic or usage details beyond schema. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool wires ControlKeel into the agent host, installing hooks and artifacts. It distinguishes from sibling ck_mcp_discover with specific guidance.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to use (after one-line MCP install when host lacks hooks) and suggests using ck_mcp_discover first for host ID. Provides clear context and alternative.
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 set readOnlyHint=false, destructiveHint=false, idempotentHint=false, indicating this tool can create or modify data. The description adds value by mentioning auto-redaction of PII and rate limit tracking, but does not fully specify side effects of each mode or authorization needs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—three short phrases covering purpose, features, and modes. Every sentence adds unique value without redundancy, and the core purpose is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (12 parameters, output schema present, nested objects), the description provides sufficient high-level context for an agent to select the correct mode and understand the tool's role. The presence of an output schema reduces the need to describe return values. A bit more detail on mode-specific prerequisites would elevate completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
100% schema description coverage sets a baseline of 3. The description does not add parameter-level details beyond what the schema provides, though it contextually explains modes that influence parameter usage (e.g., 'limit' is relevant for top_services mode).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly defines the tool's purpose: 'Track and govern agent interactions with external SaaS APIs.' It lists specific capabilities (rate limits, cost attribution, PII redaction) and enumerates operational modes (record, summary, rate_limit_status, top_services), making it distinct from sibling tools that focus on other domains.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly names the four modes and their purposes, guiding the agent on when to use each (e.g., 'record (log an interaction with auto-redaction)'). However, it does not provide explicit 'when not to use' guidance or compare directly to siblings like ck_cost_optimizer or ck_observability.
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, idempotentHint, destructiveHint. Description adds context about operating on 'recent session traces in the same workspace' and returning 'eval candidates', which supplements the annotations without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single, well-structured sentence with the verb front-loaded. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (4 parameters, output schema exists), the description effectively conveys core purpose and what it returns. It does not clarify 'recent' or clustering details, but output schema likely covers that.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 75%, so the burden on description is lower. The description does not add extra parameter meaning beyond the schema, resulting in baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses specific verb (cluster) and resource (failure modes from session traces) and mentions outcome (return reusable eval candidates). It clearly distinguishes from siblings like ck_observability or ck_validate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description implies usage for analyzing failures but does not explicitly state when to use vs alternatives or exclude other cases. No when-not or alternative tool suggestions.
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. The description adds that loading can be bulk and 'governed,' but does not disclose additional behaviors like authentication needs or rate limits. The annotation coverage reduces the burden, but the description adds moderate value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the fallback purpose, and every word adds value. No redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the main purpose and bulk loading capability. With an output schema present and annotations covering safety, the description is adequate for an AI agent to understand the tool's primary use case, though it does not detail all parameters beyond uris.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 75%, with session_id lacking a description. The description provides a URI format example (skills://<name>) that adds clarity to the 'uris' parameter, but it does not compensate for the missing description of session_id. Overall, the description adds some meaning but does not fully offset the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool loads CK resource URIs, especially skills, and explicitly positions it as a fallback for clients that do not support MCP resources or native bulk skill loading. This distinguishes it from sibling tools like ck_skill_load and provides a specific verb and resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool: 'Fallback for clients that do not support MCP resources or native bulk skill loading.' This provides clear context but does not name specific alternative tools, leaving some room for interpretation.
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 readOnlyHint, idempotentHint, and non-destructive. The description adds useful context: it queries an external endpoint and enables progressive discovery. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core action, no redundant information. Every word serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is complete for a discovery tool with a well-documented schema and output schema (not shown but present). Minor gap: does not mention error handling or output format, but output schema covers return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all three parameters. The description does not add extra meaning beyond what is in the schema, meeting the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it auto-discovers tools from an external MCP server by querying its tools/list endpoint. It uses a specific verb+resource, and the purpose is distinct from sibling tools like ck_skill_list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when needing to discover tools from an external server, but does not explicitly state when to avoid it or compare with siblings (e.g., ck_external_service or ck_skill_load). No when-not or alternative 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 mark the tool as read-only and idempotent. The description adds behavioral context: it analyzes specific files and returns detailed reports, which is useful and consistent with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single, focused sentence front-loading the purpose. No wasted words, every part adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists, the description does not need to detail returns, but it summarises them well. With annotations and schema, the description is adequately complete 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/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline 3. The description does not add meaningful detail beyond the schema for the parameters 'mode' and 'project_root'. It only mentions them in context but not semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool audits project rule files and skills for token overhead, specifying the files (AGENTS.md, CLAUDE.md) and outputs (word counts, token estimates, duplicate detection, optimization recommendations). This distinguishes it from siblings as a token overhead auditor.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for auditing token overhead but does not explicitly state when to use versus alternatives like ck_validate or ck_skill_evolution. No when-not or alternative 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 readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds value by specifying the scope of analysis (specific tools) and the output categories (load-bearing, active, etc.). It does not contradict annotations and provides useful behavioral context beyond what annotations offer.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the primary action and then specifies details. It is efficient, though slightly dense. Every phrase adds value, but it could be split for improved readability. Still, it is concise and structurally sound.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 optional parameters and an output schema, the description adequately explains what the tool does, the scope of analysis, and the type of output. It does not elaborate on the output schema's details, but that is acceptable since the output schema exists. Minor gap: 'governance coverage' is not explicitly defined, but context is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed descriptions for all three parameters. The description does not add additional meaning beyond the schema, so baseline score of 3 applies. No extra parameter guidance provided in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool analyzes governance coverage across recent sessions, enumerates specific CK governance tools (ck_validate, ck_review_submit, etc.), and categorizes them as load-bearing, active, low-usage, or unused. It returns actionable recommendations for gaps, which is highly specific and distinguishes it from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states the tool is for analyzing governance coverage and identifying gaps. While it doesn't mention when to not use it or list alternatives, the context is clear and the tool's purpose is well-defined among many sibling tools. A slight deduction for lacking explicit exclusions.
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 indicate readOnlyHint=false, destructiveHint=false, idempotentHint=false. The description adds behavioral context by describing real-time event streaming and the collaborative aspect, which aligns with the annotations. It does not contradict 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the primary purpose, and efficiently covers the key modes. No extraneous words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (7 parameters, nested objects) and that an output schema exists, the description provides sufficient high-level context. It could be more explicit about parameter usage per mode, but the schema covers details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and parameters are already described. The description adds value by summarizing the modes but does not elaborate on other parameters like actor, event_type, limit, payload, session_id, task_id beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is a real-time collaborative channel for human actions streaming to the agent, explaining that agents can see human viewing, editing, approving. It distinguishes itself from siblings by specifying modes (subscribe, publish, presence, history) and the collaborative nature.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the four modes and what each does (receive events, emit event, who is active, recent events), providing clear context for when to use. However, it does not explicitly state when not to use or contrast with alternatives.
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?
Description adds value over annotations by detailing sandbox defaults, denial of capabilities, validation step, and dry_run support. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence efficiently conveys core purpose and key constraints without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (12 params, output schema exists), the description covers essential behavior. Could detail timeout/output handling but is sufficient with schema support.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 75%, so baseline 3 is appropriate. Description mentions dry_run and sandbox but does not elaborate on other parameters beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool executes code in a non-local sandbox, specifying Docker as default, and lists restrictions. It distinguishes from siblings as no other tool performs code execution.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use (for code execution in a sandbox) and what it denies, but does not provide explicit alternatives or when-not-to-use scenarios.
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 provide readOnlyHint, idempotentHint, destructiveHint. The description reinforces read-only behavior and adds extra context by listing excluded operations (e.g., benchmark execution, promotion mutation). No contradictions, and adds value beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of two sentences. The first sentence lists all report types, and the second clarifies read-only scope. No redundant information; every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of the tool (9 parameters, many enum values) and the presence of an output schema, the description adequately covers the core purpose and exclusions. It could be slightly more explicit about when to use specific report types, but overall sufficient for an agent to understand basic functionality.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is high (89%), so the schema already documents most parameters. The description does not add parameter-level details but lists the report types, which overlap with the 'report' parameter enum. Baseline score of 3 is appropriate as the description does not significantly enhance parameter understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads local observability reports, listing specific report types (sessions, loop status, problems, memory, costs, trends, evals, etc.). It also explicitly states what it does not do (no benchmark execution, draft approval, etc.), which helps distinguish it from sibling tools that perform those mutations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit 'Read-only' statement and lists excluded operations, guiding agents not to use this tool for mutations. However, it does not explicitly contrast with specific sibling tools like ck_validate or ck_execute_code, leaving some implicit guidance. Clear context for read-only usage is given.
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 read-only, non-destructive, idempotent; description adds return value context; no contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded, no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With output schema present, description provides adequate context; mentions return fields and usage flow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage 100% and param descriptions are good; main description does not add extra parameter meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it lists all available AgentSkills for the project, returns names, descriptions, and scopes, and distinguishes from sibling ck_skill_load.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says call this to discover capabilities then use ck_skill_load, providing clear usage context; could mention when not to use (e.g., if already know skills).
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, idempotentHint, and destructiveHint. The description adds value by detailing the output structure (wrapped in XML tags, list of resources) and the prerequisite workflow, confirming it is a safe read operation with no destructive side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words. The first sentence states purpose and result, the second gives usage instruction. Efficiently structured for quick comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists and annotations are present, the description adequately covers the tool's behavior. It explains the return format and the dependency on ck_skill_list. Optional parameters are documented in the schema, so no critical gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 80% with good parameter descriptions. The description adds context for the 'name' parameter (from ck_skill_list) but does not significantly enhance understanding of other parameters. 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/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Load' and the resource 'AgentSkill', specifies the output format (SKILL.md body in <skill_content> tags plus bundled resources), and differentiates from sibling ck_skill_list by explicitly noting it should be called after listing 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises 'Call after ck_skill_list to activate a specific skill', providing clear sequential usage guidance. While alternatives are implied (ck_skill_list first), there is no explicit when-not-to-use, but context is sufficient.
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 (readOnlyHint=false, etc.) are basic; description adds meaningful context: 'complete' mode is blocked if unresolved findings exist, and each mode has distinct behavior. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences efficiently convey purpose and mode overview. No superfluous content; front-loaded with the core function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given complexity (11 params, 6 modes, output schema), the description covers main behaviors. Missing some edge-case details (e.g., error conditions beyond blocked complete) but adequate with schema and annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters with descriptions, so baseline is 3. The description adds value by linking parameters to specific modes (e.g., task_id for status/claim/complete, output for report), providing additional semantic grouping.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool manages governed tasks within a session and lists six specific modes (status, claim, complete, heartbeat, checks, report) with brief explanations. This distinguishes it from sibling tools like ck_session or ck_finding.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage through mode enumeration but lacks explicit guidance on when to use this tool vs alternatives, no 'when not to use' statements, and no mention of prerequisites or context for mode 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 already indicate readOnlyHint and idempotentHint, making safety clear. The description adds value by specifying it returns ranked results with citations, which is not obvious from annotations alone. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences plus two example questions, all front-loaded. Every sentence adds value without extraneous detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, description appropriately focuses on scope ('current workspace') and content type ('findings and tasks'). It is fully sufficient for a search tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (all parameters described), so baseline is 3. The description does not add extra meaning beyond the schema; it merely restates 'freeform' for the query parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it performs freeform full-text search across findings and tasks, returning ranked results with citations. This distinguishes it from siblings like ck_experience_index (indexing) and ck_experience_read (reading specific entries).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides concrete examples of questions it answers (e.g., 'has this deployment pattern caused a blocked finding before?'), giving clear context for when to use it. However, it does not explicitly mention when not to use it or alternative tools.
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 readOnlyHint, idempotentHint, and destructiveHint, confirming safe read-only behavior. The description adds context about the polling pattern and the return of status, notes, and URL, which goes beyond annotations without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph that efficiently conveys purpose, usage, and behavioral context without redundancy. It is appropriately front-loaded with the main action (fetch status) and then details. Could be slightly more streamlined, but it is effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists (though not shown), the description covers the key return fields (status, notes, URL) and usage pattern (polling). For a relatively simple read-only tool, this is complete enough. It could mention error handling or not-found cases, but it is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 67% schema description coverage, the description adds meaning by explaining the interaction between review_id, task_id, and review_type, particularly that review_type filters when task_id is used without review_id. This clarifies parameter usage beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches the latest decision status, reviewer notes, and browser review URL, distinguishing it from sibling tools like ck_review_submit and ck_review_feedback. It specifies the resource and verb effectively.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use the tool: with review_id or task_id, and explains that review_type filters when task_id is used. It also advises polling after ck_review_submit to check approval before proceeding. While it lacks an explicit 'when not to use' statement, the context is clear.
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 discloses that 'mode=create' persists a finding and 'mode=resolve|dismiss|escalate' dispositions existing findings. It mentions that using 'allow' auto-resolves matching open/blocked findings, which provides behavioral insight beyond annotations. Annotations indicate a write operation (readOnlyHint=false), and the description confirms it without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is moderately long but each sentence adds necessary information. It front-loads the main action and mode distinction, then details parameters and returns. Minor redundancy could be trimmed, but overall it is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers all relevant aspects: modes, required fields, default behaviors, return values, and sibling differentiation. With output schema present, the return structure is clarified. For a tool with 13 parameters and multiple modes, the description is thorough and leaves no critical ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 92% (high), so baseline is 3. The description adds value by explaining defaults (decision defaults to warn), special behavior (allow auto-resolves), and how bulk disposition works via rule_id/category/status, which is not fully detailed in the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Record or disposition a governed finding.' It explains both create and disposition modes, and distinguishes from sibling 'ck_memory_record' by specifying that ck_finding is for policy findings while the sibling is for general knowledge.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use each mode (create vs. disposition) and lists required fields for create. It directly recommends using ck_finding for policy findings and ck_memory_record for general knowledge, offering an alternative. It does not explicitly state when not to use the tool, but the context is clear.
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 destructiveHint=true. Description adds conditional behavior (blocked findings prevent commit), which adds value. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Five sentences, front-loaded with main action. No redundant information. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers validation, conditional commit, output, prerequisite, and limitation. Output schema exists, so return values are covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 67% but description does not clarify the undocumented 'session_id' parameter. Message and project_root are partially implied but not explicitly linked to schema fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it validates a commit message and executes git commit if validation passes. Distinguishes from siblings by specifying prerequisite (ck_git_status) and what it does not do (no push). Specific verb+resource+conditions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises to use ck_git_status first and notes that git push is separate. Provides clear when-to-use and 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, idempotentHint=true, destructiveHint=false. The description reinforces read-only behavior and adds that it returns diff text and CK validation findings, which provides context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with three main sentences plus a usage triplet. It front-loads the core purpose and read-only nature, with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists and annotations cover safety, the description covers core usage, parameter behavior, and distinguishes alternatives. The only gap is the session_id parameter, but overall it is complete enough for correct tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 75%, and the description adds meaning for base_ref and head_ref by explaining they are git refs and can be omitted. However, the session_id parameter lacks explanation in both schema and description, so the description only partially compensates for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool generates a git diff and runs CK validation. It explicitly says 'Read-only — no commits are created' and distinguishes from siblings like ck_git_status and ck_git_commit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use guidance: 'Use ck_git_diff to review changes before committing or submitting a review.' It also gives clear alternatives: 'Use ck_git_status for a summary without the full diff. Use ck_git_commit to create the commit after reviewing.' Additionally, it explains parameter usage for base_ref and head_ref.
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?
Description declares 'Read-only and side-effect free — no findings are created or modified', which aligns with annotations (readOnlyHint, idempotentHint, destructiveHint). Adds context about what the tool does not affect, enhancing transparency beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences: purpose/output, read-only declaration, usage guidance. Every sentence adds value; no fluff. Front-loaded with the primary function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, safety, usage guidelines, and alternatives. Output schema exists but is not shown; description adequately describes return types. Only minor gap is parameter documentation, but overall complete for a read-only tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50%; only project_root has a description. Session_id is not described in schema or in the tool description. The description does not explain the role or format of session_id, leaving ambiguity. Parameter semantics are weak.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it retrieves git working tree status correlated with CK governance findings, listing specific outputs (staged/unstaged/untracked files, blocked/open findings). Differentiates from sibling tools ck_git_diff and ck_git_commit by mentioning alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use ('before ck_git_commit') and when to use alternatives ('prefer ck_git_diff for diff content; prefer ck_git_commit when ready to commit'). Provides clear context and exclusions.
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 are minimal (readOnlyHint=false, destructiveHint=false), so the description carries the burden. It discloses three different behaviors per mode and the authorization requirement for switch. 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the main purpose, then lists modes concisely. No extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists, the description covers essential usage and parameter nuances. It could mention error handling or prerequisites like project_root existence, but overall sufficient for invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds extra meaning, e.g., 'Omit or pass nil to resolve from project binding' for session_id, and the mode parameter's behavioral impact. This justifies above baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it enumerates and manages governed sessions with three distinct modes (list, status, switch). This is specific and distinguishes it from sibling tools like ck_session_digest.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use each mode and notes that switch requires confirm: true. However, it lacks explicit guidance on when not to use this tool or comparisons to alternatives.
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 adds behavioral context beyond annotations: it explains that generate creates a new digest, latest returns the most recent, and list provides paginated history. Annotations (readOnlyHint=false, destructiveHint=false) are consistent; no contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no wasted words. First sentence summarizes purpose and content; second sentence lists modes and use case. Efficient and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 parameters (2 with enums) and an output schema exists, the description provides sufficient context: it explains modes, output type (condensed digest), and mentions pagination for list mode. The presence of an output schema covers return value details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description adds value by explaining the three modes and their purposes (e.g., 'create a new digest', 'return the most recent', 'paginated history'). This supplements the enum descriptions in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it generates a condensed, human-scannable digest of session activity, listing specific components (tasks, findings, budget, etc.) and three modes. This distinguishes it from sibling tools like ck_session which likely provides raw session data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the tool is designed for a quick summary without reading raw event streams, implying when to use it. It does not explicitly mention alternatives or when not to use, but the context is clear enough for an agent.
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 readOnly, idempotent, non-destructive. Description adds behavioral details: output size limit (100KB), that validation uses the skill's frontmatter field, and the two validation paths. No contradictions; description complements annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two well-structured sentences. First sentence states the core purpose and mechanism. Second sentence covers both invocation patterns. No redundant or unclear phrasing. Front-loaded with actionable information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters (1 required), full annotations, and presence of an output schema, the description covers the key behavioral aspects: validation origin, size limit, two modes. Lacks explicit mention of return value, but output schema likely covers that. Sufficient for an agent to select and call correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, baseline 3. Description adds semantic value: explains that 'output' can be JSON string or plain text (not in schema), clarifies that 'skill_name' makes 'schema' optional, and ties 'project_root' to usage with skill_name. This goes beyond what the schema alone tells the agent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the action ('Validate skill output against a JSON Schema'), specifies the resource (skill output), and distinguishes two modes (direct schema vs. built-in schema). The verb 'validate' is specific and distinguishes it from sibling tools like ck_validate, which may validate other things.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to use: after running a skill to enforce typed output. Describes two invocation modes (output+schema or output+skill_name). Does not explicitly state when not to use, but context is clear. No mention of alternatives, but sibling names suggest other validation tools (e.g., ck_validate) exist.
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 idempotentHint true. The description reinforces 'Read-only' and adds behavioral details about detail_level behavior and token efficiency. No contradictions; adds 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is multi-sentence but every sentence adds value: purpose, components, parameter guidance, usage timing, sibling alternative. Efficient and front-loaded, though slightly verbose; still earns its length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity, rich input schema, and many sibling tools, this description is thorough. It lists return components, explains parameter trade-offs, gives usage context, and covers edge cases (e.g., automatic session resolution). No output schema needed for explanation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema documents all 4 parameters with 100% coverage. The description adds defaults (compact for detail_level, session_id defaults to active bound session, project_root for resolution), providing meaning beyond the schema's definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Fetch') and resource ('full governed session state'), enumerating the components (mission, budget, findings, etc.). It explicitly distinguishes from the sibling tool ck_context_pack by directing when to use each, making the purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear guidance: 'Call ck_context at the start of every task to reacquire state' and specifically recommends ck_context_pack for focused retrieval. Also explains when to use compact vs full detail_level, giving explicit 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 readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description confirms 'Read-only — no budget records are written' and outlines two modes with their outputs (suggest: optimization tips; compare: price breakdown). This adds value beyond 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences: purpose and read-only status, mode definitions, and usage guidance with an alternative. It is front-loaded, efficient, and every sentence adds actionable value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 parameters and an output schema, the description covers the core logic (two modes, parameter requirements, return types) and provides a real-world usage scenario. While it omits the 'spending' parameter, the overall completeness is high for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 71% schema description coverage, the description clarifies the critical parameter 'mode' and maps other parameters to modes (e.g., session_id for suggest; task_description, estimated_tokens, top_provider, top_model for compare). However, the 'spending' parameter is not mentioned, leaving a small gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Get cost optimization suggestions or compare AI provider/model prices for a task.' It specifies two distinct modes (suggest, compare) and contrasts with sibling tool ck_budget for recording spend, making the 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit usage guidance is provided: 'Use ck_cost_optimizer before choosing a model for expensive multi-agent work; use ck_budget to record and enforce spend limits.' The description details which parameters to pass for each mode (session_id for suggest, task_description/estimated_tokens/top_provider/top_model for compare), offering clear when-to-use and when-not-to-use information.
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, idempotentHint, destructiveHint. The description reinforces with 'Read-only — no files are modified or created' and adds windowed read behavior. No contradiction. Adds context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, front-loaded with purpose, no redundant words. Each sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given output schema exists and annotations cover safety, the description covers usage, parameters, and alternatives well. Minor omission: no mention of error handling for missing paths or permissions, but overall complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 80%; description adds meaning: path must be relative to project root, start_line is 1-indexed, max_lines enables windowed reads, omit both for full file. The schema lacks description for max_lines, so description compensates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Read a file from the bound project root' with clear verb and resource, and explicitly distinguishes from sibling tools (ck_fs_find, ck_fs_grep, ck_fs_ls).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use guidance: 'Use ck_fs_read to inspect a file at a known path' and lists alternatives for locating, searching, and listing. Also explains when to use start_line/max_lines for windowed reads vs. omitting for full file.
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 provide safety info (not read-only, not idempotent, not destructive). Description adds behavioral context: marks as archived, not deleted, and is a write operation, enhancing transparency beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise (5 sentences), front-loaded with purpose, explains effect, input, usage, and alternative. Every sentence adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, usage, parameter details, and alternatives. With output schema present, return values are explained elsewhere. Missing error conditions or permissions, but sufficient for an archive tool given annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 67%. Description adds meaning for memory_id (explains its origin). session_id and project_root rely on schema descriptions, but the description compensates for the missing memory_id description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it archives a memory record to exclude it from search results, specifies it's a write operation not deletion, and distinguishes from sibling tools like ck_memory_record and ck_memory_search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises when to use (stale, superseded, no longer guiding) and when to use alternative (update via ck_memory_record), providing clear 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?
Discloses write vs read-only modes and mentions impact on other tools. Annotations lack behavioral details, so description adds value. Could further mention idempotency or side effects but is sufficient given output schema presence.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise and well-structured, breaking down modes with clear bullet points. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers all essential aspects: three modes, required parameters per mode, usage timing, and integration with other tools. Output schema handles return values, so no further detail needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Adds significant meaning beyond schema by mapping parameters to specific modes (e.g., 'For record mode: pass...') and enumerating outcome values. Schema coverage is 63%, so description compensates well for undocumented parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly defines three distinct modes (record, get_session, get_leaderboard) with specific verbs and resources. Distinguishes itself from siblings by focusing on outcomes and leaderboards, as evidenced by mention of feeding data to ck_route and ck_cost_optimizer.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit usage context: 'Call after task completion before ending the session' and explains downstream dependencies. However, does not directly contrast with alternatives among siblings or state when not to use.
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?
Description states 'Read-only' which aligns with annotations (readOnlyHint=true, destructiveHint=false). It also explains default behaviors for omitted query and detail_level. Adds value beyond annotations by clarifying synthesis of query and default detail_level.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences: first states purpose, second outlines parameters, third gives usage guidance. No redundant words. All information is front-loaded and critical for agent decision.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 6 parameters, output schema, and annotations, the description covers purpose, parameter behaviors, defaults, and usage context. It is complete and does not need to explain return values due to output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 83%, so baseline is 3. Description adds meaningful defaults and behavior for query (synthesized when omitted), top_k (default 5), and detail_level (compact default). This enriches understanding beyond the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool builds a compact, citation-enriched context bundle. It uses specific verbs and resources ('Build a ... context bundle') and distinguishes itself from the sibling tool ck_context by specifying use cases (mid-task vs session start).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly guides when to use this tool over ck_context: 'Prefer ck_context_pack over ck_context when you need a focused, query-driven bundle for a specific sub-task rather than the full session snapshot. Use ck_context at the start of a session... use ck_context_pack mid-task.' This provides clear context and alternatives.
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 provide readOnlyHint and idempotentHint. The description adds context by clarifying that query is a path fragment or glob pattern and that the search is non-destructive. No contradictions; behavioral traits are well-explained beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (several sentences) and well-structured: purpose, read-only note, parameter explanations, usage guidelines. No redundant or filler text. Front-loaded with the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 parameters, an output schema, and rich annotations, the description covers all essential aspects: what it does, parameter semantics, scope, and when to use alternatives. It feels complete for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning for query ('path fragment or glob pattern'), path ('scopes search to subdirectory'), and limit ('default 50'), which go beyond the schema. Schema description coverage is 80%, so baseline 3 is elevated to 4 due to these clarifications.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with a specific verb and resource: 'Find files or directories whose path contains a given fragment, searching within the bound project root.' It clearly distinguishes from sibling tools by naming ck_fs_grep and ck_fs_read for alternative use cases.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool ('Use ck_fs_find to locate files by name or path') and provides alternatives for content search (ck_fs_grep) and reading known files (ck_fs_read). It also declares the tool is read-only, indicating it should not be used for modifications.
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, destructiveHint=false. The description reinforces that it is read-only and states that no files are modified. It also clarifies the path parameter behavior (omit to list root). No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences that cover purpose, read-only nature, path guidance, and sibling tool references. Every sentence adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, annotations provide safety and idempotency, and an output schema exists, the description is complete. It covers what, how, and when to use, plus alternatives. No gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 3 parameters with 67% description coverage (path lacks description). The description adds meaning for 'path' by explaining it is a relative directory path and that omitting it lists the project root. This compensates for the missing schema description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (list), the resource (files and directories), and the scope (inside bound project root). It also distinguishes from sibling tools like ck_fs_find, ck_fs_read, and ck_fs_grep.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when to use this tool ('browse directory structure') and provides direct alternatives for other tasks (ck_fs_find, ck_fs_read, ck_fs_grep). It also notes the read-only nature.
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?
Discloses idempotency behavior (re-submitting same source_id updates rather than duplicates) and write operation, adding context beyond annotations. No contradiction with annotations except idempotentHint discrepancy.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with core purpose. All sentences are informative without redundancy. Slightly long but justified due to number of parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers key parameters (memory, record_type, source_id, tags) but not all 12 parameters (e.g., task_id, session_id, project_root). However, schema descriptions fill some gaps. Adequate for complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Adds meaning by explaining memory parameter can be plain string or object with body, title, summary, etc. Also explains record_type enum values. Schema coverage is 75%, so description compensates moderately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Write a governed memory record' and explains persistence to database. It distinguishes from sibling tools like ck_memory_search (retrieval) and references ck_finding and ck_goal for alternative use cases.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance: 'Use ck_memory_record to persist knowledge that should survive session boundaries.' Also tells when to use alternatives: 'Use ck_finding for policy violations... Use ck_goal for durable multi-session intent.'
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 annotations (destructiveHint=true), description adds that it creates an audit finding on every rollback and refuses if downstream tasks depend on changes. This provides critical behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is four sentences, front-loaded with the main purpose. Every sentence adds value without redundancy or verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (5 parameters, 4 modes, output schema exists), the description covers safety, audit, git checkpoint, all modes, and parameter requirements. The output schema handles return values, so no gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. Description adds defaults (mode defaults to status) and indicates conditional requirements (task_id required for certain modes). The reason parameter's purpose in audit finding is clarified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description starts with 'Execute a governed rollback of an agent's work,' clearly stating the verb and resource. It lists four modes (checkpoint, execute, status, list) which distinguish it from sibling checkpoint tools like ck_checkpoint_create and ck_checkpoint_restore.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description explains when to use: for rollback with safety check (refuses if downstream dependencies). It implicitly excludes other scenarios but lacks explicit alternatives or when-not-to-use. The safety check provides clear 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 already declare readOnlyHint=true and idempotentHint=true, so the description's 'Read-only — no session state is changed' aligns with them but adds verbal clarity. The description additionally reveals that the tool returns a ranked list with rationale, which goes beyond basic annotations. A 4 is appropriate since the annotation set is already strong.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four concise sentences that are front-loaded with purpose, then parameter guidance, then sibling differentiation. Every sentence adds value without redundancy. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists (noted in context), the description adequately covers return behavior ('Returns a ranked list of agent recommendations with rationale'). All four parameters are described both in schema and in text. Annotations cover safety. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, baseline 3. The description adds clarifying context: 'task is a plain-language description', 'risk_tier filters out agents... defaults to medium', and 'allowed_agents restricts routing... omit to allow all'. This improves understanding beyond schema types and descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the verb 'recommend' and the resource 'best available AI agent', and mentions criteria (security tier, budget, task type, past performance). It distinguishes from siblings like ck_delegate and ck_cost_optimizer by naming them and their purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use this tool ('Use ck_route to pick an agent'), provides a follow-up action ('then ck_delegate to transfer the task'), and names an alternative ('Use ck_cost_optimizer for a price-focused comparison without routing'). This leaves no ambiguity about 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 already readOnlyHint=true, destructiveHint=false. Description confirms 'Read-only — no changes are applied to the project.' Adds context on return structure (validation result with findings) and trust-boundary logic. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is 6-7 sentences, front-loaded with purpose and read-only status. Efficient structure: main action, then safety, then return type, then parameter explanations, then usage. No unnecessary sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 14 parameters (1 required) and high schema coverage, description covers key behavioral aspects, usage context, and return type. Output schema existence reduces need to explain returns. Provides complete guidance for agent to use tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 86% (high), so baseline is 3. Description adds meaning for key parameters: content (required), kind (policy routing), source_type (trust-boundary checks), domain_pack, requested_capabilities. Not all parameters described, but enough added value to exceed baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description starts with 'Validate proposed code, config, shell commands, or text against CK policy before execution.' Clearly identifies verb (validate) and resource (content against policy). Differentiates from execution siblings like ck_execute_code by stating to call before those actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: 'Call ck_validate before writing files, running shell commands, or executing generated code.' Also provides alternative: 'If validation returns blocked findings, do not proceed — use ck_finding to record them.'
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 states 'Mutates session state to reflect the delegation,' which aligns with annotations (readOnlyHint=false, destructiveHint=false). It also explains the four modes and their behaviors, providing transparency 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four sentences, front-loaded with the core purpose, and each sentence adds essential information without redundancy. It is a model of conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (5 parameters, output schema exists), the description covers purpose, usage, modes, and alternatives. It lacks explicit mention of error conditions or prerequisites but is otherwise complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 80%, and the description adds meaning by explaining the four modes (e.g., 'auto: ControlKeel picks the best agent'), which is not in the schema. However, it does not elaborate on the purpose of task_id, session_id, or project_root beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Hand off a governed task or session to another AI agent, transferring governance context.' It specifies the verb 'hand off' and the resource, distinguishing it from siblings like ck_route.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance is provided: 'Call ck_route first to identify the best agent, then ck_delegate to transfer. Prefer ck_route when you only need a recommendation without transferring; prefer ck_delegate when you are ready to hand off execution.' This clearly indicates when to use this tool vs the alternative.
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?
Describes three modes with different read/write behaviors, explains horizon scope, and does not contradict annotations (readOnlyHint=false indicates writes are possible).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single paragraph is clear and front-loaded, but could use slight restructuring (e.g., bullet points) for easier scanning. No wasted sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given complexity (3 modes, many optional params) and presence of output schema, description covers all major behavioral aspects and usage context comprehensively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is high (88%); description adds meaning by explaining mode-dependent required fields, horizon roles, and differentiation from sibling. Adds value beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it records/lists/updates goals, specifies three modes, and distinguishes from sibling ck_memory_record by stating use case.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use guidance for each mode, required parameters per mode, and compares with ck_memory_record for 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?
The description discloses that it is a write operation that updates the review record and unblocks or halts the execution gate. This adds behavioral context beyond the annotations, which correctly indicate it is not read-only, not idempotent, and not destructive. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is slightly long but well-structured, front-loading the core action and then providing parameter details and workflow context. Every sentence adds value, with no unnecessary repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 parameters (some nested) and an output schema, the description covers all aspects: purpose, parameters, workflow, and behavioral impact. It is comprehensive and does not leave gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explains each parameter's role and the relationship to ck_review_submit. However, the schema description for 'decision' mentions 'allow, warn, block, escalate' while the enum is 'approved/denied', creating a minor inconsistency that reduces clarity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool approves or denies a review, specifying the verb 'Approve or deny' and the resource 'submitted review'. It also distinguishes from siblings like ck_review_submit by noting it is called after submission.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance: it is human-facing, agents should call ck_review_submit first, and after approval the agent proceeds, after denial the plan is revised. It clearly defines when to use this tool versus alternatives.
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 explicitly states 'Write operation — creates a review record and returns a review_id and browser URL,' which aligns with annotations (readOnlyHint=false). It goes beyond annotations by detailing the three review types, the iterative refinement mechanism, and that the plan-quality scorer evaluates structured fields. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively long but front-loaded with the core purpose and key details. Each sentence adds value: first sentence gives purpose and returns, then explains types, iteration, scorer fields, return values, polling instructions, and sibling tools. It could be slightly more terse, but the density is justified given the complexity (42 params).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (42 parameters, nested objects, multiple review types, iterative refinement, and an output schema), the description is thorough. It covers return values (review_id, status, URL), polling behavior, iteration pattern, and the importance of structured fields for scoring. The output schema handles return format, so no gap there. Complete for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers only 57% of parameters, but the description adds significant meaning to many: it explains the role of review_type, submission_body, previous_review_id, plan_phase, and lists numerous structured fields that influence the score (e.g., research_summary, options_considered). This compensates well for the schema coverage gap, providing context beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Submit a governed plan, diff, or completion packet for human review and execution gating.' It uses a specific verb ('submit') and identifies distinct resource types (plan, diff, completion), differentiating it from sibling tools like ck_review_status (polling) and ck_review_feedback (recording decisions).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use guidance: for iterative plan refinement, pass previous_review_id and plan_phase. It also tells the agent what to do after submission: 'After submission, poll ck_review_status until the decision is approved or denied before proceeding.' It explicitly names sibling tools (ck_review_feedback, ck_review_status) and their roles, offering clear context and alternatives.
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 adds significant context beyond annotations: it declares read-only behavior ('Read-only — no files are modified'), explains the fixed-string default with option to switch to regex, describes output format (matching lines with file path and line numbers), and notes the default limit (50). Annotations already indicate readOnlyHint and idempotentHint, and the description aligns perfectly without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with five sentences, each carrying essential information. It front-loads purpose, then covers behavior, parameter hints, output, and sibling differentiation. No redundant or extraneous text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the parameter count of 7, high schema coverage, and presence of an output schema, the description covers all key aspects: purpose, read-only safety, search modes, scope, result limits, output format, and alternatives. It is self-contained and leaves no critical gaps for agent decision-making.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is high (86%), so baseline is 3. The description adds meaning beyond schema by explaining that query uses fixed-string search by default with the option fixed_strings: false for regex, that path can be a relative directory or glob, and that limit caps results with a default of 50. These clarifications help an agent select correct parameter values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Search file contents using grep-style pattern matching' with a specific verb and resource. It explicitly distinguishes from siblings by naming ck_fs_find and ck_fs_read for alternative tasks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use guidance: 'Use ck_fs_grep to find code patterns or strings inside files.' It also tells when not to use it by referencing sibling tools for name-based search or file reading. It explains default behavior (fixed-string) and how to change to regex.
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 fully discloses behavior: explains that estimate and status are read-only, commit is a write operation that deducts from session budget, and mentions optional token overhead attachment. Annotations only provide hints, but the description gives concrete behavioral details without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four concise sentences that efficiently convey purpose, modes, usage guidance, and parameter hints. Front-loaded with key information, no redundant or vague phrasing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (three modes, 14 parameters, nested objects), the description covers all essential aspects: mode behavior, required params per mode, integration with token overhead, and link to sibling tool. Has output schema (context says true), so return values are documented elsewhere.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
While schema covers all parameters, the description adds crucial context: specifies required parameters for commit mode (session_id, estimated_cost_cents, provider, model, input_tokens, output_tokens) and explains include_token_overhead requires project_root. This goes beyond schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Estimate, record, or check the cost of an agent operation against session and daily spend budgets.' It explicitly describes three modes (estimate, commit, status), distinguishing it from sibling tools like ck_cost_optimizer.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance: 'Check ck_budget before expensive multi-agent work or large model calls' and 'Use ck_cost_optimizer for model price comparisons without recording spend.' This clearly indicates when to use this tool and when to use an alternative.
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?
Discloses that analyze and dns_guide are read-only, generate_files is a write operation (creates files). Mentions dry_run to preview writes. Annotations (readOnlyHint=false) are consistent; description adds detail 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four concise sentences: main purpose, mode summary, required parameter note, usage guidance. Front-loaded and efficient with no extraneous content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers all modes, their behaviors, and expected outcomes (recommendations, file generation, DNS instructions). With output schema present, no further return details needed. Complete for a multi-mode tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Adds meaning beyond schema: explains dry_run purpose ('preview what would be created without writing files') and when to use it (with generate_files). Clarifies project_root is required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description states specific verb-resource pairs for three modes: analyze (analyze stack), generate_files (generate configs), dns_guide (return DNS instructions). Clearly distinguishes from sibling tool ck_budget.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: 'before deploying a new project or when setting up CI/CD for the first time'. Recommends alternative 'ck_budget' for cost checks. Also describes mode-specific usage.
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?
Description adds context beyond annotations: it is read-only, performs freeform text search across titles/bodies/tags, returns ranked records with citations and scores. Annotations already declare readOnlyHint=true and idempotentHint=true; description reinforces and elaborates.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is front-loaded with main purpose, then parameter details, then usage guidance. Every sentence is informative with no wasted words. Structure is clear and logical.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 9 parameters, output schema present, and rich annotations, the description fully covers usage, parameters, and context. It explains when to use, what each parameter does, and the return format (ranked records with citations and scores). An agent can confidently select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 89% high, yet description adds meaning: explains query as freeform text search, record_type filters by type listing options, top_k limits results with default 10, source_type and source_id filter by origin, detail_level options compact vs full. This adds significant value beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Search governed typed memory for the current session to recover prior decisions, findings, proofs, and domain knowledge.' It uses a specific verb and resource, and distinguishes from siblings like ck_memory_record and ck_experience_search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides when to use: 'Use ck_memory_search to retrieve what was recorded...' and when not: 'Use ck_memory_record to write new records. Use ck_experience_search for full-text search across findings and tasks workspace-wide.'
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, idempotentHint, destructiveHint. Description adds byte-range support, limits, and that it works on completed runs only. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise but informative: 4 sentences that progressively build from purpose to parameters to decision logic. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With output schema present, description covers all necessary aspects: what it does, how to call it, what parameters mean, and when to use alternatives. Complete for its complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but description adds crucial context: package_root origin, default and max values for peek_bytes and offset, and usage of result_ref (even though not in schema).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool peeks at stdout from a ck_delegate run, distinguishes it from loading full context, and specifies the key inputs (result_ref, package_root).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use (after ck_delegate), how-to-use (use result_ref and package_root), and decision criteria (use result_length to decide peek, pass, or skip). Mentions the RLM pattern.
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:

[![controlkeel MCP server](https://glama.ai/mcp/servers/aryaminus/controlkeel/badges/card.svg)](https://glama.ai/mcp/servers/aryaminus/controlkeel)

Score Badge

Copy to your README.md:

[![controlkeel MCP server](https://glama.ai/mcp/servers/aryaminus/controlkeel/badges/score.svg)](https://glama.ai/mcp/servers/aryaminus/controlkeel)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/aryaminus/controlkeel'

If you have feedback or need assistance with the MCP directory API, please join our Discord server