agy-mcp

by Boulea7

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

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

Latest release: v0.1.8
Disambiguation5/5
Each tool has a clearly distinct purpose: agy/agy_continue/agy_start differentiate synchronous, resume, and background execution; agy_status/read/result/cancel/sessions cover distinct monitoring and control operations; and agy_doctor/install_skill/purge are separate admin utilities. Even the similar agy_read and agy_result are unambiguously separated by event log vs. captured output.
Naming Consistency4/5
All tools share the agy_ prefix and snake_case, creating a predictable namespace. However, the pattern mixes imperative verbs (start, read, cancel) with nouns (status, result, sessions), and the bare `agy` tool breaks the verb_noun convention. Despite this, the naming remains readable and internally consistent.
Tool Count5/5
With 11 tools, the server is well-scoped for its purpose, covering synchronous execution, background job lifecycle, monitoring, and admin functions without redundancy or bloat. This falls comfortably within the ideal 3-15 range.
Completeness4/5
The tool set provides comprehensive coverage of session and job lifecycle: run, continue, start, status, read, result, cancel, list, and purge. Minor gaps exist, such as no direct single-job delete or skill uninstall, but these are not critical to the core workflow and can be worked around.
Average 4/5 across 11 of 11 tools scored. Lowest: 3.4/5.
See the Tool Scores section below for per-tool breakdowns.
- 0 of 2 community issues answered or closed in the last 6 months
- 0 commits in the last 12 weeks
- Last stable release on May 27, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It only lists the return fields and does not state whether the operation is read-only, any authentication or permission requirements, rate limits, or potential 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 a single, front-loaded sentence with a clear verb and resource. It contains no filler or redundant content, making it appropriately concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter status lookup, the description covers the basic function and an output schema exists to detail return values. However, it lacks usage context and behavioral details (e.g., whether it can be called for any job_id or if it has side effects), leaving some gaps in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, and the description merely repeats 'job_id' without adding format, origin, or example details. It provides no additional meaning beyond the schema's property name and required flag, so it fails to compensate for low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Return') and identifies the exact resource ('JobRecord') along with its key fields (status, exit code, error, timestamps) for a given job_id. This clearly distinguishes it from sibling tools like agy_start, agy_cancel, and agy_result.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a job's status is needed, but provides no explicit guidance on when to use this tool versus alternatives such as agy_result or agy_read. It does not mention exclusions or prerequisites, leaving the context implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits but only says 'the underlying adapter resumes the Antigravity conversation.' It does not mention side effects, write permissions, session state changes, or other behaviors. Given zero annotation coverage, this is a significant gap.
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, front-loaded with the core purpose, and every word adds value. It efficiently conveys the main function and the critical requirement (SESSION_ID) without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the tool has 15 parameters and no annotations. The description is minimal and does not explain key behavioral aspects like modes, backends, or the meaning of parameters such as allow_write or return_all_messages. It is too sparse for a tool of this complexity.
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%, and the description only adds meaning to SESSION_ID (clarifying it is required for continuation). It does not explain PROMPT or the other 13 parameters, nor does it elaborate on enums or defaults. The reference to `agy` might imply shared semantics, but that is not self-contained.
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 explicitly states 'Continue an existing agy session' with a specific verb and resource, and distinguishes itself from siblings by noting 'Identical to `agy` except SESSION_ID is required.' This clearly differentiates it from agy_start (new session) and other session-related 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 implies usage is for continuing an existing session, with 'SESSION_ID is required' as the key differentiator. It references the alternative `agy` but does not explicitly state exclusions like 'do not use for new sessions.' However, the context is clear enough for an agent to decide when to use it.
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 the ordering ('newest first') and the limit behavior (default 50, 0 for full list), which is useful. However, it does not explicitly state that the operation is read-only or describe potential side effects, though 'list' implies a safe read.
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 entire description is a single sentence, concise and front-loaded with the main action. Every word earns its place, conveying both purpose and parameter details without 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?
For a simple list tool with one optional parameter and an output schema, the description covers the core aspects: what is listed, ordering, and limit semantics. It omits explicit mention of read-only status or the definition of 'jobs', but the presence of an output schema reduces the need to describe return values.
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 provides only a bare parameter with a default, but the description adds crucial semantics: 'limit defaults to 50; pass 0 for the full list.' This explains the parameter's behavior and special value, effectively compensating for the 0% schema description coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'List recent jobs' with an explicit ordering ('newest first'), giving a specific verb and resource. It does not explicitly differentiate from sibling tools like agy_status or agy_result, but the resource 'jobs' and the list action are distinct enough.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as agy_status or agy_result. There is no mention of typical use cases, prerequisites, or exclusions, leaving the agent without context for tool selection.
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 must carry the burden of behavioral disclosure. It discloses that the session runs in the background and returns a status and job_id. It does not mention side effects like file system changes, permissions, or rate limits, but for a 'start' tool the core behavior is reasonably conveyed. Lacks depth expected for a 14-parameter tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded, zero fluff. The first sentence states the core action, the second explains the return value and next steps. 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?
Despite the presence of an output schema (per context), the tool is complex with 14 parameters and rich options (modes, sandbox, workflows). The description only covers the basic launch-and-poll flow, offering almost no guidance on parameter selection, which is essential for correct usage in varied situations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description should compensate for parameter meaning. It does not explain any of the 14 parameters (PROMPT, mode, backend, sandbox, allow_write, etc.). The only mention of job_id refers to the return value, not the input parameter. This leaves the agent guessing about all 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 action: 'Start an agy session in the background.' This identifies a specific verb and resource, and the mention of returning a job_id to poll distinguishes it from sibling tools like agy_status and agy_cancel. It leaves no ambiguity about 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: this tool is for launching a background session and then polling it via agy_status/agy_read/agy_cancel. It implies usage for asynchronous workflows and names the related tools. However, it does not explicitly say when NOT to use this tool or mention alternatives like 'agy' for interactive sessions.
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 present, so the description bears the burden. It discloses synchronous execution and return content, and mentions parameters like allow_write and sandbox that hint at side-effect control, but it does not specify permissions, side effects, or operational risks.
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, efficiently delivering the core action, return type, and parameter compatibility. No filler or redundancy; information 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?
With 15 parameters, 0% schema coverage, and no annotations, the description is too thin. It relies heavily on familiarity with the legacy gemini tool and does not explain modes, enums, or the output structure beyond 'assistant text + metadata'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It lists parameter groups ('same PROMPT / cd / ...' and 'new mode / timeout / ...') but does not explain the meaning of individual parameters or enum values, leaving the agent without sufficient semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Run agy --print synchronously and return the assistant text + metadata', providing a specific verb, resource, and output. It distinguishes this from sibling tools like agy_start and agy_continue by positioning it as the primary execution tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers clear context by calling itself a 'drop-in for the legacy gemini tool', indicating when it should be used (when you would use gemini). However, it does not explicitly contrast with siblings or provide exclusions, but the inference is straightforward from the names.
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 burden of behavioral disclosure. It explains the return semantics (`success=True, signalled=True` vs `signalled=False`) and the condition for each outcome (worker alive vs unknown/finished), going beyond the schema.
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, front-loaded with the core action, and no redundant wording. Every word adds value, including the return-value 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?
For a simple one-parameter cancellation tool with an output schema available, the description provides key behavioral and return information. It lacks broader context like prerequisites or side effects, but the simplicity of the operation makes it reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage and only one parameter, `job_id`. The description indirectly references the job but does not explain what format `job_id` should take or how to obtain it. The parameter name is self-explanatory, but more explicit guidance would improve the score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('Signal a running job to stop') with a specific verb and resource. It distinguishes itself from siblings like agy_status, agy_read, and agy_continue by focusing on cancellation.
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: use this when you want to stop a running job. However, it does not explicitly mention when not to use it or how it relates to alternative tools like agy_continue or agy_purge.
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 the default behavior (latest finished job) and the include_events toggle, but does not explain error handling or what happens if no finished job exists. It is adequate but not rich in behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose. No wasted words; every sentence provides actionable guidance, including a sibling reference.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the main use case and directs to agy_read for full logs, but the unmentioned 'since' parameter and lack of edge-case details make it slightly incomplete. The presence of an output schema covers return values, so this is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains job_id and include_events but completely omits the 'since' parameter (integer with default 0). This leaves a meaningful gap in understanding the tool's full parameter set.
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: 'Return the captured output for a finished background job.' It uses a specific verb and resource, and explicitly contrasts with agy_read for the full event log, effectively distinguishing 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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage instructions: pass job_id to select a job or omit it to use the latest finished job from agy_sessions, and set include_events=true to also return stored events. It also directs users to agy_read for the full event log, offering clear alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden. It discloses that 'since' is a 0-based offset, defines the translate values, and specifies the default output (canonical events as dicts). However, it does not cover error scenarios, event ordering, or rate limits, which would add further transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, each packed with relevant information and no redundancy. The purpose is front-loaded, and the parameter details are presented efficiently.
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?
An output schema exists, so return values need not be detailed. The description covers parameter behaviors and default output well, but lacks explicit usage guidance relative to sibling tools and potential edge cases, leaving minor 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?
Schema description coverage is 0%, so the description properly explains parameter meanings. It clearly defines 'since' as an offset and 'translate' with its enum options, adding value beyond the bare schema. job_id is self-explanatory, so the overall parameter semantics are well covered.
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 'Read events from a job's event log', a specific verb-resource pairing that clearly distinguishes this from sibling tools like agy_status or agy_start. The mention of translate formats further specifies the tool's function.
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 states what the tool does but does not explicitly mention when to use it over alternatives, nor does it provide exclusions. The use case is implied by the read-only nature, but there is no direct guidance relative to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the deletion action, the validation constraints (positive integer <= 3650, rejection of zero/negative), and the return value (removed job ids and coarse count). This adds safety context and expected behavior, though it does not detail irreversible effects or permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no redundancy. The first sentence states the core action, the second provides validation details and rationale. Every word adds value, and the most critical information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tool's purpose, parameter constraints, and return value, which is sufficient given the simple single-parameter interface and the presence of an output schema. It does not describe the exact structure of the output, but the output schema presumably covers that, and it does not mention edge cases like empty results, but these are minor gaps.
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?
The schema only defines `days` as an integer with a default, providing no description. The tool description fills this gap completely by specifying the valid range (1-3650), the requirement for positivity, and the rationale for rejecting zero/negative values, which prevents misuse.
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 ('Delete') and the resource ('session-store job directories'), and specifies the condition based on mtime and days. It also mentions the return value, which distinguishes it from sibling tools like agy_status or agy_cancel by describing a unique cleanup operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for cleaning up old session jobs, and explicitly warns about safe values for `days` to avoid accidental wipes. However, it does not explicitly state when to prefer this tool over alternatives, nor does it mention when not to use it (e.g., if active jobs might be affected).
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 takes on the burden. It discloses caching behavior ('drop the cached binary probe'), the return format ('structured report (no secrets)'), and appropriateness for MCP. It doesn't explicitly state safety or side effects, but the context is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences front-load the purpose, describe the output, and then explain the parameter. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one optional parameter) and an output schema exists. The description covers the purpose, output nature, and the cache nuance, making it complete 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.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema coverage, the description fully explains the one parameter: 'Pass `force_refresh=true` to drop the cached binary probe' and gives the exact scenario for using 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 states 'Run capability + auth + session-store probes' with a specific verb and resource, clearly distinguishing it from sibling tools like agy_status or agy_read as a diagnostic tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear context for the force_refresh parameter ('use after upgrading the underlying agy / gemini CLI'), but does not explicitly compare with alternatives or state when-not to use it. The diagnostic purpose is implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully bears the transparency burden. It details exact filesystem paths per scope, the force flag behavior (skip vs. unconditional rewrite), and the reasoning behind using ~/.agy/ over ~/.gemini/ due to a standing rule. This is rich behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single well-structured paragraph, front-loaded with the main action, then logically covering targets, scope paths, the Antigravity exception, and force semantics. Every sentence adds necessary context without waste.
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 4 parameters, 0% schema coverage, and existing output schema, the description covers all parameters, defaults, and edge cases, leaving no significant ambiguity for an agent to decide when and how to invoke the tool.
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?
Schema description coverage is 0%, and the description compensates thoroughly: targets values are enumerated, scope modes are tied to concrete paths, project_root is explained, and force behavior is defined for both false and true.
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: 'Install the agy-mcp collaboration skill bundle into one or more agent platforms.' It clearly differentiates from sibling tools like agy_start or agy_status by focusing on installation.
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 target expansion and scope semantics, giving clear context on parameter choices. It does not explicitly name alternatives or exclusions, but the tool's purpose is self-contained and sibling names clearly differ.
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:

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

Score Badge

Copy to your README.md:

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

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