CLI Agent MCP

by shiharuharu

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: v1.0.0
Disambiguation4/5
Most tools have distinct purposes targeting different AI agents or functions (e.g., banana for image generation, claude for code implementation, get_gui_url for dashboard access). However, there is some overlap between 'banana' and 'image' as both handle text-to-image generation and editing, which could cause confusion despite different backend providers.
Naming Consistency3/5
The naming is mixed: some tools use simple names (banana, image, claude, codex, gemini, opencode), while others append '_parallel' for parallel execution variants (claude_parallel, codex_parallel, gemini_parallel, opencode_parallel). This pattern is somewhat consistent for parallel tools, but the base names lack a uniform verb_noun structure, making it less predictable overall.
Tool Count4/5
With 11 tools, the count is reasonable for a CLI agent server that orchestrates multiple AI agents and utilities. It covers core agents, their parallel versions, and auxiliary functions like image generation and GUI access, though it might be slightly heavy if some tools are rarely used.
Completeness4/5
The tool set provides good coverage for running various AI agents (claude, codex, gemini, opencode) with parallel execution options, plus image generation and GUI access. A minor gap is the lack of tools for managing agent sessions or configurations, but core workflows are well-supported.
Average 4.1/5 across 11 of 11 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- 0 of 1 community issues answered or closed in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
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

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool returns an HTTP URL, which is useful behavioral context. However, it lacks details on potential errors, authentication needs, or rate limits, leaving gaps for a tool that likely involves network access.
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 zero waste: it front-loads the core purpose and adds clarifying detail about the return value. Every sentence earns its place by providing essential information without 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?
Given the tool's simplicity (0 parameters, no output schema), the description is adequate but has gaps. It explains the return value but lacks context on error handling or integration with sibling tools. For a tool that likely fetches a URL, more behavioral details would enhance completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema description coverage is 100% (as there are no parameters to cover). The description does not need to add parameter semantics, so a baseline of 4 is appropriate, as it efficiently avoids redundancy.
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 specific action ('Get') and resource ('GUI dashboard URL'), and distinguishes its purpose by specifying it returns 'the HTTP URL where the live event viewer is accessible.' This is precise and unambiguous, avoiding tautology with the tool name.
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 (e.g., sibling tools like 'claude' or 'codex'), nor does it mention any prerequisites or exclusions. It only states what the tool does, leaving usage context implied at best.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key behaviors: results are appended to save_file with XML wrappers, tasks share workspace/permission/save_file, and model configuration options. However, it doesn't cover important aspects like error handling (beyond fail_fast), performance characteristics, or what happens when tasks exceed max concurrency.
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 appropriately sized with three sentences that each add value. It's front-loaded with the core purpose, followed by implementation details and configuration options. There's minimal waste, though the final sentence about model configuration could be slightly more concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex parallel execution tool with 11 parameters and no annotations or output schema, the description provides adequate but incomplete coverage. It explains the parallel nature and some behavioral aspects, but doesn't address error scenarios, output interpretation beyond XML wrappers, or how results from multiple tasks are organized in the save_file.
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 100% schema description coverage, the schema already documents all 11 parameters thoroughly. The description adds minimal value beyond the schema - it mentions the model array behavior and max 100 tasks limit (which is also in the schema). The baseline of 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Run multiple gemini tasks in parallel') and distinguishes it from its sibling 'gemini' by emphasizing parallel execution. It specifies the resource (gemini tasks) and scope (max 100 tasks, shared workspace/permission/save_file).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool (parallel execution of multiple tasks) and implicitly distinguishes it from non-parallel alternatives like 'gemini'. However, it doesn't explicitly state when NOT to use it or name specific alternative tools for different scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does well by disclosing key behaviors: 'Images are saved to disk (no base64 in response)', 'Returns XML with file paths', and mentions capabilities like style transfer and multi-image fusion. It doesn't cover rate limits or authentication needs, but provides substantial operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (CAPABILITIES, RESPONSE FORMAT, BEST PRACTICES) and every sentence earns its place by providing actionable information. It's appropriately sized for a complex tool without unnecessary verbosity, making it easy to scan and understand.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (12 parameters, no output schema, no annotations), the description does a strong job covering capabilities, response format, and best practices. It could benefit from more explicit error handling or performance characteristics, but provides sufficient context for effective use despite the missing structured fields.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 12 parameters thoroughly. The description adds minimal parameter-specific information beyond the schema (e.g., briefly mentions reference images with roles), but doesn't provide significant additional semantic value. This meets the baseline for high schema coverage.
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 'Generate images using Nano Banana Pro (Gemini 3 Pro Image)' which specifies the verb (generate) and resource (images) with the specific model. However, it doesn't explicitly differentiate from sibling tools like 'image' or 'gemini' which might also handle image-related tasks, preventing a perfect score.
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 'BEST PRACTICES' section provides clear guidance on when and how to use the tool effectively (e.g., 'Be descriptive', 'Use negative constraints', 'For editing: provide reference image'). It doesn't explicitly mention when NOT to use it or name specific alternatives among siblings, but the practical advice is comprehensive for proper usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key behaviors: output format with XML wrappers, shared resource model, task limits, and model configuration options. It doesn't cover error handling, performance characteristics, or authentication needs, but provides substantial operational context for a complex parallel execution tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured in three sentences that cover purpose, output format, and key constraints. Each sentence adds value without redundancy. While dense, it's appropriately sized for a complex parallel execution tool with many parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex 14-parameter tool with no annotations and no output schema, the description provides good operational context but lacks information about return values, error responses, or performance expectations. It covers the parallel execution model and output formatting well, but doesn't fully compensate for the missing structured metadata about this mutation-capable tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the schema already documents all 14 parameters thoroughly. The description adds minimal parameter-specific information beyond the schema, mentioning only that 'Model can be array: single element shared by all, or one per task' and output formatting details. This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Run multiple claude tasks in parallel' with specific details about shared resources and output format. It distinguishes from siblings like 'claude' (single task) and 'codex_parallel' (different model family), making the scope and differentiation explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool ('All tasks share workspace/permission/save_file') and mentions capacity limits ('Max 100 tasks'). However, it doesn't explicitly state when NOT to use it or name alternatives like 'claude' for single tasks, though the parallel nature is implied as the distinguishing factor.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and does well at disclosing key behavioral traits: results are appended to save_file with XML wrappers, max 100 tasks, model can be array with sharing options, and tasks run as independent subprocesses. It doesn't mention error handling beyond fail_fast or performance characteristics, but covers the essential execution model.
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 appropriately sized with three sentences that each add value: first states core functionality, second describes output format and limits, third explains model configuration. It's front-loaded with the main purpose and avoids unnecessary repetition. Could be slightly more structured but efficiently conveys key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex parallel execution tool with 12 parameters and no annotations/output_schema, the description provides good coverage of the execution model, output format, and constraints. It explains the parallel nature, resource sharing, and key limitations. Missing details about error responses or specific use cases, but covers the essential operational context given the complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 12 parameters thoroughly. The description adds minimal parameter-specific information beyond the schema, mentioning only the model array behavior and XML output format. It doesn't provide additional semantic context about how parameters interact or usage patterns.
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: 'Run multiple codex tasks in parallel' with specific details about shared workspace/permission/save_file and XML output formatting. It distinguishes from sibling tools like 'codex' (single task) and 'claude_parallel' (different model family) by specifying it's for codex tasks with parallel execution.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context about when to use this tool: for running multiple codex tasks concurrently with shared resources. It mentions the 100-task limit and model configuration options. However, it doesn't explicitly state when NOT to use it or name specific alternatives among siblings like 'codex' for single tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and does well by disclosing key behavioral traits: it describes the response format (XML with file paths, images saved to disk), mentions that images are saved rather than returned as base64, and includes best practices for effective usage. It doesn't cover rate limits, authentication needs, or error handling, but provides substantial operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (CAPABILITIES, RESPONSE FORMAT, BEST PRACTICES) and efficiently conveys information. While slightly longer than minimal, each section adds value and the structure helps with quick scanning. The final 'Supports:' line feels redundant but doesn't significantly detract.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex 9-parameter tool with no annotations and no output schema, the description provides substantial context about capabilities, response format, and best practices. It covers the tool's scope well but doesn't address potential limitations, error cases, or provide examples of the XML response structure that would help the agent understand what to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 9 parameters thoroughly. The description adds some context about reference images for editing and general capabilities, but doesn't provide additional parameter semantics beyond what's in the schema. This meets the baseline expectation when schema coverage is complete.
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 as 'Generate images via OpenRouter-compatible or OpenAI-compatible endpoints' with specific capabilities listed including text-to-image generation, image editing, and multiple aspect ratios/resolutions. It distinguishes from sibling tools (which appear to be text/chat models) by focusing exclusively on image generation and manipulation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool (image generation and editing) and includes 'BEST PRACTICES' section with specific guidance on prompt construction and editing workflows. However, it doesn't explicitly state when NOT to use this tool or name alternatives for similar functionality.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure and does so comprehensively. It details critical behavioral traits: memory limitations ('NO SHARED MEMORY'), what the agent can see, cross-agent handoff procedures, capabilities, best practices, and supported features. This goes well beyond basic functionality to explain how the tool behaves in practice.
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 well-structured with clear sections (NO SHARED MEMORY, CROSS-AGENT HANDOFF, etc.), but it's quite lengthy at 12 sentences. While most content is valuable given the tool's complexity, some sentences could be more concise (e.g., the capabilities section lists three bullet points that could be condensed). It's front-loaded with critical information but could be tighter overall.
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 high complexity (14 parameters, no annotations, no output schema), the description provides substantial context about behavioral characteristics, usage patterns, and limitations. It covers memory constraints, handoff procedures, capabilities, and best practices. The main gap is lack of output format information, but otherwise it's quite complete for helping an agent understand when and how to use this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 14 parameters thoroughly. The description doesn't add significant parameter-specific information beyond what's in the schema. It mentions concepts like 'context_paths' and 'file attachments' generally but doesn't explain individual parameters. The baseline of 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Run OpenCode CLI agent (full-stack development).' It specifies the verb ('Run') and resource ('OpenCode CLI agent') with additional context about its domain ('full-stack development'). However, it doesn't explicitly differentiate from sibling tools like 'codex' or 'gemini' beyond mentioning OpenCode supports multiple AI providers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides excellent usage guidelines. It explicitly states when to use this tool: 'Excellent at rapid prototyping and development tasks' and 'Good at working with multiple frameworks and tools.' It offers best practices like 'Specify agent type for specialized tasks' and 'Use file attachments for context-heavy tasks.' It also details cross-agent handoff procedures for small vs. large data, giving clear operational guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key behaviors: results are appended to save_file with XML wrappers, tasks share workspace/permission/save_file, and there's a max of 100 tasks. It also explains the model array behavior. However, it doesn't mention error handling, performance implications, or what happens when tasks fail beyond the parallel_fail_fast parameter.
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 efficiently structured in three sentences that each earn their place: first establishes the core functionality, second describes the output format and constraints, third explains the model parameter behavior. No wasted words, front-loaded with the most important information about parallel execution.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex tool with 13 parameters, no annotations, and no output schema, the description does well by covering the parallel nature, shared resources, output format, and model behavior. However, it doesn't explain what the tool returns (only mentions output is written to save_file) or provide guidance on error scenarios, leaving some gaps in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the baseline is 3. The description adds some value by explaining that 'All tasks share workspace/permission/save_file' and mentioning the model array behavior, but it doesn't provide significant additional parameter semantics beyond what's already thoroughly documented in the schema descriptions for all 13 parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Run multiple opencode tasks in parallel') and distinguishes it from its sibling 'opencode' by emphasizing parallel execution and shared workspace/permission/save_file. It also mentions the XML output format and max task limit, providing a comprehensive purpose statement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool (for parallel execution of opencode tasks) and mentions the max 100 tasks limit. However, it doesn't explicitly state when NOT to use it or name specific alternatives among the sibling tools (like 'opencode' for single tasks or other *_parallel variants), which prevents a perfect score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and delivers comprehensive behavioral disclosure. It explains critical constraints (no shared memory, agent-specific continuation IDs), security implications through permission parameter context, cross-agent collaboration patterns, and practical limitations like context overflow management. This goes well beyond basic functional description.
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 well-structured with clear sections (NO SHARED MEMORY, CROSS-AGENT HANDOFF, CAPABILITIES, BEST PRACTICES, Supports) that make information easy to find. While comprehensive, some sections could be more concise - the CAPABILITIES and BEST PRACTICES sections contain some redundancy with the opening statement. Overall, most sentences earn their place by adding important operational context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex 15-parameter tool with no annotations and no output schema, the description provides substantial context about behavioral constraints, collaboration patterns, and practical usage. It effectively compensates for the lack of structured metadata. The main gap is not explaining return values or output format, but given the tool's nature as an agent runner, the operational context provided is quite complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 15 parameters thoroughly. The description adds some context about parameter usage (e.g., prompt context requirements, save_file benefits, cross-agent considerations), but doesn't provide significant semantic value beyond what's in the parameter descriptions themselves. Baseline 3 is appropriate given complete schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Run Anthropic Claude CLI agent (code implementation)' - a specific verb+resource combination. It distinguishes Claude from other agents by highlighting its unique capabilities ('Strongest code writing and implementation abilities'), but doesn't explicitly differentiate from all sibling tools like codex or gemini beyond mentioning they have separate memory spaces.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides excellent usage guidance with explicit when/when-not scenarios. It explains memory limitations ('NO SHARED MEMORY'), cross-agent handoff procedures, when to use save_file vs prompt inclusion, and best practices for code replacement and cleanup. It clearly defines the tool's specific role among agents based on capabilities.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure and does so comprehensively. It clearly explains the 'NO SHARED MEMORY' constraint, cross-agent handoff procedures, specific capabilities, and best practices. This provides crucial operational context that isn't captured in the input schema alone.
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 well-structured with clear sections (NO SHARED MEMORY, CROSS-AGENT HANDOFF, CAPABILITIES, BEST PRACTICES) and uses bullet points effectively. While comprehensive, some sections could be more concise, but overall it's efficiently organized with minimal redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex 12-parameter tool with no annotations and no output schema, the description provides substantial operational context about memory limitations, multi-agent workflows, and capability strengths. However, it doesn't explain what the tool returns (output format) or error handling, which would be helpful given the absence of an 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?
The schema description coverage is 100%, so the schema already documents all 12 parameters thoroughly. The description doesn't add any parameter-specific information beyond what's in the schema. However, it does provide important context about how parameters like 'continuation_id' and 'context_paths' fit into the broader multi-agent workflow.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Run Google Gemini CLI agent (UI design / comprehensive analysis).' It specifies the agent type and its primary capabilities. However, it doesn't explicitly distinguish this tool from its siblings like 'claude' or 'codex' beyond mentioning Gemini's specific strengths.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides excellent usage guidance with explicit when-to-use recommendations: 'Good first choice for "understand this codebase" tasks' and lists specific capabilities where Gemini excels (UI design, image understanding, rapid prototyping, full-text analysis). It also explains cross-agent handoff procedures and memory limitations, giving clear operational context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure and does so comprehensively. It explains memory limitations ('NO SHARED MEMORY'), cross-agent handoff procedures, capabilities, best practices, and even notes 'Supports: image attachments.' This provides rich behavioral context beyond what any structured annotations would typically cover.
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 well-structured with clear sections (NO SHARED MEMORY, CROSS-AGENT HANDOFF, CAPABILITIES, BEST PRACTICES) and uses bullet points for readability. While comprehensive, it could be slightly more concise as some information (like cross-agent handoff details) might be inferred from the tool's purpose. Every sentence earns its place by providing essential operational context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of this tool (13 parameters, no annotations, no output schema), the description provides complete contextual information. It explains the agent's capabilities, limitations, memory behavior, cross-agent workflows, and best practices. This fully compensates for the lack of annotations and output schema, making the tool's behavior and appropriate usage clear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 13 parameters thoroughly. The description doesn't add any parameter-specific information beyond what's in the schema. However, it does provide important context about how parameters like 'prompt' and 'continuation_id' interact with the agent's memory limitations, which adds some semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Run OpenAI Codex CLI agent (deep analysis / critical review).' It specifies the exact action ('Run') and resource ('OpenAI Codex CLI agent'), and distinguishes it from siblings by highlighting its unique capabilities ('Strongest deep analysis and reflection abilities', 'Excellent at finding issues, edge cases, and potential bugs', 'Good at critical code review and architectural assessment').
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool vs alternatives. It states 'NO SHARED MEMORY' and clarifies what the agent can see, specifies 'CROSS-AGENT HANDOFF' procedures for small vs large data, lists 'CAPABILITIES' that make it suitable for specific tasks, and gives 'BEST PRACTICES' for effective use. It also distinguishes from siblings by noting it 'Cannot see messages/outputs from gemini/claude/opencode'.
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:

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

Score Badge

Copy to your README.md:

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

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