Asterisk S2S MCP Server

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation5/5
Every tool has a clearly distinct purpose with no ambiguity. Each tool targets a specific action (cancel, get, make, check) on specific telephone system resources (calls, history, logs, metrics, status, health), making it easy for an agent to select the right tool without confusion.
Naming Consistency5/5
All tools follow a perfect verb_noun pattern with consistent snake_case naming. The 'phone_' prefix establishes clear domain ownership, and action verbs (cancel, get, make, check) are consistently applied throughout the set.
Tool Count5/5
Nine tools is an excellent number for a telephone system server. This provides comprehensive coverage without being overwhelming, allowing agents to handle all major telephone operations while maintaining manageable cognitive load.
Completeness5/5
The tool set provides complete lifecycle coverage for telephone operations: initiating calls (make_call), monitoring active calls and status, accessing history and results, canceling calls, checking system health, and gathering logs and metrics. No obvious gaps exist for the stated telephone system domain.
Average 3/5 across 9 of 9 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 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?
No annotations are provided, so the description carries full burden. It states the tool cancels an ongoing call, implying a destructive mutation, but doesn't disclose behavioral traits such as required permissions, whether cancellation is reversible, side effects (e.g., call termination notifications), or error handling. The description is minimal and lacks critical 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 a single, efficient sentence in Spanish that directly states the tool's function. It's front-loaded with the core action and resource, with zero wasted words. This is appropriately concise for a simple tool.
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's complexity (a destructive mutation with no annotations and no output schema), the description is incomplete. It doesn't explain what happens upon cancellation, return values, error conditions, or dependencies on sibling tools. For a mutation tool, this leaves significant gaps in understanding for an AI agent.
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%, with the single parameter 'callId' documented as 'ID de la llamada a cancelar'. The description adds no additional meaning beyond this, such as format examples or sourcing guidance (e.g., from phone_get_active_calls). Baseline 3 is appropriate since the schema fully covers the parameter.
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 ('Cancelar' = Cancel) and target resource ('una llamada telefónica en curso' = an ongoing phone call). It's specific about what the tool does, though it doesn't explicitly differentiate from sibling tools like phone_get_active_calls or phone_make_call. The purpose is unambiguous but lacks sibling comparison.
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 prerequisites (e.g., needing an active call), exclusions, or relationships with sibling tools like phone_get_active_calls (which might list calls to cancel) or phone_make_call. Usage context is implied but not stated.
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 the action ('obtener') but doesn't describe what 'recientes' means (e.g., time frame), whether this is a read-only operation, potential rate limits, authentication needs, or the format of returned data. For a tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Spanish that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, with every word contributing to understanding.
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 lack of annotations and output schema, the description is incomplete. It doesn't explain what 'recientes' entails, the structure of returned conversation history, or how this tool differs from siblings. For a tool that retrieves data with potential complexity in scope and format, more context is needed.
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%, with the single parameter 'limit' fully documented in the schema. The description doesn't add any parameter-specific information beyond what's in the schema, so it meets the baseline of 3 where the schema does the heavy lifting.
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 ('obtener' - get) and resource ('historial de conversaciones telefónicas recientes' - recent phone conversation history), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'phone_get_logs' or 'phone_get_active_calls', which might also retrieve conversation-related data, preventing 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?
The description provides no guidance on when to use this tool versus alternatives like 'phone_get_logs' or 'phone_get_active_calls'. It doesn't mention prerequisites, constraints, or typical use cases, leaving the agent to infer usage 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool retrieves the last processed result, implying a read-only operation, but doesn't specify what 'procesado' entails, potential errors (e.g., if no result exists), or the return format. This leaves gaps in understanding the tool's behavior and output.
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 that directly states the tool's purpose without unnecessary words. It is front-loaded and efficient, though it could be slightly more structured by including usage hints. Overall, it earns its place by being clear and to the point.
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 complexity of retrieving processed results and the lack of annotations and output schema, the description is insufficient. It doesn't explain what 'último resultado procesado' means in practice, the data format returned, or error conditions. For a tool with no structured output information, more descriptive context is needed to guide the agent effectively.
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 has 100% description coverage, with the parameter 'callId' clearly documented as 'ID de la llamada'. The description adds no additional semantic context beyond this, such as format examples or constraints. Given the high schema coverage, a baseline score of 3 is appropriate as the schema handles the parameter documentation adequately.
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 ('Obtener el último resultado procesado') and resource ('de una llamada específica'), making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like 'phone_get_conversation_history' or 'phone_get_logs' which might also retrieve call-related data, leaving some ambiguity about uniqueness.
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 prerequisites, such as needing a processed call, or compare it to siblings like 'phone_get_conversation_history' for broader history or 'phone_get_status' for current state, leaving the agent without context for selection.
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. While it mentions the purpose ('para debugging'), it doesn't describe important behavioral traits: whether this is a read-only operation, what format the logs are returned in, whether there are rate limits, authentication requirements, or potential performance impacts. The description is minimal and lacks crucial 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient Spanish sentence that communicates the core purpose. It's appropriately sized for a tool with clear parameters documented in the schema. While it could be more detailed given the lack of annotations, it doesn't waste words or include unnecessary information. The structure is straightforward and front-loaded with the main purpose.
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's complexity (3 parameters, no annotations, no output schema), the description is insufficiently complete. It doesn't explain what the tool returns (log format, structure, or content), doesn't mention behavioral constraints, and provides minimal context beyond the basic purpose. For a debugging tool that likely returns structured data, more information about the output would be valuable to the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% description coverage, so all parameters are documented in the schema itself. The description doesn't add any parameter-specific information beyond what's already in the schema descriptions. It mentions 'logs del sistema telefónico' which aligns with the tool's purpose but doesn't provide additional semantic context about the parameters. Baseline score of 3 is appropriate when schema does the heavy lifting.
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 ('obtener' - get/retrieve) and resource ('logs del sistema telefónico'), and specifies the purpose ('para debugging'). It distinguishes from siblings like phone_get_active_calls or phone_get_metrics by focusing specifically on system logs rather than call data or performance metrics. However, it doesn't explicitly differentiate from all siblings (e.g., phone_get_last_result might also return debugging information).
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 when this tool is appropriate (e.g., for troubleshooting specific issues) or when other tools might be better (e.g., phone_get_status for system status, phone_get_metrics for performance data). The 'para debugging' phrase hints at context but doesn't provide explicit usage guidelines.
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 full burden for behavioral disclosure. While 'Obtener el estado actual' implies a read-only operation, it doesn't specify what 'estado' includes (e.g., ringing, connected, ended), whether permissions are required, or what format the status returns. For a tool with zero annotation coverage, this leaves significant behavioral questions unanswered.
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, focused sentence that directly states the tool's purpose without any unnecessary words. It's perfectly front-loaded and wastes no space on redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description should provide more complete context about what 'estado' means and what information is returned. For a status-checking tool that likely returns structured data about call state, the current description is insufficient to understand what the agent will receive as output.
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%, with the single parameter 'callId' clearly documented as 'ID de la llamada'. The description doesn't add any additional parameter context beyond what the schema provides, but with complete schema coverage, the baseline score 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 action ('Obtener el estado actual') and resource ('una llamada telefónica'), making the purpose immediately understandable. However, it doesn't explicitly differentiate this tool from sibling tools like 'phone_get_active_calls' or 'phone_get_last_result', which also retrieve call-related information.
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. With siblings like 'phone_get_active_calls' (likely listing multiple calls) and 'phone_get_last_result' (likely retrieving a specific outcome), there's no indication of when this status-checking tool is appropriate versus those other options.
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 call is 'conversacional automatizada' (automated conversational), hinting at AI-driven interaction, but fails to disclose critical traits: whether this is a read/write operation (likely write, as it initiates calls), authentication needs, rate limits, error handling, or what happens on timeout (though timeout is a parameter). For a tool with no annotations and potential side effects, 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Spanish that directly states the tool's purpose without fluff. It's appropriately sized and front-loaded, with every word contributing to understanding the core function. No unnecessary details or repetition are present.
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 complexity of an automated phone call tool with no annotations and no output schema, the description is incomplete. It lacks information on behavioral traits (e.g., side effects, error handling), return values (since no output schema exists), and usage context. For a tool that likely involves external interactions and mutations, this leaves the agent under-informed about critical operational aspects.
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%, so the schema already documents all 6 parameters (e.g., 'telefono' as phone number, 'proposito' as call purpose). The description adds no additional meaning beyond what's in the schema—it doesn't explain parameter interactions, default behaviors, or usage examples. With high schema coverage, the baseline is 3, as the description doesn't compensate but also doesn't detract.
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 'Realizar una llamada telefónica conversacional automatizada' (Make an automated conversational phone call), which is a specific verb+resource combination. It distinguishes this from siblings like phone_cancel_call or phone_get_active_calls by focusing on initiating calls rather than managing or retrieving information about them. However, it doesn't explicitly differentiate from all siblings (e.g., it could be more specific about automated vs. manual calls).
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 prerequisites (e.g., whether the system must be configured first), when not to use it (e.g., for non-conversational calls), or direct alternatives among the siblings. The agent must infer usage from the purpose alone, which is insufficient for clear decision-making.
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 states what the tool does (get active calls) but doesn't reveal important behavioral traits: whether this is a real-time query, if it requires specific permissions, what format the returned data has, if there are rate limits, or how 'active' is defined (e.g., in-progress vs. recently completed). For a tool with zero annotation coverage, this is inadequate.
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, clear sentence that efficiently communicates the tool's purpose. It's appropriately sized for a simple tool with no parameters. Every word earns its place - there's no redundancy or unnecessary elaboration.
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 that this is a data retrieval tool with no annotations, no output schema, and no parameters, the description is incomplete. It doesn't explain what 'active' means, what data fields are returned, whether this is real-time or cached data, or any error conditions. For a tool that presumably returns structured call data, the description should provide more context about the return format and behavioral characteristics.
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 with 100% schema description coverage (empty schema). The description doesn't need to explain any parameters, and it correctly doesn't mention any. Since there are no parameters to document, the description appropriately focuses on the tool's purpose rather than 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 clearly states the tool's purpose: 'Obtener lista de llamadas telefónicas activas en este momento' (Get list of active phone calls at this moment). It specifies the verb ('obtener' - get) and resource ('llamadas telefónicas activas' - active phone calls), but doesn't explicitly differentiate it from sibling tools like phone_get_conversation_history or phone_get_logs, which also retrieve call-related information.
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 when this tool is appropriate (e.g., for real-time monitoring) versus when to use siblings like phone_get_conversation_history (for past calls) or phone_get_logs (for detailed records). The description is a simple statement of purpose without contextual usage information.
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. While 'verificar' implies a read-only operation, the description doesn't specify whether this tool requires authentication, has rate limits, returns specific health metrics versus general status, or what format the output takes. For a tool with zero annotation coverage, this leaves significant behavioral questions unanswered.
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, clear Spanish sentence that directly states the tool's purpose without any unnecessary words. It's perfectly front-loaded with the essential information and wastes no space on redundant or irrelevant details.
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 that this is a health-check tool with no annotations, no output schema, and multiple sibling tools that might overlap in functionality, the description is insufficiently complete. It doesn't explain what constitutes 'health' versus general status, what metrics or checks are performed, or how the results differ from other status-related tools. For a tool in this context, more specificity is needed.
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 schema description coverage is 100% (since there are no parameters to describe). The description appropriately doesn't discuss parameters since none exist. The baseline for zero parameters with full schema coverage is 4, as there's no need for parameter explanation in the 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 'Verificar el estado de salud del sistema telefónico' clearly states the tool's purpose: to verify/check the health status of the telephone system. It uses a specific verb ('verificar') and resource ('sistema telefónico'), making the purpose unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'phone_get_status' or 'phone_get_metrics', which might provide related status information.
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. With multiple sibling tools that might provide overlapping or related information (phone_get_status, phone_get_metrics, phone_get_active_calls), there's no indication of what makes this health check distinct or when it should be preferred over other status-checking tools.
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. While 'Obtener' implies a read-only operation, it doesn't specify whether authentication is required, if there are rate limits, what format the metrics are returned in, or if the data is real-time or historical. For a metrics tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Spanish that directly states the tool's purpose without any fluff or redundancy. It's appropriately sized and front-loaded, with every word contributing to understanding what the tool does.
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 simplicity (0 parameters, no output schema), the description is adequate but not complete. It clearly states what the tool retrieves but lacks context about the metrics' scope, format, or behavioral traits. Without annotations or output schema, the agent doesn't know what to expect from the response. The description meets minimum viability but has 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 tool has 0 parameters, and schema description coverage is 100% (since there are no parameters to describe). The description doesn't need to add parameter semantics beyond what the schema provides. A baseline of 4 is appropriate for a zero-parameter tool where the schema fully covers the input structure.
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 'Obtener métricas y estadísticas del sistema telefónico' clearly states the tool's purpose: to retrieve metrics and statistics from the phone system. It uses specific verbs ('Obtener') and identifies the resource ('sistema telefónico'). However, it doesn't explicitly differentiate from siblings like phone_get_status or phone_get_logs, which likely provide different types of phone system information.
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 what distinguishes it from sibling tools like phone_get_status or phone_get_logs, nor does it specify prerequisites, appropriate contexts, or exclusions. The agent must infer usage from the tool name alone.
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-s2s-asterisk MCP server](https://glama.ai/mcp/servers/gcorroto/mcp-s2s-asterisk/badges/card.svg)](https://glama.ai/mcp/servers/gcorroto/mcp-s2s-asterisk)

Score Badge

Copy to your README.md:

[![mcp-s2s-asterisk MCP server](https://glama.ai/mcp/servers/gcorroto/mcp-s2s-asterisk/badges/score.svg)](https://glama.ai/mcp/servers/gcorroto/mcp-s2s-asterisk)

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/gcorroto/mcp-s2s-asterisk'

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