Agent Gateway MCP

by Kvxw1105

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

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

Latest release: v0.2.0
Disambiguation5/5
Each tool has a clear, distinct purpose. The generic agents_* tools manage asynchronous tasks, while kimi_* tools are specific to Kimi Code sessions; even similar operations like agents_resume and kimi_resume are differentiated by target system and description.
Naming Consistency5/5
All tools follow a consistent snake_case pattern with clear domain prefixes: agents_* for generic agent management and kimi_* for Kimi-specific operations. The pattern is predictable and uniform.
Tool Count5/5
With 11 tools, the server is well-scoped for its purpose of managing local CLI agents and Kimi sessions. The count falls within the ideal range and each tool serves a distinct function.
Completeness4/5
The generic agent lifecycle (spawn, resume, status, wait, logs, cancel) is complete, and Kimi-specific tools cover status, run, resume, and listing. Minor gaps exist, such as no explicit kimi_cancel, but the generic cancel may cover it, so core workflows are supported.
Average 3.9/5 across 11 of 11 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 5 commits in the last 12 weeks
- Last stable release on August 13, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under Apache 2.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries full burden. It only states 'Return the current state' without detailing behavior: whether it's non-blocking, what happens for unknown tasks, what the state values are, or any side effects. This is a thin disclosure for a tool that could have various internal behaviors.
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, immediately states the action, no filler. Perfectly concise for the information it conveys.
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 is simple with one parameter and no output schema, but the description lacks any mention of return format, error conditions, or how this compares to sibling status tools like kimi_status. For a status endpoint, it's adequate but leaves out details that could help an agent know what to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must explain the parameter. It says 'asynchronous agent task,' which adds context that task_id belongs to such a task, but it doesn't clarify how the ID is obtained, what format beyond UUID, or any special values. The description adds minimal value over the schema field 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?
Clear verb+resource: 'Return' the 'current state' of 'an asynchronous agent task.' It directly maps to status-checking and is distinct from sibling tools like agents_spawn (create) or agents_cancel (cancel).
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 usage context is implied: call this with a task_id to check on an async task. However, there's no explicit guidance on when to prefer this over agents_wait or agents_logs, or when it's not appropriate. The description doesn't name alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses asynchronous behavior, immediate task-id return, a read-only default, and the worktree constraint for parallel writes. However, it omits potential side effects (e.g., resource consumption), persistence details, error behavior, and how to manage the spawned agent beyond the implied sibling tools. These gaps keep it from being more transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short, front-loaded sentences. The first states the primary action and immediate result; the second adds critical usage constraints. No wasted words, and the structure is easy to scan.
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?
At 7 parameters with 14% schema coverage, no output schema, and no annotations, the description is too sparse. It covers the core async behavior and key constraints, but does not explain required parameters like provider and work_dir, how to monitor the resulting task, or what errors/timeouts might occur. For a tool that spawns a local CLI agent, this is insufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 14% (only isolated_worktree has a description). The description adds meaning for 'permission' via 'Use read-only unless edits are required' and for 'isolated_worktree' via 'independent Git worktrees', but it does not explain the purpose or valid values for provider, model, prompt, work_dir, or timeout_seconds. Given the low schema coverage, the description should have compensated more for these undocumented parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Start a local CLI agent asynchronously and return a task id immediately.' This uses a specific verb and resource, and distinguishes agents_spawn from sibling tools like agents_list, agents_status, and agents_cancel, which manage or query existing agents.
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 actionable guidance: 'Use read-only unless edits are required' clarifies the permission parameter's default and when to change it. 'Parallel write tasks must use independent Git worktrees' sets a clear precondition for concurrent writes. It stops short of explicitly naming alternatives or when to choose this tool over siblings, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses the core behavior (waiting until terminal state with a timeout bound) but does not disclose what happens on timeout, whether the call is read-only, or error handling for invalid task IDs. It adds some context beyond the name, but leaves gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence with no redundant words. It front-loads the action and resource immediately, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (2 flat params, no output schema), but without annotations or parameter descriptions, the description is thin. It omits what happens on timeout and what the function returns. A mid-level completeness score is appropriate given the minimal context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no parameter descriptions in the schema. The description does explain that wait_seconds bounds the wait, giving it meaning, but task_id is left implicit. With two parameters and no schema descriptions, the description only partially compensates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb ('Wait') and resource ('agent task'), and adds the key scope ('terminal state', 'bounded by wait_seconds'). This distinguishes it from siblings like agents_status, which likely just checks status, and agents_cancel.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for blocking until a task finishes, but does not explicitly state when to use it vs alternatives like agents_status for polling, nor does it mention any exclusions or alternatives. Sibling names are available but not referenced.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of disclosure. 'List' implies a read-only operation, but the description does not explicitly state non-mutating behavior or mention any side effects, error conditions, or response formats. It gives minimal transparency beyond the core action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 12 words, front-loaded with the main action. It avoids unnecessary detail and every word contributes meaning. This is exemplary conciseness.
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?
As a simple list tool with two optional parameters and no output schema, the description covers the purpose and the main filter but omits behavior around the limit parameter and the return format. It is adequate for a basic understanding but lacks details that would fully complete the 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 explains the purpose of the work_dir parameter ('filtered by working directory'), but never mentions the limit parameter, leaving it undocumented in both the schema and description. This is a significant gap for one of only two parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists local Kimi Code sessions and optionally filters by working directory. The verb 'list' is specific and the resource 'local Kimi Code sessions' is precise, differentiating it from sibling tools like kimi_status or kimi_run.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear context for when to use the tool (listing sessions) and mentions the optional filter, but does not explicitly state when not to use it or name alternatives. It lacks exclusionary guidance, so it stops short of 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?
The description discloses a key behavioral trait: the Kimi CLI may read, edit, and run commands in the working directory. This is critical side-effect information, especially with no annotations available. It also notes the session is non-interactive. However, it omits details about authentication, output handling, and session lifecycle.
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 the first sentence front-loading the purpose and the second delivering a concise warning. No redundant or filler content—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?
The tool executes potentially arbitrary commands in a working directory, yet the description does not explain what happens after starting the session, how results are returned, or that it may run asynchronously and require status checks via sibling tools. With no output schema and no annotations, the description leaves critical operational details uncovered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides descriptions for prompt and work_dir, though terse. The description adds value by advising to 'scope the prompt and work_dir carefully,' which implies their importance. However, the third parameter, timeout_seconds, is left completely unexplained, leaving a gap in parameter 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 specific action (start a new non-interactive session), the resource (Kimi Code agent), and the working directory. It distinguishes itself from sibling tools like kimi_resume (resuming sessions) and kimi_list_sessions by emphasizing 'start a new' and 'non-interactive'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for starting new sessions and warns to scope the prompt and work_dir carefully, but it does not explicitly mention when to use this tool instead of alternatives like agents_spawn or kimi_resume. No clear 'when not to use' guidance is provided.
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 transparency burden. It discloses a key behavioral scoping detail (does not affect TUI sessions) but omits other important aspects such as irreversibility, side effects on related tasks, permission requirements, or behavior when the task is already finished. The coverage is minimal but adequate for a simple cancel operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the main verb and resource, and each sentence serves a distinct purpose. There is no wasted wording, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema, and no annotations), the description covers the core action and a critical scoping exception. It could benefit from noting expected outcomes (e.g., whether cancellation is acknowledged) but is otherwise complete for its 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?
The input schema has 0% description coverage, so the description must compensate, but it does not mention the task_id parameter or provide any additional meaning beyond the schema's name and type. The parameter is self-explanatory, but the description adds no value to parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action with a specific verb and resource: 'Cancel a running agent task.' This distinguishes it from sibling tools like agents_list, agents_spawn, and agents_resume, which handle different operations. 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool (to cancel a running agent task) and includes an explicit exclusion: 'This does not attach to or modify unrelated interactive TUI sessions.' However, it does not explicitly name alternatives or offer when-not-to-use scenarios beyond the TUI caveat.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses that the tool creates 'a new asynchronous task' and warns against injecting into an open interactive TUI session, which are key behavioral traits. It does not mention side effects on the original session or permission requirements, but the primary operational behavior is clearly stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exactly two sentences: one stating the purpose and one providing a critical exclusion. It is front-loaded with the core verb and resource, with no wasted words.
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 tool with 8 parameters, no annotations, and no output schema, this description is incomplete. It omits parameter semantics, behavior on failure, and how to track or wait for the resulting asynchronous task, which are essential for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 8 parameters with 0% description coverage, yet the description only clarifies that session_id refers to a completed CLI agent session. The other parameters (provider, prompt, work_dir, model, permission, timeout_seconds, isolated_worktree) are left unexplained, so the description does not compensate for the schema's lack of parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'resume' targeting 'a completed CLI agent session' with the outcome 'as a new asynchronous task.' It also explicitly warns against using it with open interactive TUI sessions, which distinguishes it from other session-management tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It clearly states the tool is for resuming completed sessions and provides a strong when-not-to-use rule: 'Never use this to inject into a session still open in an interactive TUI.' However, it does not explicitly name an alternative tool to use for open sessions or for new sessions, only implying these are outside its scope.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses a critical behavioral risk—concurrent writers—that is not derivable from the schema or parameter names. It does not mention permissions or return values, but the race condition warning is highly valuable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only two sentences. The first states the core action, and the second adds a crucial caveat. Every word earns its place, and the purpose is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 4-parameter tool with no annotations and no output schema, the description is incomplete. It does not explain how to obtain session_id, what prompt or work_dir should be, or how timeout_seconds behaves. The warning is helpful but leaves major gaps for an agent to invoke 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?
Schema description coverage is 0%, and the description mentions none of the four parameters (session_id, prompt, work_dir, timeout_seconds). It provides no additional meaning beyond the parameter names themselves, failing to compensate for the lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Resume a Kimi Code session' with a clear verb and resource, and the 'Kimi Code' qualifier distinguishes it from sibling tools like agents_resume. It is immediately obvious what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says 'Do not resume a session that is still open in an interactive TUI' and gives the rationale ('two writers can race on the same session'). This is an actionable when-not guideline, though it does not name alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool checks callability and reports version, which implies a read-only operation. However, it does not mention error behavior, return format, or side effects (though likely none). This is adequate but not detailed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that communicates the core purpose without excess. Every word contributes.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with no parameters and no output schema. The description covers its main action and result. It could optionally detail the exact version output format, but that is a minor omission.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so there are no parameter semantics to convey. Per the rubric, a baseline of 4 is appropriate for zero-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Check' and identifies the resource 'local Kimi Code CLI', then specifies two outcomes: callability and version. This clearly distinguishes it from sibling tools like kimi_run and kimi_list_sessions, which perform different actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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 or list alternatives. It implies a pre-flight check, but there is no direct comparison to sibling tools or conditions for use. This 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?
With no annotations, the description carries the full burden. It clearly conveys a read-only listing action and scopes to local CLI agents while specifying the capability categories reported. It does not describe return format or error behavior, but for a simple list tool this is reasonable.
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, focused sentence that front-loads the verb and resource and conveys the key detail about capabilities. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-parameter read-only list, the description adequately explains what the tool returns (list of agents and their capabilities) without needing an output schema. It lacks formatting or error details, but they are not critical for such a simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline of 4 applies. The description does not need to explain parameter meanings and correctly avoids adding unnecessary information about them.
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 ('List') and clearly identifies the resource ('supported local CLI agents') and the specific capability categories (transport, resume, permission). This distinguishes it well from sibling tools like agents_spawn and agents_status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by mentioning 'resume and permission capabilities', which suggests it should be used before agents_resume or agents_spawn, but it does not explicitly state when to use this tool versus alternatives or any exclusions. This is implied usage, not explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey safety and side effects. 'Read' indicates a non-destructive operation, and the cursor mechanism implies logs are retained for incremental access. It does not detail edge cases like end-of-stream or error behavior, but the key trait (incremental read) is disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no redundancy. The first sentence states the core operation, and the second explains the continuation mechanism. All content is useful.
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 two-parameter log reader, the description is sufficient. It explains the input concept (cursor) and the expected behavior (incremental output). Although no output schema exists, the phrase 'returned cursor' implies the response contains a cursor, making the tool understandable end-to-end.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers task_id (required UUID) and cursor (integer) with minimal descriptions. The description adds meaning to cursor by explaining it is a character cursor and that passing the returned one fetches new output, effectively defining pagination. task_id is not elaborated but is self-evident from 'agent'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool's function: reading agent stdout/stderr using a character cursor. The verb 'Read' and resource 'agent stdout/stderr' are specific, and the cursor concept distinguishes it from sibling tools like agents_status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly instructs to pass the returned cursor to fetch only new output, providing usage context. However, it doesn't mention alternative tools or when not to use it, so there's no explicit exclusion or comparison.
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:

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

Score Badge

Copy to your README.md:

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

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