agent-mailbox

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation3/5
Most tools are distinct, but mailbox_send already supports sending to 'all' for broadcast, making mailbox_broadcast redundant. mailbox_check and mailbox_list also overlap in listing/fetching messages, though descriptions partially clarify their intent.
Naming Consistency4/5
All tools share a consistent mailbox_ prefix and mostly use lowercase imperative verbs. However, mailbox_done is a state rather than an action, and mailbox_whoami departs from the verb-first pattern, creating minor inconsistency.
Tool Count5/5
Nine tools is well within the ideal range and each tool serves a plausible part of the mailbox workflow. The count is not bloated and does not feel thin for the stated purpose.
Completeness4/5
The toolkit covers the core mailbox lifecycle: registration, sending, replying, broadcasting, checking, listing, waiting, and acknowledging messages. It lacks explicit deletion, unregistration, or sent-message management, but agents can still accomplish the main workflows without major dead ends.
Average 3.1/5 across 8 of 9 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 21 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 MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the message becomes 'handled' and may later be archived, but it does not explain idempotency, permissions, whether the message disappears from normal views, or what the response contains.
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 very short, front-loaded with the primary verb, and contains no filler. Both sentences contribute meaning, though brevity comes at the cost of missing important context.
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 simple tool this might be sufficient on surface, but with no annotations, no output schema, and undocumented parameters, the description leaves too much unstated. It also fails to position the tool against its mailbox siblings.
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% and the description names no parameters. The agent must infer that msg_id identifies the message and what agent_id means, so the description adds no value beyond the schema.
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 a specific action, 'Mark a message as handled', which clearly identifies the operation and resource. It is distinguishable from siblings like mailbox_send and mailbox_reply, though it does not explicitly name the distinction.
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?
No guidance is given about when to use this tool versus alternatives such as mailbox_list or mailbox_check. The statement 'Done messages can be archived' hints at a consequence but does not provide decision context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 adds the optional status filter and the 'your mailbox' scope, but it does not disclose whether the operation is read-only, how status values are interpreted, whether results are paginated or ordered, or how agent_id affects the call.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words. The core action is front-loaded and the optional qualifier is appended cleanly.
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?
Given no annotations, no output schema, and several sibling mailbox tools, the description is too thin. It does not clarify agent_id, status semantics, return contents, or when to prefer this over mailbox_check and mailbox_wait, so an agent would have to guess important details.
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 gives meaning to 'status' by indicating optional filtering, but it leaves 'agent_id' completely unexplained and does not define valid status values. This is insufficient for two parameters.
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 action ('List messages') and the resource ('your mailbox'), and it mentions an optional status filter. However, it does not distinguish this tool from read-related siblings like mailbox_check or mailbox_wait.
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?
There is no guidance about when to use this tool versus alternatives such as mailbox_check, mailbox_wait, or mailbox_reply. The only usage signal is the verb 'List', which leaves selection among sibling tools to inference.
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 the full burden, and it does disclose the key blocking behavior, the timeout cap, and the immediate-return path. But it omits what happens when the timeout expires (return value vs exception), whether a returned message is consumed, and any side effects. The 'Import time' line adds an implementation detail but not behavioral clarity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The first sentence is concise and front-loaded with the core behavior, and the second sentence adds a useful edge case. But the final 'Import time is at module top' sentence is implementation noise that does not help an agent select or invoke the tool, making the description less crisp than it could be.
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 two parameters with no schema descriptions, no annotations, and no output schema, so the description is the only information source. It fails to specify the timeout outcome, whether messages are consumed, and what the return payload looks like, which are critical for a blocking mailbox read. This makes the definition incomplete for confident invocation.
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 only hints at timeout semantics ('up to timeout'), leaving the timeout_seconds parameter partially explained, and says nothing about agent_id. An agent cannot infer the meaning or allowed values for agent_id from this text.
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 action ('Block') tied to a clear resource (a new mailbox message), and defines the response behavior ('Returns immediately if pending messages exist'). It also names the mechanism (long-poll, up to timeout). However, it never references sibling tools, so differentiation is implicit rather than explicit.
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 only implies when to call this tool — when the agent wants to wait for a message — but doesn't state when to prefer it over mailbox_check or whether it should be used as a fallback. There are no exclusions or alternative routing. The 'Import time' note is irrelevant to usage decisions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 of behavioral disclosure. It states the broadcast includes the boss, which is useful, but it does not clarify side effects (e.g., whether recipients can reply, whether the broadcast creates permanent conversation threads, or whether it requires a special sender permission). 'Broadcast' implies message creation, but key context about delivery and feedback is missing.
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?
A single sentence with no filler, and it front-loads the key scope ('every registered agent') immediately. It is brief and readable, though it sacrifices parameter semantics for brevity.
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?
Given there is no output schema and no annotations, the description needs to explain more: the actual message format, expected delivery behavior, and success/failure indicators. For a broadcast tool with two required parameters and a semi-optional from_id, it leaves too much room for misinterpretation—especially around whether responses are expected or how broadcast history is tracked.
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, but it does not explain what the subject and body parameters represent beyond obvious naming. from_id has a default but its purpose is unclear (who is broadcasting? How is it used?). The description adds no parameter-level detail, leaving the agent to guess formatting or optionality nuances.
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 a clear action ('Broadcast') and the target resource ('every registered agent, including boss'), which distinguishes it from other mailbox tools that send to a single recipient. It could be slightly more explicit about the difference from sibling tools, but the verb and scope are unambiguous.
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 when to use this tool—when you need to reach all registered agents—but does not explicitly contrast it with mailbox_send or mailbox_check. There's no when-not-to-use guidance, so the agent must infer the boundary based on the wording and sibling names.
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 burden of behavioral disclosure. It does disclose idempotency, which is valuable. But it does not describe what happens on first call vs subsequent calls, whether claiming a mailbox is exclusive or shared, what the return value is, or any side effects. For a registration tool with no annotations, this is a moderate gap.
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 one concise sentence plus an idempotency hint. It is front-loaded with the action and wastes no words. It loses one point only because it could have used the space to give parameter or usage hints.
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 simple setup tool with 3 parameters, no annotations, and no output schema, the description is thin. It explains what the tool does but not enough about the parameters, the registration semantics (exclusive ownership? idempotent means same agent re-registers?), or what response to expect. An agent cannot confidently call this correctly on the first try.
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%, and the description does not explain what any of the three parameters (owner, agent_id, description) mean beyond what the schema names show. The description mentions 'agent' and 'mailbox' but adds no meaning to owner or description. Since the schema provides only names and defaults, an agent cannot infer the intended values for owner and description.
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 a clear action: register the agent and claim its mailbox. It goes beyond a tautology by naming the resource (mailbox) and the operation (register/claim). However, it does not explicitly distinguish itself from sibling tools like mailbox_check or mailbox_send, relying on the resource name alone for differentiation.
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 this is a setup or onboarding call — you register before checking or sending mail. It does not state when to call it again, when not to use it, or name alternatives. The idempotency note ('safe to call again') hints at retry scenarios but no explicit guidance is given.
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 the behavioral burden. It does disclose a meaningful behavior: automatic routing to the original sender. However, it does not mention side effects, permission requirements, error behavior, or what happens if the thread or sender cannot be resolved.
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 a single concise sentence with no filler. The core action is front-loaded, and the auto-routing behavior is stated efficiently. It could earn a 5 only if it also briefly clarified the optional agent_id.
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?
Given no annotations, no output schema, and no parameter descriptions, the description is too sparse to fully inform an agent. It fails to explain the role of agent_id, expected response, or failure modes, leaving the agent to guess on important invocation details.
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. 'Reply to a message thread' implies msg_id identifies the thread and body contains the reply content, but the optional agent_id parameter is completely unexplained. The description provides only partial parameter understanding.
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 identifies the action ('Reply to a message thread') and the resource, and adds a distinguishing behavior ('Routes to the original sender automatically') that separates it from a generic send or broadcast tool. It doesn't explicitly name sibling tools, but the purpose is 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: reply to an existing thread rather than starting a new message. It gives enough context to infer when to use it versus mailbox_send or mailbox_broadcast, but it does not explicitly state when not to use it or name alternatives.
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 the full burden of behavioral disclosure. It does reveal a meaningful behavior: the special value all means broadcast. However, it does not explain delivery, side effects, return behavior, or how this differs from the mailbox_broadcast sibling.
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 one concise sentence with no wasted words and front-loads the primary action and recipient variants. It is easily scannable and appropriately tserse for what it communicates.
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 tool with no annotations, no output schema, and multiple sibling tools, this description is too minimal. It lacks the distinction from mailbox_reply/broadcast, does not describe what happens after sending, and does not cover the optional parameters or their effects.
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 description adds helpful meaning for the to parameter by explaining one, list, and all as valid target forms. But with zero schema description coverage, it leaves subject, body, from_id, and priority semantically unexplained, so the description only partially compensates.
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 uses a specific verb and resource: send a message. It clearly lists the recipient forms: one agent, a list of agents, or all. However, it does not differentiate this tool from sibling tools like mailbox_broadcast or mailbox_reply, so it lacks full sibling separation.
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: use this tool when you want to send a message to one recipient, several recipients, or to everyone. It gives no explicit when-not-to-use guidance and does not mention alternate tools such as mailbox_reply or mailbox_broadcast.
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 a significant side effect: fetched messages 'become acked.' This goes beyond what the name alone implies. However, it does not explain what 'acked' means in practice, whether the effect is reversible, or how the mark parameter influences this 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 one tight sentence with a parenthetical, front-loading the core action before the side effect and usage timing. Every phrase earns its place, and there is no filler.
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 no annotations, no output schema, and no parameter descriptions, the single sentence leaves important gaps: what 'acked' means for message availability, the role of mark and agent_id, and how this differs from mailbox_list. An agent can begin to use it but lacks enough context to invoke it with full confidence.
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 carries the full responsibility for explaining parameters, but it mentions neither 'mark' nor 'agent_id.' The parenthetical about messages becoming acked hints at mark's behavior but never names the parameter or clarifies the default true value.
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 a specific action ('Fetch your pending messages') and identifies the resource ('messages'), so an agent can tell this tool retrieves mailbox contents. However, it does not differentiate this tool from the sibling mailbox_list, which likely also relates to reading 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 says 'Call at session start,' giving a clear contextual trigger for when to use this tool. It does not mention alternatives or when not to use it, but the timing guidance is concrete and useful.
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 the behavioral burden. 'List' strongly implies a read-only operation with no side effects, and the description states what information is returned. However, it does not clarify whether registration is required beforehand, whether the output is a simple array or structured object, or whether any permissions are needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that says exactly what the tool does with no filler or repetition. Every word contributes meaning, and the main action and result are 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?
For a zero-parameter introspection tool with no output schema, the description is largely sufficient: it names the two outputs (registered agents and mail root location). It loses one point because it does not specify the output shape or indicate whether mailbox registration is a prerequisite for appearing in the 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?
This tool has zero parameters, so there is nothing meaningful for the description to explain. The schema already covers the parameter surface completely, and the description appropriately focuses on the operation's outcome.
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 ('all registered agents and the mail root location'), making the tool's purpose immediately clear. This also distinguishes it from its siblings, which are all mailbox operations rather than agent-registry introspection.
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 provides no guidance about when to use this tool versus alternatives such as mailbox_list or mailbox_register. It does not mention prerequisites, typical use cases, or exclusions, so the agent must infer context from the name and siblings.
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:

[![agent-mailbox MCP server](https://glama.ai/mcp/servers/polaris-smart/agent-mailbox/badges/card.svg)](https://glama.ai/mcp/servers/polaris-smart/agent-mailbox)

Score Badge

Copy to your README.md:

[![agent-mailbox MCP server](https://glama.ai/mcp/servers/polaris-smart/agent-mailbox/badges/score.svg)](https://glama.ai/mcp/servers/polaris-smart/agent-mailbox)

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/polaris-smart/agent-mailbox'

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