EarSay MCP

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation5/5
Each tool targets a distinct action on the transcription service: lifecycle (start/stop/pause/resume), retrieval (full vs. incremental), checkpointing, and status. The only potential overlap between voice_get_new and voice_get_text is clearly resolved by their descriptions (incremental since checkpoint vs. all text). No two tools perform the same operation.
Naming Consistency5/5
All tool names follow the voice_<action> pattern using snake_case consistently. Actions are clear verbs or verb-noun combinations (get_new, set_checkpoint, start, stop, pause, resume). This uniformity makes the set predictable and easy to navigate.
Tool Count5/5
With 8 tools, the set is well-scoped for a transcription server. Each tool fulfills a necessary role in the lifecycle, from initialization to text retrieval and checkpoint management. No tool is redundant or extraneous.
Completeness5/5
The tool surface covers the full lifecycle: start/stop, pause/resume, full and incremental text retrieval, checkpoint setting, and status monitoring. This provides all essential operations for interacting with the EarSay transcription server, with no obvious gaps that would hinder typical workflows.
Average 4.4/5 across 8 of 8 tools scored. Lowest: 3.8/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit in the last 12 weeks
- No stable releases found
- 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?
With no annotations, the description must carry the burden of disclosing side effects and safety. It states it returns the complete transcript buffer, which implies a non-destructive read, but it does not explicitly confirm the operation is read-only or that it does not clear the buffer. This is a minor gap for a get-style tool.
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 concise and front-loaded with the main action. However, the second sentence ('Returns the complete transcript buffer.') is largely redundant with the first, providing only slight clarification. No extra fluff, but a small redundancy prevents a perfect 5.
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 zero-parameter tool with an output schema, the description is mostly complete. However, it fails to explicitly relate to sibling tools, particularly voice_get_new, leaving the agent to infer when to choose one over the other. Adding a brief contrast would significantly improve completeness.
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 coverage is 100% (vacuously). There are no parameter details for the description to elaborate on. The baseline for 0 parameters is 4, and the description adds no unnecessary parameter info.
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 all transcribed text since the server started.' It specifies the resource (transcribed text) and the scope (since server start), effectively distinguishing it from the sibling tool voice_get_new which likely retrieves incremental text.
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 the full transcript—but does not explicitly mention alternatives or when not to use it. It could have contrasted with voice_get_new (e.g., 'for only new text, use voice_get_new'). This is a typical case of implied usage without clear guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It clearly states two side effects (stopping the server and releasing the microphone), but does not mention reversibility, session termination consequences, or whether audio data is saved. This is adequate but not rich behavioral 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 is a single sentence that is direct and front-loaded. Every word contributes meaning, with no filler or repetition.
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 (no parameters) and the presence of an output schema, the description covers the primary behavior. It could be enriched by noting that voice_start can restart the session, but the core action is sufficiently specified.
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 shows an empty object. The description adds no parameter information, but none is needed. With 0 params, the baseline is 4, and the description does not detract.
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 clearly identifies the resource ('EarSay transcription server') and the additional action ('release the microphone'). It distinguishes from sibling tools like voice_pause and voice_resume by indicating a full stop rather than a pause.
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 context is clear: use this tool to stop the transcription server and release the microphone. However, it does not explicitly mention when not to use it or cite alternatives such as voice_pause for temporary suspension, so it lacks explicit exclusion 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 annotations, the description carries the burden of disclosure. It transparently reveals that the tool does not auto-advance the checkpoint (by instructing to use set_checkpoint) and returns a 'potential checkpoint index' for later use. This conveys key read-only behavior implicitly, though it doesn't mention error handling or edge cases.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short, front-loaded sentences. Every sentence adds value: the first states the core purpose, the second explains the return content and points to the companion tool. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-argument tool with an output schema, the description covers the main behavior and workflow sufficiently. It explains what is returned (new text and checkpoint index) and how to integrate with set_checkpoint. Lacks details about no-checkpoint behavior but that is a minor edge case given the output schema exists.
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 coverage is 100% effectively. The baseline for zero parameters is 4, and the description adds relevant context about the checkpoint index which relates to the tool's behavior rather than parameters, so no deduction is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get text transcribed since the last checkpoint.' This specifies a unique verb and resource, and distinguishes it from sibling tools like voice_get_text (which likely returns all text) by anchoring on the checkpoint mechanism.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs using voice_set_checkpoint to mark read content, providing a clear workflow. It doesn't explicitly mention when not to use, but the pointer to the complementary sibling tool gives solid contextual 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 annotations, the description carries the full behavioral burden. It discloses a key side effect ('The microphone is re-opened'), which is useful beyond the bare action. It could mention resumption from a checkpoint, but for this simple tool it is sufficiently transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the main action and a clarifying side effect. Every word earns its place; no filler or 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?
The description is complete for a zero-parameter, simple state-transition tool. It conveys the primary purpose and a key behavior, and the sibling list provides surrounding context. An output schema exists, so return value details are not required.
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 there is no parameter meaning to add. According to the rubric, 0 params warrants a baseline 4, and the description does not need to compensate for missing schema info.
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 ('Resume transcription'), the resource (transcription), and the condition ('after a pause'). It effectively distinguishes itself from siblings like voice_start and voice_pause by specifying the resume 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 description provides a clear condition for use ('after a pause'), which tells the agent when this tool is appropriate. However, it does not explicitly exclude alternatives or reference sibling tools, so it falls short of full 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?
With no annotations provided, the description carries full burden. It discloses two meaningful behaviors: 'microphone is released' and 'server stays alive,' which go beyond just the action of pausing. It also implies reversibility via the resume instruction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the primary action. Every word contributes value, no redundancy.
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 simplicity of the tool (no parameters, output schema present), the description fully covers the necessary information: action, behavioral effects, and how to resume. No gaps identified.
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 schema coverage is 100%, so baseline is 4. The description adds no parameter details, but none are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Pause' with the resource 'transcription', and distinguishes itself from siblings by explaining the microphone is released but the server stays alive. This clearly sets it apart from voice_stop and voice_resume.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Call voice_resume to start listening again,' which provides an alternative. It gives clear context for temporary pause but does not explicitly contrast with voice_stop or list exclusions, so it falls short of a full when/when-not guide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. 'Get the current status' clearly implies a read-only operation, and the listing of return fields provides transparency about what data the tool exposes. For a status tool, no side effects are expected, and the description does not obscure any behavior.
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: the first states the action, the second lists outputs. It is front-loaded and every word adds value, with 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 that the tool has no parameters and an output schema is present, the description fully covers the operational scope. It enumerates all return fields, making it complete for a simple, read-only status tool. There are no obvious gaps in context.
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, which earns a baseline 4. The description appropriately focuses on return values instead of attempting to explain inexistent 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 a specific verb ('Get') and resource ('EarSay server status'), and enumerates the exact output fields (status, uptime, character count, checkpoint count, subscription count). This clearly distinguishes it from sibling tools that perform actions like start/stop/pause/resume.
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 clearly states this is for retrieving current server status, which gives an unambiguous usage context. While it doesn't explicitly name alternatives, the sibling tool set shows voice_status is the only status-query tool among action-oriented commands, so exclusion is implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the behavioral trait that setting a checkpoint advances a read cursor and affects voice_get_new. It also states constraints: 'Must be after the last checkpoint and not exceed the total available text.' However, it does not describe return values or error conditions, relying on the output schema for those.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: a one-line summary, a two-sentence explanation, and an Args section. 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?
Given the single-parameter scope and presence of an output schema, the description sufficiently covers what the tool does, its constraints, and its interaction with voice_get_new. The parameter constraints are explicit, and the output schema can handle return details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only provides the parameter name and type. The description adds crucial meaning: 1-indexed, must be after last checkpoint, must not exceed total text. This fully compensates for the schema's 0% description 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?
States a specific action: 'Set a checkpoint at the given character position.' This clearly distinguishes it from sibling tools like voice_get_new or voice_pause by focusing on marking a position in the transcript.
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?
Explains the functional consequence: 'Subsequent calls to voice_get_new will only return text after this position.' This gives clear context for when to use the tool, though it does not explicitly mention alternatives 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?
No annotations are present, so the description carries the burden. It discloses idempotent behavior ('no-op' if already running) and the startup action, though it doesn't detail potential errors or permissions. This is sufficient for a zero-parameter initialization tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the primary action and followed by usage context. 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?
For a simple, parameterless server-start tool, the description covers what it does, when to call, and idempotency. Output schema exists, so return values are structurally defined. Sibling tools are present, and the prerequisite relationship is explicit.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has zero parameters; schema coverage is 100% by default. Baseline 4 applies as there are no parameter semantics to clarify.
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 'Start the EarSay transcription server' with a specific verb and resource. It also positions itself as a prerequisite among voice_* tools, distinguishing it from siblings like voice_stop or voice_pause.
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 instructs 'Call this once before using any other voice_* tools' and explains the no-op behavior when already running, giving clear when-to-use guidance.
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:

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

Score Badge

Copy to your README.md:

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

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