CodeAgent MCP

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation5/5
Each tool targets a distinct resource and action, with clear domain prefixes (workspace, fs, browser, visual, ops, git, project, terminal). The only similar pair, fs_write_binary and fs_write_file, is distinguished by input source (Base64 vs host file reference). No two tools have ambiguous boundaries.
Naming Consistency5/5
All tool names use lowercase snake_case with a consistent domain_prefix_verb_noun pattern (e.g., fs_read, browser_open, terminal_create). Minor deviations like workspace_acquire (noun-verb) are negligible and do not break the overall predictable style.
Tool Count2/5
At 39 tools, the server is well beyond the 3-15 tool sweet spot and even exceeds the 25+ 'too many' threshold. While the broad domain coverage (filesystem, git, terminal, browser, visual) justifies some volume, the sheer count risks overwhelming agents and suggests possible consolidation.
Completeness4/5
The toolset covers the full lifecycle for a coding agent: workspace leases, execution, file read/write/patch, git status/diff, terminal management, browser automation, visual capture/compare, and project orientation. Minor gaps like file deletion or git commit/push are addressable via exec_run, so they do not create dead ends.
Average 4.1/5 across 39 of 39 tools scored. Lowest: 2.6/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 25 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
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?
The description adds little beyond the annotations. Annotations already indicate readOnlyHint=false, openWorldHint=false, idempotentHint=false, and destructiveHint=false. The description only adds 'Requires lease_id,' which is already in the input schema. It does not disclose potential side effects, prerequisites beyond the lease_id, or error behavior, so behavioral transparency is minimal.
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 very brief, which is good, but it includes an enum list that duplicates the schema. It lacks structural organization (e.g., sections for usage, parameters, behavior). It is concise but not optimally structured, and some text (the enum list) adds no value beyond the schema.
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?
The tool has four parameters and an output schema, but the description only covers two parameters and does not explain the optional 'alias' and 'pane_id' parameters. It also does not mention the output or any return semantics, though the output schema might cover that. Given the complexity and low schema coverage, the description is 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 description coverage is 0%, so the description must compensate. It only mentions the 'key' parameter by listing its enum values (redundant with the schema) and states that 'lease_id' is required (also in schema). It completely ignores the optional 'alias' and 'pane_id' parameters, providing no meaning for them, and fails to add contextual detail to the required parameters.
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 a specific verb and resource: 'Send a special key to a terminal.' It also enumerates the allowed key values, which adds scope. However, it does not explicitly distinguish itself from sibling tools like terminal_write or terminal_interrupt, so it misses the top score for sibling differentiation.
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 guidance on when to use this tool versus alternatives. It only states that a lease_id is required, which is a prerequisite, not usage context. There is no mention of when special keys are appropriate or when to prefer other terminal tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Contradiction with annotations: description says 'Destroy a terminal pane' (destructive action) while annotations set destructiveHint=false. This is a serious inconsistency. The additional context about 'Active project lease may reclaim orphans' adds value, but the contradiction forces a score of 1.
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?
Three concise sentences front-load the main action and scope. Each sentence adds information (destroy, reclaim orphans, not tmux). The second sentence is slightly cryptic but not wasteful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite an output schema, the description lacks parameter semantics and usage guidance. The contradiction with annotations further reduces reliability. It covers the core action but leaves significant gaps for a 3-parameter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It only hints at lease_id via 'Active project lease', but does not explain alias, pane_id, or lease_id roles. This leaves the agent without enough information to correctly populate parameters for the intended target.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the action with a specific verb ('Destroy') and resource ('terminal pane'), and adds 'drop its registry entry' to define the outcome. It distinguishes from siblings like terminal_interrupt and terminal_reset by focusing on destruction/removal, and explicitly notes it does not kill the tmux server.
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 when a terminal pane should be destroyed, but it does not explicitly state when to use this over alternatives like terminal_interrupt or terminal_reset. It provides a negative scope ('Does not kill the tmux server') but no exclusions or alternative tool references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that it closes an existing alias and creates a fresh terminal, which is a destructive/mutating action. However, the annotations declare destructiveHint: false, implying the tool is not destructive. This directly contradicts the described behavior of closing a terminal, which can kill running processes. Therefore, the description contradicts the annotations, violating transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one sentence explaining the operation followed by a brief usage note. It front-loads the key action and adds only essential context. No superfluous wording, making it easy to parse.
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 provides useful context about when to use the tool (after SESSION_DEAD or to reclaim) and outlines the core behavior. However, it omits critical context about the required lease_id parameter, the meaning of 'reclaim', and how the optional cwd parameter behaves relative to the fresh terminal. The presence of an output schema reduces the need to explain return values, so this score reflects the remaining gaps.
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 for its three parameters (lease_id, alias, cwd). The description only clarifies the meaning of 'alias' (the terminal alias to reuse) but provides no explanation for lease_id or cwd. This is insufficient for the agent to understand all required inputs, especially lease_id which is required and not described.
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 operation: close an existing alias if present, then create a fresh terminal with the same alias. It specifies the resource (terminal) and the action sequence, and distinguishes itself from terminal_create or terminal_close by combining both steps. The usage context 'after SESSION_DEAD or to reclaim' further clarifies its specific role.
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 usage context: 'Use after SESSION_DEAD or to reclaim.' This tells the agent when to invoke this tool, setting it apart from alternatives like terminal_create or terminal_close. However, it does not explicitly list exclusions or mention when not to use it, so it misses a small part of full guidelines.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states 'Idempotent' while annotations set idempotentHint=false, which is a direct contradiction. This is a serious inconsistency that undermines trust in the tool's behavioral metadata.
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, all essential: action, idempotency, side effects, and a misuse caution. 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 one-parameter tool, the description covers purpose, side effects, and safety considerations. However, the contradiction with annotations and lack of error-case detail keep it from a perfect score.
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?
Only 'lease_id' is mentioned by name, with no additional meaning beyond the schema. With 0% schema description coverage and one parameter, the description fails to compensate by explaining the format, source, or behavior related to the lease_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 action ('Release an exclusive workspace lease') with a specific resource and identifier ('by lease_id'). It distinguishes itself from sibling tools like workspace_acquire and workspace_status.
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 context on use (release a lease) and a critical caution ('Do not use to steal another writer's lease unless you possess their lease_id'). It does not explicitly name alternatives, but the when-not-to-use guidance is valuable.
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 annotations offer no safety hints (all false), so the description must carry the burden. It adds context like 'bounded action' and 'usually a CSS selector,' which hints at behavior. However, it does not disclose side effects, failure modes, or return value expectations, so it falls short of being highly 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 a single, well-structured sentence that front-loads the action list and includes the key prerequisite (lease_id). It is concise with no superfluous information.
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?
Even with an output schema present, the tool is complex (6 params, 0% schema coverage). The description omits critical details about parameters like key/value and timeout_ms, prerequisites for specific actions (e.g., wait may not need a selector), and expected outcomes, making it incomplete for reliable invocation.
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 6 parameters with 0% description coverage. The description only mentions lease_id and selector, leaving key, value, timeout_ms, and action semantics (beyond the enum) unexplained. This does not adequately compensate for 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 performs one bounded browser action and enumerates the specific action types (click, fill, press, select, wait). This distinguishes it from sibling tools like browser_open and browser_snapshot, which handle navigation and state capture respectively.
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 implies usage when an agent has an active lease and needs to interact with a page by specifying 'Requires lease_id and usually a CSS selector.' It provides clear context but does not explicitly mention alternatives or exclusions (e.g., when to prefer browser_snapshot for reading the page).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond annotations by specifying viewport defaults (1280x720), the requirement for lease_id, non-durability across MCP process death, and loopback isolation. Since annotations are all false and provide no hint, these details add significant operational context without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences long, front-loading the primary purpose, then adding essential parameter defaults and caveats. Every sentence contributes value, with no redundant phrasing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Core behavior and caveats are covered, but the description does not explain the origin/role of lease_id (presumably workspace_acquire) or the semantics of force. Given the low schema coverage and the presence of an output schema, these omissions leave the description only moderately 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 0%, so the description must compensate. It explains width and height with defaults, and notes lease_id as required, but entirely omits the force parameter. This is a notable gap given the absence of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool starts or reuses an isolated headless Chromium session with loopback browsing. It distinguishes from visual_capture but does not explicitly contrast with browser_open, which could cause slight ambiguity. The core purpose is still 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 that screenshots belong to visual_capture and that the session is not durable unlike tmux, providing some exclusions. However, it does not explicitly state when to use this tool versus browser_open or other browser siblings, nor that it should be called before using browser actions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is a write operation (readOnlyHint=false) and not destructive. The description adds useful context by explaining the CDP mechanism for ignore_cache and the lease_id requirement. However, it does not disclose potential side effects like page state reset or network implications beyond the cache, so it is adequate but not exceptional.
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 clause serves a purpose. It explains the key parameter and a prerequisite without any fluff, making it highly 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 reload tool, the description covers the main action and an important parameter, but it omits semantics for timeout_ms and does not mention what the return value or output schema contains. Given the tool's simplicity, this is an average level of completeness; more detail on timeout_ms would push it higher.
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. It explicitly explains ignore_cache and notes that lease_id is required, but timeout_ms is completely ignored. With three parameters, leaving one entirely unexplained is a notable gap, though the other two are handled.
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 'Reload' and identifies the resource as 'the current page', making the tool's purpose unambiguous. It clearly distinguishes itself from sibling tools like browser_open and browser_action by focusing solely on reloading the page.
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 clearly states the action and offers guidance on using ignore_cache for a hard reload. It does not explicitly mention when to use this tool over alternatives, but the use case is inherently clear for a reload operation, so it earns a strong score despite lacking explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide no safety hints (all false), so the description must disclose behavioral details. It adds the max 3840x2160 limit and the need for lease_id, but does not clarify side effects, persistence, or interaction with browser state (e.g., whether it affects subsequent snapshots or actions).
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, front-loaded sentence that wastes no words. Every clause adds information: action, scope, integer nature, max constraint, and prerequisite.
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 viewport setter, the description covers the essential behavior and constraint. The existence of an output schema likely handles return values. However, it does not mention edge cases like invalid dimensions or the need for an active session beyond lease_id, which might be relevant.
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 zero descriptions for parameters, so the description must compensate. It explains width/height are integers and sets a max, and reminds about lease_id, but does not elaborate on units or semantics beyond the obvious. The max constraint is useful, but the description largely restates schema requirements (lease_id is already marked required).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sets an arbitrary viewport size on the current browser session, with a specific verb (Set), resource (viewport size), and scope (current browser session). It also adds the max dimension constraint, distinguishing it from related browser tools like browser_action or browser_open.
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 is for changing viewport dimensions on an active browser session, but it does not explicitly state when to use this tool versus alternatives, nor does it mention exclusions (e.g., if the browser is not open). The requirement for lease_id is mentioned, but no guidance on session prerequisites is given beyond that.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds valuable context beyond annotations: 'Paths cannot escape the root' and 'lease_id optional', giving behavioral security and invocation context. It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with the primary action. Every word adds value: verb, resource, scope, safety, and constraint. No fluff or 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?
The tool has an output schema, so return values are covered. However, the description omits critical operational details such as how max_entries behaves, what project defaults are, and the semantics of lease_id. Given the moderate complexity (4 params) and zero schema descriptions, the description is only partially 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 compensate for parameter meaning. It only mentions 'lease_id optional' and that paths cannot escape the root. It does not explain the purpose of path, project, or max_entries (e.g., what max_entries limits or what project refers to). This is insufficient given zero schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists directory entries under a registered project root, using a specific verb and resource. It also adds important scope constraints (project root, cannot escape root) that distinguish it from sibling file tools like fs_read or fs_search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for listing directories but does not explicitly state when to prefer this over alternatives like fs_read or fs_search. It provides context (project root, read-only) but lacks exclusion or alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so safety is covered. The description adds valuable behavior beyond annotations: 'no symlink follow', 'max_matches capped', and 'supports literal or regex query'. These disclose important operational 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 two sentences, front-loaded with the core purpose, and every sentence adds value. No filler words or redundancy with the schema.
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 7 parameters and an output schema, but the description does not explain several parameters (glob, path, project). While safety and core search behavior are covered, the missing parameter context makes it less complete for effective invocation. Output schema existence reduces the need for return-value explanation, but the parameter gaps remain.
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 compensate for parameter meanings. It explains 'literal or regex query' (literal parameter) and 'max_matches capped' (max_matches), but does not explain 'glob', 'path', or 'project' parameters, leaving key filtering options ambiguous. The description only partially fulfills the compensation burden.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Search file contents under the project root' with a specific verb and resource, and distinguishes it from sibling tools like fs_read (read a file) and fs_list (list files). The mention of 'ripgrep' and 'no symlink follow' further specifies the exact operation.
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 (for content search) but does not explicitly contrast it with alternatives or state when not to use it. The 'supports literal or regex query' hints at use cases, but there is no explicit exclusion or alternative naming.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are all false, offering no positive safety hints. The description adds the useful distinction that it sends TTY-level Ctrl+C rather than a signal to the PID, and notes the lease_id requirement. It does not disclose error behaviors, side effects, or idempotency details, so it 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?
The description is one concise sentence, front-loaded with the primary action and includes a non-obvious caveat. Every word adds value, and there is no 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?
An output schema exists, so return values needn't be described. The description covers the core action and prerequisite. However, given the tool belongs to a terminal family and has three parameters with no schema descriptions, more context about when to use it (e.g., for a running process) and how pane selection works would improve completeness.
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 should compensate. It only mentions 'pane' (likely mapping to pane_id) and states the lease_id requirement, which is already in the schema. It offers no explanation for alias or the relationship between alias and pane_id, leaving significant gaps.
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: 'Send TTY Ctrl+C to the pane' — a specific verb, resource, and action. It also distinguishes itself from an alternative ('not kill -INT to pane_pid'), which aligns with the sibling 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?
The description gives a clear context (sending Ctrl+C to the pane) and an explicit exclusion ('not kill -INT to pane_pid'), implying when to use it versus process-level kill. However, it does not name alternative tools like terminal_key or terminal_write, so it falls short of thorough guidance.
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 annotations are all false, so they don't provide a strong safety profile. The description adds that the tool 'Returns metrics + a highlighted diff image' and notes the size-matching requirement, which is useful. However, it doesn't disclose whether the operation has side effects or how it uses the lease, leaving some behavioral ambiguity.
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, using four short sentences each delivering a distinct piece of essential information: action, return value, constraint, and prerequisite. There is no wasted wording, and the primary verb is front-loaded.
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 no output schema, the description conveys the main return value (metrics + diff image) and key constraints. However, it omits any explanation of the threshold parameter and doesn't detail what metrics are returned, which leaves some gaps. Given the tool's moderate complexity, a slightly richer description would be more 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 0%, so the description must compensate. It clarifies that lease_id is required and that artifact_id_a and artifact_id_b are the two PNG artifacts. However, the threshold parameter is not mentioned at all, leaving its meaning undocumented. Since the description doesn't cover all parameters, it only partially compensates for the schema's lack of 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 'Pixel-diff two PNG artifacts,' which clearly identifies the specific verb (pixel-diff) and resource (two PNG artifacts). This distinguishes it from sibling tools like visual_capture and visual_get, and the mention of returning metrics and a diff image further clarifies the purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context by stating 'Sizes must match' and 'Requires lease_id,' which are important preconditions for use. However, it doesn't explicitly say when not to use this tool or name alternative tools, so it doesn't fully cover exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is covered. The description adds valuable behavior: tmux metadata only, returns SESSION_DEAD if shell exited, and that output is via terminal_read/snapshot. This goes beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with the primary purpose and key distinction. No filler; 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?
An output schema exists, so return values need not be described fully. The description covers the core behavior and edge case (SESSION_DEAD), but leaves lease_id undocumented and does not clarify how pane_id/alias interact with lease_id. This is a noticeable gap for a tool with three parameters, though the tool is simple.
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 mentions pane_id and alias but omits the required lease_id, which is puzzling since lease_id is the only required parameter. The relationship between lease_id and the optional identifiers is unclear, leaving a gap in selecting and invoking the tool 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 it returns the status of one terminal by pane_id or alias, with a specific detail (metadata only, SESSION_DEAD). It distinguishes from siblings like terminal_list (lists all) and terminal_read (reads output).
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 'Status of one terminal' implies use when you need status for a specific terminal, and it mentions output via terminal_read/snapshot, giving a sense of where to get the actual output. However, it does not explicitly state when not to use it or contrast with alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only and idempotent behavior. The description adds valuable context beyond annotations by mentioning the accessibility tree is capped, includes console and page errors, and explicitly excludes screenshots. This improves the agent's understanding of scope and output limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words. The purpose is front-loaded, specifics follow, and the alternative is clearly noted. 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?
Given the output schema and annotations, the description sufficiently covers purpose, scope, and constraints. It mentions the lease requirement and the no-screenshot boundary. It could be more complete by mentioning when to use it in a workflow, but that is not necessary for this simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It only restates that lease_id is required without explaining its purpose, format, or relationship to workspace acquisition. This provides minimal value beyond the schema's required field list.
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 identifies the tool as producing a structured page summary with specific contents (DOM highlights, accessibility tree, errors). It explicitly differentiates from the sibling visual_capture by noting 'No screenshots (use visual_capture)', which removes ambiguity.
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 alternative for screenshots and states a prerequisite (requires lease_id), which implies when to use the tool. However, it does not explicitly describe when not to use it or compare it with other browser-related tools like browser_action or visual_get.
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?
Beyond the annotations (readOnlyHint, idempotentHint), the description adds behavioral constraints: it returns only metadata, never executes anything, and does not include skill bodies. It also specifies the known roots scanned. This contextualizes the read-only nature without contradicting annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences are front-loaded with the core purpose, followed by essential exclusions. There is no redundant phrasing or filler.
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, an output schema, and strong annotations, the description covers the key aspects: what is listed, where roots are, what is excluded, and read-only behavior. It leaves no critical ambiguity for a straightforward listing tool, though it could explain lease_id's role.
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 two parameters with defaults but zero descriptions. The description only notes 'lease_id optional' and provides no explanation of what lease_id affects or how project selects the workspace. With 0% schema coverage, the description fails to compensate for the missing parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb phrase ('List Agent Skills manifests under known roots') and clarifies scope ('under known roots (.claude/.cursor/.agents/.codex skills)'). It also distinguishes from project_skill_read by explicitly noting 'Metadata only — no SKILL.md bodies.'
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 clearly states what the tool does not do ('Does not execute skills, !command, or scripts' and 'no SKILL.md bodies'), which implies when not to use it. However, it does not explicitly name alternative tools for those cases, so it misses the highest bar.
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 a key behavioral trait: it sends literal text without an implicit Enter, which is not captured by the annotations. It also highlights the need for a lease_id. Since annotations only indicate non-read-only, non-idempotent, non-destructive, this extra context adds meaningful transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two compact sentences with no fluff. Front-loaded with the primary action, it effectively communicates the core behavior and a critical alternative in a well-structured manner.
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 the presence of an output schema, the description covers the essential behavior, submission method, and a prerequisite. However, it omits explanations for alias and pane_id, leaving some ambiguity in optional parameters. Overall, it is adequate for a basic write operation.
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, so the description must compensate. It clarifies that text is literal text and that lease_id is required, but leaves alias and pane_id completely unexplained. With four parameters, this is insufficient for an agent to correctly populate all fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: "Send literal text to a terminal." It distinguishes itself from sibling tools by explicitly noting no implicit Enter and referencing terminal_key(ENTER) for submission, making the tool's purpose clear and unique.
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 guidance on when to use this tool versus alternatives by stating "Use terminal_key(ENTER) to submit," which directs the agent to a specific sibling tool for key input. It also includes a prerequisite (Requires lease_id), but does not explicitly mention other exclusions or contexts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, so the bar is lower. The description adds value by disclosing the return content, capping behavior, lease renewal, and path constraint—context beyond the structured annotations. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with the core purpose, and every sentence provides necessary info without waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present and strong annotations, the description covers purpose, return content, constraints, and lease behavior. It is complete for the tool's complexity, though it could briefly mention project registration requirements.
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 description carries the burden. It clarifies `path` (must stay under root) and `lease_id` (renews if provided), and implies `max_entries` with 'capped.' However, `project` and the exact relationship between `max_entries` and the cap are not explicitly stated, leaving room for ambiguity.
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 a specific verb and resource: 'Structured read-only git status for a registered project root.' It enumerates the returned data (branch, upstream ahead/behind, staged/unstaged/untracked entries), which distinguishes it from siblings like git_diff or workspace_status.
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 gives clear context: it is read-only, for a registered project root, and path must stay under the root. It does not explicitly name alternative tools, but the constraints and read-only nature provide enough guidance for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, non-destructive, idempotent behavior. The description adds valuable context beyond these: it does not return full rule/skill bodies, lease_id is optional, and repo content is untrusted. This security warning and the limitation on return content are significant behavioral disclosures not present in annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences front-load the purpose, followed by a limitation, a side-effect note, and a security warning. Every sentence carries essential information with no redundancy or excessive detail.
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 tool's purpose, limitations, safety profile, and security stance, which is strong. However, parameter semantics for 'paths' and 'project' remain ambiguous, which is a critical gap for correct invocation. The presence of an output schema mitigates the need to describe return values, but the parameter ambiguity prevents a higher score.
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 clarifies that lease_id is optional. It does not explain the meaning or usage of 'paths' or 'project', leaving the agent to infer them from the tool name and defaults. With three parameters and no schema descriptions, the description must compensate more but only touches one 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 opens with 'First orientation for a registered project' and enumerates specific contents (instruction manifests, skill manifests, VCS summary, warnings, recommended_reads). It explicitly distinguishes itself from related sibling tools by stating 'Does not return full rule/skill bodies', making it clear this is a summary orientation rather than a detailed retrieval tool.
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 phrase 'First orientation' implies use when initially working with a project, and the statement that it does not return full rule/skill bodies hints that other tools (like project_instructions or project_skill_read) are for those details. However, it does not explicitly name alternatives or provide when-not-to-use conditions, so it falls just short of full guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are all false, so they provide no safety or behavior info. The description adds important behavioral traits: persistence, dedicated tmux socket, survival across MCP restarts, and a per-lease limit. These go beyond the annotations and help the agent anticipate 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 only five short sentences, each delivering distinct value: purpose, requirement, alias recommendation, limit, and persistence. No filler or repetition. The most important sentence comes first, making it easy to scan.
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 moderate complexity (3 params, output schema), the description covers purpose, prerequisites, usage limit, and lifecycle behavior. Missing details like cwd semantics and what happens on limit violation are minor, and output schema covers return values. Overall adequate and well-rounded.
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 description must compensate. It explains lease_id as a required identifier and recommends specific values for alias. However, it does not mention cwd at all, leaving that parameter's meaning unclear. Partial compensation but a notable gap for a third 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 begins with a specific verb and resource: 'Create a persistent bash PTY under the dedicated tmux socket.' This clearly distinguishes it from sibling tools like terminal_read or terminal_write. It also includes key constraints (requires lease_id, max 3 per lease) that further define its purpose.
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 prerequisites ('Requires lease_id'), usage limits ('Max 3 per lease'), and naming conventions ('Aliases main/app/debug recommended'). While it does not explicitly contrast with alternatives like terminal_list or terminal_close, the context of creating a persistent session is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds valuable behavioral context beyond annotations: ANSI sanitization, cursor advancement over raw bytes, and the lease_id requirement. It doesn't cover all edge cases (e.g., retention limits, invalid lease behavior) but significantly enriches the safety profile provided by annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three concise sentences, front-loading the main action and then providing essential details in a logical order. Every sentence adds value—no repetition, filler, or unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists, return values don't need explanation. The description covers the core mechanics (cursor, lease, sanitization) and is well-aligned with annotations. It misses details about retention behavior and optional parameter roles, but for a read operation with strong annotations and schema, it's 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 description coverage is 0%, so the description must compensate. It explains 'cursor' and 'lease_id' explicitly, but leaves 'alias', 'pane_id', and 'max_bytes' unexplained. The parameter names are somewhat self-explanatory (e.g., max_bytes), but 'alias' and 'pane_id' could be ambiguous without further context. Partial compensation, but gaps remain.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Read incremental terminal output from the durable spool (pipe-pane).' This uses a specific verb (Read), identifies the resource (terminal output from durable spool), and distinguishes it from sibling tools like terminal_snapshot by emphasizing 'incremental' and 'pipe-pane.'
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 practical usage context: it explains cursor mechanics ('Pass next_cursor from the previous call; omit cursor to start at retained start') and the lease requirement. It doesn't explicitly contrast with alternatives like terminal_snapshot, but the 'incremental' vs. snapshot distinction is implied. This is clear guidance without formal exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are sparse (readOnlyHint false, destructiveHint false), so the description carries the burden. It adds a behavioral statement ('Does not navigate'), a prerequisite ('requires lease_id and an open browser session'), and a return type ('metadata + MCP ImageContent'), providing useful context beyond the structured fields. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise, front-loaded sentences with zero redundancy. Every sentence adds either core purpose, parameter behavior, prerequisites, or a side-effect disclaimer.
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 six-parameter tool with no output schema and no schema descriptions, the description covers the main behavior, prerequisites, navigation side-effect, and return type. The main omission is the mode/selector relationship and how width/height interact with device presets, making it slightly incomplete but still robust.
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 description must compensate. It explains the core parameters: mode (viewport/element/full_page), width/height as optional overrides of device presets, and lease_id as required. However, it fails to connect the selector parameter to the 'element' mode, leaving a critical dependency undocumented.
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 the action ('Capture a PNG screenshot'), the resource ('current browser page'), and the three modes (viewport/element/full_page), making it immediately distinguishable from sibling tools like browser_snapshot (likely DOM) and visual_get (may retrieve existing screenshots).
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?
It provides clear context: requires lease_id and an open browser session, and explicitly states it does not navigate. However, it does not name alternative tools like visual_get or visual_compare or state when to prefer one over another, so it stops short of full when/when-not 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?
The description adds useful behavioral context beyond the annotations: it discloses the LEASE_BUSY error condition, the renewal pattern, and explicitly states 'Does not write project files'. This goes beyond the bare annotations (all false) and helps the agent understand 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 four sentences, each serving a purpose: core action, usage timing, error handling, and renewal semantics. It is front-loaded and free of fluff, making it easy for an agent to parse quickly.
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 an output schema and only three optional parameters, the description covers the essential aspects: acquisition, renewal, busy state, and the no-write guarantee. It does not mention lease duration or what happens on expiration, but these are less critical given the output schema and sibling context.
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 must compensate for all parameters. It explains `project` ('registered project id; default demo') and `lease_id` ('Pass the same lease_id to renew'), but does not explain `mode` beyond the schema default of 'exclusive'. It partially compensates but leaves the mode parameter underspecified.
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 opens with 'Acquire or renew an exclusive workspace lease for a registered project', which is a specific verb+resource (acquire/renew + lease) and clearly distinguishes from workspace_release and workspace_status by focusing on the acquisition/renewal lifecycle.
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?
It explicitly says 'Use before mutating tools' and gives concrete guidance on handling LEASE_BUSY ('do not retry blindly') and renewal ('Pass the same lease_id to renew by activity'). However, it does not explicitly name alternative tools like workspace_release or workspace_status as comparisons.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is covered. The description adds valuable behavioral nuance beyond annotations: the privacy constraint 'Does not reveal another holder's lease_id' and the conditional behavior 'With lease_id, reports that lease.' These are non-obvious details that help the agent understand side effects and limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences long, front-loads the core purpose, then adds an edge-case behavior and usage timing. Every sentence contributes meaningful information with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists (so return values need not be described) and annotations cover read-only/idempotent behavior, the description covers the main purpose, conditional lease handling, a privacy caveat, and workflow timing. A minor gap is the missing explanation of how project and lease_id interact, but overall the tool is adequately specified.
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 description coverage is 0%, so the description must compensate. It explicitly explains lease_id ('With lease_id, reports that lease') and implies 'project' refers to the workspace whose status is reported. However, it does not clarify the relationship between the two parameters, whether either is required, or what happens when both are provided. This leaves some ambiguity.
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 'Report whether a project workspace is free, held, or expired,' which clearly states a specific verb ('report') and resource ('project workspace') and enumerates the possible statuses. This distinguishes it from sibling tools like workspace_acquire and workspace_release, which perform different actions.
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 instruction 'Use after LEASE_BUSY or before acquire' provides explicit timing context, telling the agent when to call this tool in a workflow. It does not explicitly name an alternative to avoid, but the contrast with 'acquire' and the presence of workspace_acquire/workspace_release siblings makes the intended usage clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering safety. The description adds meaningful behavioral context by specifying the exact content scope (orphan lease/terminal hints, cleanup counters) and explicitly stating what is excluded (secrets, tokens, full transcripts). This is valuable beyond annotations, though it does not discuss rate limits or auth, which are less critical for a read-only status 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 concise sentences, front-loaded with the main purpose and followed by a critical privacy caveat. Each sentence earns its place with no redundant or vague language. This is an excellent example of minimal, high-density description.
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 no-parameter read-only status tool with a provided output schema, the description adequately covers purpose, content scope, and exclusions. The output schema handles return structure, so the description does not need to explain field formats. The privacy disclosure adds completeness by setting clear expectations about what the tool will not return, making it complete for its complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema is an empty object, so there is no parameter semantics to document. The description appropriately focuses on the output rather than parameters. Baseline for 0 params is 4, and the description adds no unnecessary parameter details.
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 reports operational status with specific details: orphan lease/terminal hints and last cleanup counters, and explicitly notes it does not reveal secrets, tokens, or full transcripts. This content scope distinguishes it from sibling status tools like workspace_status and terminal_status. The implied verb 'get' is acceptable for a status tool.
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 as a status query for operational metrics (orphan leases, cleanup counters) but does not explicitly state when to use it versus alternatives, nor does it mention exclusions or prerequisites. Given the presence of multiple status tools (workspace_status, terminal_status), the lack of comparative guidance is a clear gap. The context is discoverable from the resource name but not explicitly contrasted.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool read-only, idempotent, and non-destructive. The description adds useful behavioral context by stating that output bodies are not included, which is a limitation an agent would need to know. It also clarifies that only 'managed terminals' are returned, adding precision beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences front-load the core purpose and immediately state the key requirement and limitation. No wasted words; every clause adds 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?
Given the tool's simplicity (one parameter, output schema present) and the coverage provided by annotations, the description is complete. It covers the essential aspects: what is listed, the required input, and a critical non-goal. The output schema handles return-value detail.
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 description must compensate. It mentions lease_id and indicates it is required, but does not explain what lease_id represents beyond being associated with a project. This adds some meaning but leaves the parameter's origin or format ambiguous.
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 a specific action ('List managed terminals') with a clear scope ('for the project of lease_id'). It also distinguishes itself from related tools by explicitly noting it does not include output bodies, setting it apart from terminal_read or terminal_snapshot.
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?
It clearly identifies the required input (lease_id) and implies the use case: listing terminals for a specific project. While it does not name alternative tools, the exclusion of output bodies provides practical guidance on 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the tool provides a point-in-time snapshot rather than a continuous log, and that it includes scrollback. The annotations already cover read-only and idempotent behavior, so the description adds the key distinction from terminal_read without contradicting 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 two concise sentences, front-loaded with the core action and quickly clarifying the alternative and prerequisite. No filler or redundant 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?
With an output schema covering return values, annotations covering safety, and the description covering the core behavior and distinction from terminal_read, the tool is sufficiently complete for the agent to select and invoke it correctly. Minor gaps in parameter-specific details are handled by parameter semantics scoring.
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 no descriptions (0% coverage), and the description only mentions that lease_id is required, which is already in the schema. It does not explain the roles of alias, pane_id, or include_history beyond the general scrollback mention, failing to compensate for the 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?
The description clearly states the tool captures a visible pane and scrollback via capture-pane, with a specific verb and resource. It also distinguishes itself from terminal_read by stating it is not an incremental log, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says not to use it for incremental logs and directs to terminal_read instead, providing a clear alternative. It also notes the lease_id requirement, implying it is for active terminal sessions. This gives clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already include destructiveHint=true, but the description adds non-interactive/no-shell behavior, exclusive lease requirement, cwd restriction, and production write gating via CODEAGENT_*_WRITE + project policy. This goes beyond annotations and gives useful behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with a clear structure: purpose first, then constraints, then usage guidance. Every sentence adds value with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, prerequisites (lease), usage context, and key constraints (cwd, write gating). Output schema handles return details. Minor gap is the lack of explanation for optional parameters, but overall the description is sufficiently complete for correct selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It clarifies command as an argv list (no shell), lease_id as exclusive lease from workspace_acquire, and cwd must stay under project root. However, env_overrides, timeout_s, and max_output_bytes are not explained, leaving a gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Run a non-interactive command as an argv list (no shell)', which is a specific verb+resource+mode. It clearly distinguishes from terminal_* interactive PTY tools, making the tool's purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use for pytest/builds/scripts; use terminal_* later for interactive PTY', providing direct when-to-use and alternative guidance. Also notes the lease prerequisite and cwd constraint, which are essential for correct invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint. The description adds valuable behavioral context: the path is scoped to the project root and escapes are prevented via openat2, and lease_id renews if provided. This goes beyond what the annotations provide, without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences that front-load the core purpose and then add essential security and lease details. No filler or redundancy. Every phrase 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 a moderate-complexity stat tool, the description covers purpose, path scoping, default project, read-only nature, lease behavior, and security. An output schema exists to handle return value documentation. Missing only minor details like whether the path must exist, but overall complete for agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero description coverage, so the description carries the burden. It clarifies that 'path' is relative to the project root, 'project' defaults to 'demo', and 'lease_id' renews if provided. This adds practical meaning beyond the schema's bare parameter names and 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 stats a path under a registered project root, with a specific verb and resource. It distinguishes from sibling tools like fs_read and fs_list by focusing on stat (metadata) and mentions the default project. The purpose is unambiguous and 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 provides clear context: it is read-only, operates under a registered project root, and has optional lease renewal. It does not explicitly name alternatives or exclusions, but the context is sufficient for an agent to decide when to use this tool. Lacks an explicit 'use when' statement, hence not a 5.
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 annotations already marking destructiveHint=true, the description adds value by specifying safety boundaries: it will not kill tmux panes or delete configured project roots. It also lists the cleanup scope. The only minor gap is ambiguity around 'orphan detection' (whether it deletes or just detects), but overall the behavioral context is solid.
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 exactly two sentences: the first states the action and scope, the second adds critical safety exclusions. It is concise, front-loaded, and every word earns its place. No filler or 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?
For a zero-parameter tool with an output schema, the description covers the core action and provides important safety disclaimers. It leaves some ambiguity about what 'aged' means and whether orphan detection results in deletion, but these are minor for an otherwise simple cleanup operation. It is largely complete but not exhaustive.
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 tool has zero parameters and an empty input schema, so there are no parameter details to explain. The description focuses on behavior, which is appropriate. The baseline for 0 params is 4, and this description fully meets that baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as a cleanup operation with specific targets (expired artifacts, aged spool files, orphan detection). It also distinguishes it from potentially destructive actions by explicitly stating what it does not do, which is helpful given the tool name is generic. This clarity sets it apart from sibling tools like ops_status.
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 for when to use the tool ('safe cleanup') and lists the exact items handled. It also gives exclusions (does not kill tmux panes or delete project roots), which is a form of 'when not to use' guidance. However, it doesn't explicitly name alternatives or broader usage scenarios, so it stops short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, and non-destructive behavior. The description adds valuable behavioral nuance beyond annotations: it explicitly states that it does not silently merge conflicting rules, provides provenance, and explains empty-path behavior. This gives the agent critical safety-awareness without contradicting the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: three sentences that front-load the purpose, then highlight behavioral traits, then provide parameter guidance. Every sentence adds value without fluff, making it easy for an agent to parse quickly.
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 tool has 5 optional parameters and an output schema. Description covers core behavior, conflict handling, and key parameter semantics. Notable omissions like max_bytes and project are not critical given the output schema and the clarity of the overall context, making this a well-rounded description.
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 description must compensate. It does explain include_agent_requested and lease_id, and describes the semantics of empty paths, but leaves project and max_bytes undocumented. This is partial compensation; the agent would benefit from more parameter-level 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 uses the specific verb 'Return' with a clear resource: 'applicable project instructions for path(s)' with provenance. It distinguishes itself from sibling tools like project_skills_list and project_skill_read by focusing on instructions rather than skills, and also clarifies its scope (always-on vs. rule files).
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 context on when to use the tool: when you need project instructions, with specific guidance for empty paths and the include_agent_requested flag. It does not explicitly name alternatives or exclusions, but the context is strong enough for an agent to decide when this tool is relevant.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, but the description adds a critical behavioral guarantee: it never executes !command or bundled scripts, and clarifies that allowed-tools is metadata only. This goes beyond the readOnlyHint and provides important safety context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with purpose, then return values and safety caveat. Every sentence adds value with no fluff or 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?
The description covers the essential behavior (reading a skill, return contents, no execution, read-only) and the output schema exists for return values. Minor gaps remain around 'project' and 'max_bytes', but these are secondary to the main purpose and the tool is adequately scoped.
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 the description carries the burden. It explains skill_id as the path to SKILL.md and notes lease_id is optional, but it does not explain the 'project' or 'max_bytes' parameters, which remain ambiguous. Partial compensation for the 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?
The description clearly states the tool reads one skill by skill_id, specifying the resource (SKILL.md file) and how the ID is obtained (from project_skills_list). It distinguishes itself from the sibling list tool by focusing on a single skill 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 implies when to use the tool: after obtaining a skill_id from project_skills_list. It gives context on the skill_id source, but does not explicitly contrast with alternatives or state exclusions. The usage is clear enough from the phrasing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds the TTL constraint and return content ('metadata + ImageContent'), which are not in annotations and provide valuable operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loaded with the core action and resource. Every phrase adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with two required string params and no output schema, the description covers purpose, key constraints (TTL), return type, and required parameter. It is complete enough for an agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema_description_coverage, the description compensates by explaining that artifact_id is 'opaque' and 'within TTL' and that lease_id is required. This adds meaning beyond the raw schema, though it does not fully define what lease_id represents.
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 ('Re-fetch a previously captured artifact') and the resource ('artifact by opaque artifact_id'). It distinguishes from siblings like visual_capture and visual_compare by emphasizing 'previously captured' and 'within TTL'.
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 implies use after a prior capture and within the TTL window, and it explicitly requires a lease_id, which is a clear precondition. However, it does not explicitly name alternative tools 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and description adds valuable context: returns sha256 of full file, shows truncated flag, rejects binaries while still returning sha256 for replace flows, and clarifies lease_id is optional. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three dense sentences, front-loaded purpose, no fluff; every sentence provides unique value (behavior, return, binary handling, read-only).
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 6 params, 0% schema descriptions, and presence of output schema, the description adequately explains purpose, constraints (project root, UTF-8), and key behavior (binary rejection, truncated content). Missing details: lease_id purpose, max_bytes interplay, and error conditions beyond binary, but overall sufficient for a 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?
Schema coverage is 0%, but description compensates by clarifying line range for start_line/end_line, project root for project, and optional lease_id. However, lease_id and max_bytes are not fully explained, leaving some 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?
Specific verb+resource: 'Read a UTF-8 text file under the project root' distinguishes from sibling fs_stat, fs_list, fs_search; mentions optional line range and return values that differentiate it as a content-reading tool.
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 context (read-only, text files, under project root) and implicitly indicates when to use via 'read-only' and 'rejects binaries,' but does not explicitly name alternatives or when-not-to-use scenarios. The 'replace flows' mention hints at a workflow but lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (which already indicate a non-read, mutable action), the description adds critical behavioral details: it blocks certain protocols and hosts, and requires a lease_id. This informs the agent of restrictions and prerequisites without contradicting 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 concise sentences, front-loaded with the action. Every sentence provides critical information: what it does, what it blocks, and what it requires. No fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a navigation tool with an output schema present and good annotations, the description covers the core function, constraints, and prerequisite. It is sufficiently complete for an agent to select and invoke it correctly among many sibling browser 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?
With schema description coverage at 0%, the description compensates by constraining the URL parameter to loopback http(s) addresses and highlighting that lease_id is mandatory. It does not explain what lease_id is, but the requirement is stated, which adds value over the bare 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 to a loopback http(s) URL, with specific verb ('Navigate') and resource (loopback URL). It distinguishes itself from siblings by explicitly blocking file:// and off-loopback hosts, making it unique among browser 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 implies when to use this tool: for navigating to local development servers only. The constraints (blocks file:// and off-loopback hosts) give clear context, though it does not explicitly name alternative tools for other navigation scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the destructive annotation, the description discloses key behaviors: conflict detection, atomic temp+rename, production write restrictions, and the distinction between edits and full content replacement. This provides agents with safety-critical knowledge about failure modes and requirements.
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 packs critical information into a few sentences, front-loading the main action and following with prerequisites, modes, and safety details. No redundant content is present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a patch tool with two modes, conflict handling, and environment restrictions, the description covers the key operational aspects. The existence of an output schema addresses return values, so the description does not need to explain them.
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 carries the burden of explaining parameters; it defines edits, new_content, create, expected_sha256, and project identifiers. It leaves path somewhat implicit (under project root) and does not explain lease_id format, but overall adds substantial semantic value beyond the bare 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 applies a structured text patch under the project root, distinguishing it from sibling file-write tools by emphasizing structured edits and the ability to do full replace via new_content. The verb 'apply' and specific resource make the action unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explains when to use the tool: requires a lease_id, and for existing files, an expected_sha256 from fs_read to detect conflicts. However, it does not explicitly compare to alternatives like fs_write_file, so while context is clear, exclusion guidance is implicit. The mention of create=true and production writable_env gates gives situational guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, and the description adds useful details about output truncation ('byte-capped unified diff with truncated=true when clipped') and the no-mutations policy. It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with the core purpose. Each sentence contributes essential information: purpose/modes, output/truncation, and caveats/alternative. 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 the moderate complexity, the description covers purpose, output behavior, optional parameters, and an alternative fallback. The existence of an output schema reduces the need to explain return values further, and the description is self-contained for a developer.
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 compensates by explaining mode values, path scope ('under root'), lease_id optionality, and max_bytes via the byte-capping behavior. It doesn't explicitly explain the 'project' parameter, but the overall semantics are adequately conveyed.
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 'Structured read-only git diff for a registered project root' with specific modes (unstaged|staged|both). It distinguishes from siblings by specifying the output (numstat summary, file list, unified diff) and mentions exec_run as an alternative for uncovered Git ops.
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?
It explicitly provides usage context (git diff, modes, optional path/lease_id) and names an alternative: 'For uncovered Git ops use exec_run.' This satisfies the when/when-not/alternatives criterion, even though it doesn't explicitly mention git_status.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering the safety profile. The description adds context by stating the response does not include secrets, env, or host paths, which is useful behavioral information beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four concise sentences, each earning its place: purpose, when to use, what it excludes, and the alternative. Information is front-loaded and there is no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, zero-parameter tool with an output schema present, the description is complete. It covers what is returned, when to use it, what is not included, and the alternative tool, making it fully sufficient for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The schema is fully covered (100%) and there is nothing to explain about parameters. The description's mention of response content does not relate to parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns the CodeAgent MCP version and capability summary, using a specific verb and resource. It also explicitly differentiates from project_bootstrap by saying when not to use this tool.
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?
It gives explicit usage guidance: 'Use on first contact' and 'Do not use for project orientation — that is project_bootstrap.' This names the alternative tool and provides both positive and negative usage instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the destructiveHint annotation, the description discloses atomic temp+fsync+replace behavior, a 2MB decoded-size cap, Base64 format tolerance (line breaks, URL-safe alphabet, optional padding), and conflict behavior. This substantially enriches the agent's understanding of side effects and failure modes.
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?
Every sentence adds a necessary constraint or clarification. The description is dense but not verbose, front-loads the core purpose, and uses an ordered progression from input format to limits to overwrite semantics to atomicity.
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?
This is a complex mutation tool with an output schema, and the description covers format, size limits, concurrency checks, atomic writes, and related tool behavior. It gives sufficient context for safe invocation without needing to inspect the schema.
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?
With 0% schema description coverage, the description compensates richly: content_base64 is fully specified, expected_sha256 rules are explicit, create semantics are stated, lease_id is highlighted, and path is scoped to project root. This gives the agent far more than the bare property 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 opens with a specific verb and resource: 'Write a binary file under the project root from plain Base64', clearly differentiating binary writes from the sibling fs_write_file. It also states scope constraints (project root) and input format (Base64, not data URL).
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 preconditions and semantics: lease_id is required, create=true for new files, expected_sha256 mandatory for existing files, and CONFLICT on mismatch. It references fs_apply_patch for write gates, but does not explicitly contrast with fs_write_file or state when to prefer text-file writing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds substantial behavioral constraints beyond annotations: HTTPS from an allowlisted OpenAI host, no redirects, a 2,000,000-byte size cap, and shared gates with fs_write_binary. It also clarifies that path is authoritative while file_name/mime_type are metadata only.
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 and front-loaded with the core purpose. Every sentence contributes critical constraints or usage guidance, with no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the tool's complexity (external download, auth, size cap), the description covers essential behavioral aspects. The existence of an output schema covers return values, so the description doesn't need to. It is sufficient for an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With only 17% schema coverage, the description compensates well by explaining the file object's key fields (download_url + file_id), the authoritative nature of path, and lease_id. It references create/SHA gates indirectly, though it doesn't fully explain the create and project 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 identifies the tool's verb ('Write') and resource ('binary file from a ChatGPT host file reference'). It explicitly differentiates from sibling fs_write_binary by noting it takes the file itself rather than Base64, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives explicit usage context: 'Preferred way to move an uploaded or ImageGen-generated file into a project' and states the alternative ('Portable clients should use fs_write_binary (Base64) instead'). Also highlights the requirement for lease_id.
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:

[![codeagent-mcp MCP server](https://glama.ai/mcp/servers/davidlosasgonzalez/codeagent-mcp/badges/card.svg)](https://glama.ai/mcp/servers/davidlosasgonzalez/codeagent-mcp)

Score Badge

Copy to your README.md:

[![codeagent-mcp MCP server](https://glama.ai/mcp/servers/davidlosasgonzalez/codeagent-mcp/badges/score.svg)](https://glama.ai/mcp/servers/davidlosasgonzalez/codeagent-mcp)

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/davidlosasgonzalez/codeagent-mcp'

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