MCP Aruba Email & Calendar Server

by jackfioru92

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

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

Latest release: v0.2.1
Disambiguation5/5
Each tool has a clearly distinct purpose with no significant overlap. Calendar tools handle specific actions (accept, decline, tentative, create, delete, list), email tools cover distinct operations (list, read, search, send, check bounces, manage signatures), and the separation between email and calendar domains is clear. An agent can easily differentiate between tools like list_emails and search_emails or accept_calendar_event and decline_calendar_event.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern with snake_case throughout. Calendar tools use verbs like accept, decline, create, delete, list, tentative paired with 'calendar_event', while email tools use verbs like list, read, search, send, check, get, set paired with 'email' or related nouns (e.g., 'email_signature', 'bounced_emails'). This uniformity makes the tool set predictable and easy to navigate.
Tool Count5/5
With 14 tools, the count is well-suited for the server's dual-domain purpose of email and calendar management. It provides comprehensive coverage without being overwhelming, balancing core operations (e.g., CRUD for events, email listing/sending) with specialized utilities (e.g., signature management, bounce checking). This scope aligns with typical productivity server expectations.
Completeness4/5
The tool set offers strong coverage for both email and calendar domains, including full lifecycle management for calendar events (create, list, accept/decline/tentative, delete) and essential email operations (send, list, read, search, bounce checking, signature management). Minor gaps exist, such as no tools for updating calendar events or managing email folders, but agents can work around these with the provided tools without significant hindrance.
Average 3.6/5 across 14 of 14 tools scored. Lowest: 2.9/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 status not available
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 behavioral disclosure. It states what the tool does but doesn't mention permissions needed, error conditions (beyond a vague 'error' reference), or whether it's read-only (implied but not explicit). For a tool with zero annotation coverage, this is insufficient.
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 appropriately sized and front-loaded, with the core purpose stated first. The Args and Returns sections are structured, but the Example is redundant (repeating the tool name) and could be more informative, slightly reducing efficiency.
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 tool's low complexity (1 parameter, no annotations, but has an output schema), the description is minimally adequate. It covers the basic operation and parameter, but lacks details on error handling, sibling tool differentiation, and behavioral context, making it incomplete for optimal agent 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 description adds minimal value beyond the input schema. It explains the parameter 'signature_name' and its default, but with 0% schema description coverage, it doesn't compensate fully—e.g., it doesn't clarify if the name is case-sensitive or what happens if the signature doesn't exist. The baseline is 3 since the schema lacks descriptions, but the tool's description only partially fills the gap.
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 with a specific verb ('Get') and resource ('saved email signature'), making it immediately understandable. However, it doesn't differentiate from the sibling tool 'list_email_signatures', which might retrieve multiple signatures versus this tool retrieving a specific one.
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 like 'list_email_signatures' or other email-related tools. It lacks context about prerequisites (e.g., needing existing signatures) or exclusions, leaving usage decisions unclear.
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 mentions default values and limits (e.g., 'default: 10, max: 50') and describes the return format, but fails to address critical aspects like authentication requirements, rate limits, error handling, or pagination behavior for a list 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 well-structured with sections for Args, Returns, and Example, making it easy to scan. It's appropriately sized with no redundant information, though the example could be more integrated to enhance flow.
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 tool's moderate complexity (3 parameters, no annotations, but with an output schema), the description is partially complete. It covers parameters and return values adequately, but lacks context on behavioral traits like error handling or performance limits, leaving gaps in overall understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, so the description must compensate. It effectively adds meaning by explaining each parameter's purpose, default values, and constraints (e.g., 'folder: Mail folder to list from (default: INBOX)', 'limit: Maximum number of emails to return (default: 10, max: 50)'), providing clear semantics beyond the bare 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 clearly states the tool's purpose: 'List emails from the specified folder.' It specifies the verb ('list') and resource ('emails'), making the action explicit. However, it doesn't differentiate from sibling tools like 'search_emails' or 'read_email', which limits the score to 4 instead of 5.
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 like 'search_emails' or 'read_email'. It includes an example but lacks explicit context or exclusions for tool selection, offering minimal usage direction.
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 states it 'List all saved email signatures' and returns a 'Dictionary of all signatures', which implies a read-only operation but doesn't clarify permissions, rate limits, or error handling. For a tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose in the first sentence, followed by return value and an example. Each sentence adds value: the first states what it does, the second clarifies the output, and the third provides usage syntax. It's efficient with minimal waste, though the example could be slightly more informative.
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 tool has 0 parameters, an output schema exists, and no annotations, the description is minimally complete. It covers the basic action and return type, but lacks details on behavioral aspects like error cases or data format. For a simple list tool, this is adequate but leaves room for improvement in context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and the input schema has 100% description coverage (though empty). The description correctly indicates no parameters are needed by showing 'list_email_signatures()' in the example. Since there are no parameters to document, the description adequately addresses this by omission, warranting a high score.
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 ('List') and resource ('all saved email signatures'), making the purpose immediately understandable. It distinguishes from siblings like 'get_email_signature' (singular) and 'set_email_signature' (write operation). However, it doesn't explicitly contrast with other list tools like 'list_emails' or 'list_calendar_events', keeping it from a perfect score.
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 provided on when to use this tool versus alternatives. For instance, it doesn't mention if this should be used before setting a signature or how it relates to 'get_email_signature'. The description lacks any context about prerequisites or exclusions, leaving usage entirely implicit.
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 mentions the tool deletes an event and returns a status, but lacks critical details such as whether deletion is permanent, requires specific permissions, affects recurring events, or has rate limits. This is inadequate for a destructive operation with zero annotation coverage.
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 well-structured and front-loaded with the core purpose, followed by clear sections for Args, Returns, and an Example. Every sentence earns its place by providing essential information without redundancy, making it efficient and easy to parse.
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 tool's complexity (a destructive operation with no annotations) and the presence of an output schema (which likely covers return values), the description is partially complete. It explains the action and parameter but misses key behavioral aspects like safety warnings or usage context. The output schema reduces the need to detail returns, but more guidance is needed for a mutation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaningful context for the single parameter 'event_uid' by explaining it's the 'UID of the event to delete' and providing an example format ('abc123@aruba.it'), which compensates for the 0% schema description coverage. Since there's only one parameter, this is sufficient to achieve a high score despite the schema gap.
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 with a specific verb ('Delete') and resource ('a calendar event'), making it immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'decline_calendar_event' or 'tentative_calendar_event', which might handle event status changes rather than deletion.
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 provided on when to use this tool versus alternatives. For example, it doesn't clarify if this should be used instead of 'decline_calendar_event' for removing events or if there are prerequisites like needing event ownership. The description only states what it does, not when or why to use it.
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 mentions the tool returns a list of matching emails, which is basic, but fails to disclose critical behavioral traits such as authentication requirements, rate limits, error handling, or whether it's read-only or destructive. This is inadequate for a search tool with no annotation coverage.
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 appropriately sized and front-loaded, starting with the purpose, followed by a structured breakdown of args and returns, and ending with an example. Every sentence adds value without redundancy, making it efficient and easy to parse.
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 tool's moderate complexity (4 parameters, 1 required), no annotations, and an output schema present, the description is partially complete. It covers parameters well but lacks behavioral context and usage guidelines. The output schema reduces the need to explain return values, but overall, it's adequate with clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant meaning beyond the input schema, which has 0% schema description coverage. It explains each parameter's purpose, defaults, and formats (e.g., date format, limit max), compensating well for the schema's lack of descriptions. However, it doesn't fully cover all nuances, such as the 'from_date' accepting null, keeping it from a perfect score.
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 as 'Search emails by subject or body content,' which is a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like 'list_emails' or 'read_email,' which might have overlapping functionality, so it doesn't reach the highest score.
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 like 'list_emails' or 'read_email.' It includes an example but lacks explicit context, prerequisites, or exclusions, leaving the agent to infer usage from the purpose 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 mentions the tool lists events within a date range and returns a list, but lacks details on permissions, rate limits, pagination, error handling, or whether it's read-only (implied but not stated). For a tool with zero annotation coverage, this is a significant 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 appropriately sized and well-structured, with a clear purpose statement followed by sections for Args, Returns, and an Example. Every sentence adds value, such as clarifying parameter formats and defaults. Minor improvements could include briefer phrasing, but it's efficient overall.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (3 parameters, no nested objects) and the presence of an output schema (which handles return values), the description is mostly complete. It covers parameters thoroughly and states the return type. However, it lacks behavioral context like permissions or error handling, which is notable since no annotations are provided.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds substantial meaning beyond the input schema, which has 0% schema description coverage. It explains each parameter's purpose, format (ISO format for dates), and default values (today, 30 days from now, 50 for limit). This fully compensates for the schema's lack of descriptions, providing clear semantics for all three 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 tool's purpose: 'List calendar events within a date range.' It specifies the verb ('List') and resource ('calendar events'), making the action unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'search_emails' or 'create_calendar_event', which would require a 5.
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. It doesn't mention sibling tools (e.g., 'create_calendar_event' for adding events or 'search_emails' for email-related queries) or specify contexts like viewing upcoming events versus historical data. Usage is implied only by the tool's name and description.
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 full burden but provides minimal behavioral information. It mentions the transport mechanism ('via SMTP') and shows a default sender name, but doesn't disclose important behavioral traits like authentication requirements, rate limits, error conditions, whether emails are queued or sent immediately, or what happens with invalid addresses. The 'Returns' section is vague about what 'details' includes.
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 well-structured with clear sections (purpose, args, returns, example) and efficiently communicates essential information. The example is helpful but could be more concise. Some sentences like 'Send an email via SMTP' are perfectly efficient, while the example shows multiple parameters that could be trimmed.
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 5-parameter mutation tool with no annotations but with output schema, the description covers the basic purpose and parameters adequately. However, it lacks important context about behavioral implications (side effects, error handling, authentication needs) that would be crucial for safe usage. The presence of an output schema reduces the need to document return values, but other gaps remain significant.
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?
With 0% schema description coverage, the description compensates well by providing clear parameter documentation in the 'Args' section, including data types, optionality, and default values. It adds meaningful context beyond the bare schema, explaining that 'cc' accepts comma-separated addresses and 'from_name' has a specific default. However, it doesn't explain format constraints (e.g., email validation) or provide examples for complex cases.
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 specific action ('Send an email via SMTP') and resource ('email'), distinguishing it from sibling tools like list_emails or read_email. It provides a concrete verb+resource combination that leaves no ambiguity about the tool's function.
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 like list_emails or search_emails. There's no mention of prerequisites, appropriate contexts, or when other email-related tools might be more suitable. The example shows usage but doesn't explain context.
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 full burden for behavioral disclosure. While it mentions the tool creates events and returns details including UID, it lacks critical information about permissions required, whether attendees receive invitations, error conditions, or rate limits. For a mutation tool with zero annotation coverage, this is insufficient.
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 well-structured with clear sections (Args, Returns, Example) and front-loads the core purpose. While the example is detailed, it serves a practical purpose. Some sentences could be more concise, but overall it's efficiently organized.
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 tool's complexity (6 parameters, mutation operation) and the presence of an output schema (which handles return values), the description covers parameters well but lacks behavioral context. With no annotations and incomplete behavioral disclosure, it's adequate but has clear gaps for a creation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides comprehensive parameter documentation beyond the schema, which has 0% description coverage. It explains each parameter's purpose, format requirements (ISO format for dates, comma-separated list for attendees), and optionality, adding significant value over the 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 the specific action ('Create a new calendar event') with the resource ('calendar event'), distinguishing it from sibling tools like 'delete_calendar_event' or 'list_calendar_events'. The verb 'create' is unambiguous and directly communicates the tool's function.
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 like 'tentative_calendar_event' or 'accept_calendar_event', nor does it mention any prerequisites or contextual constraints. It simply states what the tool does without usage context.
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 full burden for behavioral disclosure. It mentions the action ('Mark a calendar event as tentative') and return value ('Response status'), but lacks details on permissions needed, whether this is reversible, rate limits, or what specific status codes might be returned. The example adds some context but not comprehensive behavioral traits.
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 efficiently structured with a clear purpose statement, parameter explanations, return value note, and a practical example. Every sentence adds value without redundancy, and information is front-loaded appropriately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (2 parameters, mutation action), no annotations, but with an output schema (implied by 'Returns: Response status'), the description is reasonably complete. It covers purpose, parameters, and returns, though could benefit from more behavioral context like error conditions or side effects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaningful semantics beyond the input schema, which has 0% description coverage. It explains that 'event_uid' is the 'UID of the event' and 'comment' is an 'Optional comment' for providing context like 'Forse riesco a partecipare'. This compensates well for the schema's lack of descriptions, though it doesn't detail UID format or comment constraints.
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: 'Mark a calendar event as tentative (maybe attending).' It specifies the verb ('Mark'), resource ('calendar event'), and action ('as tentative'), but doesn't explicitly distinguish it from sibling tools like accept_calendar_event or decline_calendar_event beyond the different status.
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 context through the phrase 'maybe attending' and the example comment, suggesting this is for uncertain attendance. However, it doesn't explicitly state when to use this tool versus accept_calendar_event or decline_calendar_event, nor does it mention prerequisites like event access permissions.
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 full burden for behavioral disclosure. While it mentions the action ('Accept'), it doesn't describe what acceptance entails (e.g., updates to calendar, notifications sent, permissions required), response format details beyond 'Response status', or any side effects. The example helps but doesn't fully compensate.
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 well-structured and front-loaded with the purpose, followed by organized sections for Args, Returns, and Example. Every sentence adds value with no redundant information, making it efficient for an AI agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (mutation action with 2 parameters), no annotations, but an output schema exists, the description is reasonably complete. It covers purpose, parameters, and includes an example, though more behavioral context would enhance completeness for a mutation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It provides clear parameter explanations: 'event_uid: UID of the event to accept' and 'comment: Optional comment for the acceptance', adding meaningful context beyond the bare schema. However, it doesn't specify UID format or comment constraints.
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 specific action ('Accept a calendar event invitation') and identifies the resource ('calendar event invitation'). It distinguishes from sibling tools like 'decline_calendar_event' and 'tentative_calendar_event' by specifying the acceptance action.
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 context (accepting calendar invitations) but doesn't explicitly state when to use this tool versus alternatives like 'decline_calendar_event' or 'tentative_calendar_event'. No guidance on prerequisites or exclusions is provided.
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 full burden for behavioral disclosure. It states the action ('Decline') which implies a mutation, but doesn't disclose important behavioral traits like permission requirements, whether the decline is reversible, how it affects the calendar, or rate limits. The example adds some context but not comprehensive behavioral information.
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 efficiently structured with clear sections (Args, Returns, Example). Every sentence earns its place - the purpose statement is front-loaded, parameter explanations are concise, and the example demonstrates practical usage without unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (which handles return values) and the description covers both parameters despite 0% schema coverage, the description is reasonably complete. However, as a mutation tool with no annotations, it could benefit from more behavioral context about what 'decline' actually entails in the system.
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?
With 0% schema description coverage, the description compensates well by explaining both parameters: event_uid ('UID of the event to decline') and comment ('Optional comment for the decline'). It clarifies which parameter is required and which is optional, adding meaningful context beyond the 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 the specific action ('Decline') and resource ('a calendar event invitation'), distinguishing it from sibling tools like accept_calendar_event or tentative_calendar_event. The verb+resource combination is precise 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 context (declining an invitation) but doesn't explicitly state when to use this tool versus alternatives like accept_calendar_event or delete_calendar_event. No guidance is provided about prerequisites (e.g., needing an invitation) or exclusions.
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 discloses that it reads full content and returns specific fields, but lacks details on permissions, rate limits, error handling, or whether it's read-only (implied by 'read' but not explicit). It adds some behavioral context but misses key operational traits.
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 well-structured and front-loaded with the core purpose, followed by args, returns, and an example. Every sentence adds value without redundancy, making it efficient and easy to parse for an AI agent.
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, 0% schema coverage, but an output schema exists, the description is mostly complete. It covers purpose, parameters, and returns, but could improve by addressing behavioral aspects like auth or errors. The output schema reduces the need to explain return values in detail.
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 description coverage is 0%, so the description must compensate. It explains email_id as 'Email ID to read (from list_emails)' and folder as 'Mail folder (default: INBOX)', adding meaning beyond the schema's basic titles. However, it doesn't detail folder options or email_id format, leaving some gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Read the full content') and resource ('a specific email'), distinguishing it from siblings like list_emails (which lists emails) or search_emails (which searches). It precisely defines what the tool does without being vague or tautological.
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 by mentioning 'from list_emails' for email_id, suggesting it should be used after listing emails, but it doesn't explicitly state when to use this tool versus alternatives like search_emails or provide exclusions. The guidance is present but not comprehensive.
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?
With no annotations provided, the description carries the full burden and does well by explaining what the tool does (searches for bounce notifications), listing common reasons for bounces, and describing the return format. However, it doesn't mention potential side effects, authentication requirements, 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and appropriately sized, with clear sections for purpose, common reasons, parameters, returns, and an example. Every sentence adds value without redundancy, and the information is front-loaded with the core purpose first.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity, no annotations, and the presence of an output schema (which handles return value documentation), the description is complete enough. It covers purpose, usage context, parameter meanings, and includes an example, providing sufficient guidance for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant value beyond the input schema, which has 0% description coverage. It explains what 'folder' and 'limit' parameters mean (mail folder to check and maximum number of notifications), provides default values, and includes an example showing how to use the limit 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 clearly states the tool's purpose with a specific verb ('check') and resource ('bounced or failed email delivery notifications'), distinguishing it from sibling tools like list_emails or search_emails that handle general email operations rather than specifically bounce notifications.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool by explaining it searches for delivery failure notifications, but it doesn't explicitly state when not to use it or name specific alternatives among the sibling tools (like search_emails for general email searching).
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?
With no annotations provided, the description carries full burden and does well by disclosing key behaviors: the signature is automatically appended to sent emails, photo_url auto-uploads local files, and it returns a confirmation with preview. It doesn't cover permissions, rate limits, or error handling, but provides substantial operational context.
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 well-structured and front-loaded with the core purpose, followed by organized sections for args, returns, and examples. Every sentence adds value, with no redundancy, making it efficient despite its comprehensiveness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (9 parameters, no annotations, but with output schema), the description is complete. It covers purpose, usage, parameters, behavior, and examples. The output schema handles return values, so the description appropriately focuses on input and operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate fully. It provides detailed semantics for all 9 parameters, including examples, optional/default values, and behavioral effects (e.g., photo_url triggers HTML signature). This adds significant meaning beyond the 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 the tool's purpose with specific verbs ('create and save') and resource ('professional email signature'), distinguishing it from sibling tools like get_email_signature or list_email_signatures. It explains the outcome ('automatically appended to all sent emails') and differentiates between text and HTML signatures based on optional parameters.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use this tool (to create signatures that will be appended to emails) and implies usage through parameter descriptions (e.g., photo_url creates HTML signatures). However, it doesn't explicitly state when NOT to use it or name alternatives like get_email_signature for retrieval, though the distinction is clear from purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

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

Score Badge

Copy to your README.md:

[![mcp-aruba-email MCP server](https://glama.ai/mcp/servers/jackfioru92/mcp-aruba-email/badges/score.svg)](https://glama.ai/mcp/servers/jackfioru92/mcp-aruba-email)

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/jackfioru92/mcp-aruba-email'

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