mango-office-mcp

Server Quality Checklist

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

Latest release: v1.1.0
Disambiguation2/5
There is clear overlap between get_calls and skill_call_history (both provide call logs, with the latter being today-only), and similarly get_stats vs skill_stats. While descriptions clarify the difference, agents could easily misselect when they want period-based vs today's data. Other tools like make_call, send_sms, get_users, get_recording are distinct.
Naming Consistency2/5
Naming is inconsistent: most tools use verb_noun (get_calls, make_call, send_sms), but two use the prefix 'skill_' (skill_call_history, skill_stats) which breaks the pattern. The 'skill_' prefix is unusual and suggests a different convention without clear rationale, making it harder to predict tool names.
Tool Count4/5
With 8 tools, the count is appropriate for a telephony server. However, the two redundant pairs (get_calls/skill_call_history, get_stats/skill_stats) could be consolidated, suggesting the surface is slightly padded but still reasonable.
Completeness4/5
The tools cover core telephony operations: retrieving calls, users, statistics, recordings, initiating calls, and sending SMS. Minor gaps exist (e.g., no call status updates, no user management beyond listing), but the main workflows are supported and no dead ends are evident.
Average 3/5 across 8 of 8 tools scored.
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 failing
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 provided, the description carries the full burden of disclosing behavior. It only states that SMS is sent, but does not mention any side effects, required permissions, rate limits, or what happens on failure. It is a mutating operation (send) but gives no additional behavioral context beyond the literal action.
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 description is very short, which is concise, but it essentially restates the tool name ('Send SMS') without adding value. It is not verbose, yet it does not earn its place because it provides almost no information beyond the name. It is appropriately sized but under-specified.
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, the description should at least hint at the return value or success/failure indication, but it does not. It also lacks context about using Mango Office, any prerequisites, or how this fits into the broader set of sibling tools. For a simple send operation, it misses key contextual details that an agent would need.
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 input schema covers 100% of parameters with descriptions for each, so the baseline is 3. The description adds no additional semantic meaning beyond what the schema already provides. The parameter names and descriptions are sufficient, so the description does not need to compensate.
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 verb 'Send' and the resource 'SMS via Mango Office', making the tool's purpose understandable. However, it does not differentiate it from sibling tools like make_call, which could be a similar operation. It's a clear but not fully distinguishing description.
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 on when to use this tool versus alternatives. No mention of prerequisites, limitations, or scenarios where another tool (e.g., make_call) would be more appropriate. The description provides no context for the agent to choose this tool over others.
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. The description only says 'get call history for a period,' with no information about pagination, default limits, sorting, rate limits, or what happens with large datasets. It is a sparse definition that fails to inform the agent of any behavioral traits beyond the obvious read operation.
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 wasted words. It is appropriately short, though it sacrifices detail for brevity. The structure is acceptable, but given the lack of behavioral info, it could be improved without being verbose.
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 output schema and no annotations, the description should compensate by explaining what the agent will get back, any constraints on the period, or how to handle edge cases. The current description only covers the core action, leaving out essential context like return structure, default behavior, and when to prefer alternatives. This makes it incomplete for effective use.
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 description coverage is 100%, so all three parameters have descriptions in the schema. The tool description itself adds no additional meaning beyond what the schema provides (e.g., date formats are already specified in the schema). This matches the baseline of 3 for well-documented schemas.
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 verb ('get') and resource ('call history') plus a period constraint, so an agent knows the basic action. However, it does not distinguish itself from the sibling tool 'skill_call_history', which likely serves a similar purpose. The purpose is clear but not differentiated from alternatives.
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 on when to use this tool versus alternatives like 'skill_call_history' or 'get_stats'. There is no mention of prerequisites, limitations, or exclusions. The agent is left to infer usage from the name and schema alone.
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 only says 'get summary statistics' but does not disclose what metrics are returned (e.g., call counts, durations, success rates), whether aggregation is across all users or filtered, or any permissions needed. This is a significant gap for a stats tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no unnecessary words, and the core purpose is front-loaded. It is efficient and doesn't waste tokens, though it is minimal in content. It does not repeat schema information, so it earns a solid score.
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 no output schema and no annotations, so the description must explain the return value (what stats are included) and any operational context (e.g., date range format, limits). It fails to do so, leaving an agent with insufficient information to know what to expect or how to handle results. This is inadequate for a data-retrieval 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 description coverage is 100%, and both parameters (date_from, date_to) are already described with type and format hints. The description adds no additional meaning beyond the period concept, which is already implied by the parameters. Baseline 3 is appropriate since the schema carries the parameter documentation.
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 the verb 'Получить' (Get) and the resource 'сводную статистику звонков' (summary statistics of calls) with a time period, making the core purpose clear. It is not a tautology and provides a distinct resource from siblings like get_calls (listing calls) and skill_stats (skill-specific statistics), though it does not explicitly distinguish them.
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 on when to use this tool versus alternatives. The description only states what it does, with no context about typical use cases, exclusions, or references to sibling tools like get_calls or skill_stats.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only says 'summary' without detailing what the output includes, whether it requires authentication, or any side effects. This is minimal disclosure for a tool that likely returns data.
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 extremely concise — a single short sentence. It is front-loaded and avoids filler. However, it might be too terse, missing useful elaboration on what constitutes the summary.
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 the low complexity (no params, no output schema), the description is still incomplete. It does not clarify what the summary contains, how it relates to other tools like get_stats, or any practical usage details. An agent would lack sufficient context to choose this tool confidently.
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 the baseline score is 4. The description does not need to explain parameter semantics since there are none, and the schema is empty.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: call statistics for today as a summary. It names the resource (calls) and scope (today). However, it does not differentiate from sibling tools like 'get_stats' which might also provide statistics; the precise difference is left ambiguous.
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 on when to use this tool versus alternatives (e.g., get_stats, get_calls). There is no mention of context, prerequisites, or exclusions. An agent would have to infer the intended use case from the name alone.
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?
Annotations are absent, so the description must carry the behavioral burden. It implies a read-only operation ('get a link') but does not disclose any side effects, authentication requirements, or response format. It also doesn't clarify how the 'action' parameter changes behavior beyond the schema enum.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence precisely captures the tool's purpose with no filler. It is minimal but effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with two well-documented parameters, the description is minimally adequate. However, it does not explicitly state the output type (a URL string vs. a JSON object) or address error scenarios. The lack of an output schema makes this more critical, so a 3 is given.
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 input schema documents both parameters with descriptions and enum values, achieving 100% coverage. The description adds no additional meaning or context to the parameters, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a link to a call recording, specifying the verb 'get' and resource 'recording'. It is distinguishable from siblings like get_calls (list of calls) and get_users (list of users) by its focus on a specific recording. However, it doesn't explicitly mention it operates by recording ID, though that is implied by the required parameter.
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 on when to use this tool versus alternatives, nor when to choose the 'play' vs 'download' action. Sibling tools like get_calls exist, but the description doesn't mention any conditions that would select this tool over them.
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. The phrase 'ready report' hints that the tool returns an aggregated, pre-formatted output rather than raw data, but it does not mention side effects, permissions, or what the report contains. This is minimal disclosure for a tool with no annotation support.
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, front-loaded with the core purpose. There is no wasted text, and it is appropriately brief for a parameterless tool. It could arguably be more descriptive, but it remains efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple parameterless tool, the description provides the essential purpose and scope. However, it does not explain what 'ready report' means in terms of output structure, and it does not clarify how this tool differs from get_calls or get_stats. Given the sibling context, an agent might not know which tool to use without further investigation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema is an empty object, so there is nothing for the description to explain. Following the baseline rule for 0 parameters, the description appropriately does not need to elaborate on parameter semantics.
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 'Call history for today — ready report.' This clearly indicates the tool returns a pre-aggregated report of calls for the current day. It is specific about the resource (call history) and time scope (today), and avoids being a tautology. However, it does not explicitly differentiate from sibling tools like get_calls, which also deals with calls, so it loses a point.
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 on when to use this tool versus alternatives like get_calls or get_stats. The description does not mention any conditions, exclusions, or alternative routing. The only implied usage is for today's call history, but it does not explain why the agent should choose this over a more flexible tool.
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 must disclose behavioral traits. It only states the action without mentioning side effects, success/failure behavior, asynchronicity, or any constraints. For a state-changing tool, this is a minimal disclosure and leaves the agent uncertain about the operation's full impact.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, compact sentence with no filler. It effectively communicates the core purpose without verbosity, making it easy to parse.
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 the tool initiates a potentially blocking or asynchronous action, the description lacks crucial context like whether it returns a call ID, how errors are reported, or if there are limitations on simultaneity. The agent has only the schema to work with, which isn't enough for a complete understanding of the call lifecycle.
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 covers 100% of parameters with descriptions, so the description adds little semantic value. It does imply the call is a 'callback' but doesn't clarify parameters beyond the schema, which already explains each field well. Baseline of 3 is appropriate.
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 verb 'инициировать' (initiate) and the resource 'исходящий звонок' (outgoing call) via Mango Office. It distinguishes from sibling tools like get_calls, which are read-oriented, though it doesn't explicitly call out the difference. The action is 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?
No explicit guidance on when to use versus alternatives is provided, but since there is no sibling tool for making calls, the intended use is fairly obvious. However, prerequisites like required permissions or call context are not mentioned, leaving some ambiguity for an agent.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states that the tool retrieves a user list, but does not mention any constraints, side effects, performance characteristics, or response format. For a read operation this is minimal, but it lacks transparency about anything beyond the basic action.
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 with no redundant words. It is front-loaded with the action and resource, making it immediately scannable. Every word 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?
For a simple list retrieval tool with one parameter and no output schema, the description is minimally adequate. However, it omits details like the structure of the returned users, any permissions needed, or whether pagination is handled via the limit parameter. Given the absence of annotations, more context would improve completeness, but the simplicity of the tool makes this a borderline 3.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (the limit parameter is described in the schema as 'Количество пользователей'). The description adds no extra meaning beyond what the schema already provides. Baseline of 3 is appropriate since the schema fully documents the parameter.
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 states a clear verb ('Получить' = get) and a specific resource ('список пользователей Mango Office' = list of Mango Office users). It is unambiguous and distinct from the sibling tools (get_calls, make_call, etc.), which operate on calls and SMS. The purpose is immediately obvious.
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 on when to use this tool versus alternatives, or any usage context such as pagination, authentication requirements, or typical scenarios. It simply states what it does, leaving the agent to infer when it is appropriate.
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:

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

Score Badge

Copy to your README.md:

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

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