@zeph-to/mcp-server

Server Quality Checklist

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

Latest release: v2.3.0
Disambiguation4/5
Most tools have clearly distinct purposes (sending notifications, clipboard, file transfer, session rename). The overlapping interactive tools (zeph_prompt, zeph_input, zeph_ask) are differentiated by their exact behavior—buttons vs text vs combined—and the descriptions make this clear, though the similarity is slight.
Naming Consistency4/5
All tools share the 'zeph_' prefix and generally use short action-oriented names like notify, dismiss, broadcast, ask. Some names are nouns (clipboard, file) rather than verbs, but the pattern is predictable and consistent in style, making it easy to infer tool purpose.
Tool Count5/5
11 tools is well within the ideal 3-15 range. The server covers a focused domain of device notifications and interactions without unnecessary bloat, and each tool serves a distinct function.
Completeness5/5
The tool surface provides comprehensive coverage for the domain: sending (notify, broadcast, file), receiving (list), managing (dismiss, dismiss_all), interacting (prompt, input, ask), and session labeling. No obvious missing operations for core workflows.
Average 4.2/5 across 11 of 11 tools scored. Lowest: 3.3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 35 commits in the last 12 weeks
- Last stable release on August 17, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under Apache 2.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false and destructiveHint=false. The description merely restates the sending action without adding behavioral details like rate limits, auth requirements, or side effects (openWorldHint=true suggests unknown side effects). The description lacks additional context beyond what annotations 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?
The description is two sentences, front-loaded with the core purpose, and includes a practical usage hint. Every word serves a purpose with no unnecessary information.
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 tool with five parameters and no output schema, the description explains the primary action and provides a resource lookup hint. However, it fails to describe return values, error conditions, or potential impacts on subscribers, leaving gaps 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?
Schema coverage is 100%, so the schema fully describes all five parameters. The description does not contribute any parameter-specific meaning, maintaining the baseline score of 3 as per rubric when schema coverage is high.
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 'Send a push notification to all subscribers of a channel' with a specific verb and resource. It distinguishes itself from siblings like zeph_notify by the 'broadcast' nature, but does not explicitly differentiate from zeph_notify, which may cause ambiguity.
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 includes a helpful hint to use zeph://channels to find channels, implying a prerequisite. However, it provides no guidance on when to use this tool versus alternatives (e.g., zeph_notify) or scenarios to avoid, leaving usage context vague.
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 annotations, noting that text appears in clipboard history and can be pasted immediately. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (one sentence, 14 words) and front-loaded with the core action.
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 tool with 2 parameters and no output schema, the description adequately covers the action and a key behavioral side effect.
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 description does not add significant meaning beyond what the schema already 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 verb 'Copy' and the resource 'text to the user's device clipboard', distinguishing it from siblings like zeph_broadcast or zeph_notify.
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 (clipboard operations) but does not provide explicit guidance on when to use this tool vs alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide behavioral hints (readOnlyHint=false, destructiveHint=false, idempotentHint=true). The description adds that it clears from the feed, but this is already implied by 'dismiss'. No contradictions; score is adequate but not enhanced.
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 concise sentence that front-loads the action and purpose. No wasted words, and the structure is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one required parameter and annotations providing behavioral context, the description is fairly complete. It covers what, when, and how. Minor gap: could mention nondestructive nature, but annotations already cover that.
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% with a clear description and example for pushId. The description adds no further parameter details beyond the schema, so baseline score 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 clearly states the verb (dismiss), resource (specific push notification), and action (mark as read). It distinguishes from the sibling zeph_dismiss_all by specifying 'by ID' vs. all.
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 to use after processing a notification, giving clear context. However, it lacks explicit guidance on when not to use or comparison to other sibling tools, though the distinction is implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond annotations by explaining the blocking nature, timeout behavior, environment variable requirement, and that attachments arrive as local paths in the result. This adds meaningful context beyond the annotation hints and does not contradict 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 three sentences with no redundancy. It front-loads the core purpose and efficiently covers blocking behavior, prerequisites, and attachment handling.
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 main functional aspects: purpose, blocking/timeout, environment requirement, and result attachment handling. It doesn't describe exact return structure beyond attachments, but given no output schema and moderate complexity, it's reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so all parameters are described in the schema. The description does not add additional parameter-level semantics beyond what's in the schema, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: requesting text input from the user via push notification. It also specifies blocking behavior and attachment delivery, but does not explicitly differentiate from sibling tools like zeph_ask or zeph_prompt.
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 use when interactive user input is needed, and notes the prerequisite ZEPH_HOOK_ID environment variable. However, it provides no explicit guidance on when to use this tool versus sibling tools such as zeph_notify or zeph_ask.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds significant behavioral context beyond annotations: it blocks until response or timeout, requires an environment variable, and sends a push notification. This complements the readOnlyHint=false and openWorldHint=true annotations well.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core purpose, and no unnecessary words. Every sentence adds essential information.
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?
While the description covers the blocking mechanism and environment requirement, it omits what happens on a response (likely returns the chosen action ID) and does not mention the fallback parameter's behavior. For a tool with no output schema, more context on return values would be beneficial.
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 description does not add parameter-specific information beyond what is in the schema, though it frames actions as 'predefined options'.
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 asks the user to choose from predefined options via push notification. It specifies the blocking behavior and timeout, which distinguishes it from siblings like zeph_ask or zeph_input.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a user needs to select from predefined options, but it does not explicitly contrast with sibling tools or provide when-not-to-use guidance. The blocking behavior and env variable requirement are mentioned but no alternatives are suggested.
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 destructiveHint=false, so the tool's safety is clear. The description adds behavioral context like 'list recent' and 'avoid duplicates' (consistent with idempotentHint=true). No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short, front-loaded sentences with no wasted words. Efficiently conveys purpose and usage scenarios.
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 simplicity, complete annotations (readOnly, idempotent, openWorld), and full schema, the description adequately covers purpose and use cases. No output schema needed per rules. It could mention ordering (recent) is implicit, but not required.
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% with detailed descriptions for both parameters (limit and type). The description adds no additional parameter information beyond what the schema provides, so baseline score 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 clearly states 'List recent push notifications' with a specific verb and resource, and adds usage context like checking history, avoiding duplicates, or referencing messages. This distinguishes it from sibling tools like zeph_notify (send) and zeph_dismiss (dismiss).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use this to check notification history, avoid duplicates, or reference previous messages,' providing clear scenarios. It lacks explicit when-not-to-use or naming alternatives, but the usage context is sufficiently clear.
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 provide destructiveHint=true and idempotentHint=true. The description adds that it clears the entire notification feed, specifying scope beyond the annotation hints. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with action. Every word serves a purpose; no waste.
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 zero parameters, annotations present, and no output schema, the description is adequate. It could mention irreversibility or confirmation, but annotations cover destructive behavior.
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 exist, so baseline is 4. The description does not need to add parameter information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states it dismisses all push notifications at once, distinguishing it from the sibling zeph_dismiss which likely handles individual notifications. The verb 'dismiss' and resource 'all push notifications' are clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when you want to clear the entire notification feed, and sibling names suggest zeph_dismiss is for individual dismissal. However, no explicit when-not or alternatives are stated.
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 minimal annotations: images render inline, file types are enumerated, and the two modes are explained. It doesn't contain contradictions with the annotations (readOnlyHint=false, destructiveHint=false) and offers useful operational details such as the 'never base64' rule, though it doesn't cover error handling or permission requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core action, and packs essential usage guidance without any waste. Every clause contributes meaning, making it an exemplar of concision.
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 main use cases and relies on the schema for parameter details. However, it omits the implicit requirement that at least one of filePath or content must be provided, and doesn't state what happens if neither is passed. Given the optional parameters, this leaves a small completeness gap.
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%, so the baseline is 3, but the description significantly enhances parameter understanding by linking filePath to existing files and content to generated text, and clarifying that filePath is required for images/PDFs/binary. The 'never base64 a file into content' warning adds crucial semantics not present in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's primary function: 'Send a file to the user's device.' It distinguishes itself from siblings like zeph_notify or zeph_clipboard by focusing on file transfer, and further clarifies two distinct modes (filePath for existing files, content for generated text). This is a specific verb+resource with a clear scope.
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 guidance on when to use filePath vs content, including an explicit warning against base64-encoding binary files into content. It lacks an explicit comparison to sibling tools or a 'when not to use' clause, but the context is sufficient for an agent to select it for file-sending tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate a write operation (readOnlyHint=false) and open world effects (openWorldHint=true). The description adds that long bodies are automatically uploaded as a file, which is a useful behavioral trait beyond annotations. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: first sentence states core purpose, second adds usage examples and a key behavioral note. No redundant words, front-loaded with important information.
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 notification tool (5 params, no output schema), the description covers purpose, usage, and the file upload behavior. It lacks details on return value or error cases, but is adequate for most agents given the low complexity.
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 rich context: explains priority enum usage ('urgent' for critical, 'low' for background), describes targetDeviceId behavior (omit for default/all), and notes file upload for long bodies. Adds significant 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?
The description clearly states it sends a one-way push notification to user devices, with specific use cases like task completion, errors, or status updates. This distinguishes it from siblings like zeph_ask (two-way) and zeph_broadcast (different broadcast 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 gives explicit usage context (inform about task completion, errors, status updates) but does not explicitly mention when not to use or compare with alternatives like zeph_ask or zeph_broadcast. Still provides solid 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 indicate a non-read-only, open-world, non-destructive operation. The description adds context that the rename persists until changed and targets 'THIS agent session' specifically, making the side effects clear. This goes beyond simply restating 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 three sentences with no fluff. The first sentence states the action, the second provides usage guidance with examples, and the third clarifies persistence. 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?
For a simple tool with one parameter, no output schema, and helpful annotations, the description fully covers the action, the context of use, and the durability of the change. There are no missing details that would cause an agent to misuse the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already covers the single parameter 'alias' with a description. The tool description enhances this by giving examples of valid labels and explaining the purpose behind the parameter ('Label what this session is working on'), adding meaning beyond the raw 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 immediately states the tool's function with a specific verb and resource: 'Set a custom display name for THIS agent session.' It clearly differentiates from sibling tools by specifying this is for renaming the current session in the user's Zeph app, not any other action like notifications or prompts.
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 concrete use case: labeling sessions so the user can distinguish parallel sessions on their phone, with examples ('Prod deploy', 'Auth refactor'). It doesn't explicitly state when not to use it, but since this is a unique action among siblings, the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are present (readOnlyHint=false, openWorldHint=true, destructiveHint=false) but the description adds substantial context beyond them: it blocks until timeout, requires ZEPH_HOOK_ID, exposes attachment handling, and warns that the tool is never end-to-end encrypted. This goes beyond structured fields and helps the agent anticipate side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but every sentence carries critical operational or safety information: purpose, actions best practices, blocking, environment variable, attachments, and encryption. It is front-loaded with the core purpose. Slight redundancy with schema-given actions guidance keeps it from a 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?
The description covers parameters, environment, blocking, attachments, and security, which is comprehensive for usage. However, there is no output schema, and the description does not explain the full return value (e.g., selected action id and typed text) – only mentioning that attachments arrive as paths. This leaves a gap in what the agent can expect from the result.
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% and schema descriptions are detailed. The description nonetheless adds meaning to the actions parameter by recommending 2–4 buttons and a safe Done-like fallback, and by explaining the principle 'steering surface, not decoration.' While some repetition exists, the extra contextual framing improves parameter understanding 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 opens with a specific verb and resource: 'Ask the user a question with quick-reply buttons and a text input field.' It clearly distinguishes from siblings by presenting the combined prompt+input behavior and explicitly contrasts with zeph_notify and zeph_file regarding encryption. This is a clear, actionable purpose statement.
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 guidance is provided: 'actions is the steering surface, not decoration: pass 2–4 buttons on nearly every ask... Leave actions out ONLY when the answer is inherently free-form text.' It also mentions alternatives indirectly by distinguishing from notify/file and clarifies when to omit actions. This satisfies both when-to-use and when-not-to-use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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-server MCP server](https://glama.ai/mcp/servers/zeph-to/mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/zeph-to/mcp-server)

Score Badge

Copy to your README.md:

[![mcp-server MCP server](https://glama.ai/mcp/servers/zeph-to/mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/zeph-to/mcp-server)

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/zeph-to/mcp-server'

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