Skip to main content
Glama
SinanTufekci

agent-intern

by SinanTufekci
OverviewSchemaRelated ServersScoreDiscussions
Python
Local

Server Quality Checklist

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

  • Latest release: v0.28.0

  • Disambiguation5/5

    Every tool follows a clear backend+action triad (ask/continue/status), so agents can easily distinguish new sessions, resumed sessions, and diagnostics for each backend. The image, image-swarm, and cross-backend swarm tools are also clearly separated by their prompt types and return values.

    Naming Consistency4/5

    The dominant pattern is highly predictable: {backend}_ask, {backend}_continue, {backend}_status. Minor deviations exist in agent_swarm, antigravity_image, and antigravity_image_swarm, which use noun-style names rather than a verb action.

    Tool Count4/5

    At 21 tools this is above the typical well-scoped range, but the count is structural: six backends × ask/continue/status plus three swarm/image extras. For a multi-backend bridge this is reasonable, though slightly heavy.

    Completeness5/5

    Each backeed has full lifecycle coverage: start a new session, resume the workspace session, and check diagnostics without spending quota. The swarm and image tools extend the surface naturally, and no obvious required operation is missing for the server's stated purpose.

  • Average 4.4/5 across 21 of 21 tools scored.

    See the Tool Scores section below for per-tool breakdowns.

    • 2 of 2 community issues answered or closed in the last 6 months
    • 127 commits in the last 12 weeks
    • Last stable release on
    • 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

  • Behavior3/5

    Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

    Annotations already carry the safety profile (readOnlyHint=false, openWorldHint=true, idempotentHint=false), and the description adds useful context about silent authentication via Windows Credential Manager and the text response format. It does not explicitly state in the top-level text that normal runs can execute commands or mutate the workspace, though 'tool-calling' and the schema's plan/watch caveats hint at that behavior; there is no contradiction with 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 top-level description is four short sentences, front-loaded with purpose and scope, with no filler. It adds auth, output-format, and usage-context information without repeating the schema.

    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 rich parameter descriptions, annotations, and an output schema, the definition gives an agent what it needs to select and call the tool correctly. The remaining gaps are that the top-level description does not summarize the potential side-effect/no-sandbox behavior of normal mode, and the choice versus `antigravity_continue` is left implicit.

    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 parameter descriptions already carry the semantics: plan-mode caveats, model-slug validation, structured-output behavior, workspace, and timeout. The top-level description adds only the 'bigger model for heavier reasoning' hint, which is useful but not necessary beyond what the schema provides.

    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?

    States a clear action ('Ask Antigravity'), the underlying CLI (agy, Gemini by default), and the scoping trait 'NEW conversation', which separates it from `antigravity_continue`. It also names the expected output (final response as text) and typical use ('fast tool-calling and short tasks'), so an agent can tell what this tool is 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 Guidelines4/5

    Does the description explain when to use this tool, when not to, or what alternatives exist?

    Gives explicit context: use it for fast tool-calling and short tasks, and for heavier reasoning pick a bigger model or use the host model directly. The 'new conversation' phrasing implies it is not for continuing an existing thread, but it never names `antigravity_continue` or states a hard exclusion, so alternatives are only implicit.

    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 annotations (readOnlyHint false, openWorldHint true), the description adds valuable behavioral context: it consumes AI Pro quota, saves the image, returns path/format/size, and notes that the extension may be corrected. It also mentions unsandboxed session and same privileges as other tools.

    Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

    Conciseness5/5

    Is the description appropriately sized, front-loaded, and free of redundancy?

    The description is concise, with two paragraphs that front-load the main purpose. Every sentence adds essential information (quota, file output, format behavior, security note). No redundancy or fluff.

    Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

    Completeness4/5

    Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

    The description covers key aspects: output details (path, format, byte size), format selection, execution context (unsandboxed, same privileges), and quota usage. It references a security note from elsewhere. An output schema exists but is not shown; still, the description sufficiently explains return values.

    Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

    Parameters3/5

    Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

    Schema coverage is 100%, so the description adds minimal extra detail for parameters. It restates that output_path can be absolute/relative and timeout_s default is 240, but these are already in the schema. The format correction note is a minor addition.

    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 that the tool generates an image using Antigravity (Gemini image model via agy CLI). It distinguishes itself from sibling tools like antigravity_ask (text generation) and antigravity_image_swarm by focusing on single image generation with file saving.

    Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

    Usage Guidelines3/5

    Does the description explain when to use this tool, when not to, or what alternatives exist?

    The description explains the tool's behavior (quota usage, file path return) but does not explicitly state when to use this tool versus alternatives like antigravity_image_swarm. It lacks guidance on appropriate prompts or 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?

    The description discloses file extension correction, concurrency limits, timeout, return format (path/format/size/error), and unsandboxed privileges. Annotations provide readOnlyHint and openWorldHint, which are consistent.

    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 front-loaded with the core purpose, uses brief paragraphs, and avoids fluff. However, it repeats 'like antigravity_image' and could be slightly more streamlined.

    Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

    Completeness4/5

    Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

    Given the output schema exists, the description sufficiently covers behavioral details, parameter defaults, concurrency, and workspace handling. It is complete for a tool with 6 parameters.

    Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

    Parameters3/5

    Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

    Schema coverage is 100% and descriptions are thorough. The tool description adds little extra beyond what the schema already provides, such as the listing of return values but not parameter-specific details.

    Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

    Purpose5/5

    Does the description clearly state what the tool does and how it differs from similar tools?

    The description clearly states the tool generates several images in parallel, differentiating from antigravity_image. It specifies each prompt runs in an isolated worker, and returns a block listing results. This distinguishes it from siblings.

    Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

    Usage Guidelines4/5

    Does the description explain when to use this tool, when not to, or what alternatives exist?

    The description explains when to use this tool (for parallel image generation) and compares to antigravity_image and antigravity_swarm. However, it does not explicitly state when not to use it or mention alternatives like sequential generation.

    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 annotations, the description discloses important behaviors: session pinning via grok_ask's id, fallback to cwd, persistence across server restarts, per-invocation permission flags, and the sandbox's effect. It also notes the experimental caveat and auth requirement, adding value over the structured annotations which only indicate openWorld and read-only state.

    Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

    Conciseness4/5

    Is the description appropriately sized, front-loaded, and free of redundancy?

    The description is a compact paragraph that front-loads the purpose and then provides necessary technical details. Each sentence contributes useful information — purpose, session mechanism, permission behavior, and experimental caveat — without redundancy or fluff.

    Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

    Completeness4/5

    Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

    Given the presence of a detailed input schema, annotations, and an output schema, the description is complete enough. It covers the core behavior, session continuity, permission handling, and caveats. It doesn't discuss edge cases like missing prior sessions, but the fallback mechanism partially addresses that, and the experimental tag signals volatility.

    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?

    All 5 parameters are fully described in the schema (100% coverage), so the description has little additional semantic burden. It adds one clarifying note that 'sandbox takes effect here too' and ties it to a workflow, but this is marginal relative to the schema's already explicit parameter descriptions.

    Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

    Purpose5/5

    Does the description clearly state what the tool does and how it differs from similar tools?

    The description opens with 'Continue the Grok session rooted at this workspace', which clearly specifies the verb (continue), the resource (Grok session), and the scope (rooted at this workspace). It further explains the mechanics (resuming via session id or fallback to cwd), distinguishing it from sibling tools like grok_ask and grok_status.

    Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

    Usage Guidelines4/5

    Does the description explain when to use this tool, when not to, or what alternatives exist?

    The description provides clear context: it is for continuing an existing session, references the companion grok_ask for read-only analysis, and explicitly recommends using 'workspace-write' to apply fixes. It lacks explicit 'when not to use' or named alternatives beyond grok_ask, but the workflow guidance is strong.

    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 indicate mutation and external access, and the description adds context: it uses Cursor CLI, returns stdout, explains sandbox modes (including agent-enforced but not hard boundary), and mentions streaming via watch. This provides valuable behavioral insight beyond the structured annotations.

    Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

    Conciseness5/5

    Is the description appropriately sized, front-loaded, and free of redundancy?

    The description is two concise sentences in the first paragraph, front-loading the core purpose. Every sentence adds necessary context without redundancy. It is well-structured and 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 complexity (6 parameters, output schema exists), the description covers purpose, authentication, return behavior, and basic use. It lacks explicit error handling or timeout details, but the schema covers most parameters. Overall, it provides sufficient context for an AI agent to use the tool effectively.

    Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

    Parameters4/5

    Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

    Schema coverage is 100% with detailed parameter descriptions. The description adds value by noting that workspace enables context-aware answers and linking to cursor_status for auth, supplementing the schema. It does not repeat schema information unnecessarily.

    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 'Ask the Cursor CLI a question or task in a NEW chat', specifying the verb and resource. It distinguishes from sibling 'cursor_continue' by emphasizing 'new chat' and mentions return value and authentication, making the purpose unambiguous.

    Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

    Usage Guidelines3/5

    Does the description explain when to use this tool, when not to, or what alternatives exist?

    The description implies usage for new conversations but does not explicitly state when not to use it or provide alternatives. It references 'cursor_status' for auth but lacks direct comparison with 'cursor_continue'. The guidance is implied but not explicit, warranting a mid-range score.

    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 signal mutating, open-world, non-idempotent behavior. The description adds useful behavioral context: the exact conversation id routing, version-dependent behavior on agy 1.1.8+, and the guarantee that it resumes THIS thread even if a separate conversation was started in the same folder. 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 short, purposeful paragraphs. The first states the core purpose; the second adds a necessary edge-case clarification about global 'most recent' versus the exact conversation thread. Every sentence earns its place with no filler.

    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?

    With 100% schema coverage, rich per-parameter descriptions, an output schema, and safety/open-world annotations, the description only needs to disambiguate conversation routing behavior, which it does thoroughly. It is complete enough for an agent to select and invoke the 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?

    Schema description coverage is 100%, and each parameter already has a detailed description, so the tool description does not need to explain parameters. It adds some conceptual context about how workspace maps to the recorded conversation id, but the schema carries the semantic load.

    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 exactly what the tool does: 'Continue the Antigravity conversation rooted at this workspace' and explains it resumes the exact conversation id recorded for the workspace. This clearly distinguishes it from starting a new ask and from other sibling tools.

    Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

    Usage Guidelines4/5

    Does the description explain when to use this tool, when not to, or what alternatives exist?

    The first sentence frames when to use the tool, and the second paragraph clarifies that it uses the workspace-recorded conversation id rather than agy's global 'most recent', preventing common misuse. It does not explicitly name antigravity_ask as the alternative for starting new conversations, so it stops short of full when/not guidance.

    Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

  • Behavior4/5

    Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

    Beyond the annotations (readOnlyHint=false, openWorldHint=true), the description adds meaningful behavioral details: the tool uses an existing Codex login, returns only the final message read from `--output-last-message`, and does not use stdout scraping. It also hints at potentially heavy execution with 'real code work.' No contradiction with annotations; some safety specifics live in parameter descriptions, but the core behavioral traits are 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?

    The description is compact and front-loaded: the first sentence states the core action and session type. Every subsequent sentence earns its place—login prerequisite, output mechanism, use-case guidance, and workspace advice. No filler or repetition of schema content.

    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 tool that launches a coding agent, the description covers the key operational context: new session, login requirement, output retrieval method, suitability for heavy reasoning, and workspace recommendation. An output schema exists, so return-value detail is not required, and the sandbox/window caveats are handled in the parameter descriptions. An agent has enough information to invoke it correctly and set expectations.

    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%, and the schema itself provides rich parameter descriptions (e.g., sandbox policies, watch behavior, timeout). The main description adds a small strategic tip about `workspace` ('Point workspace at a real project dir'), but otherwise does not need to compensate. This matches the baseline for fully documented schemas.

    Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

    Purpose5/5

    Does the description clearly state what the tool does and how it differs from similar tools?

    The description opens with a specific verb-resource pair: 'Ask OpenAI Codex a question or task in a NEW session.' It distinguishes this from siblings by emphasizing 'NEW session,' which clearly separates it from codex_continue and other agent ask tools. The additional context that it uses `codex exec` and returns the final message makes the tool's intent unmistakable.

    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 it: 'suits heavier reasoning and real code work, not just cheap tool-calling.' It also advises pointing `workspace` at a real project directory for context-aware answers. However, it does not explicitly name alternatives or state when not to use it, so it falls just short of full exclusionary guidance.

    Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

  • Behavior4/5

    Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

    The description reveals behavioral traits beyond annotations: it resumes the exact session ID, falls back to the newest on-disk session, and re-applies permission flags each call. This adds value over the annotations (readOnlyHint=false, openWorldHint=true) which do not specify these details. 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 concise with two short paragraphs. The first sentence immediately states the core purpose. The second paragraph adds crucial differentiation without redundancy. Every sentence provides value, and the information is front-loaded.

    Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

    Completeness5/5

    Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

    Given the tool has an output schema and high schema coverage, the description covers all necessary context: session resumption, workspace fallback, permission behavior, and comparison to codex_continue. It is complete for an AI agent to understand when and how to use the 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?

    Schema description coverage is 100%, so baseline is 3. The description adds no extra parameter details beyond the schema, but it does reinforce that 'sandbox' takes effect here, which is already in the schema. The parameter meaning is well-covered by schema descriptions themselves, so no need for more.

    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 continues a GitHub Copilot session rooted at a workspace, resuming its session ID. It distinguishes itself from siblings like codex_continue by mentioning permission re-application. The title 'Continue GitHub Copilot session' further clarifies the purpose.

    Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

    Usage Guidelines4/5

    Does the description explain when to use this tool, when not to, or what alternatives exist?

    The description explains when to use this tool: after a copilot_ask, and when you want sandbox permissions to take effect. It contrasts with codex_continue, but does not explicitly list scenarios where alternatives like antigravity_continue are preferred. The fallback behavior after restart is noted, providing 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 indicate readOnlyHint false, openWorldHint true, idempotentHint false. Description adds useful behavioral details: uses existing login, returns stdout from CLI in silent mode, best-effort watch option, and notes sandbox is not a hard boundary. 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.

    Conciseness4/5

    Is the description appropriately sized, front-loaded, and free of redundancy?

    Description is front-loaded with the key action and well-structured, though it could be slightly more concise without losing important details.

    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 (6 params, output schema, siblings), the description covers purpose, usage, parameters, and output. It lacks explicit error handling but is otherwise sufficiently complete.

    Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

    Parameters5/5

    Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

    All 6 parameters have schema descriptions (100% coverage), and the description adds context beyond schema, such as explaining model validation limitations, sandbox distinctions from codex, and workspace usage for context-aware answers.

    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 'Ask the GitHub Copilot CLI a question or task in a NEW session,' specifying the verb, resource, and distinguishing from sibling tools like copilot_continue.

    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 advises using the tool for real code/repo work with workspace context, and mentions alternatives like copilot_status for login. It warns about model validation errors, but could more explicitly say when not to use.

    Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

  • Behavior5/5

    Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

    Beyond annotations, the description discloses the experimental status ('has never completed an authenticated round-trip'), warns that it may misbehave and asks to report issues, and states it returns the agent's final message from `--output-format json`. This adds meaningful risk and behavior context not present in structured hints.

    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 front-loaded with the core purpose and experimental warning in the first paragraph; the second paragraph covers auth, output, and workspace usage. Each sentence is substantive, though slightly verbose.

    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 complexity, the rich schema/annotations/output schema, and the experimental nature, the description covers the essential risk factors, auth, output, and workspace guidance. It is complete enough for an agent to decide and invoke it safely.

    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 descriptions cover 100% of parameters with detailed explanations (e.g., sandbox profiles, watch streaming). The description adds no extra parameter meaning beyond a passing mention of workspace location, so baseline 3 applies.

    Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

    Purpose5/5

    Does the description clearly state what the tool does and how it differs from similar tools?

    The description opens with a specific verb+resource: 'Ask Grok Build (`grok -p`) a question or task in a NEW session.' This clearly distinguishes it from grok_continue (explicit 'NEW session') and grok_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 states prerequisites ('Needs a SuperGrok / X Premium+ login... or an XAI_API_KEY env var'), directs the agent to 'run `grok_status` first,' and suggests pointing workspace at project dir for context-aware answers. It doesn't explicitly name the alternative for continuing sessions, but the 'NEW session' wording implies the boundary.

    Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

  • Behavior5/5

    Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

    Annotations already flag readOnlyHint=false, openWorldHint=true, idempotentHint=false, but the description adds substantial behavioral context: the tool is experimental and community-verified only, no authenticated round-trip has ever been run, it requires authentication, reads output from stdout, and — critically — 'has NO sandbox and auto-executes every tool call (like antigravity).' This goes well beyond the annotations and fully warns the agent of the tool's dangerous side effects.

    Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

    Conciseness4/5

    Is the description appropriately sized, front-loaded, and free of redundancy?

    The description is longer than average but every sentence contributes meaningful information: purpose, experimental status, auth steps, return format, what Kimi Code is, workspace tip, and a critical safety warning. It is front-loaded with the primary action and uses line breaks to separate warnings. Slightly verbose but justified by the tool's complexity and risk.

    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 experimental, unauthenticated, and dangerous nature, the description is remarkably complete. It explains the output (agent's final message from stdout), prerequisites, the safety model (no sandbox, auto-execution), and how to get better results (workspace). The presence of an output schema reduces the need to describe return values, and the description covers the rest comprehensively.

    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 all four parameters (model, prompt, timeout_s, workspace) are already documented. The description adds one useful hint for the workspace parameter ('point workspace at a project dir for context-aware answers'), but adds nothing new for prompt, model, or timeout_s. With high schema coverage, this marginal extra keeps it at baseline 3.

    Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

    Purpose5/5

    Does the description clearly state what the tool does and how it differs from similar tools?

    The description opens with a specific verb-resource pairing: 'Ask Kimi Code... a question or task in a NEW session.' This clearly distinguishes the tool from the sibling kimi_continue (which presumably continues a session) and kimi_status. It also names the underlying command (`kimi -p`) and states what it returns, making the tool's function 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 phrase 'in a NEW session' provides clear context for when to use this tool versus continuation alternatives, even though no alternative is explicitly named. It also gives prerequisites (authentication via `kimi login` or API key, then checking `kimi_status`) and a safety restriction ('run it only with trusted prompts on trusted content'). Missing an explicit 'use kimi_continue instead' but otherwise strong.

    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 valuable behavioral context beyond annotations: it explains session resumption logic, fallback behavior, and that the session keeps its original sandbox and model. No contradictions with annotations (readOnlyHint=false, idempotentHint=false, openWorldHint=true) are present.

    Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

    Conciseness5/5

    Is the description appropriately sized, front-loaded, and free of redundancy?

    The description is concise, with two short paragraphs. The first sentence front-loads the primary purpose. Every sentence adds value, with no redundant or irrelevant information.

    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 complexity (4 parameters, 1 required), schema coverage (100%), and the presence of an output schema, the description covers all key aspects: session identification, fallback, behavior after restart, and preservation of original settings. It is complete for an agent to correctly invoke the 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 baseline is 3. The description does not add significant extra meaning for parameters beyond what is already in the input schema schema. It provides context around workspace defaults and timeout, but these are already described in the schema.

    Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

    Purpose5/5

    Does the description clearly state what the tool does and how it differs from similar tools?

    The description clearly states that the tool continues an existing Codex session, using a specific command (`codex exec resume`). It distinguishes from sibling tools like codex_ask (which starts a session) and codex_status (status check), and explains the fallback behavior for session identification.

    Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

    Usage Guidelines4/5

    Does the description explain when to use this tool, when not to, or what alternatives exist?

    The description explains when to use this tool (after codex_ask, to continue a session) and includes practical details like fallback after server restart. It does not explicitly state when not to use it or mention alternatives, but the context is clear enough for an agent to infer appropriate 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?

    Annotations already declare readOnlyHint=true and idempotentHint=true, so no contradiction. The description adds value by detailing the best-effort GitHub update check and the AGY_BRIDGE_NO_UPDATE_CHECK environment variable, providing useful behavioral context beyond 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 composed of four efficient sentences, front-loading the purpose and quota-free nature. Every sentence earns its place, with no redundancy or unnecessary detail.

    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 zero parameters, existing output schema, and thorough description of diagnostics reported, the description is fully complete for an agent to understand what the tool does and what it will return.

    Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

    Parameters4/5

    Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

    With zero parameters, schema coverage is 100% and baseline is 4. No additional parameter description needed.

    Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

    Purpose5/5

    Does the description clearly state what the tool does and how it differs from similar tools?

    The description clearly states 'Report diagnostics for the Cursor bridge setup' with specific resources (bridge version, cursor-agent, login status, chat storage). It distinguishes from sibling antigravity_status by noting the same update notice is shown, clarifying overlap.

    Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

    Usage Guidelines4/5

    Does the description explain when to use this tool, when not to, or what alternatives exist?

    The description explicitly says 'Use this to debug cursor not found or auth errors before spending quota,' providing clear usage context. It lacks explicit when-not-to-use but is sufficient for a diagnostic tool.

    Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

  • Behavior4/5

    Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

    Annotations already declare the tool as non-read-only, open-world, and non-idempotent. The description adds meaningful behavioral context: session scoping per working directory (no ID needed), error condition when no prior session exists, and experimental/auth caveats. This goes beyond basic annotations and helps an agent understand prerequisites and side effects.

    Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

    Conciseness5/5

    Is the description appropriately sized, front-loaded, and free of redundancy?

    The description is three sentences, front-loads the main purpose in the first sentence, and includes only essential details. No extraneous information or redundant restatement of the title.

    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 moderate complexity (experimental, has prerequisites, multiple parameters) and the presence of an output schema and annotations, the description covers the critical context: how to use it, what will happen if misused, and the experimental nature. It's sufficient for an agent to invoke correctly.

    Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

    Parameters4/5

    Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

    The input schema covers all three parameters with clear descriptions (100% coverage). The description adds meaning by explaining the session scoping mechanism, which clarifies the 'workspace' parameter's purpose and why no session ID is required. This enriches the schema without radically changing it.

    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 resumes a prior Kimi session for the workspace via `kimi -c`. It distinguishes from siblings like kimi_ask (starting a new session) and kimi_status (checking status) by specifying the action and workspace scoping. The verb 'continue' is specific and unambiguous.

    Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

    Usage Guidelines4/5

    Does the description explain when to use this tool, when not to, or what alternatives exist?

    The description provides explicit guidance by stating it errors if no prior kimi_ask was run, indicating when the tool is applicable. It also references the same experimental caveat and auth requirement as kimi_ask, framing the appropriate context. However, it doesn't explicitly contrast with alternatives like kimi_ask or kimi_status, so it falls just short of fully explicit.

    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 significant behavioral context beyond the annotations (readOnly, idempotent): it states it spends no AI Pro quota, is a best-effort GitHub check honoring AGY_BRIDGE_NO_UPDATE_CHECK, details how 0% quota per family is reported as a problem, and lists filesystem checks. 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?

    The description is a dense but well-organized paragraph with the main purpose front-loaded and usage guidance at the end. All details are relevant, though the long clauses and extensive list make it slightly less scannable than optimal.

    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 an output schema exists, the description thoroughly covers all checks performed, including version-specific behavior, env-var handling, and edge cases like quota exhaustion. The usage guidance completes the picture, making it comprehensive for a no-parameter diagnostic 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 schema fully covers parameter semantics (baseline 4). The description adds no parameter-specific details, but none are 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 opens with 'Report diagnostics for the agy bridge setup', which is a specific verb+resource statement. It distinguishes from sibling status tools (codex_status, copilot_status) by explicitly targeting the agy bridge, and then details the specific checks performed.

    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 final sentence provides explicit when-to-use guidance: 'Use this to debug empty or failed responses — or to see if the bridge itself is out of date, or if you are simply out of quota — before spending quota.' This is clear, but it does not name alternative tools or when-not-to-use, so it falls just 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.

  • Behavior5/5

    Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

    Adds substantial context beyond annotations: 'spends no quota,' 'EXPERIMENTAL,' expected auth row prior to login, and backend unverified. These are behavioral traits not captured by readOnlyHint/idempotentHint.

    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 front-loaded with a clear one-line summary. The subsequent paragraph is detailed but each sentence adds necessary caveats or specifics. Slightly verbose with backticks and examples, but overall efficient.

    Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

    Completeness5/5

    Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

    With an output schema present and annotations, the description provides complete context: purpose, cost (no quota), experimental status, expected caveats, and specific checks performed. No significant gaps.

    Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

    Parameters4/5

    Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

    Tool has zero parameters and schema coverage is 100% trivially. The description doesn't add parameter semantics, but none are needed; baseline 4 applies.

    Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

    Purpose5/5

    Does the description clearly state what the tool does and how it differs from similar tools?

    The description opens with a specific verb and resource: 'Report diagnostics for the Kimi bridge setup'. It enumerates concrete checks (version, newer release, kimi binary, provider, data location) and distinguishes it from sibling status tools by referencing antigravity_status's update notice.

    Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

    Usage Guidelines4/5

    Does the description explain when to use this tool, when not to, or what alternatives exist?

    The description implies use when checking bridge setup, notes 'spends no quota' as a benefit, and warns the backend is unverified. However, it does not explicitly state when to use this instead of kimi_ask/kimi_continue or when not to use it.

    Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

  • Behavior5/5

    Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

    The description discloses meaningful behavior beyond the annotations: workers run "truly concurrently," results return "in one labelled block," failed workers are "reported in place," and successful ones still return. The security warning about "N unsandboxed agents" and the prompt-injection surface adds important context that aligns with openWorldHint=true and readOnlyHint=false.

    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: a front-loaded purpose statement, a brief explanation of worker behavior, and a clearly separated security warning. Every sentence earns its place and none merely repeats the schema.

    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 complex, high-risk tool with an output schema and 100% schema coverage, the description covers the essential invocation context: parallel execution, backend mixing, failure behavior, concurrency cap, and security caveats. Nothing critical is missing for an agent to decide whether and how to call it.

    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 100%, so the baseline is 3. The description adds useful behavioral meaning for the tasks parameter — that each task is its own worker, names a backend, and can mix backends in one swarm — and clarifies that max_concurrency caps real parallelism. It does not add much on the other parameters, but the schema already documents them thoroughly.

    Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

    Purpose5/5

    Does the description clearly state what the tool does and how it differs from similar tools?

    The description opens with a specific verb and scope: "Run SEVERAL tasks IN PARALLEL across ALL backends in a single swarm." This clearly distinguishes agent_swarm from the single-backend sibling tools like antigravity_ask or codex_ask, and the title reinforces the mix of backends and 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 gives clear context for when to use the tool: multiple tasks, multiple backends, parallel execution. It also provides an explicit exclusion: "Only use it with trusted prompts on trusted content." However, it does not explicitly name single-task sibling tools as alternatives, leaving the when-not-to-use guidance slightly incomplete.

    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 goes beyond annotations by disclosing the tool's best-effort nature: the GitHub check 'honors AGY_BRIDGE_NO_UPDATE_CHECK' and auth detection is 'best-effort' with specific caveats. It also notes that the update notice is the same as antigravity_status. No contradictions with annotations (readOnlyHint, idempotentHint).

    Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

    Conciseness5/5

    Is the description appropriately sized, front-loaded, and free of redundancy?

    The description is concise and well-structured. It opens with a clear summary sentence, then bullet-points the diagnostics items without unnecessary words. Every sentence adds value, and the length is appropriate for the tool's complexity.

    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 has no input parameters and an output schema exists, the description covers all necessary behavioral context: what diagnostics are reported, edge cases (best-effort checks), and the intended debug use case. It is fully complete for the agent to understand and invoke correctly.

    Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

    Parameters4/5

    Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

    The input schema has zero parameters and 100% coverage, so the description does not need to explain parameters. The baseline of 4 is appropriate as the description adds no additional parameter information.

    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: 'Report diagnostics for the Copilot bridge setup.' It details the specific items checked (version, update, PATH, auth, session state) and explicitly says to use it for debugging 'copilot not found' or auth errors. This distinguishes it from sibling status tools like antigravity_status by focusing on Copilot-specific diagnostics.

    Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

    Usage Guidelines4/5

    Does the description explain when to use this tool, when not to, or what alternatives exist?

    The description provides explicit usage guidance: 'Use this to debug "copilot not found" or auth errors before a call.' It also explains that the update notice matches antigravity_status, implying when to choose this over that. However, it does not explicitly state when not to use it or name alternative tools for other scenarios.

    Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

  • Behavior5/5

    Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

    The description adds significant behavioral context beyond annotations: it explains the resumption logic (exact chat id from last cursor_ask, fallback to newest chat with matching cwd), how permission flags apply per invocation, and that it works after server restart. No contradictions with annotations (readOnlyHint false, openWorldHint true, idempotentHint false).

    Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

    Conciseness5/5

    Is the description appropriately sized, front-loaded, and free of redundancy?

    The description is concise with two short paragraphs. The first sentence immediately states the core action. The second paragraph adds necessary detail without fluff. Every sentence adds value.

    Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

    Completeness5/5

    Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

    Given the complexity (5 parameters, output schema exists), the description covers all essential behavioral aspects: resumption logic, fallback, permission per invocation, and restart resilience. It does not need to explain output schema since it exists separately.

    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 coverage, the baseline is 3. The description does not add new parameter-level semantics beyond what is already in the schema. It reiterates that sandbox takes effect, but does not provide additional details or context that enhance 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 identifies the tool's action: 'continue the Cursor chat.' It uses specific verb ('continue') and resource ('Cursor chat'), and distinguishes from sibling tools like cursor_ask (which starts a new chat) and cursor_status (which shows status).

    Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

    Usage Guidelines5/5

    Does the description explain when to use this tool, when not to, or what alternatives exist?

    The description explicitly states when to use this tool: after a cursor_ask to continue that chat. It also provides context on fallback behavior and permission handling, with an example usage scenario ('analyze read-only with cursor_ask, then continue with workspace-write'), guiding the agent on when and why to invoke this tool.

    Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

  • Behavior5/5

    Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

    Annotations provide readOnlyHint and idempotentHint, but the description adds valuable context: confirms no quota spent, describes best-effort GitHub check with environment variable, and details each diagnostic check. 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.

    Conciseness4/5

    Is the description appropriately sized, front-loaded, and free of redundancy?

    The description is a single paragraph with a clear flow: purpose, detailed checks, usage note. Slightly long but every sentence adds value; could be more concise but remains efficient.

    Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

    Completeness5/5

    Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

    Given no parameters, rich annotations, and presence of output schema, the description fully explains what the tool does, its side effects (no quota), and when to use it. It covers all behavioral and contextual aspects.

    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 with 100% coverage, so description does not need to add parameter details. Baseline score of 4 is appropriate.

    Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

    Purpose5/5

    Does the description clearly state what the tool does and how it differs from similar tools?

    The description clearly states the tool reports diagnostics for the Codex bridge setup, listing specific checks (version, update, PATH, login status, session storage, pinned sessions). It distinguishes from sibling status tools by referencing antigravity_status and focusing on Codex-specific debugging.

    Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

    Usage Guidelines5/5

    Does the description explain when to use this tool, when not to, or what alternatives exist?

    Explicitly tells when to use: 'debug "codex not found" or auth errors before spending quota.' It also implies not to use for other bridges, and notes the tool spends no quota, making it safe to run.

    Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

  • Behavior5/5

    Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

    Beyond the readOnlyHint and idempotentHint annotations, the description reveals that no quota is consumed, that auth/model data come from `grok models` which answers even when logged out, and importantly warns that the backend is EXPERIMENTAL with unverified end-to-end behavior. These are valuable behavioral insights.

    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 front-loaded with the key fact ('spends no quota'), structured into a clear overview, detailed output list, and usage guidance. Every sentence carries unique value and there is no repetition or filler.

    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 zero-parameter diagnostic tool, the description fully covers its purpose, output scope, safety characteristics, usage context, and a crucial caveat about experimental status. The presence of an output schema makes the lack of explicit return-format details acceptable.

    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 requires no parameters, so the baseline is 4. The description compensates by explaining what the tool reports, which is more relevant to output than parameter semantics. No parameter information is needed.

    Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

    Purpose5/5

    Does the description clearly state what the tool does and how it differs from similar tools?

    The description states the tool's specific action ('Report diagnostics') and resource ('Grok Build bridge setup'), and immediately clarifies it spends no quota. It distinguishes itself from sibling tools like grok_ask/grok_continue by being a status/diagnostic tool, and even references antigravity_status for the update notice.

    Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

    Usage Guidelines5/5

    Does the description explain when to use this tool, when not to, or what alternatives exist?

    Explicitly states when to use: 'Use this to debug "grok not found" or auth errors before spending quota.' It also positions itself as cheap, safe, and first to call, giving clear decision guidance relative to other tools that spend quota.

    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

agent-intern MCP server

Copy to your README.md:

Score Badge

agent-intern MCP server

Copy to your README.md:

Latest Blog Posts

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/SinanTufekci/agent-intern'

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