@ikenga/mcp-iyke

by Royalti-io

Overview Schema Related Servers Score Discussions

JavaScript

Local

Server Quality Checklist

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

Latest release: v0.1.2
Disambiguation5/5
Each tool has a distinct purpose, clearly differentiated by noun and verb. Even within the same category (e.g., todos, projects), operations are uniquely named and described, leaving no ambiguity for an agent to choose the wrong tool.
Naming Consistency5/5
All tools follow the consistent pattern iyke_<noun>_<verb>, using snake_case throughout. The prefix 'iyke_' is always present, and the noun-verb order is uniform, making the set highly predictable and easy to navigate.
Tool Count3/5
At 67 tools, the server is large and could be overwhelming. However, the tools cover a broad platform (Ikenga desktop app) with many subsystems (UI, projects, packages, secrets, etc.), so the count is borderline appropriate but still on the high side for typical MCP servers.
Completeness4/5
The tool set provides comprehensive lifecycle coverage for most domains (todos, projects, secrets, scratchpads, locks, timers). Minor gaps exist, such as no explicit pkg install tool or project delete (archive substitutes), but these are workable and do not severely impact agent workflows.
Average 4/5 across 54 of 67 tools scored. Lowest: 2.6/5.
See the Tool Scores section below for per-tool breakdowns.
This repository is archived. Archived repositories automatically receive an F maintenance tier.
This repository is licensed under Apache 2.0.
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.
Add a glama.json file to provide metadata about your server.
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?
With no annotations, the description must fully disclose behavior. It states the tool is read-only but does not mention side effects, error conditions, permissions, or what happens if the pane doesn't exist or has no published state.
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?
Two sentences, front-loaded with purpose and examples. No wasted words, but could be more structured (e.g., separate lines for parameters, returns).
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?
Lacks return value description (no output schema), no error handling, no prerequisites. Given the simplicity of the tool (1 param), the description is insufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% coverage for the 'pane' parameter. The description does not explain what values it expects (e.g., pane ID, name, type) or provide any context. The description adds no 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 it reads the latest published state object for an iframe pane, with concrete examples (storyboard cursor, comp current frame). This distinguishes it from general state or send tools, though it does not explicitly compare to siblings like iyke_state.
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 (e.g., iyke_state) or when not to use it. Prerequisites like iframe existence are implied but not stated.
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 implies a read-only operation and lists returned fields. However, without annotations, it does not disclose whether the buffer is cleared on read, if data persists across sessions, or any potential side effects. Minimal but adequate for a simple read.
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 sentence and front-loads key information, but it omits critical parameter details. It is efficient but incomplete, which reduces its overall conciseness value.
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?
Given no output schema, partial parameter coverage, and no annotations, the description falls short. It explains the output fields adequately but fails to describe the parameters, making the tool's full usage unclear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has two parameters (since, source) with 0% schema description coverage. The description does not mention either parameter, leaving the agent without any clue about their purpose, format, or effect on the results.
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 recent fetch + XHR network activity with a limit of 100 entries. The verb 'Read' and resource 'network activity' are specific, and the tool is easily distinguished from sibling tools like iyke_dom or iyke_logs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives (e.g., iyke_devtools for broader debugging). There is no mention of prerequisites, limitations, or situations where another tool would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully convey behavioral traits. It only states the tool is idempotent, but omits side effects, return values, error conditions, and any security or authorization requirements. This is insufficient for safe and correct invocation.
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 at two sentences, with no filler. Every word is functional. This is efficient for an experienced user who already understands the domain.
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?
Given the lack of output schema and zero parameter documentation, the description fails to provide enough context for reliable use. There is no mention of success/failure indicators, error handling, or the effect of idempotence on the system state. The tool is simple but still under-documented.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description adds almost no meaning beyond parameter names. 'by scope+name' does not explain the role of scope or name, their formats, or valid values. The user is left to guess.
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 (Delete) and the resource (a scratchpad) with the key identifier (scope+name). It also notes idempotence, which adds precision. This distinguishes it from sibling scratchpad tools (write, append, read, 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 is provided on when to use this tool versus alternatives like iyke_scratchpad_write or iyke_scratchpad_list. There is no mention of prerequisites, consequences, or scenarios that would make this tool preferable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It indicates a write operation but offers no details on success behavior, side effects, permissions, or idempotency. Minimal transparency for a creation tool.
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?
Two sentences, no fluff, efficiently conveys purpose and key parameter notes. Could be slightly more structured but highly concise.
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?
No output schema, description does not mention return values. Lacks differentiation from siblings and does not cover all parameter contexts. Incomplete given the tool's simplicity and lack of annotations.
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 0%, so description must compensate. It explains tags, assignee, and blocker_id, but is silent on body and scope. Partially clarifies parameter semantics but incomplete.
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?
Description clearly states it creates a project-scoped todo, with specific details about tags, assignee, and blocker_id. It distinguishes from siblings like update/list by focusing on creation, though no explicit differentiation.
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?
Provides guidance on how to use parameters (free-form tags, assignee, blocker_id) but lacks when to use this tool vs alternatives like update or list. No exclusionary context given.
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 states idempotency, but lacks other behavioral details such as error handling, permissions, or effects on related data. With no annotations, this is somewhat adequate but minimal.
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, with only two sentences that convey the purpose and a key behavioral trait. No unnecessary words.
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?
The description covers the core operation and idempotency, but for a delete tool, missing details about scope parameter and what happens when key doesn't exist. Not fully complete but functional.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameter descriptions are provided in either the schema or the description. With 0% schema description coverage and no mention of parameters in the text, the agent has no guidance on what 'key' and 'scope' represent.
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 specific verb 'Delete' and resource 'KV entry', clearly distinguishing from sibling tools like iyke_kv_get and iyke_kv_set.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no usage context or comparisons to sibling tools. No when-to-use or 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the fire-and-forget nature and that the bridge listens for known kinds. With no annotations, it adds some behavioral context but does not cover error conditions or prerequisites like iframe being loaded.
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 fluff, front-loaded with the verb and resource. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with 3 parameters and no output schema, the description covers the basic purpose and a use case. It could be improved by indicating known 'kind' values or that 'pane' must be a valid pane identifier.
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 0% with no parameter descriptions. The description only names the parameters and gives one example for 'kind', leaving 'pane' and 'payload' underspecified. It adds minimal 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 sends a fire-and-forget postMessage to an iframe pane, with an example kind and use case. It differentiates from siblings implicitly by being the only tool for sending messages, but does not explicitly contrast with iyke_iframe_state.
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 mentions using the tool to drive mini-app actions from outside the app, which gives context for when to use it. However, it does not specify when not to use it or provide alternatives like iyke_iframe_state for queries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description lacks behavioral details such as whether it scrolls into view, waits for element presence, or has side effects. This is a significant gap for a mutation tool.
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 concise at two sentences, front-loaded with the core action. Minor improvement could be a structured list of parameters.
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?
The description covers element selection adequately but misses explanation of the 'pane' parameter and does not mention return values or success/failure behavior. Given no output schema, these gaps reduce completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explains ref, selector, and text and their mutual exclusivity, but completely omits the 'pane' parameter, leaving its purpose unclear. With 0% schema coverage, more parameter detail is needed.
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 'Click an element' and specifies three distinct identification methods (ref, selector, text), distinguishing it from sibling tools like iyke_type or iyke_focus.
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?
It instructs to specify exactly one of ref, selector, or text, and notes that refs are most reliable. However, it does not explain when to choose one method over another, nor does it mention the pane parameter or 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses that absent keys return a 200 with null value instead of 404, which is useful but omits other behavioral traits like rate limits or idempotency.
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 conveys purpose and a key behavioral detail, with no wasted words.
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?
The description covers the main behavior and absent case but lacks explanation of the scope parameter and potential error scenarios beyond the 200 for missing keys. Given the simplicity, it is somewhat 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?
Schema coverage is 0%, so the description must explain parameters. It only mentions 'scope+key' without defining them, providing minimal value beyond the schema. No defaults or constraints are given.
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 'Read a JSON value at scope+key,' which specifies the action and resource. It distinguishes from sibling tools like iyke_kv_set and iyke_kv_delete.
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 like iyke_kv_list. The description does not mention exclusions or context for choosing this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey all behavioral traits. It indicates a read operation (list) and a filter, but omits details like pagination, what happens with missing scope, or 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?
The description is a single, clear sentence plus an inline note. It is appropriately sized and front-loaded with the main action.
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?
Given the absence of output schema and annotations, the description is too brief. It does not explain return format, error handling, or behavior when no prefix is given.
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?
With 0% schema description coverage, the description adds valuable context by stating that 'prefix' narrows by key prefix and implying 'scope' is the target. However, it does not explain parameter types or defaults.
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 lists KV entries with a prefix filter. It uses specific verb 'List' and resource 'KV entries in a scope', distinguishing it from sibling tools like iyke_kv_get or iyke_kv_delete.
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 for listing entries with optional prefix filtering, but it does not explicitly state when to use this tool vs alternatives or provide any when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It does not state that the tool is read-only, nor does it mention pagination, rate limits, side effects, or output format. The description is minimal for a list operation given the absence of annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no extraneous words. It front-loads the core action (list todos) and conveys defaults and filters efficiently. Minor improvement could separate defaults and filters more clearly, but overall concise.
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?
Given no output schema, the description should mention what is returned (list of todo objects) but does not. It also omits details on ordering, default limit, or handling of edge cases (e.g., no todos). For a 4-parameter list tool with no annotations, completeness is low.
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 schema has 0% description coverage, so the description must compensate. While it names all four parameters (scope, status, tag, assignee) and explains their filtering role, it adds no additional semantic detail beyond the schema (e.g., format, constraints, relationships). The enum for status is already 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 lists todos, specifies the scope defaults to active project, and lists three filter options (status, tag, assignee). This distinguishes it from mutation siblings like iyke_todo_create, iyke_todo_update, and iyke_todo_complete.
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 mentions 'defaults to active project' which provides context for when the scope parameter can be omitted. However, it does not explicitly state when to use this tool versus alternatives or when not to use it. Since there are no other list-todo siblings, the lack of explicit exclusion is acceptable.
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?
No annotations provided, so description carries full burden. It discloses that only active leases are considered and mentions return behavior for expired leases. However, it doesn't specify whether the operation is read-only or has side effects (though implied read-only). Could add more about permission requirements or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no fluff. But missing parameter documentation makes it less concise in utility. One sentence could be moved to clarify parameters.
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?
No output schema, but description explains the held field. Lacks parameter details and does not fully define 'locked' in context of leases. For a simple check tool, it's moderately complete but not self-sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 2 parameters (scope, resource) with 0% schema description coverage, but the description does not explain either parameter. Agent receives no guidance on what values to supply for 'scope' or 'resource'. This is a critical 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?
Description clearly states the tool checks lock status on a resource, specifying it considers only active leases and explains the return value meaning ('held=false if expired'). Distinguishes from siblings like iyke_lock_acquire.
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?
Purpose implies use before acquiring/releasing locks, but no explicit guidance on when to use vs alternatives (e.g., iyke_lock_release). No exclusion criteria or prerequisites 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?
No annotations are provided, so the description carries the burden. It discloses the tool reads logs and includes error captures, and mentions a limit of 500 entries. However, it does not specify if the logs are persistent or session-bound, nor does it describe the output format. There is 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?
The description is a single, concise sentence that conveys the core functionality and key constraints (last 500, includes error types). Every word earns its place with no unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool is a read operation with no output schema and no annotations, the description provides reasonable context: it reads recent logs, includes errors, and has a limit. However, it omits details about the output format, whether logs are cumulative or reset, and the behavior of optional filters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides descriptions for two of three parameters (since and source). The description does not add additional meaning to any parameter; for example, it does not explain how the 'level' filter works. With 67% schema coverage, the description adds marginal value 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 reads recent console and error logs from the running webview, including specific error captures. It uses a specific verb and resource, and while it doesn't explicitly differentiate from siblings, the tool name and description make its purpose obvious.
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 for reading logs but provides no explicit guidance on when to use this tool versus alternatives. No alternative tools are mentioned, and there is no discussion 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose all behavioral traits. It only says 'Only supplied fields are changed' (implying partial update) but omits any side effects, error handling, validation constraints, or consequences of the update. This is insufficient for safe usage.
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 filler. The first sentence defines the core action, the second provides a usage tip and sibling alternative. Every sentence earns its place; it is appropriately sized and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 6 parameters (including enums) and no output schema, the description should cover return values, error scenarios, and parameter relationships. It only hints at merge behavior ('only supplied fields are changed') but lacks details on what the response looks like, how IDs are validated, or any preconditions. Incomplete for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the description provides no individual parameter documentation. It only mentions the 'status' parameter by example ('Pass status="done"') but does not clarify semantics of body, title, assignee, blocker_id, or the meaning of each status enum value. This adds negligible value 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 performs a 'Partial update of a todo' with the verb 'update' and resource 'todo'. It distinguishes from siblings by mentioning iyke_todo_complete as an alternative for setting status to 'done'.
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 'Only supplied fields are changed', guiding usage. Also provides a specific recommendation: 'Pass status="done" or use iyke_todo_complete for the common case', which clarifies when to use this tool versus a sibling.
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?
No annotations are provided, so the description carries the full burden. It mentions the fallback rule, but does not disclose side effects, auth requirements, or behavior when the pin does not exist. The description is adequate but not rich.
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, minimal fluff. The key information is front-loaded: action and fallback. Every sentence is useful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with three required parameters and no output schema, the description is minimal. It lacks details on return values, error handling, or what happens if the pin does not exist. It is adequate for a simple operation but incomplete for full autonomy.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description adds no meaning to the three parameters (scope, asset_kind, asset_name). It does not explain their roles, constraints, or the enum values, leaving the agent with no additional insight 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 action: 'Remove a pinned resolution.' It also distinguishes from sibling tools like iyke_claude_asset_pin (pin) and iyke_claude_asset_list_pins (list) by its specific verb and resource. The fallback behavior adds clarity.
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 context of unpinning is clear, but no explicit when-to-use or when-not-to-use guidance is provided. The description implies usage by naming the action, but lacks exclusions or alternatives beyond the sibling names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It only states 'extend a lock', implying mutation, but does not mention failure cases, required preconditions (lock must be held), or whether extensions are cumulative. This is minimal disclosure for a mutation tool.
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, each serving a distinct purpose: stating the action and providing a usage scenario. It is front-loaded and contains no redundant words.
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?
The tool has 4 parameters and no annotations or output schema. The description covers the core function but lacks details on preconditions, error states, and parameter constraints. It is minimally complete for a simple operation, but more context would improve agent usability.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description only hints that 'ttl_ms' is the extension amount. It does not explain 'holder', 'resource', or 'scope'. The description adds marginal value beyond the parameter names, leaving the agent to infer their roles.
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 'extends a lock you hold by ttl_ms', using a specific verb and resource. The sibling tools include 'iyke_lock_acquire' and 'iyke_lock_release', so it is well-differentiated as a renewal operation.
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 says 'Useful for long-running work that needs more time than the original lease', providing clear context for when to use the tool. It does not explicitly exclude scenarios or name alternatives, but the sibling set makes the distinction clear.
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 discloses that it returns a data preview truncated to 200 chars and lists the fields. However, it does not indicate if the operation is read-only or destructive, nor does it explain the effect of the 'pane' parameter. No annotations are provided to compensate.
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 that are front-loaded and contain no unnecessary words. The first sentence lists output contents, the second gives the use case.
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?
The description covers the output fields but omits any explanation of the 'pane' parameter, which is the only input. Without that, the tool is incomplete for the agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one undocumented parameter 'pane' with no description, and the tool description does not mention it at all. Schema coverage is 0%, so the description fails to explain what this parameter does.
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 dumps the TanStack Query cache and lists the fields included (queryKey, status, etc.). It distinguishes itself from sibling diagnostic tools like iyke_state or iyke_logs by being specific to query cache.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear use case: 'diagnosing stale data or failed fetches.' However, it does not explicitly compare to alternative tools or state 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must bear the full burden. It states the action but does not disclose behavioral traits such as whether the switch is immediate, if there are side effects, or if permissions are required. The impact is minimal but could be clearer.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loads the verb and resource, and includes all necessary information without extraneous text. Every sentence 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?
For a simple tool with one enum parameter and no output schema, the description adequately covers the purpose and valid inputs. It could mention if the tool returns a success message, but that is not essential.
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 semantic value beyond the schema by categorizing modes as 'core' vs 'mini-apps', which helps in selecting the correct value. Since there is only one parameter with an enum, this extra context is beneficial.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Switch' and resource 'activity-bar sidebar mode'. It lists all valid modes and distinguishes between core and mini-apps, making the purpose clear and distinguishable from sibling tools that have different functions.
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 to switch sidebar modes and lists valid options, but it does not provide explicit guidance on when to use this tool versus alternatives like iyke_open or iyke_focus. No exclusions or context are given.
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?
No annotations are provided, so the description must fully convey behavioral traits. It discloses that the tool opens a tab in the focused pane and specifies parameter dependencies for each kind. However, it does not mention potential failure modes (e.g., if the pane is not focused) or side effects (e.g., if a tab with the same content already exists).
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 long, front-loading the primary action ('Open a new tab in the focused pane') and then concisely listing the kind-to-parameter mapping. Every sentence contributes essential information 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 tool has 5 parameters (1 required) and no output schema, the description covers the main functionality for each kind. It is complete enough for an agent to understand how to open different tab types. Minor omissions like error cases or return value are acceptable for this level of complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 80%, meaning most parameters already have descriptions. The description adds a structured overview of how each kind maps to its parameter, but this largely reiterates schema information. It offers marginal added value beyond the schema's own 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 starts with 'Open a new tab in the focused pane,' which is a clear verb+resource combination. It further elaborates on the 'kind' parameter to distinguish different view types (route, terminal, chat, artifact, mini-app). This clearly defines the tool's action and scope, differentiating it from sibling tools like iyke_close or iyke_split.
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 explains what the tool does and maps each kind to its required parameter, but it does not explicitly state when to use this tool versus alternatives (e.g., iyke_split for splitting panes, iyke_focus for focusing). Usage context is implied but not clearly bounded.
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?
With no annotations, the description carries the full burden and discloses key behaviors: side effects (stops sidecars, removes registry, deletes files), what persists (project-scoped state), and exceptions (builtins blocked). Missing details on authorization or irreversibility, but largely transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences front-load the main action and efficiently list consequences and exceptions with no unnecessary words.
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?
Covers major effects and constraints but omits important details like return value (or lack thereof), behavior on failure (e.g., unknown pkg_id), and the exact scope of 'project-scoped state'. Adequate but not 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?
Schema coverage is 0% and the description adds no meaning to the 'pkg_id' parameter beyond its existence. It does not specify format, source, or validation, forcing the agent to rely on implicit knowledge.
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 'Uninstall a pkg' and enumerates specific actions (stop sidecars, remove registry entries, delete files), distinguishing itself from sibling tools like iyke_pkg_list. It also notes restrictions on builtins and surviving state, providing precise purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use (to uninstall a package) and notes that builtins cannot be uninstalled, but it does not explicitly contrast with alternatives like iyke_pkg_list or provide scenarios for 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?
With no annotations provided, the description carries full burden. It discloses key behaviors: appending without overwriting, creating if missing, and the with_separator parameter inserting a rule+timestamp. However, it does not detail what happens during creation (e.g., initial state) or any idempotency aspects.
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 extraneous information. The first sentence states the core purpose, and the second explains a key parameter. Front-loaded and efficient.
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 simple append tool with 4 parameters and no output schema, the description covers the primary operation and the with_separator behavior but omits explanation of the scope parameter. It is adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain parameters. It only explains with_separator, leaving body, name, and scope completely undocumented. This is insufficient for an agent to correctly use those parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool appends to a scratchpad without overwriting, and creates it if missing. It distinguishes itself from the sibling tool iyke_scratchpad_write by emphasizing 'without overwriting', making the purpose specific and differentiating.
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 for adding content without replacing existing content but does not explicitly compare to alternatives like iyke_scratchpad_write or provide when-not-to-use scenarios. The context is implied rather than explicitly guided.
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?
With no annotations provided, the description carries full burden. It discloses the 404 error if the scratchpad is missing and specifies return fields (id, body, updated_at). This adequately covers behavioral traits for a read-only operation, though it could mention if there are any side effects or access restrictions.
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 sentences, front-loaded with the core action, error condition, and output fields. Every sentence adds value without redundancy.
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 simple read tool with two parameters and no output schema, the description covers purpose, error, and return fields. However, it lacks parameter descriptions and any usage context (e.g., what a scratchpad is), which reduces completeness. It is adequate but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, and the description only mentions 'by scope+name' without explaining what 'scope' or 'name' mean, their constraints, or allowed values. This leaves the agent with minimal understanding of the parameters beyond their names.
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 'Read' and the resource 'scratchpad', specifying the parameters 'scope+name'. It distinguishes from siblings like write, append, list, delete by clearly indicating this is a retrieval operation. The mention of return fields further clarifies purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for reading existing scratchpads but provides no explicit guidance on when to use this tool versus alternatives such as iyke_scratchpad_list or iyke_scratchpad_write. No when-not-to-use or context 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?
No annotations provided, so description carries full burden. It discloses key behavioral trait: it's a no-op if the lock is held by another or expired. Missing return/error details but core behavior is well communicated.
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 action. Every part earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 3 parameters, no output schema, and no annotations, the description omits parameter semantics and return value behavior. Incomplete for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description provides no explanation of the three parameters (resource, holder, scope). Agent lacks guidance on how to fill these fields correctly.
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 ('Release a lock you hold') and the resource (a lock). It is specific and distinguishes from siblings like iyke_lock_acquire, iyke_lock_renew.
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 includes when the tool is safe to call ('No-op if held by someone else or already expired'), implying idempotent behavior. It does not explicitly list alternatives 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses scope (restarts all entries per pkg) and failure mode (404). However, it does not mention side effects, permissions needed, or idempotency. Some aspects are implied but not explicit.
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, each adding value. First sentence announces action, second clarifies scope, third provides usage context and failure condition. No fluff, well front-loaded with action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations or output schema, the description covers purpose, scope, and failure condition. It lacks information on expected return value or success confirmation. For a restart tool, agents would benefit from knowing if restart succeeded or any async behavior.
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?
Only one parameter, pkg_id, with 0% schema description coverage. The description mentions 'by pkg id' confirming parameter meaning. However, it does not explain format or provide guidance on obtaining pkg_id, which would help 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 verb 'Restart' and resource 'supervised MCP server by pkg id'. It distinguishes by specifying that it restarts every long-lived MCP entry per pkg, not per server name, and contrasts with per-call MCPs which cannot be restarted.
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 states when to use: 'Useful when a child has wedged.' Also explains when it fails (404 for non-supervised pkgs) and why per-call MCPs are not restarted. Does not suggest alternative tools for non-supervised pkgs, 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description provides good behavioral detail on scoping rules and entry fields (including active_now). But it does not explicitly state it is read-only or mention any side effects, rate limits, or auth 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 a single, concise paragraph with clear structure: purpose statement, then scoping rules, then listed fields. No unnecessary words; front-loaded with the main action.
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 no output schema, the description covers the key behavioral aspects (scoping, entries). It lacks parameter clarification but is otherwise complete for a list operation of moderate complexity.
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 0%. The description mentions include_other_projects in context but does not explain the 'kind' parameter at all. It adds partial meaning but is incomplete.
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 'List installed pkgs visible from the active project' with specific verb and resource. It distinguishes from sibling tools by detailing scoping behavior.
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 workspace vs project-scoped packages are included, and the effect of include_other_projects. However, it lacks explicit when-not-to-use or alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It describes the output format and implies a read-only operation by listing trust states, but it does not explicitly state it is non-destructive or mention any side effects, authentication needs, or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core purpose, followed by output details and usage guidance. No unnecessary 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?
The description explains the return fields adequately despite lacking an output schema. It does not cover error cases or data format details, but for a simple listing tool, it is sufficiently 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?
There are zero parameters, so schema coverage is effectively 100%. The description does not need to explain parameters. Baseline for no parameters is 4.
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 it lists trust state for every installed package and specifies the output fields (state, permissions summary, last grant timestamp). However, it does not explicitly contrast with sibling tools like iyke_pkg_trust_status (which likely checks a single package) or iyke_pkg_list (which lists packages without trust info), so it loses a point for not differentiating.
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 second sentence explicitly advises using this tool when surveying which third-party packages need user approval before invoking their MCP tools. This provides clear context. It does not list when not to use it, but for a simple list tool, this is sufficient.
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?
No annotations are provided, so the description carries the full burden. It discloses that only key names are returned (not values) and that results are sorted and stripped of the scope prefix. However, it does not mention error conditions, default scope behavior, or pagination, leaving some behavioral gaps.
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, each providing essential information without redundancy. The first sentence states core functionality and scope semantics; the second describes output format and use case. 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?
For a simple list tool with one parameter and no output schema, the description covers primary behavior: output format, safety (no values), and sorting. Minor omissions like error handling or scope defaults prevent a perfect score, but it's largely sufficient.
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 only parameter ('scope') has no schema description (0% coverage). The description mentions it but relies on a reference to iyke_secret_get for semantic details. It does not explain the format or acceptable values, adding minimal meaning beyond the raw 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 lists secret key names (not values) in a scope. It explicitly distinguishes from value retrieval operations and specifies output format (sorted, stripped). This provides a precise verb-resource pair that differentiates it from siblings like iyke_secret_get.
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 tells when to use it: 'inventory what secrets are stored in a project without revealing values.' It also references 'same scope semantics as iyke_secret_get' for consistency. While it doesn't explicitly say when not to use it, the context makes its purpose 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?
With no annotations provided, the description discloses key behavioral traits: metadata-only, no restart of claude subprocess, cwd unchanged, and failure on unknown/archived project. It adds value beyond the schema but could mention side effects or return type.
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, each earning its place: purpose, behavioral limitation, failure condition. No redundancy or excess. Front-loaded with the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and 2 required params, the description covers purpose and key behavior but omits how to obtain thread_id or project_id, and the return value. With sibling tools like session_list and project_list available, referencing them would improve 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?
Schema description coverage is 0%, so the burden is on the description. It explains project_id implicitly via constraints (unknown/archived), but thread_id is only implied as 'chat thread'. Neither parameter gets explicit format or source guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Move a chat thread between projects' with a specific verb and resource. It also distinguishes from sibling tools by noting 'Metadata-only — does not restart the claude subprocess', making its scope explicit.
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 when to use the tool (moving a thread) but does not provide explicit alternatives or when-not-to-use guidance. It only states a failure condition, lacking comparison to sibling tools like session_list or project_set_active.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description lacks details on side effects, error conditions (e.g., invalid pane_id), or whether the tool is read-only. For a mutation tool, this is insufficient behavioral disclosure.
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 that front-loads the purpose and then provides parameter details. No wasted words, efficient structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple focus action with no output schema, the description covers the main usage aspects. It does not describe return values or error handling, but given the tool's simplicity, it is mostly 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 0%, but description adds significant meaning beyond schema: explains that pane_id comes from iyke_state response and that index is 1-based DFS leaf index matching keyboard shortcuts.
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 explicitly states 'Focus a specific pane' and specifies two identification methods (pane_id or index), clearly distinguishing it from sibling tools like iyke_split or iyke_open.
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?
Describes how to use the tool by providing either pane_id (with source reference) or index (with keyboard shortcut mapping). Does not explicitly state when not to use or alternatives, but guidance is clear enough for typical usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly explains the combo syntax and targeting behavior. While it does not detail side effects or error handling, the core functionality is transparently described.
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 core action ('Dispatch a keyboard combo'), followed by concise examples and targeting options. Every sentence is informative 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?
Given the tool's simplicity, no output schema, and the presence of sibling tools, the description provides sufficient guidance for correct invocation. It covers the main usage scenario and targeting, though it omits details about the 'pane' parameter and potential errors.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no descriptions (0% coverage), so the description must compensate. It explains the 'combo' parameter format and states that 'ref'/'selector' target an element. However, the 'pane' parameter is not mentioned, leaving one parameter partially undocumented. The description adds value but does not cover all parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Dispatch' and resource 'keyboard combo', immediately distinguishing it from sibling tools like iyke_type (text input) and iyke_click (mouse click). It provides concrete examples of key names and modifiers, clearly defining the tool's action.
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 explains the combo format and optional targeting, but does not explicitly state when to use this tool versus alternatives (e.g., iyke_type for typing text) or when not to use it. The usage context is implied but lacks explicit guidance on tool selection.
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?
With no annotations, the description carries the burden. It discloses the list returns id, name, updated_at, and a 200-char preview, and that scope defaults to active project. However, it does not mention pagination, error handling, or other behavioral traits like ordering or limits. Adequate but not fully transparent.
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, zero waste. The first sentence covers action and scope default; the second lists return fields. Every word is informative and necessary. No redundant or vague 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?
Given the tool's simplicity (one optional parameter, no output schema), the description provides the essential information: what it does, default behavior, and what each returned entry contains. It is complete for basic usage, though it could mention any limitations like pagination or how to list all scratchpads if no scope is specified.
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 0%, so the description must explain the single parameter 'scope'. It does so by stating the default value ('active project'), adding meaning beyond the schema's type-only definition. The description could be improved by specifying valid scope formats, but for an optional parameter, this is sufficient.
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 resource 'scratchpads' with scope qualifier. It distinguishes from sibling tools like iyke_scratchpad_write by focusing on listing. The return fields are specified, 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions scope defaults to active project, providing context on default behavior. However, it lacks explicit guidance on when not to use this tool or how it compares to alternatives like iyke_scratchpad_read for individual items. No exclusions or prerequisites are stated.
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?
No annotations are provided, so the description bears full burden. It discloses the output (saved path, dimensions, byte count) and default path, but does not mention potential side effects, prerequisites (e.g., window visibility), or error conditions. The behavior is adequately described for typical use but lacks depth.
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 exceptionally concise (two sentences) and front-loaded with the core action. Every sentence adds value: the first states the function and output, the second specifies the default path. 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 simplicity (3 parameters, no output schema), the description covers the essential aspects: purpose, capture options, return values, and default path. It is sufficient for correct invocation, though it could mention error handling or edge cases for completeness.
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 coverage, the description adds meaning by explaining the two capture modes (window/pane) and linking them to parameters. It also mentions the return values, which are not in the schema, providing additional context beyond what the schema offers.
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 captures a PNG screenshot of either the full window or a specific pane, with a specific verb and resource. It distinguishes itself from sibling tools like iyke_click or iyke_open, which serve different purposes, making the tool's function unmistakable.
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 does not provide explicit guidance on when to use this tool versus alternatives, but no alternative screenshot tool exists among siblings. The intended use case is implied by the description (capturing visual state), but no conditions or exclusions are stated.
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 discloses sorting behavior and defaults, but no annotations exist. It lacks details on whether the operation is read-only, destructive, or requires auth, which would be useful for a tool with no 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 sentences, zero waste. Information is front-loaded and 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 no output schema, description mentions sort order but not return fields. For a simple list tool with 2 optional params, it covers most essential information; however, missing output schema leaves some ambiguity about returned timer structure.
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 0%, so description must add meaning. It explains scope's default and status enum values, but does not specify scope's expected format (e.g., project ID). Overall, it partially compensates 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 timers in a scope, defaulting to the active project, with optional status filter, and sorting by fire_at ascending. This distinguishes it from sibling tools like iyke_timer_schedule and iyke_timer_cancel.
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 implies usage for listing timers with optional filtering, and context from sibling tools suggests when not to use it (e.g., for scheduling/cancelling). However, no explicit when-not or alternatives are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the behavioral effect: it stamps completed_at. For a simple tool with no annotations, this adds necessary transparency, though it omits idempotency or error states.
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 front-loaded with the primary action and provides an equivalent alternative; every word adds value.
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?
The description is adequate for a simple single-parameter tool but lacks details on return values, error conditions, or behavior on already-done todos.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The sole parameter 'id' has no description in the schema (0% coverage), and the tool description provides no additional meaning or context about the 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 the action 'Mark a todo as done' on the 'todo' resource, and distinguishes from sibling tools by explicitly noting equivalence to 'iyke_todo_update with status=done'.
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 (to mark a todo as done) and provides an alternative (iyke_todo_update), making usage context very 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?
No annotations provided; description fully carries burden. Discloses that the tool deletes state and leaves current view in place. Lacks mention of auth or error scenarios, but sufficient for the action.
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, front-loaded with action and consequences. 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 simple destructive action with one parameter and no output schema, description covers purpose, effect, and use cases adequately. Missing parameter documentation reduces completeness slightly.
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?
Single parameter 'project_id' has 0% schema description coverage. Description adds no explanation of the parameter, relying on the name alone. Should clarify expected value.
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 'Reset' and resource 'project's saved layout', enumerates specific items deleted (pane tree, files-explorer state, panel sizes), and is distinct from sibling tools like iyke_layout_get.
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 states when to use: 'recover from a wedged layout' or 'clean-slate workflow'. Does not provide explicit exclusions but context is clear enough.
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?
With no annotations, the description carries the full burden. It discloses that the tool triggers a re-dump of the env-vault file, values land in encrypted Stronghold snapshot, and that it is a write operation. Lacks details on auth or rate limits, but covers key behavioral traits.
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, each adding value: purpose, side-effect, and caution. No redundancy, well front-loaded with the main action.
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?
Considering the tool's complexity (secret write with side-effects), the description covers purpose, side-effect, security context, and scoping. It doesn't specify overwrite behavior or return value, but for a write tool with no output schema, it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning no individual parameter descriptions. The description only mentions 'scope' with a reference to sibling semantics, but key and value are not explained beyond their names. This under-documents the parameters given the lack of 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 writes a secret to the vault, provides scope semantics by referencing the sibling iyke_secret_get, and distinguishes from other secret-related tools (get, delete, list). The verb 'Write' and resource 'secret to the vault' are specific.
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 includes a usage advisory ('Use this sparingly') and explains that it triggers a re-dump, providing context for when to use. It does not explicitly list alternatives or when-not scenarios, but the sensitivity and side-effect info guide usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the operation is idempotent (no-op if fired/cancelled) and specifies the return value {cancelled: bool}. This is good transparency for a cancel operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loading the main action. Every sentence adds value: first defines purpose, second adds behavioral nuance and return value. 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 simplicity (1 parameter, no output schema, no annotations), the description covers the core behavior, edge cases, and return type. It could mention error handling or prerequisites, but for a cancel operation it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one required parameter 'id' with no description. The tool description does not explain what 'id' refers to (e.g., timer id from a list) or its format. Since schema coverage is 0%, the description should provide more detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Cancel a pending timer by id', specifying the verb (cancel) and resource (pending timer). It distinguishes from siblings like iyke_timer_schedule and iyke_timer_list.
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 mentions 'No-op if already fired or cancelled', which provides guidance on when it's safe to call. However, it does not explicitly state when to use this tool over alternatives, though the context is clear from the name.
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?
No annotations provided, so description carries full burden. It discloses id handling (bump last_seen_at or mint new), return value (opaque id), and purpose. Lacks details on error handling or permissions, but is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (three sentences) and front-loaded with the core purpose. No extraneous words; every 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 4 parameters, no output schema, and nested objects, the description covers main behavior and return value, linking to related tools. Missing details on model and metadata, but overall completeness is good for a registration 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 50% (descriptions for id and name only). Description adds meaning for id (bump or mint) and name (display name example), but model and metadata are not explained. This partial compensation keeps score at baseline given moderate 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 clearly states the tool registers an agent for lock/timer attribution, returns an opaque id, and explains the id's use with iyke_lock_acquire. It distinguishes the tool's purpose from siblings by focusing on registration.
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 informs when to use (register agent for locks/timers) and how the id is used, linking to iyke_lock_acquire. It does not explicitly state when not to use or alternative methods, but the provided context is sufficient for typical use.
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?
No annotations provided, so description carries full burden. Discloses return structure (preferred_tier + preferred_source) and scope semantics. Lacks details on side effects, idempotency, authentication, or error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with main action, no extraneous information. Every word contributes to understanding.
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 simple schema (1 required param, no output schema), description adequately covers return format and scope options. Minor gaps: no mention of pagination, empty list behavior, or rate limits, but these are typical for a list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% coverage on the only parameter 'scope'. Description adds context beyond schema by explaining the two scope literals and the return fields, adding value for agent decision-making.
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 'List', resource 'Claude-config asset pins', and scope options ('workspace' or 'project:<id>'). Differentiates from sibling tools like 'iyke_claude_asset_pin' and 'iyke_claude_assets_list' by focusing on pins specifically.
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?
Describes valid scope values and what the tool returns. Clear context for use but lacks explicit when-not-to-use or alternatives (e.g., no mention of when to use iyke_claude_asset_pin instead).
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?
No annotations provided, so description carries full burden. It discloses the debug-only behavior and production error, but lacks details on side effects, permissions, or UI impact.
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, front-loaded with action, no redundant 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?
For a no-parameter tool lacking output schema and annotations, the description covers purpose, environment constraint, and error case. Missing minor details like state changes, but adequate.
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?
Input schema has no parameters with 100% coverage; description doesn't need to add param info. Baseline 4 for zero-parameter tools.
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 'Open' and the resource 'Chrome DevTools for the main webview', specifying the debug build constraint and production fallback, which 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 indicates when to use (debug builds) and when not to (production, returns 503), providing clear context though lacking explicit mention of 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?
With no annotations provided, the description carries full burden for behavioral disclosure. It reveals that the tool returns refs that become invalid on subsequent snapshots or navigation, and that it offers filtering via 'query' and 'all' parameters. This covers key behavioral traits but could be enhanced by mentioning any side effects or performance considerations.
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 three sentences that efficiently convey purpose, ref behavior, and parameter usage. It is front-loaded with the primary action and avoids redundant or unnecessary wording.
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 absence of an output schema, the description offers important context: it mentions the return type (Playwright-style text plus structured JSON) and the invalidation of refs. However, it does not detail the JSON structure or the exact format of the return values, which would further aid an agent in understanding the output.
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 67% (two of three parameters described). The description reinforces the schema for 'all' and 'query' but adds no new semantic detail beyond what the schema provides. The 'pane' parameter remains undocumented in both places. With high schema coverage, 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 the tool's action: 'Take an accessibility-tree snapshot of the focused pane.' It specifies the resource (accessibility tree) and distinguishes from sibling tools like iyke_click and iyke_type by explaining that it returns refs for downstream interaction.
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 tells when to use this tool: to obtain stable refs for interactive elements, which can then be passed to iyke_click, iyke_type, or iyke_key. It also mentions that refs invalidate on next snapshot or page navigation, implying when to re-snapshot. However, it does not explicitly state when not to use it or provide direct alternatives for similar tasks.
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?
No annotations provided, so the description carries full burden. It discloses that the tool returns raw layout_state row contents (JSON or null). However, it does not mention error cases, idempotency, or authentication requirements. The behavioral info is adequate but not comprehensive.
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 purpose is front-loaded, and every sentence adds value. Highly efficient.
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 low complexity (1 optional param, no output schema), the description covers return format, default behavior, and a use case. Adequate but could mention potential errors or more about the response structure.
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 0%, but the description adds meaning by explaining that project_id defaults to the active project and is optional. This compensates for the bare schema, providing clear guidance on parameter usage.
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 specific verbs ('Get') and resources ('saved layout'), and lists components (pane tree, files-explorer state, panel sizes). It clearly distinguishes from sibling tools like iyke_layout_reset by focusing on retrieval.
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 notes default behavior (active project) and how to query a specific project. It also mentions a specific use case (conductor pattern). However, it does not explicitly state when not to use this tool or mention alternatives among siblings.
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?
With no annotations, the description fully explains the return states and their conditions, plus the implication of needs_approval triggering a structured error. This is good behavioral context, though it could mention if the tool is read-only or requires permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured paragraph that front-loads the purpose, then lists and explains return values, and finally provides actionable context for one state. 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?
Given the tool's simplicity (1 param, no output schema, no annotations), the description covers the return values, their meanings, and downstream effects. It is complete for a status-checking 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?
The single parameter pkg_id is not described beyond its name. Since schema description coverage is 0%, the description should compensate but only implies its purpose through the tool's function. Adding a brief clarification like 'the package identifier' would improve semantic 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 it retrieves the trust state for a single installed pkg and enumerates four possible return values with explanations. It distinguishes from siblings like iyke_pkg_trust_list, which likely handles multiple packages.
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 that this tool is for checking trust status of one package and provides context on when to use it (e.g., identifying why a package might be blocked). It does not explicitly state when not to use it, but the sibling context implies iyke_pkg_trust_list for bulk checks.
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?
No annotations provided, so description carries full burden. It discloses slug uniqueness, reserved 'default', cwd behavior for root_path, and hex color usage. It does not mention side effects or permissions, but overall fairly transparent.
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, front-loaded with the main action, and uses bullet-like structure. Every 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?
No output schema, but description explains what the tool does and its parameters. It could mention the return value (e.g., created project object) but is still reasonably complete.
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 83%, and description mostly repeats schema info for id, display_name, root_path, color. Some nuance added for root_path (optional but recommended). Icon parameter not mentioned. Baseline 3 is appropriate as description adds marginal value.
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 'Create a new project in the Ikenga shell' and explains that projects scope various surfaces. It clearly distinguishes from sibling tools like update, list, archive, etc.
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 includes 'Use when the user asks to set up a new working context' which provides clear guidance. However, it lacks explicit when-not-to-use or alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses ordering, hidden archives, and parameter effect. However, lacks details on pagination limits, permissions, or auth requirements, which is moderate for a list tool.
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: first states primary behavior and returned fields, second clarifies the parameter. No fluff, every 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?
For a simple list tool with one parameter and no output schema, the description covers ordering, fields, parameter behavior, and use case. Missing pagination details, but that is minor for this scope.
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?
Only one parameter 'include_archived' with 0% schema coverage. Description adds explicit default (false), explanation of behavior, and a concrete use case for when to set true. This compensates fully.
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 'List projects' with ordering specification (position ASC, created_at) and enumerates returned fields. It distinguishes from sibling project tools like create, update, archive, etc.
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?
Context is clear: archived hidden by default, parameter to include them. Provides an example use case 'restoring an old project'. No explicit when-not-to-use or alternative tools, 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?
Discloses that operation is destructive, idempotent (ok for missing key), and does not affect legacy unscoped key. However, no mention of permissions, side effects, or rate limits. With no annotations, description carries burden and does a good job but not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no filler. Front loads the core action, then adds important details (idempotency, legacy behavior). Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers core behavior and idempotency, but lacks parameter documentation for scope and key. No output schema, but description hints at return behavior. Could be more complete by explaining scope semantics inline.
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 has 0% description coverage for parameters. Description mentions 'scope' but does not explain its semantics or allowed values, only references another tool. 'key' is described only as the secret key implicitly. Minimal added value beyond schema itself.
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 'Delete a secret from the given scope' and distinguishes from siblings by noting it does not touch legacy unscoped key, providing specific verb+resource+scope.
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 (delete a secret), notes idempotent behavior (returns ok even if key missing), and gives direct guidance on cleaning up legacy entries by deleting at unscoped key directly.
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?
With no annotations, the description discloses key behaviors: lazy subprocess spawning on first prompt, initial_prompt being informational only. It clearly indicates a write operation (creation). Could additionally mention side effects or constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four sentences long, each sentence contributes unique information. No fluff, front-loaded with 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?
Given no output schema and low schema coverage, the description explains return value (thread_id), parameter behavior (cwd default, initial_prompt limitation), and lifecycle (lazy spawn). Lacks explicit definition of project_id, but overall 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 coverage is 33% (only cwd described in schema). The description adds important context for initial_prompt (informational only) and implies project_id meaning, but does not explicitly describe project_id. It adds moderate 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?
The description uses a specific verb 'Mint' and resource 'new Claude chat thread attached to a project', clearly distinguishing it from sibling session tools like iyke_session_list and iyke_session_move.
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 clear context: after creation, use acp_prompt or open session UI. It also notes that initial_prompt is currently not forwarded. However, it lacks explicit when-not-to-use or 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 clarifies that the tool writes (types) text and describes the default append behavior and replace option. No annotations are provided, so the description carries the full burden. It does not mention error handling or what happens if the element is not found, but the behavior is reasonably transparent.
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 unnecessary words. It front-loads the core purpose and provides key details succinctly.
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 simplicity and lack of output schema, the description covers most essential aspects: target element, how to specify it, text input, and append/replace behavior. It misses an explanation of the pane parameter and does not describe return values, but overall is fairly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% coverage, so the description must add meaning. It explains that ref and selector are mutually exclusive, that replace defaults to false, and the text parameter. However, the pane parameter is not explained, and ref/selector are not described beyond being identifiers.
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 (type text) and the target resources (input/textarea/contenteditable elements). It specifies the targeting mechanism using ref or selector, which distinguishes it from sibling tools like iyke_click or iyke_key.
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 default behavior (append) and how to override it (replace=true). It also states the constraint to specify exactly one of ref or selector. However, it does not explicitly mention when not to use this tool or provide 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?
No annotations exist, so description carries full burden. It discloses the return format ({ satisfied, elapsed_ms, message? }) and implies synchronous, non-destructive waiting. Could add that it blocks until condition or timeout.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with purpose, no redundancy. Every sentence adds value.
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 usage guidance and return shape are helpful, the lack of parameter explanations for the predicate types and timeout makes it incomplete for reliable tool invocation without additional schema descriptions.
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 0%, but description only mentions 'predicate' without explaining the four parameters (kind, value, pane, timeout_ms). The enum values for kind (text, selector, etc.) are left undefined, limiting agent understanding.
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 'Wait until a predicate is satisfied or timeout,' defining the tool's verb and resource. It distinguishes itself from siblings by advising use after iyke_click/iyke_go instead of fixed sleeps.
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 iyke_click/iyke_go to wait for new state to render') and provides an alternative context ('instead of fixed sleeps'), giving clear usage 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?
With no annotations, the description fully discloses the soft-delete nature, data preservation, restrictions on 'Default', and fallback behavior. It could mention idempotency or error states but is still transparent.
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, front-loaded with the core action, and each sentence serves a purpose (soft-delete, effects, constraints, special cases). 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 a single parameter, no output schema, and no annotations, the description covers all necessary behavioral context: soft-delete, data retention, constraint on 'Default', and active project fallback. It is complete for this 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% and the parameter 'id' is described as 'Slug of the project to archive.' The description does not add new semantics beyond what the schema already provides, so 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 defines the tool's action: 'Archive a project (soft-delete — sets archived_at, no data removed).' It uses specific verbs and resource, and distinguishes from sibling tools like iyke_project_update (restore capability) and iyke_project_create/list.
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 it, what happens (project disappears from switcher, data preserved), and edge cases (refuses to archive 'Default', active project fallback). It lacks explicit 'when not to use' but the context is sufficient.
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?
With no annotations, the description carries the transparency burden. It discloses idempotent create/replace, scope defaults, name uniqueness, and 1 MB cap, but does not mention side effects, permissions, or success/error responses.
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 only, no fluff. Front-loaded with purpose, then usage context, then parameter details. Every sentence 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?
Covers purpose, usage, parameters, and constraints (1 MB). Lacks return value description and error conditions, but for a write operation, the provided info is largely sufficient.
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 0%, so description fully compensates. It explains scope defaults (project:<active_id>) and valid overrides ('workspace' or 'pkg:<id>'), name as a unique slug, and body size limit, adding meaning to all three parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates or replaces a project-scoped Markdown scratchpad, with explicit use cases (plans, handoffs, working context). It distinguishes from siblings like read, append, and delete.
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 specifies when to use (for context that outlives a chat) and explains scope behavior, but does not explicitly exclude cases or compare 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?
No annotations are provided, so the description carries the full burden. It discloses key behaviors: OS notification on fire, optional inbox delivery with 24h TTL, and mutual exclusivity of timing params. However, it omits edge cases like error handling, timer persistence, or whether cancellation is possible.
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 primary action, and every sentence adds unique information. No wasted words.
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?
The tool has 6 parameters and no output schema, yet the description does not mention what the tool returns (e.g., timer ID, success status). It also lacks error conditions or validation details. While behavioral aspects are covered, the missing return value info leaves a 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 description coverage is high (83%), so baseline is 3. The description adds value by reinforcing mutual exclusivity of fire_at and delay_ms, clarifying 'one-shot', and elaborating on scope usage. It also explains the effect of agent_id 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 'Schedule a one-shot timer' with a specific verb and resource. It distinguishes from sibling tools like iyke_timer_cancel and iyke_timer_list by emphasizing one-shot nature and scope options.
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 timing options (fire_at vs delay_ms) and scope, providing clear context. However, it lacks explicit when-not-to-use guidance or prerequisites beyond 'active project or specified scope'.
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?
No annotations are provided, so the description carries the full burden. It explains the override mechanism, scoping, and the meaning of preferred_tier and preferred_source. It does not mention persistence or side effects, but covers key behavioral traits.
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, single paragraph, front-loaded with the main action. It uses an example and packs all necessary information without 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 complexity (5 params, no output schema, no annotations), the description is fairly complete. It covers the pinning concept, default behavior, scope, tier, and source. Minor gaps like timing of application are not critical.
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 low (20%, only scope has a description). The description compensates by explaining preferred_tier enum values, preferred_source syntax, and the role of asset_name. It adds significant 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?
The description uses a specific verb 'Pin' and identifies the resource: 'preferred provider for a Claude-config asset name in a scope'. It explains the default behavior (lowest tier wins) and that a pin overrides this, distinguishing it from sibling tools like unpin and list.
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 the tool (to override default lowest-tier selection) and provides context on scope and tier values. It does not explicitly state when not to use it, but the context of siblings makes it 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?
With no annotations, the description carries full burden. It explains that the output is a tree showing conflicts between tiers, and that it defaults to the active project. Good behavioral context beyond a simple 'list'.
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, each serving a distinct purpose: action, output format, defaults/parameter, usage advice. No fluff, 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?
Explains return value structure (tree with AssetSource entries and conflict indication). Lists asset kinds covered. Lacks details on error scenarios or access restrictions, but given no output schema and 0 required params, coverage is reasonable.
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 50% (kind described, project_id not). Description adds meaning: kind filters to one asset kind, project_id queries a specific project. Could be more explicit about project_id format (likely a string ID).
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 lists Claude-config assets (skills, agents, commands, hooks, mcps) discovered for a project, grouped by provider tier. It distinguishes from sibling tools like iyke_claude_asset_list_pins by focusing on discovered assets rather than pinned ones.
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 clear usage context: 'Use this to see what an agent will actually load in a project context.' Mentions defaulting to active project and ability to specify a project_id. Does not explicitly state when not to use or list alternatives, but the 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?
Discloses size caps (64 KB per value, 1 MB per scope) and default scope behavior. No annotations exist, so description carries full burden. Could be improved by mentioning whether existing values are overwritten or the return value on success/failure.
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, no redundancy. Front-loaded with the primary action and key constraints. 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?
Given no output schema and sparse schema descriptions, the description covers the essential behavioral aspects: purpose, size limits, alternative tool, and default scope. A minor gap is the lack of return value description, but for a simple set operation this is 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?
With 0% schema description coverage, the description adds some meaning: 'value' must be a JSON object (implied by 'JSON value'), and 'scope' defaults to active project. However, it does not explain what 'key' should be (e.g., string format) or constraints on 'value' beyond JSON.
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 the tool stores a small JSON value at a scope+key, distinguishing it from sibling tools like iyke_kv_get, iyke_kv_delete, and iyke_kv_list. The verb 'store' and resource 'JSON value' are specific and 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?
Explicitly provides guidance on when not to use this tool: 'For larger durable text, use scratchpads.' Also mentions scope default behavior, helping the agent decide between this 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?
With no annotations, the description carries full burden and discloses key behavior: holder must come from iyke_agent_register, ttl_ms defaults and clamping, and wait_ms blocking behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Five sentences efficiently cover purpose, usage, and key parameter behaviors without fluff, front-loading the core action.
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 5 params, no output schema, and no annotations, the description covers purpose, usage, and most parameter behavior. Missing details on 'scope', 'resource', return value, and error cases, but still fairly complete.
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 0%, so description must compensate. It explains holder, ttl_ms (defaults/clamping), and wait_ms (blocking), but does not clarify 'scope' or 'resource' beyond the name.
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 acquires a project-scoped lease lock on a named resource, which distinguishes it from the sibling tool 'iyke_lock_release' and other coordination 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 provides clear usage context ('short-lived coordination around shared files, plans, migrations') and ties to a sibling ('iyke_agent_register'), but does not explicitly state when not to use or compare to 'iyke_lock_renew'.
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?
With no annotations, the description carries full burden. It discloses that panes are not navigated, that existing queries refetch automatically, and that the tool fails on unknown/archived ids. The term 'phase-2/6-aware surface' is unclear but adds nuance.
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, no wasted words. The core action is in the first sentence, followed by effects and limitations. Efficiently 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 no output schema, the description covers changes, side effects, and failure. It does not describe the return value on success, but the tool is simple enough that this is acceptable. Distinguishes well among many sibling tools.
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% with param description 'Slug of an existing, non-archived project.' The tool description reinforces this and adds behavioral context (fails if unknown/archived), going 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 verb 'Switch' and the resource 'the shell's active project'. It specifies what the change affects (new chats, scratchpads, todos, pkg installs) and distinguishes from sibling tools like iyke_project_get_active by focusing on setting rather than getting.
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 clear context: when to use (to change active project), what happens after (refetch, defaults), and failure conditions (unknown/archived id). It does not explicitly name alternatives like iyke_project_get_active but implies the use case.
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?
With no annotations provided, the description carries full burden. It thoroughly discloses the return structure (name×source pair, source tier, provider, lifecycle, live state, source file path) and parameter behavior. It does not mention authentication or rate limits, but for a read-only list operation, the disclosure is sufficient.
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 fairly concise while packing in essential details about return fields and usage. It starts with the core action and then lists specifics. A small reduction could be made, but overall it is well-structured and 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?
Given no output schema, the description provides a comprehensive explanation of the return format, covering all key fields. The tool has only one optional parameter, and the description fully explains its use. The behavior is completely described for a list operation.
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 description coverage is 0%, but the description adds clear meaning for the single parameter project_id, stating it is optional and defaults to the active project. This fully explains the parameter's role.
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 lists MCP servers visible from a project, specifying the exact resource and verb. It distinguishes itself by noting that it returns pairs to surface conflicts across tiers, which adds specificity beyond a simple list.
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 default behavior (active project) and how to query a specific project via project_id. However, it does not explicitly contrast with sibling tools or provide when-not-to-use guidance, though the unique purpose (listing MCP servers) is clear among many siblings.
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?
With no annotations provided, the description fully bears the behavioral disclosure burden. It discloses that the tool returns rows newest-first, only shell.execute denials currently write here, and the limit cap. No destructive actions are implied, but authentication needs are not mentioned, which lowers the score from 5 to 4.
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 dense paragraph with no wasted words, but it could be slightly more structured (e.g., bullet points for return fields). It earns its place with high information density.
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 no output schema, the description enumerates all return fields (attempted, declared, scope_kind, pkg_id, occurred_at) and explains the scope of data (only shell.execute denials). This is complete for a list 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?
Schema coverage is 0%, yet the description fully explains both parameters: limit defaults to 100 with a hard cap of 1000, and pkg_id filters to a specific package. This adds significant meaning beyond the bare type declarations.
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 lists kernel-level permission-violation audit rows newest-first, specifying the resource (audit rows) and the verb (list). It distinguishes from siblings like iyke_pkg_list by focusing on violations rather than packages.
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 pkg_id (filter to one package) and the limit behavior, but does not explicitly state when not to use this tool versus alternatives. However, the context implies it's for auditing specific violations, which is sufficiently 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?
No annotations provided, but description implies read-only by stating 'Return'. Lists returned fields clearly, though does not explicitly declare side effects or auth needs. Adequate for a simple getter.
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 result fields then usage guidance. Every sentence earns its place.
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?
Lists returned fields compensating for no output schema. Provides usage context. Complete for a simple read tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist; schema coverage is 100% trivially. Description does not need to add param info, baseline for 0 params is 4.
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 the tool returns the currently active project and lists the fields returned. Distinguishes from sibling by naming iyke_project_set_active.
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 it: before iyke_project_set_active or any project-scoped mutation. Provides clear context but does not mention 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?
No annotations provided, so description carries the full burden. Discloses key behaviors: defaulting to focused pane, directional split, and a system cap. Lacks details on reversibility or permissions, but adequate for the tool's simplicity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no filler. First sentence introduces action and optional parameter; second sentence clarifies direction semantics and constraint. Information is front-loaded.
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?
For a simple 2-parameter split tool with no output schema, the description covers all critical aspects: purpose, parameter usage, direction semantics, and a system constraint. No gaps identified.
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 beyond schema: explains pane_id default behavior ('Defaults to focused pane') and visualizes directional effects ('side-by-side' vs 'top-bottom'). Schema only provides enum for direction but no description; 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?
Clearly states 'Split the focused pane (or a specific pane via pane_id) into two' with explicit directional meanings. Unambiguous verb-resource pair; no sibling tool duplicates this functionality.
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 a concrete constraint ('Subject to the in-app MAX_LEAVES cap (currently 6)') that guides when to use. Could explicitly state when not to use (e.g., when max leaves would be exceeded), but the cap is clearly mentioned.
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?
No annotations provided, so description carries full burden. It details the structure of shell.panes (leaves with id, focused, activeTabIdx, tabs) and explains how to use the output (e.g., use leaves[].id with specific tools). It does not mention destructive actions or auth needs, but as a read-only state getter, the behavioral disclosure is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is three sentences, front-loaded with purpose, then output shape, then usage guidance. Every sentence adds value with no redundancy. Highly 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?
Considering no output schema, the description provides a thorough breakdown of the return value shape and how to use it with sibling tools. It fully explains the state structure and usage context, making it 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.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0 parameters with 100% coverage, so description need not add parameter info. Baseline 4 applies; description adds no param details but that is appropriate given no parameters exist.
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 'Get the current state of the Ikenga desktop app' with specific components (sidebar mode, focused pane route, pane tree). It distinguishes from sibling tools by indicating it should be called before iyke_go/iyke_mode/iyke_focus/iyke_close, giving a clear resource and usage context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Call this before iyke_go / iyke_mode / iyke_focus / iyke_close to check what the user is currently looking at,' providing clear guidance on when to use. No explicit when-not-to-use, but the instruction implies a prerequisite role, which is sufficient for a read-only state 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?
With no annotations, the description fully carries the burden. It discloses that changing scope triggers a kernel reconcile and causes sidecars to start/stop accordingly. This gives the agent clear behavioral expectations for the tool's 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 crisp sentences cover purpose, parameters, and side effects without unnecessary detail. Every word adds value, making it highly efficient for an AI agent to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple scope-change tool with no output schema, the description is fairly complete. It explains the scope parameter and side effects. However, it doesn't specify the format of pkg_id or how to obtain it, which would be helpful but is not critical given the context.
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 explanation of the 'scope' parameter adds significant meaning beyond the schema, detailing the exact format and effect. The 'pkg_id' parameter is mentioned but not elaborated, though its role is inferable from context. Given 0% schema coverage, the description compensates well.
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: 'Change the scope of an installed pkg.' It specifies the two valid scope values ('workspace' and 'project:<id>') and their meanings, which distinguishes it from sibling tools like iyke_pkg_uninstall or iyke_pkg_list.
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 scope options and their behavioral implications, guiding when each scope should be used. However, it does not explicitly state when to use this tool over alternatives or provide any exclusions, leaving a slight gap in 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?
No annotations provided, so description carries full burden. It discloses patch semantics, null clearing for nullable fields, and position ordering. Lacks details on return value or potential side effects, but mutation nature is clear.
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 no superfluous words. Sentences are well-structured: purpose first, then specific behaviors, and a key exclusion (id immutability).
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 no output schema, description doesn't explain return values. It covers key behavioral aspects but omits error cases or prerequisites. Still, it is fairly complete for an update operation in this toolset.
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 50% (only id has description). Description adds value by explaining patch object semantics, which fields are nullable, and position meaning. However, it doesn't describe each property individually (e.g., display_name).
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 patches fields on an existing project, distinguishing it from sibling tools like create or archive. It explains partial update semantics and explicitly notes the immutable id field.
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 on when to use (patch existing project) and when not to (cannot change id; suggests creating and migrating instead). This helps the agent choose appropriately among siblings.
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?
With no annotations provided, the description fully discloses behavior: returns null for missing keys, falls back to legacy unscoped key with a deprecation log. It implies no destructive actions (read-only), which is consistent with the tool name.
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—four sentences that front-load the main purpose and then add necessary details. 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.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description covers return values (string or null) and fallback mechanics. It does not mention potential errors (e.g., invalid scope format), but it is sufficiently complete for a read tool with clear scope semantics.
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 0%, so the description must compensate. It thoroughly explains the 'scope' parameter with valid values and usage. However, the 'key' parameter, though required, is not elaborated beyond being a string; no format or constraints are given.
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 a secret from the vault, specifying the action (read) and resource (secret). It also differentiates from related sibling tools like iyke_secret_set or iyke_secret_delete by explicitly calling it a read operation.
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 detailed guidance on using the scope parameter: omitting it for active project, 'workspace' for shared secrets, and specific partition identifiers. It also explains fallback behavior. However, it does not explicitly state when not to use this tool or compare with alternatives like iyke_secret_list.
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?
With no annotations, the description fully covers behavior: default limit (50), max (200), and return fields. It implies read-only operation (listing) and provides output structure. 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?
Three sentences, each earning its place: purpose, filtering usage, and return details. No fluff, front-loaded with action.
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 no output schema, description includes return fields. Covers purpose, parameters, limits, and output. Minor omission: no mention of ordering or pagination, but adequate for the tool's simplicity.
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 describes 2 of 3 parameters; description adds meaning for 'limit' (default/max) and clarifies 'project_id' ('defaults to active'). Adds value beyond schema, especially for limit behavior.
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 'List Claude chat sessions' with specific filtering options (project, include_all). It distinguishes from sibling tools like iyke_session_move and iyke_session_start_in_project by focusing on listing.
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 include_all (to list across all projects) and defaults (active project). It lacks explicit alternatives or when-not-to-use guidance, 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?
With no annotations provided, the description bears full responsibility. It discloses that closing a pane also closes all its tabs and that the last pane cannot be closed. While it doesn't detail side effects like unsaved changes, the disclosure is sufficient for the tool's simplicity.
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, with no extraneous information. It front-loads the core action and follows with key usage notes, making it concise and well-structured.
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?
For a simple tool with one optional parameter and no output schema, the description is complete. It explains the action, the alternative for single tabs, and a constraint (refusing to close the last pane). No gaps are evident.
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 input schema has 100% coverage with one optional parameter. The description adds meaning by stating that the default is the focused pane, which goes beyond the schema's minimal description. This effectively clarifies the parameter's behavior.
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 'close' and the resource 'pane', specifying that it closes the entire pane and all its tabs. It also distinguishes from closing a single tab via keyboard shortcuts, providing clarity amidst sibling tools like iyke_focus and iyke_split.
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 provides a when-not-to-use case: 'to close a single tab from the in-app keyboard, use ⌘⇧W (⌘W closes the whole pane).' It also notes that it refuses to close the last remaining pane, giving clear usage boundaries.
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?
No annotations are provided, so the description carries the full burden. It discloses the key behavioral trait: it replaces the focused pane's active tab content. This is adequate for a navigation tool, though it could mention reversibility or 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 the main action front-loaded. No extraneous information; every sentence contributes meaning.
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?
For a simple tool with one parameter and no output schema, the description fully covers purpose, usage, and behavioral distinction. 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 coverage is 100% for the single 'path' parameter, which describes it as a route path starting with '/'. The description adds an example and emphasizes the leading slash, providing marginal additional value 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 navigates the focused pane to a route path within the Ikenga app, with an example. It distinguishes from the sibling iyke_open tool by specifying that this replaces rather than adds a tab.
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 on when to use this tool versus iyke_open with kind=route. States that path must start with '/'. Provides clear context for when to choose this tool.
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:

[![ikenga-pkg-mcp-iyke MCP server](https://glama.ai/mcp/servers/Royalti-io/ikenga-pkg-mcp-iyke/badges/card.svg)](https://glama.ai/mcp/servers/Royalti-io/ikenga-pkg-mcp-iyke)

Score Badge

Copy to your README.md:

[![ikenga-pkg-mcp-iyke MCP server](https://glama.ai/mcp/servers/Royalti-io/ikenga-pkg-mcp-iyke/badges/score.svg)](https://glama.ai/mcp/servers/Royalti-io/ikenga-pkg-mcp-iyke)

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/Royalti-io/ikenga-pkg-mcp-iyke'

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