mcp-dolphin

by dmang-dev

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

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

Latest release: v0.2.0
Disambiguation5/5
Every tool targets a distinct action: frame advance, diagnostics (ping, info), memory reads/writes at specific widths, button presses per controller type, state save/load, and reset. No two tools have overlapping or ambiguous purposes.
Naming Consistency5/5
All tools follow the consistent pattern 'dolphin_verb_noun' or 'dolphin_noun_verb' with snake_case, e.g., dolphin_frame_advance, dolphin_read32, dolphin_press_gc_buttons. The read/write family uses a numbered suffix, while state and button tools use descriptive suffixes.
Tool Count5/5
17 tools cover the essential operations for controlling a Dolphin emulator: input (GC and Wii), memory access (5 read tools, 4 write tools, range), state management (save/load), diagnostics (ping, get info), reset, and frame advance. This is well-scoped and not excessive.
Completeness4/5
The tool set covers most core workflows (frame-perfect input, memory manipulation, state saving, diagnostics). However, the descriptions mention dolphin_pause and dolphin_resume tools that are not present, creating a dependency gap for frame_advance. Adding pause/resume would make the set complete.
Average 4.8/5 across 17 of 17 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- 0 of 1 community issues answered or closed in the last 6 months
- 37 commits in the last 12 weeks
- Last stable release on May 19, 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.
This repository includes a glama.json configuration file.
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.
View related servers

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

Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Disclosed as 'DESTRUCTIVE to angular-velocity state' with 'ClearOn::NextFrame semantics', giving clear behavioral expectations for a tool with no 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?
Uses labeled sections (PURPOSE, USAGE, BEHAVIOR, RETURNS) with minimal, effective sentences. No superfluous 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?
Covers purpose, usage, behavioral effects, and return format adequately. Lacks error handling or edge cases, but is sufficient for typical use given no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema already describes each parameter with units. Description repeats units and adds context about axes but does not significantly expand beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Set the Wii MotionPlus angular velocity on the given port', specifying the action and resource. It distinguishes from sibling tools like dolphin_set_wiimote_acceleration and dolphin_set_wiimote_pointer.
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?
Provides explicit usage context: 'Use for games that read rotation rate from the MotionPlus add-on' and mentions prerequisite about controller config. Does not explicitly contrast with alternatives but is sufficiently clear.
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 covers behavior: it declares the tool 'DESTRUCTIVE to pointer state,' explains coordinate normalization and typical range, and mentions ClearOn::NextFrame semantics for holding positions across frames. This provides rich behavioral insight.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with labeled sections (PURPOSE, USAGE, BEHAVIOR, RETURNS), making it easy for an agent to parse. It's concise enough to be informative without unnecessary 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 no output schema, the description provides a return string example. It covers input parameters, usage context, and behavioral traits. It could mention error handling or prerequisites (e.g., Dolphin must be running), but overall is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (all parameters documented), but the description adds value by explaining that coordinates are normalised floats, typical range, and that port defaults to 0. It also clarifies the need to call repeatedly to hold position, which is beyond schema detail.
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 begins with 'PURPOSE: Set the Wii Remote's IR pointer position on the given port,' which clearly states the action and resource. It distinguishes from sibling tools like dolphin_set_wiimote_acceleration by focusing on pointer position and provides example game titles for context.
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 USAGE section explicitly lists use cases (menu navigation in Wii titles) and suggests combining with dolphin_press_wiimote_buttons for click-and-aim sequences. While it doesn't explicitly state when not to use or list alternatives, the sibling tools are differentiated by their functions.
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?
No annotations are provided, so the description carries full responsibility. It declares 'No side effects — pure read.' It details alignment behavior (MUST be 8-byte aligned) and warns that misaligned accesses silently return aligned-down data. It explains the return format as a decimal string to preserve precision and lists error conditions (unmapped address, bridge disconnect, FAIL).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections (PURPOSE, USAGE, BEHAVIOR, memory landmarks, Notes, RETURNS) and front-loaded. While comprehensive, it is somewhat lengthy due to detailed memory map and general notes that could be condensed. Still, every section serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity and lack of output schema, the description covers all necessary aspects: purpose, usage guidelines, behavioral details, parameter constraints, return format, and error conditions. The memory map and endianness notes provide essential context for correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The input schema already thoroughly describes the address parameter (alignment, ranges, 8-byte read). The tool description adds some context (memory map, return format) but does not significantly enhance understanding of the parameter itself beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Read an unsigned 64-bit big-endian value from PowerPC memory at the given absolute address.' It specifically contrasts with smaller reads (e.g., 'usually game state is 32-bit') and advises using this only for actual 64-bit fields, effectively distinguishing it from sibling tools like dolphin_read32.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use ('Use this when you actually have a 64-bit field') and when not to ('not as a convenience for two 32-bit reads'). It provides alignment requirements (8-byte aligned) and directs unaligned reads to dolphin_read_range. The memory map helps users choose valid addresses.
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?
No annotations exist, so the description fully covers behavior. It states it is destructive with no undo, mentions error conditions on bridge disconnect, explains byte swapping, and provides extensive memory layout details. This is thorough and transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (Purpose, Usage, Behavior) and front-loaded with key information. It is lengthy due to a detailed memory map, but each part is useful and earned its place. Slightly verbose, but justified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity and absence of an output schema, the description covers return format, errors, alignment, byte ordering, and memory ranges. It provides all necessary context for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the schema already explains alignment, ranges, and signed encoding. The description adds context about byte swapping and big-endian handling, but doesn't significantly enhance parameter semantics beyond what the schema provides. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the purpose as writing an unsigned 16-bit big-endian value to PowerPC memory. It clearly identifies the verb (write) and resource (16-bit value), and distinguishes from sibling tools by mentioning alternatives for other sizes.
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 guidance for 16-bit cheats/pokes and directs to sibling tools for other sizes. It also notes alignment requirements and byte swapping, giving clear context for when to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully explains blocking behavior, timeout, reliance on emulator state, and that it does not pause/resume. This covers all behavioral traits needed for correct invocation.
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?
Well-organized with labeled sections (PURPOSE, USAGE, BEHAVIOR, RETURNS). Every sentence is informative, and the description is appropriately sized for the tool's simplicity.
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 absence of annotations and output schema, the description covers all essential aspects: blocking, timeout, dependency on unpaused state, and return value format. No gaps remain for safe usage.
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 already describes the 'frames' parameter well (1-600, time equivalence). The description adds context about chaining larger values and the counter mechanics, providing incremental value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the purpose: waiting for a specified number of frames using a monotonic counter. This is distinct from all sibling tools, which read/write memory or control other aspects.
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?
Provides a practical usage loop (pause, set controller, frame_advance, read memory) and warns that the emulator must be unpaused, advising to call dolphin_resume first. It implicitly guides when to use (TAS sequencing) but doesn't explicitly exclude other scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Explicitly states 'DESTRUCTIVE TO LIVE STATE: replaces ALL current emulator state' and warns of crash risk from incompatible states. No annotations provided, so description fully carries burden.
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?
Four dense, front-loaded sentences with zero fluff. Every sentence serves a purpose: purpose, usage, behavior, and return value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema), the description fully covers purpose, usage, behavior, constraints, and return. Completely adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter 'slot', and description adds no additional meaning beyond the schema's own description. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Load a previously-saved state from the given slot, replacing all live state.' Specific verb and resource, distinguishes from sibling dolphin_save_state.
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 describes counterpart relationship and provides classic usage pattern: save_state(N) → experiment → load_state(N). Also warns about compatibility requirements.
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, description covers all behavioral traits: no side effects, timeout, connection details, prerequisites (bridge must be loaded). Discloses internal mechanism and error conditions.
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?
Well-structured with labeled sections (PURPOSE, USAGE, BEHAVIOR, RETURNS). Concise yet comprehensive, 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?
Completely covers all relevant aspects for a zero-parameter tool: purpose, usage, behavior, and return value. No output schema needed; description handles it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters. Baseline 4 for 0 params. Description adds value by explaining return format, but not required.
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?
Explicitly states purpose: verify bridge reachable and responding. Clearly distinct from sibling tools (e.g., dolphin_read*, dolphin_press_*).
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?
States 'Call once at session start before other tool calls,' providing clear usage context. Does not explicitly mention when not to use or alternatives, but is sufficient.
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?
Describes no side effects (pure read), alignment and error conditions, endianness handling, and behavior of Felk helpers. Warns about reading MEM2 on GameCube. Fully transparent without annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with PURPOSE, USAGE, BEHAVIOR, RETURNS, and Notes sections. However, the included memory map is lengthy and could be externalized. Overall organized but slightly verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema provided, but description explicitly states return format and covers error cases. Includes alignment, endianness, and memory map details. Fully sufficient for an AI agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description already covers address format and alignment, but the tool description adds nuance about alignment exception on real hardware vs emulator, and recommends read_range for unaligned reads. Adds value beyond 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?
Clearly states the purpose: read an unsigned 16-bit big-endian value from PowerPC memory. References specific use cases (HP, score, coordinates) and distinguishes from sibling read tools (read8, read32, read64).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use this tool vs alternatives: 'For single bytes use dolphin_read8; for 32/64-bit use dolphin_read32/read64.' Also specifies alignment requirements and provides context for memory regions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses all critical behavioral traits: destructiveness (no undo), alignment requirement (8-byte), value format (decimal string for precision beyond 2^53), and atomicity. It also explains the endianness handling and address truncation, meeting the full burden since no annotations are provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (PURPOSE, USAGE, BEHAVIOR, RETURNS) and includes a detailed memory map. While somewhat long, every sentence serves a purpose and the most critical information is front-loaded. It could be slightly more concise, but it is not wasteful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (write to emulated memory with alignment and endianness concerns) and the absence of an output schema, the description is remarkably complete. It covers safety, value range, alignment, atomicity, endianness, address truncation, and provides a comprehensive memory map for GameCube/Wii.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers both parameters with descriptions (100% coverage), so baseline is 3. The description adds significant value beyond the schema by explaining why the value is a decimal string, detailing alignment behavior (silent alignment down), and providing memory map ranges. This extra context justifies a 4.
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 purpose as writing an unsigned 64-bit big-endian value to PowerPC memory. It distinguishes itself from sibling tools like dolphin_write32 by noting its preference for atomic operations when ordering matters.
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 guidelines, including when to use this tool (for paired 32-bit slots, doubles, packed flags) and when to prefer it over alternatives (e.g., chaining two write32s). It also notes atomicity from the game's perspective.
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?
Full disclosure: destructive, no undo, bypasses MMU, writes to read-only regions silently dropped, immediate effect but visible on next tick, and regions to avoid. Compensates for missing annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Structured with sections (PURPOSE, USAGE, BEHAVIOR, memory map) and bold labels. Somewhat long but necessary due to complexity; no wasted sentences.
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?
Covers all aspects: purpose, usage, behavior, parameter semantics, return format, and critical context (memory map, alignment, endianness). No 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 covers 100% params, but description adds significant value: detailed memory map, big-endian handling, and address range guidance. Exceeds baseline.
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?
Clearly states writing a single byte, specifies use cases (cheats, debug pokes), and distinguishes from sibling tools for other widths.
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 when to use (single-byte) and when to prefer alternatives (16/32/64-bit), mentions save/load for rollback, and warns about alignment and read-only regions.
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 discloses behavior: 'No side effects — pure read.', alignment requirement, error conditions (unmapped address, disconnect, FAIL), endianness handling, and memory mapping details (MEM1, MEM2, Hollywood I/O). It also explains pointer dereferencing and byte swap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with labeled sections (PURPOSE, USAGE, BEHAVIOR, NOTES, RETURNS). It is front-loaded and every sentence adds essential information for an emulator memory reading tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity and lack of output schema, the description is exceptionally complete: it covers purpose, usage, behavior, alignment, error handling, memory map, endianness, and return format. No gaps are apparent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a detailed address description. The description adds context beyond the schema, such as the byte swap helper behavior, pointer dereferencing notes, and memory map ranges. It provides slightly more value than the baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the exact action: reading an unsigned 32-bit big-endian value from PowerPC memory. It specifies the resource (32-bit value at absolute address) and distinguishes from sibling tools by mentioning use cases (timestamps, counters, colors, pointers) and referring to 8/16/64-bit variants.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use for timestamps, large counters, RGBA colors, full pointers' and 'For 8/16/64-bit values use the corresponding sibling.' It also provides alignment requirements and address ranges, giving clear when-to-use and implicit 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully covers behavior: 'No side effects — pure read. No alignment requirement. Returns an error on unmapped address, bridge disconnect, or bridge FAIL.' Also details return format and address space.
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?
Well-structured with headers and clear sections, but the address space map and notes add length. However, every sentence earns its place for context; could be slightly trimmed.
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?
Complete for a single-byte read tool: explains return format, error conditions, address space, and big-endian handling. No output schema needed as return is described in text.
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 coverage is 100%, but the description adds significant value by explaining the address parameter with ranges, hex literal usage, and big-endian interpretation, far exceeding the schema description.
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 'Read an unsigned 8-bit byte from PowerPC memory' and distinguishes from siblings by explicitly naming alternatives for 16/32/64-bit and range reads.
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?
Provides explicit guidance: 'Use for single-byte fields — flags, counters, small enums. For 16/32/64-bit values use dolphin_read16/read32/read64. For spans of more than ~4 bytes use dolphin_read_range.' Includes alignment and endianness context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavior: no side effects, no alignment requirement, real-time bridge byte-by-byte reading, big-endian byte swap handled by helpers, address truncation for 64-bit addresses, and memory region characteristics. It also describes the return format in detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear headers (PURPOSE, USAGE, BEHAVIOR, RETURNS) and front-loaded purpose. However, the memory region table is extensive and could be summarized or linked externally; it adds context but increases length. Still, every sentence earns its place for a complex tool.
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 description is complete for a read tool with no output schema: it explains return format, covers edge cases (e.g., GameCube vs Wii memory, truncation), and provides enough context for safe and effective use. No gaps remain.
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 coverage is 100%, but the description adds significant meaning beyond the schema: explains address as absolute with no alignment requirement, length max 65536 with chunking advice, and provides a comprehensive memory region table to assist in choosing valid addresses. This adds substantial value for correct parameter selection.
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 the purpose: 'Read a contiguous range of bytes from PowerPC memory as a hex dump.' It uses specific verbs ('read') and resources ('PowerPC memory') and distinguishes from siblings by noting it is cheaper for >4 bytes compared to looping dolphin_read8.
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 clear usage guidance: use for >4 bytes as it is far cheaper; specifies maximum size (65536 bytes) and recommends chunking larger reads; warns about reading MEM2 on GameCube (returns garbage) and avoiding Hollywood I/O. It explicitly compares to dolphin_read8, helping the agent choose between 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?
No annotations are provided, so the description fully carries the burden. It explicitly declares the tool as DESTRUCTIVE, clarifies it clears live RAM and returns CPU to boot, and mentions movie state recording behavior. This is comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear labels (PURPOSE, USAGE, BEHAVIOR, RETURNS) and is concise, containing only necessary information. It is front-loaded with the most critical information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and no output schema, the description is complete. It covers purpose, usage, behavioral impact, what it returns, and how it interacts with movie recording. No gaps remain.
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?
There are no parameters in the input schema, so the baseline is 4. The description adds no parameter-level detail, but it is not needed; however, the description itself is rich enough to satisfy the parameter semantics dimension.
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 taps the GameCube/Wii hardware reset button, using the verb 'tap' and specifying the resource (reset button). It distinguishes itself from sibling tools like dolphin_save_state and dolphin_load_state by describing the destructive behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool ('equivalent to power-cycling the reset button') and provides alternatives: to preserve state, use dolphin_save_state first and dolphin_load_state after. This distinguishes it from other state-related siblings.
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?
Discloses critical behavioral traits: destructive overwriting of the target slot without prompt or backup, binding to exact game disc and build, and asynchronous return. Since annotations are absent, the description fully compensates.
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?
Well-structured with labeled sections (PURPOSE, USAGE, BEHAVIOR, RETURNS) for easy parsing. Slightly verbose in some details (e.g., repeating 'Dolphin maps slots...' in two places) but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the single integer parameter, no output schema, and no annotations, the description fully covers all necessary context: purpose, usage, behavior, return value, and side effects. Nothing is left unexplained.
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?
Adds meaning beyond schema: explains slot range and GUI mapping (1-10 to F1-F10) and that slots 0 and 11-255 are programmatic-only. With 100% schema coverage, this provides valuable context not in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool saves complete emulator state to a numbered slot. The verb 'save' and resource 'emulator state' are specific, and the description distinguishes from the sibling 'dolphin_load_state' by naming it as companion.
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?
Explicit usage guidance: 'Rollback point before risky writes, bookmarks, repro sharing.' Also instructs when not to use by referencing the companion tool 'dolphin_load_state' for restoration, providing clear alternatives.
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?
No annotations, so description fully shoulders behavioral disclosure. Labels as DESTRUCTIVE, states no undo, alignment requirement (4-byte), silent drops on read-only regions, big-endian byte swapping, and 32-bit address truncation.
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?
Structured with clear sections (PURPOSE, USAGE, BEHAVIOR, RETURNS). Though lengthy, every sentence adds value. Slight redundancy in address range descriptions, but overall well-organized.
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?
Comprehensive: includes return format, memory region landmarks (MEM1, MEM2, I/O), endianness, pointer handling, and alignment behavior. No gaps given no output schema.
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?
Even with 100% schema coverage, description adds significant value beyond schema: clarifies address alignment details, value range for signed/floats, and big-endian interpretation.
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?
Clearly states the tool writes a 32-bit unsigned big-endian value to PowerPC memory. Distinguishes from siblings by explicitly mentioning alternatives for 8/16/64-bit writes and floats.
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?
Provides explicit when-to-use and when-not-to-use guidance: references dolphin_write8/write16 for smaller values, dolphin_write64 for atomic 64-bit writes, and suggests reinterpreting floats. Also notes alignment and address ranges.
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?
Discloses no side effects and notes it uses the same underlying call as dolphin_ping, which is valuable behavior insight beyond what annotations (absent) provide.
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?
Well-structured with clear section headings (PURPOSE, USAGE, BEHAVIOR, RETURNS), concise yet comprehensive, every sentence 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 zero parameters, no output schema, and no annotations, the description covers purpose, usage, behavior, and return format completely, leaving no 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?
With zero parameters, schema coverage is 100%. The description adds value by explaining the return content (multi-line text) and its diagnostic nature, fully compensating for the lack of 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 reports what the bridge knows about its environment (bridge version, Dolphin label), and distinguishes from siblings by specifying that v0.1.0 does not query game metadata, directing users to dolphin_read_range for game state.
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 it is for diagnostic use, and provides an alternative (dolphin_read_range with specific parameters and decoding instructions) for game state queries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses behavioral traits: it states 'DESTRUCTIVE to controller state for the addressed port. Overwrites all input — anything you don't include is released.' It also explains default values for unspecified fields (false for buttons, 0 for axes).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (PURPOSE, USAGE, BEHAVIOR, RETURNS). Every sentence is necessary and informative, no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description includes a return format hint. It covers all aspects: purpose, usage, behavior, parameters, and return value. For a 2-parameter tool with a nested object, this is complete and leaves no ambiguity.
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?
Although schema coverage is 100%, the description adds significant meaning beyond the schema: it lists exact button names, specifies integer ranges for analog axes (-128..127 for sticks, 0..255 for triggers), and clarifies that omitting a key leaves it at neutral. This provides actionable detail not in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description begins with 'PURPOSE: Set GameCube controller state on a given port for one frame's worth of input.' This clearly states the specific verb (Set), resource (GameCube controller state), and scope (one frame, given port). It distinguishes from sibling tools like dolphin_press_wiimote_buttons.
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: lists supported buttons and axes, explains how to hold buttons across frames by calling repeatedly, and refers to alternating with dolphin_frame_advance for TAS sequences. It gives clear context for when to use this tool and how to combine with siblings.
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 discloses destructive behavior: 'DESTRUCTIVE to Wii Remote state... Anything you don't include is released.' It also describes the return format. This covers the key behavioral trait beyond the input 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?
The description is structured into labeled sections (PURPOSE, USAGE, BEHAVIOR, RETURNS) and every sentence provides essential information without redundancy. It is front-loaded with purpose and usage, making scanning efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool simplicity (2 params, no output schema), the description covers purpose, usage constraints, behavioral effect, and return value. It addresses the absence of annotations by disclosing destructive nature and limitations, making it self-sufficient for correct invocation.
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 coverage is 100%, but the description adds value by listing valid button names and explaining the semantics of omission (released state). This supplements the schema's boolean key expectation and clarifies inventory through natural language.
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: 'Set Wii Remote button state on a given port for one frame's worth of input.' It identifies the specific verb (set), resource (Wii Remote button state), and scope (one frame, port). This distinguishes it from sibling tools like dolphin_press_gc_buttons or dolphin_set_wiimote_pointer.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly lists supported buttons and notes that motion/pointer input and attachments are not covered, advising that games requiring those have limited control. It provides direct context on when to use this tool and its limitations, guiding the agent away from misuse.
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 covers behavior: it declares 'DESTRUCTIVE to accelerometer state', explains 'ClearOn::NextFrame' semantics, and describes the return format. This gives the agent complete understanding of side effects and lifecycle.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with clear headings (PURPOSE, USAGE, BEHAVIOR, RETURNS) and is appropriately sized. Every sentence provides essential information without redundancy, earning its place efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity, lack of annotations, and no output schema, the description is remarkably complete. It covers purpose, usage guidance, behavioral nuances, parameter semantics, and return format, leaving no critical gaps for an agent.
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 coverage is 100%, but the description adds significant value: it explains units (roughly g), gives a concrete example of neutral reading (0,1,0), and advises on single-frame impulse usage. This goes well beyond the schema's minimal 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 clearly states it sets the Wii Remote's accelerometer reading for a given port. It distinguishes from siblings by explicitly mentioning raw accelerometer data and contrasting with higher-level helpers. Examples like Wii Sports bowling/golf swings and Mario Galaxy's shake-to-spin solidify the purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use for games that read raw accelerometer data' and lists specific scenarios. It also tells when not to use it by noting that other features are 'deferred to a future release', providing clear context for selection.
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:

[![mcp-dolphin MCP server](https://glama.ai/mcp/servers/dmang-dev/mcp-dolphin/badges/card.svg)](https://glama.ai/mcp/servers/dmang-dev/mcp-dolphin)

Score Badge

Copy to your README.md:

[![mcp-dolphin MCP server](https://glama.ai/mcp/servers/dmang-dev/mcp-dolphin/badges/score.svg)](https://glama.ai/mcp/servers/dmang-dev/mcp-dolphin)

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/dmang-dev/mcp-dolphin'

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