local-agent-mcp

by ezra-y

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

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

Latest release: v0.5.1
Disambiguation2/5
Several tools have near-identical purposes: ask_codex and start_codex_job both start read-only Codex jobs, and get_codex_job/cancel_codex_job duplicate functionality already covered by the unified get_job/cancel_job. The distinction between Codex jobs, Codex turns, and workflows is also fuzzy, making selection error-prone.
Naming Consistency3/5
Most tools follow verb_noun snake_case (e.g., list_files, cancel_job), but there are inconsistencies: 'ask_codex' uses an unconventional verb, 'ping' is a bare noun, and the mix of ask/start/steer/intrerupt for Codex operations lacks a clear pattern. Still, the majority are consistent enough to be readable.
Tool Count2/5
With 28 tools, the surface is heavy, especially given the redundant job/turn management tools. Several tools could be merged or eliminated (e.g., ask_codex/start_codex_job, get_codex_job/get_job), suggesting the count is inflated beyond what the domain requires.
Completeness4/5
The surface covers core local agent operations well: file read/write/patch/list, git status/diff/commit, command and test execution, workflow management, and Codex interactions (jobs, turns, threads). Minor gaps exist (no delete file or git push), but the main workflows are supported.
Average 3.5/5 across 28 of 28 tools scored. Lowest: 2.6/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 3 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?
Annotations already declare destructiveHint=true and idempotentHint=true, so the description adds no new behavioral context. It does not describe side effects (e.g., whether the turn is terminated, whether state is lost), authentication requirements, or what happens if the turn is not active. Since annotations are present, the bar is lower, but the description still adds zero value beyond the flags.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence: 'Interrupt an active local Codex turn.' It is front-loaded with the action and purpose, with no unnecessary words. While it is short, it is not verbose; it earns its place as a clear statement. A higher score would require more structured content, but for a simple tool, this is appropriately concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool performs a destructive action and has only two parameters, the description is incomplete. It does not clarify what constitutes an 'active' turn, what the result of interruption is, or whether the operation is reversible. With an output schema present but not described, the agent lacks information on what to expect. The description should provide at least minimal context for safe invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, meaning the input schema provides no descriptions for thread_id or turn_id. The description does not mention either parameter or explain their purpose, so an agent must guess from the parameter names alone. This is insufficient for a destructive operation; the description should at least clarify that both parameters identify the specific turn.
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 states a specific verb ('Interrupt') and resource ('an active local Codex turn'), which is clear about the action's target. However, it does not explicitly differentiate from sibling tools like cancel_codex_job or steer_codex_turn, which could be ambiguous in a list of tools. The clarity is good but not exceptional.
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 does not mention conditions for interrupting a turn, how it differs from cancel_codex_job, or any prerequisites. An agent has to infer usage entirely from the tool name and context signals, which is insufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description repeats 'read-only' but adds the valuable detail 'return immediately', implying asynchronous behavior. However, it does not disclose what the job does beyond 'inspection', how to track its progress, or any permissions needed. The description adds minimal context beyond the annotations, and no contradiction is present.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that mentions the core action and the immediate-return behavior. It is concise and efficient, though it could have included a bit more without becoming verbose. No wasted words, but it sacrifices depth for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (5 parameters, async job semantics, multiple related tools), the description is far too brief. It does not explain return value (despite an output schema existing), how to retrieve results, or how this job relates to workﬂows and steps. The presence of an output schema doesn't alleviate the need for usage context, and the description fails to make the tool understandable in the broader ecosystem.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no explanation for any of the five parameters (prompt, attempt, project, step_id, workflow_id). The schema only offers bare type and default info, so the description carries no semantic weight. For a tool with several context-dependent parameters, this is a major gap.
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 verb 'start' and the resource 'read-only Codex inspection job', and adds the behavioral detail 'return immediately'. This is specific enough to distinguish from generic 'ask_codex' or 'start_codex_turn', though it does not explicitly name any sibling as an alternative. The phrase 'read-only inspection' hints at the tool's scope but doesn't fully differentiate it from other start-type tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus its siblings such as 'ask_codex', 'start_codex_turn', or 'start_step'. The description does not mention when not to use it, nor any prerequisites (e.g., needing a project or workflow context). The agent is left to infer usage from the name and vague 'inspection' wording, which is insufficient given the large sibling set.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and idempotentHint=true, so the description adds a small behavioral detail about force semantics. However, it does not explain the consequences of cancellation or what 'unconfirmed state' means, leaving significant ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short and front-loaded with the primary verb and resource. There is no wasted text, but the brevity borders on under-specification rather than efficient communication.
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 appears to target a generic 'unified job' system, but the description does not clarify how it differs from codex-specific tools like cancel_codex_job. Given the simple schema and annotations, more context about the force parameter and the job lifecycle is expected.
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?
With 0% schema description coverage, the description must compensate for both parameters. It provides a partial explanation for 'force' (releasing unconfirmed state) but gives no information about 'job_id' or how to obtain it. The meaning is too vague to be actionable.
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 states a clear verb ('cancel') and a specific resource ('unified job'), which distinguishes it from sibling tools like cancel_codex_job. The term 'unified' is somewhat ambiguous without further context, but the core purpose is understandable.
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 phrase 'force only releases unconfirmed state' hints at when the force parameter should be used, but there is no guidance on when to use this tool versus alternatives such as cancel_codex_job. No explicit conditions or exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds 'immutable' and 'executable' beyond what annotations convey. It clarifies that the created step is immutable and executable, which is not evident from readOnlyHint=false or idempotentHint=true. This is valuable behavioral context not present in structured fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise and front-loaded, but it is too terse to be useful. It omits critical parameters and usage context, so brevity comes at the expense of completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 parameters, nested objects, output schema) and the absence of schema descriptions, this one-sentence description is severely incomplete. It lacks parameter explanations, usage guidance, and behavioral details beyond immutability, leaving agents to rely on trial and error.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides zero explanation of any of the 7 parameters (workflow_id, position, name, executor_kind, spec, write_scope, worktree_path). The enum values and nested spec object are entirely undocumented, leaving agents to guess at required semantics.
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 states a clear verb ('Create') and a specific resource ('immutable executable Step inside one Workflow'), which distinguishes it from broader tools like 'create_workflow'. It doesn't contrast with sibling step-related tools (e.g., 'start_step') but the core purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'start_step' or 'create_workflow'. The description only states what it does, not when to invoke it or prerequisites like having an existing workflow.
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 destructiveHint=true and idempotentHint=true. The description adds the requirement of explicit user authorization and specifies UTF-8 encoding, providing context beyond the annotations. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence with no redundancy, front-loading the core action. However, it is extremely terse, and the lack of parameter details might be a trade-off, but for conciseness it is appropriately sized.
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 having an output schema and annotations, the description leaves out critical context: how the project parameter relates, whether directories are created, failure behavior, and how it compares to similar file-writing tools. A destructive operation with three undocumented parameters needs more detail.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate by explaining parameters. It mentions none of the three parameters (project, path, content). The agent gets zero semantic guidance.
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 states a clear action ('Create or replace one UTF-8 file') with a specific resource and scope. It is distinct from siblings like apply_patch, but it doesn't explicitly name or differentiate them, so it falls short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as apply_patch or run_command. The only usage note is 'after explicit user authorization', which is a safety precondition, not a tool-selection guideline.
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 readOnlyHint=false, so the write nature is known. The description adds 'durable', hinting at persistence, which is additional context not in annotations. However, it does not disclose behavior like side effects, failure modes, or whether the workflow is immediately executable. It adds some value but not rich behavioral detail, consistent with the lower bar set 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 a single concise sentence that immediately states the core purpose. There is zero redundancy or filler. It is front-loaded with the main action and scoping qualifier. Without the need for more length due to its minimalism, this is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description lacks essential context. It does not explain what constitutes a 'multi-Step task', how the workflow relates to steps, whether the workflow is created in a draft state, or any preconditions like project existence. For a create operation with three parameters, the description is far from complete. An agent would struggle to know the full context without additional investigation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate by explaining the meaning, constraints, or format of parameters. It does not mention any of title, project, or metadata. The schema provides only names and types, but the description adds nothing about their purpose, relationship, or potential values. This is a significant gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Create', the resource 'Workflow', and adds the qualifier 'durable for a multi-Step task'. This distinguishes it from sibling tools like create_step (which likely creates a single step) and get_workflow (which reads). It is specific and non-tautological.
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 implies usage for creating a multi-step workflow but provides no explicit guidance on when to choose this over alternatives, nor does it mention exclusions or prerequisites. It lacks any 'when not to use' or comparison to siblings like create_step or start_step. The single sentence leaves the selection logic entirely to the agent's inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the commit skips hooks, signing, filters, and pushing, which adds context beyond the destructiveHint annotation. However, it does not explain what happens on success or failure, nor the meaning of 'authorized paths'. The description aligns with annotations (destructive=true) and adds some behavioral detail, but not enough to fully understand side effects or prerequisites.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the primary action and key qualifiers. There is no redundant information or filler, and it is easy to parse at a glance.
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?
For a mutation tool with destructive behavior and three required parameters, the description is insufficient. It does not explain the meaning of 'authorized paths', the role of project and message, or what the output schema returns. The description leaves too much to inference, making it incomplete for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has three required parameters (paths, message, project) with zero descriptions, and schema coverage is 0%. The description does not explain what these parameters represent or how they are used. The only hint is 'authorized paths', which ambiguously refers to the paths parameter but leaves project and message undefined. This is a critical gap.
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 action (commit) and resource (paths), and adds specific qualifiers ('without hooks, signing, filters, or pushing') that differentiate it from a generic git commit. However, it does not explicitly name an alternative tool like run_command, so the distinction is implicit rather than explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a use case by mentioning the conditions under which the commit is performed (no hooks, etc.), but it does not explicitly state when to use this tool versus alternatives like run_command or git_status. It lacks clear when-to-use / 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the description does not need to restate safety. It does add context by specifying that the workflow includes Steps and Job attempts, which clarifies the returned data. Since the description aligns with the annotations and provides a bit of extra behavioral detail, a 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no filler or repetition. It front-loads the core purpose and includes the key details (Steps, Job attempts) without wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (single parameter), the presence of an output schema (so return values are covered there), and annotations that declare safety, the description is largely adequate. It adds value by specifying the composition of the workflow (Steps and Job attempts). The missing usage guidance is a gap, but for a straightforward getter this is not critical.
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 the only parameter, workflow_id. The description does not elaborate on the parameter beyond its existence. While the ID parameter is self-explanatory for a get-by-id tool, the description should ideally mention that the workflow_id identifies the target workflow. It does not add value beyond the schema's minimal 'Workflow Id' label.
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 verb 'Get' and the resource 'durable Workflow with its Steps and Job attempts.' It identifies what the tool returns, which distinguishes it from sibling tools like get_job or get_codex_job that fetch different entities. However, it does not explicitly name alternatives, so it falls short of a perfect 5.
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 such as get_job or get_codex_job. There is no mention of prerequisites, selection criteria, or exclusion conditions. The agent must infer usage solely from the tool name and resource type.
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 already declare destructiveHint=true and readOnlyHint=false, so the destructive nature is known. The description adds 'transactional' which implies atomicity, but it does not explain what gets destroyed, whether changes are reversible, or what authorization is required for the patch. Given the annotations cover the safety profile, a 3 is appropriate—some added context but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence with no wasted words. The verb is front-loaded, and the qualifier 'transactionally' is placed right after. Every word earns its place; it is concise without sacrificing the core meaning.
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?
For a destructive, state‑modifying tool, the description omits essential context: what the patch applies to, what 'project' refers to, and what happens on failure. The output schema exists, so return values are covered, but the input semantics and operational expectations are incomplete. An agent would need to guess or consult external docs.
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 document parameters, but it does not explain 'project' at all. It vaguely implies that 'patch' contains a 'Begin Patch block' but does not define the format or relationship. With two required parameters and no explanation, an agent cannot infer correct usage from the description alone.
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 (apply) and resource (Begin Patch block), with a qualifier ('transactionally') that adds precision. It distinguishes from siblings like write_file by referencing a specific patch format, so an agent can tell it apart without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as write_file or run_command. The description does not mention prerequisites, when not to use it, or which sibling to prefer. This is a clear gap for a tool that modifies project state.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool as mutating (readOnlyHint=false) and idempotent (idempotentHint=true). The description adds the nuance that 'force only releases unconfirmed state', which is a behavioral detail beyond annotations. However, it does not disclose what cancellation entails (e.g., termination of running processes) or the meaning of 'unconfirmed state'. Given the annotation coverage, this 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 a single, compact sentence that front-loads the main action and follows with the critical nuance about 'force'. Every word earns its place; there is zero redundancy or filler.
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 and annotations covering idempotency and mutation, so the description need not repeat those. However, it does not address potential consequences of cancellation (e.g., whether jobs are killed immediately) or the meaning of 'local' in contrast to remote jobs. For a cancellation operation, this is a moderate gap; an agent might benefit from more context about side effects.
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 'force' parameter ('only releases unconfirmed state'), adding meaning beyond the boolean type. 'job_id' is self-explanatory from its name and context. However, the explanation of 'force' is terse and does not fully clarify when it should be set or what 'unconfirmed state' means, so it only partially compensates for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Cancel a local Codex job' with a specific resource (Codex job) and verb (cancel). It distinguishes from the more generic sibling 'cancel_job' by specifying 'local Codex'. However, it doesn't explicitly differentiate from other Codex-related cancellation tools, so it loses one point.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives like 'cancel_job'. The description does not mention exclusions, prerequisites, or conditions that would select this tool over the generic cancellation tool. The agent is left to infer from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the description does not need to repeat safety. It adds the useful detail of 'bounded, paginated page,' which informs the agent that not all turns are returned at once. It does not disclose auth requirements or error behavior, but the strong annotation base makes a 4 appropriate.
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?
A single, concise sentence that front-loads the action and scope with no fluff. However, it is too short to carry all necessary information, so it is concise but under-specified rather than optimally structured.
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 having an output schema that covers return values, the description is insufficient for an agent to call this correctly: no parameter semantics, no pagination mechanics, and no guidance on when to use it versus siblings. The agent would need to infer how to set cursor and turn_limit, and what include_turns does, making the description 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%, meaning no parameter descriptions exist in the schema. The description does not explain thread_id, cursor, turn_limit, or include_turns. The mention of 'bounded, paginated' hints at cursor and turn_limit but does not define their behavior, so the agent must guess parameter semantics—a significant gap.
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 this tool reads thread metadata and a bounded, paginated page of turns. It distinguishes from list_codex_threads (which likely lists thread summaries) and get_codex_turn_status (which targets a single turn's status) by specifying the resource and scope. However, it does not explicitly name a sibling alternative, so it stops short of a perfect 5.
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 this tool is for reading thread content, but provides no explicit guidance on when to choose it over list_codex_threads, resume_codex_thread, or get_codex_turn_status. With many sibling tools, a clear 'use this when...' statement is absent, leaving selection to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false and destructiveHint=true, covering the fact that this mutates and can be destructive. The description adds 'authorized' as a prerequisite but does not disclose side effects, reversibility, or interaction with the turn beyond adding instructions. It adds marginal value 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 a single, efficient sentence that front-loads the action verb ('Send') and immediately conveys the target. There is zero fluff; every word contributes to meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With three required parameters and zero schema descriptions, the description fails to explain parameter roles. It also does not clarify what 'authorized' means, how to identify a turn, or what happens after sending instructions. While an output schema exists (not shown), the missing parameter semantics and lack of usage context make this incomplete for an agent to call correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not explain any of the three parameters (thread_id, turn_id, prompt). With schema_description_coverage at 0%, the description was the only chance to clarify that thread_id identifies the conversation, turn_id identifies the specific turn, and prompt carries the additional instructions. It offers no such detail, leaving the agent to guess.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Send'), a resource ('Codex turn'), and the intent ('additional instructions'). It clearly differentiates from siblings like start_codex_turn (which initiates) and interrupt_codex_turn (which halts) by focusing on adding input to an existing active turn.
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 phrase 'to an authorized active Codex turn' implies it should only be used when a turn is already running and authorized, but it does not explicitly state when not to use it or mention alternative tools like start_codex_turn for new turns. Guidance is implicit rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the description does not need to repeat those. It adds that the tool returns 'status and result', which is useful but not detailed. No additional behavioral traits (e.g., potential blocking, error cases, size of result) are disclosed, but given the annotations cover the safety profile, a 3 is appropriate.
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, focused sentence with no extraneous content. It front-loads the core purpose and does not waste tokens. This is an ideal level of conciseness for a simple read-only tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema and annotations for safety, the description is mostly adequate. However, it omits any clarification of 'local' versus other job types, nor does it indicate that the job must have been started by start_codex_job. An agent might confuse it with get_job or get_codex_turn_status without explicit context. Thus, it is minimally complete but with noticeable 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?
Schema description coverage is 0%, so the description must compensate entirely for the parameter 'job_id'. It implies job_id identifies a local Codex job but provides no details on provenance (e.g., how to obtain it from start_codex_job), format, or validation. This minimal information is barely sufficient for an agent to understand what to pass.
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 ('Get') and a precise resource ('status and result of a local Codex job'), clarifying the tool's scope and distinguishing it from siblings like start_codex_job or cancel_codex_job. The qualifier 'local' also sets it apart from the more generic get_job, 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives. It does not mention get_job, start_codex_job, or other codex-related tools, nor does it state conditions or exclusions. An agent must infer usage purely from the name, which is insufficient for selecting between overlapping tools like get_job.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the agent knows the operation is safe and repeatable. The description adds the useful context that it lists 'local' threads and supports filtering by project, which goes slightly beyond the annotations. However, it does not disclose pagination behavior (via cursor/limit) or the search/archived filters, missing opportunities to provide richer behavioral context. Since annotations cover the safety profile, a 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words, and it front-loads the primary action ('List') before adding the optional filter. It is appropriately concise for a simple listing tool, though it could benefit from slightly more detail without becoming verbose. The structure is clear and efficient, earning a high but not perfect score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has five optional parameters, zero schema-level descriptions, and no output schema shown, the description is notably incomplete. It omits critical usage details such as pagination (cursor, limit), search functionality, and the 'archived' filter, which an agent would need to call the tool effectively. While the output schema may exist, the description itself fails to contextualize the tool's full capabilities, leaving significant gaps for an agent to discover.
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 by explaining parameter meaning. The only parameter mentioned is 'project', which is referred to as an optional filter. The other four parameters (limit, cursor, archived, search_term) are not explained at all, and their purposes (pagination, search, archival filtering) are left to the agent's inference from names. This is insufficient for a tool with five parameters, justifying a below-average score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('List') and resource ('local Codex app-server threads'), which clearly distinguishes it from sibling tools like 'read_codex_thread' (which reads a single thread) and 'start_codex_turn' (which starts a turn). It also hints at a filter capability, reinforcing the listing scope. This is not a tautology and provides immediate clarity.
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 phrase 'optionally filtered by project' gives some usage context, implying that the tool can be used to list threads with an optional project filter. However, it does not explicitly state when to use this tool versus alternatives, nor does it mention any exclusions or prerequisites. The usage guidance is implied but not fully articulated, so it only meets a minimal standard.
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 destructiveHint=true, but the description adds valuable context: tests can 'create files and execute project-controlled code,' and runs as a background job. This goes beyond the annotations by specifying what side effects to expect, and it is consistent with the destructive hint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler. The first sentence front-loads the core purpose, and the second adds a crucial behavioral caveat. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 8 parameters, an output schema, and a background-job workflow, the description is too sparse. It does not explain how to track the job, interpret results, or handle failures. While the output schema may cover return structure, the description omits essential operational context (e.g., async behavior, retrieval via get_job), making it incomplete for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 carries full responsibility for parameter explanation. It mentions none of the eight parameters (project, cwd, argv, attempt, profile, etc.), leaving the agent to guess at their semantics and usage. Some names are self-explanatory, but this is insufficient given the tool's complexity.
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 'Start authorized project tests as a background job' clearly states the verb (start), the resource (project tests), and the mode (background job). It distinguishes this tool from generic command execution and other job-related siblings by focusing on tests specifically.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like run_command or other job tools. The description does not mention any context, prerequisites, or exclusion criteria, leaving the agent to infer when running tests via this route is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond annotations by explaining what idempotentHint means in practice: it either starts a new attempt or returns the existing Job. This clarifies the side-effect profile and aligns with the openWorldHint annotation, though it does not elaborate on external side effects or authentication 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 is a single, compact sentence with no filler. It front-loads the core action and the alternative return value, making it highly efficient. No unnecessary words or clauses.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 required parameters and zero schema descriptions, the description is severely incomplete. It does not explain the parameters, nor does it provide any guidance on when to choose this over siblings. Although an output schema exists, the missing parameter semantics and usage guidance leave the description inadequate for an agent to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description carries the full burden of explaining parameters, but it does not mention workflow_id, step_id, or attempt at all. The schema only provides titles, which are insufficient. The description fails to add any meaning to the parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Start' and identifies the resource 'Step attempt', and adds the key behavior 'or return its existing Job'. This clearly distinguishes it from sibling tools like start_codex_job which deal with codex jobs, 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 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 (to start a step attempt or retrieve an existing job) but does not explicitly mention alternatives or state when not to use it. There is no exclusions or comparison against siblings, so usage context is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and openWorldHint=false, so the safety profile is covered. The description adds the scope of job types, which is useful, but it does not disclose behavior like error responses or what happens with invalid job IDs. Given the annotations, 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 a single, front-loaded sentence with no filler. It immediately communicates the tool's purpose and scope. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple read-only getter with one parameter and an output schema present (though not shown). The description covers the input scope and job types. The presence of an output schema means return format need not be described. The description is sufficient for an agent to call this tool correctly; only minor details like error behavior are absent, which are likely in the output schema.
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?
There is only one parameter, job_id, which is self-explanatory from its name. However, schema description coverage is 0%, and the description does not add any additional meaning or format details for the parameter. The parameter name is intuitive, so the description's silence is acceptable, but it does not exceed the 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 states a specific verb ('Get') and resource ('job status'), and explicitly enumerates the job types it covers ('unified command, test, Codex, or Codex Turn'). This distinguishes it from siblings like get_codex_job and get_codex_turn_status, making it clear this is the general status endpoint.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide any guidance on when to use this tool versus the more specific siblings (e.g., get_codex_job, get_codex_turn_status). It does not mention alternatives or exclusions, leaving the agent to infer that 'unified' implies general coverage. This is a clear gap for a tool with multiple similar siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, covering the safety profile. The description adds specific output fields (branch, HEAD, modified, staged, untracked), which is useful behavioral context beyond annotations. No contradictions and no side effects are mentioned, but read-only makes that unnecessary.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with the action 'Return' and immediately lists the returned data. No filler 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?
For a simple read-only tool with an output schema, the description covers the return values but omits explanation of the required 'project' parameter. Given 0% schema coverage, this is a notable gap. No prerequisites or error conditions are mentioned, but these may not be critical for such a straightforward 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 sole parameter 'project' has 0% schema description coverage. The description does not explain what 'project' should be (e.g., path, name, or repository identifier), leaving the agent to guess the argument format. With such low schema coverage, the description needed to compensate but did not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool returns branch, HEAD, modified, staged, and untracked files. This is a specific verb and resource list, distinguishing it from siblings like git_diff and git_commit. The content list provides unambiguous scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this over siblings like git_diff or git_commit. The description implies it's for checking repo state but doesn't state when not to use it or what conditions favor it. Given overlapping siblings, more direction would help the agent choose correctly.
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 'unattended full access' phrasing adds behavioral context beyond the annotations — it signals that the tool runs autonomously without further user interaction and with broad capability. This complements annotations already declaring destructiveHint=true, readOnlyHint=false, and openWorldHint=true, and there is no contradiction between the description and the annotations. The high-privilege framing reinforces the mutating nature of the operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short paragraphs with the primary action front-loaded in the first sentence. The second paragraph earns its place by stating the critical authorization precondition. No fluff or repetition of schema data. It could fold a brief parameter note in given the 0% schema coverage, but as written it is tight and hits the key points efficiently.
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-value explanation is not required) and annotations are rich, but this is a high-privilege mutation entry point whose description omits operational context: what happens after the thread resumes (does it run to completion unattended? does it return a turn status, tying into start_codex_turn / get_codex_turn_status siblings?). The authorization precondition is covered, but the post-resume lifecycle that an agent needs to orchestrate follow-up calls is left to inference.
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 carries the burden of explaining the two parameters (thread_id, project). It mentions neither. While the names are trivially inferable — thread_id is clearly the thread to resume and project the scoping context — the description does not clarify what 'project' scoping means, the expected format of thread_id, or defaults beyond the schema. The description fails to compensate for the missing schema-documented parameter meaning.
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 names a specific action (Load/Resume), resource (existing local Codex thread), and mode ('unattended full access'). It is clear what the tool does. However, differentiation from siblings like read_codex_thread, list_codex_threads, and start_codex_turn is only implicit through the verb 'resume' — no sibling is named or contrasted, so the agent infers the distinction rather than being told.
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 an explicit, actionable precondition: 'Use it only after explicit user authorization under the permission policy returned by get_permissions.' This tells the agent when it is permitted to call the tool and what to check first. It lacks explicit when-not guidance against alternatives (e.g., when to use read_codex_thread for inspection instead), so it stops short of full 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?
Beyond the annotations (destructiveHint, openWorldHint), the description discloses important behavioral traits: the turn is persistent and runs asynchronously, and it is a high-privilege entry point that may access paths outside the structured root. This adds value over the structured metadata, making the agent aware of long-running side effects and security implications.
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 well-structured: three sentences, with the primary action and return immediately stated first, followed by the crucial async behavior and security warning. Every sentence carries significant information without fluff, making it both concise and effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity — 8 parameters, async behavior, security implications, and an output schema — the description covers only the most essential points (async, polling, thread creation, privilege level). It omits guidance on the remaining parameters, error handling, and does not describe the return format beyond 'IDs'. While the output schema exists and might fill some gaps, the lack of parameter documentation makes the description incomplete for correct usage.
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?
With 0% schema description coverage, the description is the only source of parameter meaning. It only explains thread_id ('Omit thread_id to create a new local Codex thread') and implicitly mentions polling. The other seven parameters (model, effort, attempt, project, step_id, workflow_id) are left entirely unexplained, forcing the agent to guess their purpose. This is insufficient for a tool with 8 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 the action ('Start a persistent app-server turn') and the immediate outcome ('return its IDs'). It distinguishes itself from job-based siblings by explicitly naming it a 'local Codex turn' and referencing persistent async behavior, though it does not directly compare to tools like start_codex_job. The core purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides concrete usage context: the turn is asynchronous and continues after the call returns, with an explicit instruction to poll via get_codex_turn_status. It also explains how to create a new thread vs. continue an existing one by omitting or providing thread_id. While it does not mention when not to use it or name explicit alternatives, the given guidance is actionable and sufficient for correct invocation in most cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the description does not need to restate safety. It adds the return contents (status, items, final agent message) which provides some behavioral context, but it does not disclose any edge cases or error behavior. With annotations covering safety, this is acceptable 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 a single, front-loaded sentence with no wasted words. It states exactly what the tool does and what it returns, making it easy to scan quickly.
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 read-only getter with an output schema present, the description is complete. It lists the key return elements and is consistent with the annotations. No additional information is needed for an agent to call this tool correctly.
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 parameter explanation. It does not explicitly define thread_id or turn_id, but the phrase 'for one Codex turn' gives context that these IDs identify the turn. The parameter names are self-explanatory, providing baseline understanding, but no additional detail or format is given.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the specific resource: 'status, items, and final agent message for one Codex turn.' This distinguishes it from sibling tools like get_codex_job (which operates at the job level) and list_codex_threads (which lists threads). The scope is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you need turn-level status, but it does not explicitly state when to use this tool versus alternatives like get_codex_job or read_codex_thread. No exclusions or conditions are provided, so an agent is left to infer the appropriate context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as read-only and idempotent. The description adds useful context: 'bounded' suggests a limited scope, and 'and its stat' informs the user that both diff and stat are returned. No contradiction with annotations observed.
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?
A single sentence with zero filler. The key action and scope are front-loaded, making it immediately scannable. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, the existing output schema, and safety annotations, the description covers the essential behavior. However, it does not mention that `project` is required or that `path` filters to a specific file, though these are evident from the schema. Minor gap.
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 mentions 'workspace or staged' which partially explains the `scope` parameter, but gives no detail on `path` or `project` beyond what the schema already shows. The compensation is incomplete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('return'), a clear resource ('diff'), and the scope ('workspace or staged'), which distinguishes it from siblings like git_status (status) and git_commit (committing). The purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use it (when you need a diff) but provides no explicit guidance on when to choose this tool over alternatives like git_status. It lacks exclusions or naming of sibling tools for comparison.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds valuable behavioral details beyond the annotations: 'always runs Codex in read-only mode' (redundant with readOnlyHint but reinforces) and 'server rejects paths outside that root' (security constraint). It also discloses that it returns immediately and that retrieval is separate, implying asynchronous behavior. This complements the annotations, which already cover read-only safety.
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 compact and well-structured: the first sentence states the core action immediately, followed by a second sentence clarifying constraints and the follow-up retrieval path. No redundant wording, and it front-loads the most important information first.
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 5 parameters and an output schema, but only 'project' is explained. The description omits guidance on 'attempt', 'step_id', and 'workflow_id', which could be crucial for workflow integration. While the return value is hinted (job ID) and the output schema likely covers it, input-side completeness is lacking for an agent to invoke correctly with intent.
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 schema description coverage at 0%, the description must compensate for parameter explanations. It only addresses 'project' ('The project is a path relative to the configured Codex root'). The other parameters (prompt, attempt, step_id, workflow_id) remain unexplained, limiting an agent's ability to set them correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: 'Start a read-only local Codex job and return its job ID immediately.' It specifies a distinct verb, resource type, and return value. By pointing to get_codex_job for retrieval, it distinguishes its role from that sibling, 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context by noting the project path constraint and read-only mode, and explicitly directs to use get_codex_job to retrieve results. However, it does not explicitly contrast with other start-like siblings (e.g., start_codex_job or start_codex_turn), so an agent may not know when to prefer this tool over those alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states what information is returned ('effective root, hard boundaries, and tool-use policy'), which adds specificity beyond the annotations. Since readOnlyHint=true and idempotentHint=true already signal that this is a safe, non-mutating operation, the description aligns with that and provides additional detail about the response. No additional behavioral context (e.g., side effects, authorization needs) is mentioned, but given the annotations cover the safety profile, this is acceptable.
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, compact sentence with no filler words. It directly names the key resources returned, and every word carries meaning. The structure is highly efficient and front-loaded with the core action. This meets the standard for a well-written, concise 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?
Given that the tool has no parameters and an output schema is present (as indicated by the context signals), the description does not need to elaborate on return format or edge cases. The one-sentence description fully covers what the tool does. The read-only and idempotent annotations further ensure the agent knows it is safe to call at any time. Nothing essential is missing.
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 per the rubric the baseline is 4. The description does not need to clarify any parameter meanings. The schema coverage is 100%, and there are no parameters to document. The description adds value by explaining what the response will contain, which is relevant even without inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Return') and identifies the exact resources ('effective root', 'hard boundaries', 'tool-use policy'). It clearly distinguishes this tool from the many other tools in the sibling list, which are focused on code execution, workflow management, or file operations. An agent can immediately understand the purpose without needing to inspect the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives, nor does it mention any context or exclusions. However, given the tool's obvious purpose as a read-only query for permissions, the usage is implied by the name and description. There are no competing sibling tools that appear to overlap in function, so the lack of explicit guidance is a minor gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true and idempotentHint=true. The description adds valuable behavioral context beyond these: path constraints to the root, exclusion of credential files, and types of files that are readable. This helps the agent understand both scope and limitations. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core action, then providing constraints. Every sentence earns its place; there is no redundancy or filler. The structure is optimal for quick comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With two simple parameters, an output schema, and annotations covering safety/idempotence, the description covers the essential context: what it reads, safety exclusions, and accessibility. It doesn't detail error behavior or return format, but the output schema exists, and these are minor for a read operation. The description is sufficiently complete for correct 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?
The schema has 0% description coverage for parameters, so the description must compensate. It does clarify that 'project' is the selected project and 'path' is the file path, and that both are constrained to the root. However, it does not specify whether the path is relative to the project root or absolute, nor does it give format examples. This is adequate but could be more explicit.
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 ('Read one UTF-8 text file') and the resource ('from a selected project'). It adds specific constraints (root path, credential exclusions) that distinguish it from sibling tools like write_file, apply_patch, and list_files. The purpose is unambiguous and not a tautology.
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 for when to use this tool: to read a UTF-8 text file within a project, with exclusions for credentials and permission for Git files, dependencies, and runtime config. It does not explicitly name alternatives, but the constraints imply when this tool is appropriate versus write/patch tools. The lack of explicit 'use instead of X' guidance prevents 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?
Annotations already declare readOnlyHint=true and idempotentHint=true, covering safety and idempotence. The description adds the behavioral detail that the tool does not access project files, which is useful context beyond annotations and aligns with the read-only nature. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, concise sentence that front-loads the core action ('Return bridge process health') and immediately adds the key constraint ('without accessing project files'). No wasted words, perfectly sized for a zero-parameter health check.
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 (no parameters), the presence of an output schema, and rich annotations, the description is complete. It tells the agent exactly what to expect and the key limitation, leaving nothing essential missing for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description has no parameter burden. The baseline for no parameters is 4, and the description correctly avoids inventing any parameters. The output schema provides return structure, so no additional parameter semantics needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Return'), a clear resource ('bridge process health'), and a distinguishing constraint ('without accessing project files'). It immediately tells the agent what the tool does and sets it apart from file-oriented siblings like list_files and read_file.
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 the tool is a health check but does not explicitly state when to use it versus alternatives or provide any context like 'use before other operations to verify connectivity.' The lack of explicit guidance leaves the agent to infer typical usage, which is acceptable but not exceptional.
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 crucial behavioral context beyond the annotations. It warns about high privilege, explains that no shell is inserted, and notes the executable can access paths outside the structured root. It also conveys the asynchronous nature by mentioning it returns an ID immediately, which is complemented by the annotations' destructive hint and openWorldHint. There is no contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficient and well-structured: the main action is stated in the first sentence, followed by a concise security warning and explicit pointer to related tools. Every sentence adds value and there is no fluff.
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 action, security context, and follow-up tools, and thanks to the output schema, return values are not required. However, with 7 parameters and zero schema descriptions, the lack of parameter explanations leaves a significant gap. An agent cannot confidently supply correct values for fields like step_id or workflow_id without additional context.
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 the meaning of 'argv' ('argv-based command job') but fails to explain other parameters such as project, cwd, timeout_seconds, step_id, workflow_id, and attempt. An agent would have to guess the purpose of several parameters without any guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'Start an argv-based command job and return its ID immediately.' This is a specific verb and resource, and it distinguishes the tool from siblings like run_tests or codex jobs by focusing on argv-based command execution. The reference to 'No shell is inserted' further clarifies its nature.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool: 'Use it only under the explicit policy returned by get_permissions.' It also names the follow-up tools, 'Use get_job for output and cancel_job to stop it,' providing clear guidance on the workflow. This effectively routes an agent to the correct sequence.
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 agent knows it's safe and deterministic. The description adds valuable behavioral context: credential files/directories are always excluded, and paths are relative to the selected project. It also explains the effect of include_all. No contradictions with annotations; the additional details go beyond what the annotations provide, though they don't cover all edge cases (e.g., whether it follows symlinks).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no fluff. The purpose is front-loaded, and the include_all behavior is explained in a compact sentence. Every word earns its place; it is concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a listing tool with a clear purpose, the description is complete. It covers the core behavior, parameter semantics, and constraints (credential exclusion, relative paths). The presence of an output schema likely details the return format, so the description doesn't need to. Nothing critical is missing for an agent to call this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain the parameters. It does: it explains include_all in detail ('includes dependencies, runtime state, Git internals, and caches') and clarifies that credential files are always excluded. For 'project', it notes 'Paths are relative to the selected project,' which gives context. This compensates well for the missing schema descriptions, though it could be more explicit about the project parameter's format (e.g., path vs. name).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'List readable files in a project under the configured structured root.' This specific verb ('list') and resource ('files') with the context of 'project' distinguishes it from sibling tools like read_file (which reads content) and write_file (which writes). The mention of 'readable files' and exclusion of credentials further sharpens the scope.
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: for enumerating files in a project with an option to include all (dependencies, caches, etc.). It does not explicitly name alternatives or state when not to use it, but the context signals make it clear it's for listing, not reading or modifying. The lack of explicit exclusions is a minor gap, but the 'under the configured structured root' constraint adds some usage context.
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:

[![local-agent-mcp MCP server](https://glama.ai/mcp/servers/ezra-y/local-agent-mcp/badges/card.svg)](https://glama.ai/mcp/servers/ezra-y/local-agent-mcp)

Score Badge

Copy to your README.md:

[![local-agent-mcp MCP server](https://glama.ai/mcp/servers/ezra-y/local-agent-mcp/badges/score.svg)](https://glama.ai/mcp/servers/ezra-y/local-agent-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/ezra-y/local-agent-mcp'

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