Eden MCP

by Leuconoe

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.4.0
Disambiguation4/5
Most tools have distinct purposes, but the cluster of diagnostics tools (eden_get_logs, eden_diagnose_game_issue, eden_export_diagnostics, eden_get_runtime_metrics, eden_capture_sequence) overlaps in intent and could confuse agents choosing between log reading, issue diagnosis, and metrics sampling.
Naming Consistency5/5
All tool names follow a consistent eden_<verb>_<noun> pattern with snake_case, and verbs are chosen to reflect the action (get, list, start, stop, press, take, etc.). The few short forms like eden_stop and eden_status are clear exceptions that don't break the overall convention.
Tool Count2/5
At 27 tools, the surface is too large for the apparent scope. Many diagnostic and cleanup tools (e.g., eden_export_diagnostics, eden_list_artifacts, eden_cleanup_artifacts) are highly specialized and could be consolidated, making the set feel bloated.
Completeness4/5
The toolset covers the main emulator lifecycle: sessions, launching, input, capture, diagnostics, and compatibility advice. Minor gaps exist, such as no direct configuration mutation or save management, but agents can work around these.
Average 3.8/5 across 27 of 27 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 18 commits in the last 12 weeks
- Last stable release on August 12, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already communicates that this is a safe read operation, lowering the bar. The description adds the scope of what status aspects are returned, but does not discuss parameter effects, output format, or potential caveats. It provides some value beyond the annotation but not deeply.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded and lists the key content areas without unnecessary words. It is concise and readable, though slightly dense due to the list of items.
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 read-only status tool with an output schema, the description covers the broad scope of returned information. However, it lacks parameter semantics and usage guidance, making it only minimally complete for an agent that needs to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one optional session_id parameter with zero description coverage, and the description never mentions session_id or how it influences the results. With 0% schema coverage, the description carries full responsibility for parameter explanation but fails completely.
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 that the tool retrieves the managed Eden process, backend, screen, game paths, and capabilities. The verb 'Get' is specific and the resource scope is well defined, distinguishing it from sibling tools that target individual aspects like screen size or capabilities alone.
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?
There is no guidance on when to use this tool versus alternatives such as eden_get_screen_size or eden_get_capabilities. No mention of prerequisites, exclusions, or typical use cases.
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?
Annotations only provide a title, so the description carries the full burden of behavioral disclosure. It mentions the main action ('Start Eden and open a base game file') and an optional update installation, which implies file mutation. However, it does not disclose side effects, permissions, dependencies, or what happens when the update is applied. The lack of detail on how the update modifies the game makes transparency minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the primary purpose ('Start Eden and open a base game file') and then covers the optional update behavior succinctly. Every word contributes essential information without fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a 10-parameter launch tool, this description is incomplete. It does not mention the wait_until stages (process_started, control_ready, game_ready) which are central to the tool's behavior, nor does it address session_id or how it relates to session management siblings like eden_create_session. The output schema may cover returns, but the description misses key contextual workflow details.
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 for 10 parameters. It only implicitly explains base_path ('base game file') and update_path ('separate update'), leaving eden_path, timeout_s, fullscreen, wait_until, expect_patch, application_id, and keep_running_on_timeout unexplained. This provides minimal value beyond the raw schema for the majority of parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Start Eden and open a base game file.' This clearly distinguishes it from stopping or validating tools like eden_stop and eden_validate_launch. However, it does not explicitly name alternatives or contrast with sibling tools, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this is the tool for starting the game, but it does not provide explicit when-to-use or when-not-to-use guidance. It mentions an optional update step 'when the Eden control endpoint is available', which is a usage condition, but it does not exclude cases or mention alternatives. This makes usage guidance merely implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare destructiveHint=true, so the description adds some value by scoping the operation to the process started by this MCP server. However, it does not disclose side effects, relationship to sessions, or what happens to active processes.
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 eight-word sentence that is front-loaded and contains no filler. It is appropriately concise for a straightforward stop action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description lacks critical context for a destructive operation: what exactly is terminated, whether session_id narrows the scope, and what the expected outcome is. Sibling tools indicate related cleanup operations, but the description does not clarify the boundaries.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention session_id or explain its meaning. With an optional parameter, the description should clarify whether and how it modifies the stop behavior, but it offers no such 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 action ('Stop') and the specific resource ('the Eden process started by this MCP server'). It distinguishes itself from sibling tools like eden_stop_session by explicitly targeting the process, not a session.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like eden_stop_session or eden_cleanup_sessions. The description implies usage but does not explain contexts, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, and the description reinforces these with 'read-only preflight'. It adds value by detailing exactly what is validated (fingerprints, title-ID compatibility, patch layout), which goes beyond the safety flags while remaining consistent with them.
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 dense sentence that leads with the action and packs in all relevant details without redundancy. Every phrase contributes to understanding the tool's scope.
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 good annotations and an output schema, the description lacks parameter semantics and usage context. With six parameters having zero schema descriptions and a large sibling set, the one-sentence overview is insufficient for confident tool selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention any of the six parameters by name or explain their role (e.g., base_path, update_path, expect_patch). It offers only a high-level summary of validation areas, leaving the agent without essential input guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Perform a bounded read-only preflight' and enumerates concrete checks (base/update paths, sampled fingerprints, normalized title-ID compatibility, version hints, optional LayeredFS patch layout). This clearly distinguishes it from sibling tools like eden_start_game or eden_check_environment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is given on when to use this tool versus alternatives such as eden_check_environment or eden_advise_compatibility. The phrase 'preflight' implies a pre-launch validation role, but there are no conditions, prerequisites, or exclusions stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, covering the safety profile. The description adds that unavailable counters return null, which is useful, but does not disclose other behavioral traits like rate limits, invalid session handling, or the meaning of 'bounded'.
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, front-loaded with the core action and includes an important edge case (null counters). Every word earns its place with no fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has moderate complexity with two optional parameters and an output schema. The description covers the core purpose and a behavioral nuance, but lacks parameter explanation and usage context. The output schema helps, but the description remains minimally sufficient.
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 does not explain sample_ms or session_id. The parameter names offer some intuition, but the description adds no semantics beyond the schema's raw property definitions.
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 samples and summarizes runtime metrics (FPS, frame-time, shader, video signals) with a specific verb ('sample and summarize') and resource ('current runtime evidence'). This differentiates it from siblings like eden_get_screen_size or eden_get_logs.
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, nor does it mention exclusions or prerequisites. It is a plain statement of function without contextual usage cues.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide only the title, so the description carries the transparency burden. It discloses the optional 'authenticated endpoint probe' and characterizes it as short, but does not explain potential side effects, required permissions, or whether it modifies any state beyond reading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that front-loads the action and efficiently lists the many checked elements. No wasted words or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema, so return-value explanation is not needed. However, the description lacks parameter-probe linkage and usage guidance relative to siblings, leaving some gap in context for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter (probe_control) with 0% description coverage. The description mentions an optional probe but never connects it to the parameter, leaving the agent to guess that probe_control=true triggers it. This fails to compensate for the sparse 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 gives a specific verb ('Check') and enumerates concrete resources checked: standalone executable, profile, keys/NAND hints, allowed paths, session storage. It also mentions an optional probe, making it distinct from sibling tools like eden_status or eden_get_capabilities.
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?
Usage is implied as a comprehensive environment check before running a game or session, but no explicit alternatives or exclusions are provided. The description clarifies what is checked but not when to choose this over eden_status or eden_get_capabilities.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, so the agent knows it is a safe read operation. The description adds the scope of the listing (only Eden MCP artifacts) and the inclusion of size information, which provides context beyond what annotations offer.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the action and includes all necessary scope details without any redundant text or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and has an output schema, so return values are handled elsewhere. However, the description is minimal and does not explain the purpose or effect of the session_id parameter, and it vaguely refers to 'diagnostic artifacts' without further detail, leaving some gaps for a complete understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema includes one parameter (session_id) with no description and 0% schema description coverage. The description does not mention session_id at all, failing to compensate for the lack of parameter documentation, leaving the agent without guidance on how to use the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List' and clearly identifies the resource as 'diagnostic artifacts generated by Eden MCP' while also noting size detail. This distinguishes it from sibling tools like eden_export_diagnostics and eden_cleanup_artifacts.
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 provides clear context that this tool lists artifacts only from Eden MCP, implying when it would be used. However, it does not explicitly mention when to use this tool over alternatives like eden_export_diagnostics or eden_cleanup_artifacts, nor does it state exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation destructiveHint=true already flags the tool as destructive. The description adds the prerequisite of the Eden control endpoint and the list of supported buttons, but does not elaborate on side effects (e.g., affecting game state) or any other behavioral nuances. It does not contradict the annotation, but the additional context is minimal.
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 primary purpose and followed by a concise list of supported buttons and a prerequisite. Every sentence earns its place, with no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema, return values need not be described. However, the description is incomplete for a 5-parameter tool: it does not explain action semantics, hold_ms behavior, or how player/session_id are used. It covers the core purpose and button list, but lacks the depth needed for an agent to fully understand invocation nuances.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate by explaining parameters. It only partially clarifies the 'button' parameter by listing supported values, but it does not explain 'action' (tap/down/up), 'hold_ms', 'player', or 'session_id'. The enum for 'action' is in the schema but not echoed in the description, leaving most parameters semantically unexplained.
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 sends a Nintendo Switch button directly to a player via Eden's virtual gamepad, and enumerates supported buttons. This specific verb+resource combination ('Send... button') and the explicit reference to 'Nintendo Switch' and 'virtual gamepad' distinguishes it from siblings like eden_press_key (likely keyboard) and eden_touch_screen.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by focusing on Switch buttons and the virtual gamepad, and mentions a prerequisite ('Requires the Eden control endpoint'). However, it does not explicitly state when to prefer this tool over alternatives (e.g., eden_press_key for keyboard input, eden_touch_screen for touch), nor does it name exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, so the description adds value by disclosing that the report is bounded (size limits) and shareable, and that partial results are returned if flushing fails. This error behavior and bounded nature are not derivable from annotations alone.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loading the core collection purpose and then stating partial-failure behavior. The first sentence is dense but each element is informative; no wasted words. It is appropriately sized for the tool's complexity.
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?
With 6 optional parameters and no schema descriptions, the description is adequate in conveying the report's purpose and failure behavior, but it lacks parameter semantics and alternative-tool guidance. The presence of an output schema is helpful but not visible; overall, the description is not fully sufficient for precise invocation without deeper schema inspection.
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, but it doesn't. While it mentions 'bounded' (hinting at max_bytes/max_events) and lists the focus enum values in prose, it never names or explains any parameter (e.g., max_bytes, session_id, tail_lines, context_lines) or their defaults. The mapping from description to parameters is only implicit.
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 collects a bounded, shareable gameplay failure report with specific components (process context, logs, repeated-message analysis, event context, heuristic hints) for distinct failure categories (game load, patch loop, video loop, missing patch/localization). This distinguishes it from siblings like eden_get_logs or eden_export_diagnostics.
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 the listed failure types through its enumeration, but it does not explicitly state when to use this tool versus alternatives (e.g., when simple logs are enough, use eden_get_logs) or provide exclusions. The failure-type list gives some context, but no clear 'when-not-to-use' guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no readOnly/destructive annotations carrying the safety profile, the description discloses important behavioral traits: the output is bounded, path-redacted, and explicitly excludes keys, firmware, game content, patches, saves, configuration, environment variables, and tokens. This adds significant context beyond what the schema provides, though it omits details like authentication requirements or where the ZIP is stored.
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 one tightly packed sentence that front-loads the core output (ZIP) and follows with useful constraints and exclusions. Every phrase adds value, with no redundant or filler content.
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 that an output schema exists (reducing the need to explain return values), the description covers the essential content of the ZIP and its boundaries. It lacks usage context and parameter mapping, but the explicit exclusions and bounded nature provide enough context for a moderately complex export tool. Missing guidance on when to use it is a notable gap, but overall it is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain any of the 8 parameters. While terms like 'bounded', 'path-redacted', and 'optional screenshot' loosely map to max_bytes, redact_paths, and include_screenshot, there is no explicit parameter-level guidance, leaving the agent to infer semantics from names and defaults alone. The description fails to compensate for the 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 clearly states the tool exports a bounded, path-redacted ZIP containing a diagnostic report, structured log entries, manifest hashes, and an optional screenshot. This specific deliverable distinguishes it from siblings like eden_get_logs or eden_diagnose_game_issue, 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives. It does not contrast with eden_get_logs or eden_diagnose_game_issue, nor does it mention any prerequisites or exclusions for usage, leaving the agent to infer context from the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, and the description adds that keys are resolved through Eden's active input profile and lists supported names. However, it does not disclose side effects, behavior on invalid keys, or rate limits, so it only partially goes beyond the annotation.
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 wasted words. The first sentence leads with the action, and the second enumerates supported key names efficiently.
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 5 parameters and no schema-level descriptions. The description omits guidance on modifiers, hold duration, session_id usage, and alternative tools, leaving significant gaps 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.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description should compensate by explaining parameters. It only documents valid values for the 'key' parameter, leaving 'action', 'hold_ms', 'modifiers', and 'session_id' unexplained beyond the schema's structural defaults and enums.
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 sends a host keyboard key to Eden, using specific verbs and resource framing. It distinguishes from siblings like eden_press_button and eden_touch_screen by specifying "host keyboard key" and listing supported keyboard keys.
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 that this tool is for keyboard input, but does not explicitly state when to use it versus alternatives such as eden_press_button or eden_run_input_script. It lacks explicit exclusions or alternative naming.
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 destructiveHint annotation, the description discloses important behavioral traits: held inputs are released after failures and by default at normal completion, and analog steps are rejected until supported. This adds useful context about side effects and limitations without contradicting the annotation.
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 a clear action statement, and contains no filler. Every sentence contributes meaning, and the structure is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity—a validated sequence with an array of steps, session handling, and a release flag—the description is incomplete. It does not explain what constitutes a valid step, how session_id is used, or the expected behavior of release_at_end in enough detail. The output schema exists, but the input schema leaves steps as loosely-typed objects, and the description offers no guidance on how to construct them.
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, but it does not explain the structure of the 'steps' array, the purpose of 'session_id', or the behavior of 'release_at_end' beyond a tangential mention of releasing held inputs. The description provides almost no parameter-level semantics, leaving the agent to guess how to construct valid steps.
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 ('Run') and clearly identifies the resource ('a validated sequence of waits, key/button actions, Switch button chords, touches, and visual-change checkpoints'). It distinguishes this tool from sibling single-action tools like eden_press_key, eden_press_button, and eden_touch_screen by focusing on running a sequence rather than a single action.
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 multi-step automation sequences but does not explicitly state when to use this tool versus individual input tools. It provides a usage constraint by noting analog steps are rejected until protocol support, but does not name alternatives or provide exclusion criteria. This is clear context but lacks explicit when-to-use or when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description adds extra behavior: it reads only the tail, supports case-insensitive substring filtering, and works after Eden exits. This goes beyond the minimal safety disclosure and provides useful context without contradicting annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler. The core function is front-loaded, and optional behavior is stated efficiently. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values are covered. However, with six parameters and zero schema descriptions, the description should clarify more of them. It covers the main use case but leaves pagination, session filtering, and level filtering unexplained.
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 alludes to 'tail' and 'contains' but does not explain cursor, max_bytes, session_id, tail_lines, or minimum_level. With six optional parameters, this is insufficient for an agent to understand their purpose and valid values.
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 reads the tail of Eden's eden_log.txt, with an optional case-insensitive substring filter. This specific verb+resource combination distinguishes it from sibling tools like get_runtime_metrics or get_session_storage.
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 reading logs and notes it works after Eden exits, but it does not explicitly compare to alternatives or state when not to use it. Sibling tools like export_diagnostics might be relevant, but no guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation readOnlyHint: true already communicates the read-only nature. The description adds that the value is 'current' and refers to the render coordinate space, but doesn't disclose additional behavioral traits beyond what annotations provide. No contradiction exists.
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 primary action, and every word adds value. It efficiently states what the tool does and when to use it without unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, has an output schema, and the description covers purpose and usage. The only missing element is the session_id parameter semantics, which is a minor gap given its optionality and default null.
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 description coverage is 0% and the tool description does not explain the session_id parameter at all. With only one optional parameter, the gap is moderate but still leaves the agent guessing about whether and how to provide a session_id.
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: 'Get the current Eden render coordinate space in pixels.' This distinguishes it from siblings like eden_get_capabilities or eden_get_runtime_metrics by focusing specifically on screen dimensions, and the mention of touch coordinates reinforces its 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 gives explicit guidance on when to use these dimensions: 'Use these dimensions for touch coordinates when no screenshot has just been taken.' This provides a clear context and a conditional exclusion, though it doesn't name an alternative tool explicitly.
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 declare readOnlyHint=true, and the description complements this by explaining the temporal capture behavior and the classification output, which goes beyond the annotation. It doesn't contradict the readonly hint, and adds context that this involves multiple frames over time, not a single operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently packs the core action, parameters range, and output types without redundancy. Every phrase contributes meaning, and there is no filler or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and 5 optional parameters with zero descriptions, the description provides a good high-level summary but omits return format specifics and does not clarify the meaning of threshold, session_id, or include_images. It covers the main purpose and output categories, but leaves room for ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It only vaguely references count and interval via '2-12 frames over time', leaving threshold, session_id, and include_images completely unexplained. This is a clear gap for agents to use the tool effectively.
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 specifies the action (capture 2-12 native frames over time) and the analytical outputs (perceptual differences, sampled frame hashes, classification), which distinguishes it from sibling tools like eden_take_screenshot. The verb 'capture' plus the resource 'frames' and scope make the purpose 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 provides clear context for use ('for visual loop evidence') which directly implies when to use this tool. It does not explicitly list alternative tools or exclusions, but the purpose statement is specific enough to guide selection. A bit more direct comparison to eden_take_screenshot would earn a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds meaningful behavioral context beyond the destructiveHint annotation by specifying the session is 'idle' and has a 'cloned portable profile and independent executable'. This helps the agent understand the nature of the action and its side effects, without contradicting the annotation.
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 with no filler. The first sentence defines the action and key attributes; the second explains how to use the result. Every word contributes to understanding.
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 tool with an output schema, the description covers the core purpose and the workflow well. However, the optional input parameter is left unexplained, and the destructive hint is not elaborated on, which leaves some gaps for an agent deciding how to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one optional parameter (session_id) with 0% coverage in the description. The description only mentions session_id as a return value ('Pass the returned session_id'), leaving the meaning of the input parameter completely unexplained—whether it is used to clone from an existing session, reference a parent, or something else.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Create' and clearly identifies the resource (Eden session) with valuable qualifiers: 'idle', 'cloned portable profile', and 'independent executable'. This distinguishes it from sibling tools like eden_list_sessions and eden_stop_session, which manage or list existing sessions rather than create new ones.
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 instruction to 'Pass the returned session_id to all normal control tools' provides clear workflow context: this is the entry point for using other control tools. It implies the tool should be used before session control tools, though it does not explicitly state when not to use it or mention 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?
Beyond the destructiveHint annotation, the description discloses that files are retained unless remove_profile is true, and that the session is 'forgotten'—adding meaningful 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?
Two concise sentences, front-loaded with the action, no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, the description adequately covers the core action and safety details; the missing protect_profile explanation is the only notable gap, but the tool's purpose is clear for typical use.
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?
It clarifies remove_profile's effect on file retention and identifies session_id as the target, but does not explain protect_profile, leaving a gap given 0% 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 ('Stop and forget') and resource ('one managed Eden session'), clearly distinguishing it from broader session tools like eden_stop or eden_cleanup_sessions.
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?
It implies usage for a single managed session but doesn't explicitly contrast with sibling tools or state when to prefer this over eden_stop or cleanup_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?
With only title in annotations, the description carries the full behavioral burden. It discloses the optional save side effect and explicitly warns 'Do not cache screenshots.' However, it does not mention overwrite behavior when saving, whether the operation is read-only, or any error handling. It adds some value but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exceptionally concise, with four short sentences. It front-loads the primary action and each sentence adds distinct information: what is captured, optional saving, usage guidance, and a caching constraint. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity of a screenshot tool and the absence of an output schema, the description covers the essential context: return value (PNG image), pixel dimensions for touch coordinates, and the optional save_path. Missing session_id explanation and edge cases like overwrite prevention, but overall sufficient for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 2 parameters with 0% description coverage. The description explains save_to as 'Optionally save a copy to an absolute or relative .png path', adding useful format details. However, session_id is not mentioned at all, leaving its purpose implied from sibling tools. Partially compensates for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Capture' with the resource 'current Eden render surface' and clearly states the output is a PNG image. It also distinguishes from siblings like eden_get_screen_size (which returns dimensions, not an image) and eden_capture_sequence (which likely captures multiple images) by focusing on a single current render surface.
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 on when to use the tool: when you need a screenshot and specifically to use the returned image's pixel dimensions for subsequent touch coordinates. It also advises against caching. However, it does not explicitly mention alternatives or when *not* to use it, such as when only dimensions are needed (which would be eden_get_screen_size).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds useful behavioral context beyond the destructiveHint annotation by explaining that coordinates are in screenshot pixel space and that source_width/source_height, if omitted, default to the current render size. This informs the agent about scaling behavior. It does not contradict the annotation, and the annotation already signals potential destructiveness.
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-loaded with the primary purpose, then lists actions, and finally provides parameter nuance. Each sentence adds value 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 tool's complexity (10 parameters, output schema, destructive annotation), the description covers the core interaction, action types, and important coordinate scaling behavior. It omits details on multi-touch or duration semantics, but the output schema likely covers return values, and the essential usage is clear enough for an agent to invoke the tool correctly in common scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description must compensate. It explains end_x/end_y for swipes and clarifies the meaning of source_width/source_height. Other parameters (finger_id, session_id, duration_ms) remain unexplained, and while x/y are self-evident, the partial coverage leaves gaps.
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 function clearly: 'Touch Eden at screenshot pixel coordinates.' It lists supported actions (tap, long_press, swipe, down, move, up), which distinguishes it from sibling input tools like eden_press_key or eden_run_input_script. The verb 'Touch' combined with the resource and coordinate system makes 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 provides implicit usage context: it handles touch gestures with coordinates, and gives specific guidance for swipe (end_x/end_y) and source dimensions. However, it does not explicitly state when to prefer this tool over alternatives or mention any exclusions, leaving the when-to-use mostly implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, and the description reinforces these with 'reversible' and 'never changes emulator settings.' It adds context about the input source ('current diagnostics and metrics') without contradicting annotations, providing a clear safety profile.
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 deliver the core functionality and safety guarantee without any unnecessary words. The key information is front-loaded and clearly structured.
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 simple advisory nature, good annotations, and presence of an output schema, the description is largely complete. The only gap is the absent parameter explanation, which prevents a perfect score, but the overall context is sufficient for a low-risk advisory tool.
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 does not explain the parameters 'focus' or 'session_id.' While the enum and nullable type provide some structure, the description fails to compensate for the lack of parameter documentation, leaving the agent to infer meaning from names alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('Return') and resource ('ranked, reversible compatibility experiments'), and distinguishes itself from sibling tools by explicitly noting it never changes emulator settings. This makes its advisory role unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: it is a read-only advice tool that generates experiments from current diagnostics. The phrase 'never changes emulator settings' implicitly tells the agent to use this when recommendations are needed without side effects, though it does not name specific alternative tools.
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 destructiveHint annotation, the description adds valuable behavioral context: it defaults to dry-run, only touches 'valid, stopped, unprotected' profiles, and never removes certain categories. This gives the agent clear guardrails and safety expectations. There is no contradiction with the annotation.
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, front-loaded with the core purpose and then the safety qualifier. Every sentence adds value, with no unnecessary fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema and moderate complexity. The description covers purpose and safety well, but the lack of parameter explanations (especially keep_latest and older_than_days) leaves a significant gap. Given the 0% schema coverage, the description should have compensated but didn't, making it minimally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain the parameters (dry_run, keep_latest, older_than_days). While 'dry-run' is mentioned in the description, the retention criteria parameters (keep_latest, older_than_days) are not described. This leaves the agent without essential semantics for how retention is configured.
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: applying retention to valid, stopped, unprotected Eden MCP session profiles. It uses a specific verb ('apply retention') and resource, and distinguishes itself from sibling tools like eden_cleanup_artifacts by focusing on sessions. It also conveys the safety scope ('never removes active, protected, unconfirmed, or legacy paths').
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 on when to use the tool (on valid, stopped, unprotected sessions) and explicit when-not behavior (never removes active, protected, unconfirmed, or legacy paths). It also mentions the dry-run default, guiding safe usage. However, it does not explicitly name alternative tools for comparison, so it falls slightly short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the read-only nature is known. The description adds value by specifying the output contents (state, PID, profile path) and the distinction between default and managed sessions, giving useful context beyond the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence that front-loads the action ('List') and immediately details the resource and output fields. Every word earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only list tool with no parameters and an output schema, the description is adequate. It states what is listed and the included fields. A slightly more explicit explanation of 'default and managed' would enhance completeness, but it's not essential.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. There are no parameter semantics to explain, and the description appropriately focuses on the tool's purpose rather than parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List' and identifies the resource as 'Eden sessions' with the exact scope ('default and managed') and returned fields (state, PID, profile path). This clearly distinguishes it from sibling tools like eden_create_session or eden_stop_session.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (when you need to see sessions), but it does not explicitly state when to use this tool over alternatives, nor does it provide any exclusions or prerequisites. The context is clear but lacks explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond the destructiveHint annotation: it discloses atomicity ('Atomically copy'), prerequisite (stopped session), and safety constraints (rejected roots). It does not contradict annotations and provides useful operational detail.
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 consists of two clear, front-loaded sentences with no wasted words. The primary action is stated first, followed by critical restrictions.
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 an output schema and annotations, the description is reasonably complete: it covers the action, destination, prerequisites, and safety constraints. It does not detail failure behaviors or overwrite semantics, but these are not essential with the available structured data.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate. It explains the semantics of patch_path ('unpacked RomFS/ExeFS/cheat patch') and session_id ('stopped managed session'), but it does not describe application_id or the optional label parameter, leaving gaps.
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: 'Atomically copy an unpacked RomFS/ExeFS/cheat patch into a stopped managed session's isolated user/load directory.' This specific verb+resource+destination distinguishes it from sibling session management tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool: it targets a stopped managed session and specifies rejected target types ('default profile cannot be targeted; links and key, firmware, NAND, or save-like roots are rejected'). It does not explicitly name alternatives, but the restrictions give practical usage boundaries.
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, lowering the bar. The description adds valuable behavioral context by specifying that the contract includes not just available but also conditional and unavailable operations, and that it follows 'contract 1.0'. This goes beyond a simple 'returns capabilities' statement, though it doesn't discuss error cases or session lifecycle nuances.
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 sentence that front-loads the action and resource, then packs in relevant detail about the contract's contents. No wasted words; every phrase earns its place.
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 an output schema exists, the description doesn't need to enumerate return fields. It covers the core purpose, the session context, and the semantic classes of operations. With only one optional parameter and strong annotations, the description is sufficient for an agent to understand what the tool does and when to use it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It does mention 'selected session', which implicitly ties to the session_id parameter, but it does not clarify the meaning of null or the default behavior. For a single optional parameter, this is adequate but not thorough; the parameter name is self-explanatory, but the null semantics remain ambiguous.
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 a clear resource: 'emulator-mcp-capabilities contract 1.0 for the selected session'. It also distinguishes the tool by detailing what the contract includes (available/conditional/unavailable operations across launch/input/capture/diagnostic), setting it apart from sibling tools like eden_get_logs or eden_get_runtime_metrics.
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 returns capabilities for a selected session, implying use when you need to know which operations are possible for that session. However, it lacks explicit exclusions or alternatives, such as saying 'use eden_validate_launch to check launch-specific status', so it stops short of full 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?
Annotations declare readOnlyHint=true, and the description adds behavioral context: it continues an existing wait, does not launch a second process, and never duplicates a load request. This addresses side-effect concerns beyond the annotation.
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, purpose first, then usage guidance. No filler words, every sentence adds value.
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 and annotations cover read-only, the description provides the key purpose, usage context, and a crucial behavioral guarantee. It doesn't explain timeout behavior or parameter mapping, but the enum and defaults are self-explanatory. Good coverage for a wait tool.
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 has 4 parameters with 0% description coverage. The description does not explain the role of launch_id/session_id or how target enum maps to the described states, leaving the agent to infer from schema defaults. It does not compensate for the lack of parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'wait' and identifies the resource 'Eden launch state,' explaining it continues a previously started Eden process until it exposes control or produces its first frame. It distinguishes itself from eden_start_game by explicitly stating it does not start a second process.
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: after a retryable eden_start_game timeout. Also gives exclusions: no second process started and no duplicated update load request. While it doesn't name alternative tools, it clearly differentiates from start_game.
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 destructiveHint annotation, the description discloses that the tool defaults to dry-run, meaning it is non-destructive by default, and that it only affects diagnostic bundles, not user files. This adds valuable safety context beyond the annotation.
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 sentence that front-loads the primary purpose, then adds the dry-run default and scope exclusions. Every word contributes meaning without unnecessary 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 the tool's purpose, scope, and safety default. Given the output schema exists and destructiveHint is annotated, return values and destructive nature are covered. However, the parameter semantics remain under-specified, and the description could briefly mention how keep_latest and older_than_days define the retention policy.
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 mentions 'dry-run' indirectly. The meanings of session_id, keep_latest, and older_than_days are not explicitly explained, relying on parameter names and defaults. This is a significant gap given the lack of schema 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 uses the specific verb 'Apply retention' and clearly identifies the resource as 'Eden MCP diagnostic bundle names'. It explicitly lists what is outside scope (game, profile, patch, save, key, firmware, arbitrary user files), distinguishing it from cleanup of other file types and from sibling tools like eden_cleanup_sessions.
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 scope: it only applies to diagnostic bundle names, and lists what is outside scope. It also mentions the default dry-run, informing the agent that preview is the default behavior. This gives clear when-to-use and when-not-to-use guidance, even without naming alternative tools directly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, but the description adds value by explicitly stating 'never deletes files' and detailing the classification categories. This reinforces the safety profile and gives richer behavioral context without contradicting the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary purpose and a clear safety note. Every sentence earns its place with no repetition of the title or 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?
Given the low complexity (no parameters) and presence of an output schema, the description fully covers what the tool does and its safety behavior. It is complete for an agent to select and invoke the tool appropriately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema covers all (none) with 100% coverage, so the baseline is 4. The description adds no parameter-specific details, but none are needed since there are no inputs to explain.
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: 'Inventory managed-session disk usage and classify active, reclaimable, protected, unconfirmed, and legacy directories.' This specifies a concrete verb and resource, and distinguishes it from cleanup-oriented siblings like eden_cleanup_sessions.
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 by stating 'This tool never deletes files,' which implies it should be used for inspection rather than cleanup. It does not explicitly name alternative tools for deletion, so it stops short of full when/when-not guidance, but the non-destructive implication is strong.
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:

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

Score Badge

Copy to your README.md:

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

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