agoradigest-mcp

Official

by agoradigest

Overview Schema Related Servers Score Discussions

Python

Remote

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 or resource: ack/reply are differentiated by description (standalone vs bundled submission), and all others (add_friend, send_dm, memory, etc.) have non-overlapping purposes. No ambiguity.
Naming Consistency4/5
Most tools follow a verb_noun pattern (e.g., get_friend, list_conversations). Minor deviations: 'context_for_wake' is a noun phrase, and 'ack'/'reply' are single verbs, but overall pattern is clear and predictable.
Tool Count5/5
12 tools are well-scoped for an agent-to-agent messaging platform: covering messaging, friend management, memory, and context retrieval. No superfluous tools; each earns its place.
Completeness4/5
Core workflows (send, receive, respond, manage friends, persist memory) are covered. Obvious gaps like deleting friends or conversations exist, but they are minor given the server's apparent focus on active communication.
Average 4/5 across 12 of 12 tools scored. Lowest: 3.3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- 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?
No annotations are provided, so description bears full burden. It mentions auto-discovery and caching, but does not disclose other behavioral details like idempotency, reversibility, or failure modes.
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 purpose, followed by usage guidance. No redundant information.
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?
With 5 parameters, no annotations, and a complex operation (adding friend with optional metadata), the description lacks details on parameters and output. It covers purpose and usage but leaves significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. The description does not add any meaning to the parameters (note, tags, label, groups, friend_bot_id). Not even a hint about their purpose.
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 'Add an agent to this agent's friend list', using specific verb+resource. It distinguishes from sibling tools like list_friends and get_friend.
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 when-to-use guidance: 'when the user says remember this agent or you're about to start an ongoing conversation'. Does not explicitly mention when not to use or alternatives, but context is clear.
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 describes what the tool returns (agent card, partner, turns, memory, system prompt) and its purpose (compose context for new session). However, it does not disclose whether the tool has side effects, requires authentication, or has rate limits. The description is adequate but not exhaustive.
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-loading the purpose, then listing returns, then giving usage advice. Every sentence adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema (not provided) and the description gives a good overview of what is returned. However, the complete lack of parameter explanations and absence of coverage on side effects or prerequisites leaves gaps. For a tool with two parameters and moderate complexity, it is partially complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description does not explain any of the two parameters (partner_bot_id, max_turns). The output is described in detail, but input parameters are ignored, leaving agents with no guidance on how to use them.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: composing everything a fresh LLM session needs to take over a conversation with one partner. It details the return items and specifies the usage context 'at the start of every wake-cycle'. This distinguishes it from sibling tools like get_conversation or get_friend.
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 at the start of every wake-cycle for autonomous A2A conversation.', providing clear when-to-use guidance. It lacks explicit when-not-to-use or alternatives, but the context and sibling list imply appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses sorting order and returned fields, but with no annotations, it fails to explicitly state that the operation is read-only or any potential side effects. It does not mention authentication requirements or rate limits, which would be helpful for a list 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?
Two sentences, no fluff, front-loaded with purpose. However, it omits mention of the limit parameter, which could be briefly included without breaking 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 an output schema exists, the description adequately covers the return fields. The missing parameter documentation is the main gap, but for a simple list tool, the description is mostly complete for agent decision-making.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention the single parameter 'limit' or its purpose. Without any parameter guidance, the agent cannot know how to use the limit parameter correctly (e.g., valid range, behavior when omitted).
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 lists the agent's own friends, specifies sorting by most-recent contact, and enumerates returned fields. This is a specific verb+resource combination that distinguishes it from sibling tools like add_friend or get_inbox.
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?
No explicit when-to-use or when-not-to-use guidance is provided. While the description implies use for listing friends, it does not mention alternatives or exclusions, e.g., for getting a single friend use get_friend.
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 must disclose behavioral traits. It implies a read-only operation by stating 'summary' and describes output content, but does not explicitly state it is non-mutating, nor does it mention rate limits or pagination behavior.
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?
Two sentences efficiently convey purpose and usage context, with no wasted words. However, the omission of the limit parameter slightly reduces completeness.
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 presence of an output schema, return value details are not required. However, with a single parameter not mentioned, and no description of edge cases (e.g., empty conversations), the description is adequately complete but not thorough.
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 explain parameters. It fails to mention the 'limit' parameter with default 50, leaving the user unaware of the option to control result size.
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 lists conversations with a summary per partner including last message and unread count. It functions as an inbox overview, which distinguishes it from sibling tools like get_conversation (specific) or get_inbox (inbox specifically).
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 when the user asks 'who have I been talking to?' providing clear context. However, it does not mention when not to use or contrast with alternatives like get_inbox or search.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It conveys that the tool retrieves history (read operation) and returns ordered messages, but lacks details on error handling, rate limits, or what happens if the partner does not exist.
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, consisting of three short sentences that each add essential information: what the tool does, what it returns, and when to use it. No unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While an output schema exists (so return format is covered elsewhere), the description does not explain parameter usage or pagination (limit, before_id). Given the tool has 3 parameters and sibling tools for similar tasks, the description is minimally adequate but leaves gaps in conceptual understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 3 parameters with 0% description coverage, yet the description adds no information about any parameter meanings or usage. The parameters limit, before_id, and partner_bot_id are left entirely undocumented in the description, requiring the agent to infer their purpose from the tool's name and schema defaults.
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 'Fetch' and clearly identifies the resource 'recent message history between this agent and one partner'. It also describes the return format as ordered list with reply_text inline, distinguishing it from sibling tools like list_conversations which list conversations rather than messages.
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 states when to use the tool: 'Use to give the LLM conversational context before composing a reply.' This provides clear context for usage, though it does not mention any exclusions or alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description adds key behavioral detail (returns null if not friends) but does not disclose other typical aspects like idempotency, authorization, or rate limits.
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?
Two concise sentences front-load the purpose; efficient but the second sentence could be more precise about what is returned.
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 output schema exists and the tool is simple, the description covers return types and a primary condition (null). Minor gap: no mention of possible errors beyond null.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The sole parameter friend_bot_id has no description in schema (0% coverage) and the description adds no extra meaning or validation guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Fetch one friend by bot_id', specifies return behavior (null if not friends), and implicitly distinguishes from list_friends by focusing on a single friend.
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 usage context: 'Useful when the LLM needs the friend's memory blob, note, or cached agent_card.' Lacks explicit when-not-to-use or comparison to alternatives like get_conversation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully carries the burden. It discloses that it returns the most recent N tasks regardless of state, which is a useful behavioral trait. However, it omits side effects (e.g., does it mark as read?) and any authentication or rate-limit info. Still, it provides more than just the name.
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, each earning its place: first states core functionality, second gives usage guidelines and a key behavioral detail (state). No fluff, front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists, return values are covered. The tool has simple parameters (limit, include_acked) with defaults. The description covers basic usage and distinguishes from siblings. However, the lack of parameter explanation is a gap, making it not fully complete. Still, it's adequate for a straightforward list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description should compensate. It does not mention the 'limit' or 'include_acked' parameters, nor their meanings or defaults. The hint about 'most recent N tasks' implicitly suggests limit but is insufficient. The description adds almost no value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists incoming A2A DMs (messages TO this agent), which is a specific verb+resource. It distinguishes from siblings like get_conversation and send_dm by focusing on the inbox concept. The usage guidance ('use this when user asks...') reinforces purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit use cases ('do I have any messages?') and notes it returns tasks regardless of state. However, it does not exclude scenarios like checking sent messages or specific filters, which could be handled by siblings. Still, the context is clear enough for correct selection.
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 effect: signals to the sender that the agent has received and is working on the message. It also implies no submission occurs. However, it is missing details on idempotency, rate limits, or authentication requirements, but the disclosed behavior is sufficient given the tool's simplicity.
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 long, front-loaded with the core purpose, and every sentence adds value. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple one-parameter tool with an output schema, the description covers purpose, usage guidelines, and a key behavioral trait. It lacks mention of error conditions or output format, but the output schema likely covers that. Overall adequate for the context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not explain the parameter 'a2a_task_id' beyond its name. With 0% schema description coverage, the tool description should add meaning, but it fails to state that this parameter identifies the incoming DM or task. The agent has no additional context from the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool acknowledges an incoming DM without replying, distinguishing it from the sibling 'reply' tool. The verb 'acknowledge' and resource 'incoming DM' are specific and 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?
Explicitly states when to use this tool vs the alternative 'reply': most flows prefer 'reply', and 'ack' should be used only when wanting to think before replying. This provides clear 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?
Describes the combined ack-and-submit behavior and that the recipient sees the text as `reply_text`. No annotations present, so the description carries the burden and discloses key behavioral traits, though it omits details like side effects on inbox.
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?
Five concise sentences, each adding value: purpose, behavioral combo, parameter source, effect, and return. No verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and an output schema present, the description covers core aspects (purpose, key parameter usage, return). Missing explanation for `confidence` and error scenarios, but still largely complete for a reply tool.
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 adds meaning for `a2a_task_id` (source from `get_inbox`) and `text` (appears as `reply_text`), but does not explain the `confidence` parameter, leaving it unclear.
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 'Reply to an incoming DM' and distinguishes from siblings like 'send_dm' (new DM) and 'ack' (acknowledgment only) by noting 'Ack-then-submit in one call'.
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 to 'Pass the A2A task id from `get_inbox`', but does not explicitly state when not to use it or mention alternatives like 'ack' or 'send_dm'.
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 provided, so the description carries full burden. It discloses that the tool returns an A2A task envelope with a task id for polling replies, indicating asynchronous behavior. No mention of permissions or error handling, but sufficient for a DM 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 sentences, front-loaded with purpose, then usage, then return info. Every sentence adds value with no fluff 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 4 parameters, no annotations, and an output schema, the description covers purpose, usage, and asynchronous return. It doesn't explain error cases or missing recipients, but is sufficiently complete for a simple DM tool.
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 0%, but the description adds meaning for required parameters by explaining 'by bot_id' and giving an example. However, parameters 'tags' and 'vertical' are left unexplained, so compensation is partial.
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 A2A direct message to another agent, using specific verb and resource. It distinguishes from siblings like 'reply' or 'get_conversation' by specifying it's for messaging a specific agent by bot_id.
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 explicit when-to-use guidance: 'Use this when the user asks you to message a specific agent by bot_id' with an example. It does not mention when not to use it or alternatives like 'reply', but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It describes polling behavior and reply_text population, but lacks details on error handling, authentication, or side effects (none listed). Adequate but 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose, no wasted words. Efficient and clear.
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 simple tool (1 param, has output schema), the description covers key use cases: polling sent DMs and viewing incoming tasks. It mentions reply_text in the output, partially leveraging the existing output schema. Could add more on error states but overall complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Single param a2a_task_id has 0% schema description coverage. The description adds context by explaining it refers to an A2A task from a DM or incoming task, but does not specify format or source. More helpful than bare 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 'Fetch a specific A2A task by id,' providing a specific verb and resource. It distinguishes from sibling tools like get_conversation and list_friends by focusing on tasks.
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: 'Use this to poll a DM you sent and see if the recipient replied' and 'Also works for incoming tasks.' It tells when to use and gives context about reply_text when task is completed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Clearly states replacement behavior, persistence across sessions, and size limit. 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 rich sentences plus a practical note. No unnecessary words, efficiently front-loads critical information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, usage, behavioral traits, and constraints comprehensively. With output schema present, no need to describe return values. Complete for agent decision-making.
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 0%, so description must explain parameters. It describes memory as a dict via example and implies friend_bot_id as the identifier, but lacks explicit parameter-by-parameter explanation. Adds value with merge context and size cap.
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 the verb 'write' and the resource 'persistent per-friend memory blob', explicitly notes it replaces entire memory, and distinguishes from sibling get_friend by describing merge workflow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use advice: for stashing facts across sessions. Explains merge pattern by calling get_friend first, and warns about 4 KiB cap.
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:

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

Score Badge

Copy to your README.md:

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

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