herald

by ZenonEl

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

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

Latest release: v0.6.0
Disambiguation4/5
Most tools have clearly distinct purposes, with send_update, send_text, and send_client_copy all serving different messaging contexts. However, send_update and send_client_copy could be confused as both produce client-ready copy, though their descriptions clarify the structured update vs topic-based copy distinction.
Naming Consistency3/5
The send_*, list_*, and notify_* tools follow a consistent verb_noun pattern, but the inbox_* family breaks this with noun-first names like inbox_status, inbox_fetch, inbox_done, and inbox_export, mixing nouns, verbs, and an adjective. This creates noticeable inconsistency.
Tool Count5/5
With 10 tools, the set is well-scoped for the server's purpose of Telegram messaging and inbox management. Each tool serves a distinct function and none feel redundant or unnecessary.
Completeness4/5
The inbox lifecycle is well covered with status, fetch, export, and done, and the sending tools handle various message types. A minor gap exists in managing destinations or allowed projects, but those are likely configured externally, so core workflows are complete.
Average 4.1/5 across 10 of 10 tools scored. Lowest: 2.6/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 10 commits in the last 12 weeks
- Last stable release on August 26, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under AGPL 3.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

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description mentions server enforcement of length and item limits and safe Telegram HTML rendering, adding some behavioral context. However, it does not disclose side effects like message delivery guarantees, authentication requirements, or error handling. Annotations already set readOnly=false, so the description adds moderate value but is not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is excessively long and repetitive, with many redundant instructions (e.g., multiple statements about omitting completed items, including only relevant questions). It reads more like a style guide than a tool description, lacking brevity and clear structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 13 parameters and no schema description coverage, yet the description does not adequately explain the tool's overall purpose, parameter roles, return value, or selection criteria. It gives partial guidance on content style but misses essential context for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description only indirectly references a few parameters like client_questions and decisions_needed to distinguish their use. It does not systematically explain the meaning or purpose of most parameters (e.g., agent, model, project, summary). The guidance is fragmented and not parameter-focused.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Send a concise, client-ready structured update.' which clearly indicates the action (send) and resource (update). It differentiates from siblings like send_text or notify_completion by emphasizing 'structured' and 'client-ready', making the purpose reasonably clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives. It implies client-facing updates but lacks direct guidance on selection relative to send_text or send_client_copy. No 'when to use' or 'when not to use' is provided.
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?
Adds valuable context beyond annotations: raw Telegram HTML tags, the prohibition on encoding tags, the 4096-character limit, and preset semantics. Annotations already indicate a non-read-only, open-world operation, so no contradiction; the description enriches understanding of the operation's constraints.
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 front-loaded with the purpose and moves to actionable formatting rules. Each sentence provides needed guidance (tag list, encoding warning, preset definitions, character limit) without excessive verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 9-parameter tool, the description is incomplete: it explains formatting and preset choices but not the meaning or constraints of provenance fields (project, subject, agent, model, route, reference) or how they relate to the message. It also omits side-effect details beyond the Telegram limit. The presence of an output schema mitigates return-value gaps but does not cover parameter semantics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description only elaborates on format and preset (e.g., 'brief is the default,' 'standard adds necessary context'). It leaves project, subject, agent, model, route, and reference undefined, relying on names alone. This fails to compensate for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/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: 'Send a formatted message with provenance metadata,' which clearly states the tool's function. The detailed formatting and preset guidance further clarifies scope, though it doesn't explicitly differentiate from sibling tools like send_update or send_client_copy.
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?
Provides concrete usage guidance for format and presets: 'Prefer format="html" for human-facing text,' defines brief/standard/detailed, and warns against encoded tags. However, it does not explain when to choose this tool over alternatives like send_update or send_file, leaving tool selection implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already signal non-read-only, external side effects (openWorldHint), and non-idempotent behavior. The description adds valuable context: allowed_roots path restriction, the auto/non-auto mode selection, and the 1024-character caption limit. 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 three concise sentences, front-loads the primary purpose, and packs essential constraints (allowed roots, kind behavior, caption limits) without fluff. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the high complexity (10 parameters, 6 required) and rich output schema, the description covers key behavioral rules but misses important required parameter semantics and does not fully explain conditions or edge cases. It is more complete than average but still has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains 'path', 'kind', 'caption', and 'format', but leaves required parameters 'project', 'subject', 'agent', 'model', and optional 'route'/'reference' completely undocumented. This is inadequate for a 10-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sends an explicitly requested local file or image with a caption, which is a specific verb+resource+scope. It distinguishes itself from sibling tools like send_text and send_update by focusing on files/images rather than text messages or status updates.
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 usage context: files must resolve under files.allowed_roots, kind=auto behavior is explained, and caption format/length limits are given. It does not explicitly name alternatives or when not to use, but the 'explicitly requested' phrasing implies appropriate conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, covering the safety profile. The description adds contextual detail ('allowed projects', 'default destinations') but does not disclose behavioral traits beyond that, such as ordering or filtering 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 a single, concise sentence that front-loads the action and subject. Every word adds value, with no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, zero-parameter list tool with annotations covering safety and an output schema available, the description fully communicates the tool's purpose. The mention of 'allowed projects' and 'default Telegram destinations' gives sufficient context for invocation.
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 schema coverage is trivially 100%. No parameter descriptions are needed, and the description does not attempt to over-explain. The baseline for zero-parameter tools is 4, and nothing lowers it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('allowed projects and their default Telegram destinations'), clearly distinguishing this tool from sibling send/inbox operations. It unambiguously states what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: call this to discover permitted destinations. However, it does not explicitly state when to use it over alternatives or provide exclusions, so guidance remains implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states 'deletes their downloaded copies,' which is a destructive action, but the annotations declare destructiveHint: false. This is a direct contradiction. The additional note about TTL recovery does not reconcile the mismatch, so the behavioral information is misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each earning its place. The main action is front-loaded, followed by a usage condition and a recovery note. There is no fluff or redundant 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?
The description covers purpose, precondition, parameter shape, and persistence behavior (TTL). It provides enough detail for an agent to invoke the tool correctly, even without an output schema, and the only significant gap is the annotation contradiction which is already flagged.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only defines 'keys' as an array of objects with additionalProperties: true. The description adds essential semantics: 'Each key is {"chat_id": int, "message_id": int}. This precisely specifies the required structure, compensating fully for the 0% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Mark messages as archived, which deletes their downloaded copies.' It uses a specific verb and resource, and the context about buffer copy redundancy distinguishes it from sibling tools like inbox_fetch or inbox_export.
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?
It explicitly says 'Call this only after the messages are in the archive with their hashes' and explains why (the buffer copy is redundant and grows on disk). This provides a clear precondition and rationale, effectively telling the agent 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite annotations indicating a non-read-only, non-destructive action, the description adds valuable behavioral details: never send escaped HTML, avoid emoji/greetings/'done' prefaces, and state concrete results. These formatting rules go beyond what annotations convey.
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 long, front-loaded with the primary action, and each sentence provides actionable guidance without wordiness. It is an excellent model of conciseness.
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 moderate complexity and existence of an output schema, the description covers core usage and formatting behavior well. It does not explain all parameter purposes or contrast with siblings, but it provides enough practical context for a notification tool. A slightly lower score would be warranted if the parameter set were more complex.
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 has 0% description coverage for parameters. The description compensates for the 'format' and 'preset' parameters by explaining when to use each, and 'summary' is implicitly linked to 'state the concrete completed result.' However, the other six parameters (agent, model, project, subject, route, reference) remain unexplained, leaving significant gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it sends a 'concise formatted completion notice' when explicitly requested. This distinguishes it from sibling messaging tools by specifying the completion-notice purpose and the conditional trigger.
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 guidance: use 'brief' preset by default, choose 'standard' or 'detailed' only when user requests more context, and prefer HTML format. Although it does not name alternative sibling tools, it clearly defines when to use this tool versus over-use.
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?
Discloses the side effect of marking messages as taken, consistent with readOnlyHint=false and idempotentHint=false. Clarifies non-destructive behavior ('Fetching does not remove anything') and adds forwarded-message origin context. Slight gap: no mention of error conditions, but the key behavioral traits are covered.
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 sentences, front-loaded with purpose, then critical details. No filler; each sentence earns its place. The structure logically progresses from core action to workflow to recovery use case.
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 the main workflow, time-range semantics, and recovery scenario. Has an output schema, so return values need no explanation. Missing explicit guidance on chat and limit parameters, but these are relatively self-explanatory from the schema names.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description must compensate. It explains since/until as ISO-8601 UTC timestamps and include_taken's purpose. However, chat and limit are left undescribed; limit may be inferred as a count, but chat's role is only implicit from the message context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource: 'Fetch buffered messages for a time range and mark them as taken.' This clearly states the tool's function and distinguishes it from siblings like inbox_done (archive/completion) and inbox_status.
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 directs the workflow: 'call inbox_done once the messages are recorded in the archive.' Also explains the include_taken flag as a recovery mechanism for interrupted batches. This provides clear when-to-use and 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?
The description discloses key behavioral traits beyond the annotations: it copies attachments next to inbox.json and rewrites paths to relative, marks messages as taken, requires target to be a fresh directory, and warns about the consequence of passing raw rows (attachments marked missing). These are side effects and preconditions not captured in the schema or annotations, providing rich transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured. It opens with a one-sentence summary, then elaborates with focused paragraphs on usage, workflow, and key parameter requirements. Every sentence adds value, with no fluff or redundancy. The inclusion of a warning (raw rows) and edge-case handling (include_taken) is packed 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 (6 params, no output schema) and the rich annotations, the description covers the essential aspects: what the tool produces (a self-contained folder), when to use it (archiving), how it integrates with other tools (inbox_done), critical parameter constraints, and a failure mode. This is complete for the intended use case and leaves minimal gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no parameter descriptions (0% coverage), so the description must compensate. It adds crucial semantics for target ('must be a fresh directory') and include_taken ('rebuild a bundle... only route by which attachments can still reach the archive'). However, it does not explain chat, limit, since, or until beyond their names, leaving their meaning and usage partially implicit (e.g., 'range' hints at since/until). While some parameters are covered, the incomplete compensation for the schema gap warrants a mid-range score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a clear, specific action: 'Write a self-contained folder for a range, ready to import into an archive.' It explicitly contrasts with inbox_fetch, stating 'Prefer this over inbox_fetch whenever the messages are going into the archive,' which distinguishes its purpose from the sibling tool. The verb 'write' and resource 'folder' make the operation unambiguous.
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 when-to-use guidance: 'Prefer this over inbox_fetch whenever the messages are going into the archive.' It also instructs on the required workflow ('call inbox_done once they are recorded') and when to set include_taken ('rebuild a bundle for messages handed out earlier but never archived'). This is comprehensive and actionable.
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 already declare readOnly, idempotent, and non-destructive, and the description reinforces and expands on this by noting it works 'without fetching content' and explaining output semantics (volume, age, heartbeat). The last_poll explanation adds significant operational context beyond the annotations, clarifying what the tool reveals about daemon status and potential message loss.
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 compact and well-structured: the first sentence succinctly states the core purpose, the second provides targeted usage guidance, and the third gives critical daemon-health context. Every sentence adds value, and the information is front-loaded with the most essential detail.
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?
Despite having no output schema and no parameters, the description is fully self-contained. It tells the agent what the tool does, when to use it, what to look for, and how to interpret a potential failure state. This is complete for the tool's simple read-only nature and integrates well with the sibling tool list.
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 0 parameters, so there is no parameter complexity to explain. Per the rubric, 0 parameters earns a baseline of 4. The description does not mention parameters, which is appropriate since none exist, and it adds no unnecessary parameter-related text.
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 summarizes the capture daemon's buffered content without fetching it, using a specific verb and resource. It differentiates from siblings by explicitly saying 'Check this before inbox_fetch', establishing its role as a status/inspection tool distinct from fetching or sending.
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 excellent usage guidance: when to use ('before inbox_fetch'), what information it provides (volume per chat, age of oldest message), and how to interpret the daemon's health (last_poll heartbeat with a concrete failure condition). This is exactly the contextual information an agent needs to decide when to call 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?
The description discloses important behavioral traits beyond annotations: it preserves all client subjects, removes only internal reasoning, requires questions only when they block the next action, and enforces a 4096-character limit. It also clarifies that brevity is not achieved by fixed counts, which is non-obvious behavior. This complements the annotations (readOnlyHint=false, etc.) without contradiction.
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 long but every sentence serves a purpose: purpose, usage context, and specific formatting rules. It is front-loaded with the core purpose, followed by actionable guidelines. No word is wasted given the tool's complexity.
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 covers purpose, usage, content constraints, question policy, and the hard length limit. It references context ('client message or current project') and specifies Telegram. With an output schema available, return values need not be described. The tool is complex, but the description is thorough enough for an agent to select and invoke it 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?
The description provides rich semantics for the nested ClientTopic fields, explaining that titles must be concrete subjects, details should contain facts/proposals/actions, and questions have conditional rules. However, it does not address top-level parameters like project, subject, agent, model, route, or reference, leaving those to schema names. Given 0% schema description coverage, the partial compensation is strong but incomplete, warranting 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 opens with 'Send copy-ready text addressed directly to the client,' a specific verb+resource that clearly states the tool's function. It further distinguishes itself as 'the default tool when a manager should be able to copy the body without understanding the project or rewriting it,' separating it from siblings like send_update or send_text.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: 'when a manager should be able to copy the body without understanding the project or rewriting it.' This implies when not to use (when understanding/rewriting is needed). It also provides detailed content rules, such as requiring concrete topic titles and avoiding fixed report headings, guiding the agent on what to include and exclude.
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:

[![herald MCP server](https://glama.ai/mcp/servers/ZenonEl/herald/badges/card.svg)](https://glama.ai/mcp/servers/ZenonEl/herald)

Score Badge

Copy to your README.md:

[![herald MCP server](https://glama.ai/mcp/servers/ZenonEl/herald/badges/score.svg)](https://glama.ai/mcp/servers/ZenonEl/herald)

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/ZenonEl/herald'

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