Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@oitvoip-mcp-server List all active call queues"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
šÆ Production-Ready NetSapiens Integration
Comprehensive MCP server providing AI agents with full access to NetSapiens VoIP platform
A Model Context Protocol (MCP) server that provides AI agents with seamless access to the NetSapiens VoIP platform. This server enables AI applications to interact with NetSapiens functionality including user management, call detail records, and system information.
š„ User Management: Search users, get details, devices, answer rules, greetings, and voicemails
š Phone Number Management: List and manage phone numbers across domains
šÆ Call Center Operations: Manage call queues, agents, login/logout, and statistics
š Call Analytics: Access CDR records, agent statistics, and call patterns
š¢ Domain Administration: Complete domain management and configuration
š¤ Auto Attendant: Configure and manage automated attendants
šµ Media Management: Handle greetings, voicemail, and music on hold
š° Billing Integration: Access billing information and usage data
š§ Real-time Operations: Live access to NetSapiens platform data
ā” Error Handling: Robust error handling with detailed logging
š”ļø Rate Limiting: Built-in rate limiting for API protection
š TypeScript: Full TypeScript support with comprehensive type safety
Related MCP server: VoIPBin MCP Server
oitvoip-mcp-server/
āāā src/
ā āāā index.ts # Main MCP server implementation
ā āāā netsapiens-client.ts # NetSapiens API client
āāā types/
ā āāā config.ts # TypeScript type definitions
āāā docs/ # Documentation
āāā build/ # Compiled JavaScript output
āāā package.json # Project dependencies
āāā tsconfig.json # TypeScript configuration
āāā README.md # This fileNode.js 18.0.0 or higher
npm or yarn package manager
NetSapiens API credentials
npm install -g oitvoip-mcp-serverClone the repository
git clone https://github.com/OITApps/oitvoip-mcp-server.git
cd oitvoip-mcp-serverInstall dependencies
npm installBuild the project
npm run buildConfigure in your MCP client
Add the server to your MCP client configuration with your NetSapiens credentials (see MCP Client Setup section below)
For development with hot reloading:
npm run devThis MCP server is configured entirely through your MCP client's configuration file. No separate .env file is needed - all configuration is passed through environment variables in the MCP client config.
NETSAPIENS_API_URL: Your NetSapiens API endpoint (usually https://api.ucaasnetwork.com)
NETSAPIENS_API_TOKEN: Your NetSapiens API token
DEBUG: Set to true to enable debug logging (default: false)
NETSAPIENS_TIMEOUT: API request timeout in milliseconds (default: 30000)
For OpenCode, add the MCP server to your configuration file at ~/.opencode/mcp.json:
If installed via npm:
{
"mcpServers": {
"oitvoip": {
"command": "oitvoip-mcp-server",
"env": {
"NETSAPIENS_API_URL": "https://api.ucaasnetwork.com",
"NETSAPIENS_API_TOKEN": "your_api_token_here"
}
}
}
}If installed from source:
{
"mcpServers": {
"oitvoip": {
"command": "node",
"args": ["/path/to/oitvoip-mcp-server/build/index.js"],
"env": {
"NETSAPIENS_API_URL": "https://api.ucaasnetwork.com",
"NETSAPIENS_API_TOKEN": "your_api_token_here"
}
}
}
}For Claude Desktop, add the server to your configuration file:
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
If installed via npm:
{
"mcpServers": {
"oitvoip": {
"command": "oitvoip-mcp-server",
"env": {
"NETSAPIENS_API_URL": "https://api.ucaasnetwork.com",
"NETSAPIENS_API_TOKEN": "your_api_token_here"
}
}
}
}If installed from source:
{
"mcpServers": {
"oitvoip": {
"command": "node",
"args": ["/path/to/oitvoip-mcp-server/build/index.js"],
"env": {
"NETSAPIENS_API_URL": "https://api.ucaasnetwork.com",
"NETSAPIENS_API_TOKEN": "your_api_token_here"
}
}
}
}For Cursor, add the server to your MCP configuration file at ~/.cursor/mcp.json:
If installed via npm:
{
"mcpServers": {
"oitvoip": {
"command": "oitvoip-mcp-server",
"env": {
"NETSAPIENS_API_URL": "https://api.ucaasnetwork.com",
"NETSAPIENS_API_TOKEN": "your_api_token_here"
}
}
}
}If installed from source:
{
"mcpServers": {
"oitvoip": {
"command": "node",
"args": ["/path/to/oitvoip-mcp-server/build/index.js"],
"env": {
"NETSAPIENS_API_URL": "https://api.ucaasnetwork.com",
"NETSAPIENS_API_TOKEN": "your_api_token_here"
}
}
}
}Replace /path/to/oitvoip-mcp-server with the actual path to your installation
Replace your_api_token_here with your actual NetSapiens API token
All configuration is handled through the MCP client - no separate .env file is needed
After configuration, restart your MCP client to load the server
Search for users in the NetSapiens system by username.
{
"name": "search_users",
"arguments": {
"query": "john.doe",
"domain": "company.com",
"limit": 20
}
}Retrieve detailed information about a specific user.
{
"name": "get_user",
"arguments": {
"userId": "john.doe",
"domain": "company.com"
}
}Get devices assigned to a specific user.
{
"name": "get_user_devices",
"arguments": {
"userId": "john.doe",
"domain": "company.com"
}
}Get phone numbers for a domain.
{
"name": "get_phone_numbers",
"arguments": {
"domain": "company.com",
"limit": 50
}
}Get details of a specific phone number.
{
"name": "get_phone_number",
"arguments": {
"domain": "company.com",
"phoneNumber": "+15551234567"
}
}Get list of domains in the NetSapiens system.
{
"name": "get_domains",
"arguments": {}
}Get detailed information about a specific domain.
{
"name": "get_domain",
"arguments": {
"domain": "company.com"
}
}Get call queues for a domain.
{
"name": "get_call_queues",
"arguments": {
"domain": "company.com"
}
}Get details of a specific call queue.
{
"name": "get_call_queue",
"arguments": {
"domain": "company.com",
"queueId": "sales-queue"
}
}Get agents assigned to a call queue.
{
"name": "get_call_queue_agents",
"arguments": {
"domain": "company.com",
"queueId": "sales-queue"
}
}Get agents for a domain.
{
"name": "get_agents",
"arguments": {
"domain": "company.com"
}
}Login an agent to a call queue.
{
"name": "login_agent",
"arguments": {
"domain": "company.com",
"queueId": "sales-queue",
"agentId": "agent001"
}
}Logout an agent from a call queue.
{
"name": "logout_agent",
"arguments": {
"domain": "company.com",
"queueId": "sales-queue",
"agentId": "agent001"
}
}Retrieve call detail records with optional filtering.
{
"name": "get_cdr_records",
"arguments": {
"startDate": "2024-01-01",
"endDate": "2024-01-31",
"user": "john.doe",
"domain": "company.com",
"limit": 100
}
}Get agent statistics for a domain.
{
"name": "get_agent_statistics",
"arguments": {
"domain": "company.com",
"agentId": "agent001"
}
}Get auto attendants for a domain.
{
"name": "get_auto_attendants",
"arguments": {
"domain": "company.com"
}
}Get answer rules for a user.
{
"name": "get_user_answer_rules",
"arguments": {
"userId": "john.doe",
"domain": "company.com"
}
}Get specific answer rule for a user.
{
"name": "get_user_answer_rule",
"arguments": {
"userId": "john.doe",
"domain": "company.com",
"timeframe": "business"
}
}Get greetings for a user.
{
"name": "get_user_greetings",
"arguments": {
"userId": "john.doe",
"domain": "company.com"
}
}Get voicemails for a user.
{
"name": "get_user_voicemails",
"arguments": {
"userId": "john.doe",
"domain": "company.com"
}
}Get music on hold files for a domain.
{
"name": "get_music_on_hold",
"arguments": {
"domain": "company.com"
}
}Get billing information for a domain.
{
"name": "get_billing",
"arguments": {
"domain": "company.com"
}
}Test connectivity to the NetSapiens API.
{
"name": "test_connection",
"arguments": {}
}// Search for users with "john" in a specific domain
const result = await mcp.callTool('search_users', {
query: 'john',
domain: 'company.com',
limit: 10
});// Get detailed information about a specific user
const result = await mcp.callTool('get_user', {
userId: 'john.doe',
domain: 'company.com'
});// Get call records for a specific user in the last month
const result = await mcp.callTool('get_cdr_records', {
startDate: '2024-01-01',
endDate: '2024-01-31',
user: 'john.doe',
domain: 'company.com'
});// Get devices assigned to a user
const result = await mcp.callTool('get_user_devices', {
userId: 'john.doe',
domain: 'company.com'
});npm run build - Compile TypeScript to JavaScript
npm run dev - Run in development mode with hot reloading
npm start - Run the compiled server
npm run watch - Watch mode for development
npm run clean - Clean build directory
src/
āāā index.ts # Main server entry point
āāā netsapiens-client.ts # NetSapiens API client
āāā tools/ # Individual tool implementations
types/
āāā config.ts # Configuration types
āāā netsapiens.ts # NetSapiens API typesDefine the tool in the ListToolsRequestSchema handler
Add a handler method in the CallToolRequestSchema handler
Implement the tool logic in the NetSapiens client
Update type definitions as needed
API Tokens: Configure your NetSapiens API tokens securely in your MCP client configuration
Token Security: Use strong API tokens and rotate them regularly
Access Control: Ensure API tokens have minimal required permissions
Rate Limiting: Built-in rate limiting prevents API abuse
Error Handling: Secure error logging without exposing sensitive data
Input Validation: All inputs are validated before processing
Secure MCP Configuration: Store your MCP client configuration files securely
Strong API Tokens: Use secure NetSapiens API tokens and rotate regularly
Monitor Access: Check NetSapiens access logs for unauthorized usage
Regular Audits: Run npm audit regularly for dependency vulnerabilities
Keep Updated: Maintain latest versions for security patches
HTTPS Only: All API communications use secure HTTPS connections
Environment Isolation: Use different tokens for development/production environments
Connection Failed
Verify your API URL and token in .env
Check network connectivity to NetSapiens server
Ensure API token has proper permissions
Build Errors
Run npm run clean and rebuild
Check TypeScript configuration
Verify all dependencies are installed
Tool Not Found
Ensure the tool name matches exactly
Check the tool is properly registered in ListToolsRequestSchema
Enable debug logging by setting DEBUG=true in your .env file:
DEBUG=trueFork the repository
Create a feature branch (git checkout -b feature/amazing-feature)
Commit your changes (git commit -m 'Add some amazing feature')
Push to the branch (git push origin feature/amazing-feature)
Open a Pull Request
This project is licensed under the MIT License - see the LICENSE file for details.
OITVOIP provides comprehensive VoIP solutions powered by the NetSapiens platform. This MCP server enables seamless integration between AI applications and our VoIP infrastructure.
Built with ā¤ļø by the OITVOIP team
From frontend finesse to backend brilliance - we stack it all! ā
Get agents for a domain
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | Domain name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral traits such as permissions, return format, or pagination. It only states the basic purpose, leaving the agent unaware of side effects or data scope.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, using only one sentence with no redundant words. It is appropriately sized for a simple tool with one parameter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema), the description is adequate but lacks details about the return value or what constitutes an 'agent'. This could lead to ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for the single parameter 'domain', so the description adds minimal value beyond the schema. It implies the domain is used for filtering, which is consistent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (get) and resource (agents) with a specified parameter (domain). However, it does not differentiate from the sibling tool 'get_call_queue_agents' which also returns agents but for a call queue context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 like 'get_call_queue_agents' or search tools. The description lacks context about prerequisites or use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get agent statistics for a domain
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | Domain name | |
| agentId | No | Optional specific agent ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description only states it gets statistics without disclosing behavioral aspects like required permissions, whether it aggregates data, or latency. The agent has no hints about side effects or state changes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, directly states the purpose with no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Simple tool with 2 parameters and no output schema; description is minimally complete for a retrieval operation but doesn't clarify what 'statistics' entails, leaving the agent uncertain about return format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for 'domain' and 'agentId', so the schema already documents parameters. The description adds 'for a domain' which aligns but doesn't enhance understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses specific verb 'get' and resource 'agent statistics for a domain', clearly distinguishing from siblings like get_agents or get_auto_attendants.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like get_agents or login_agent. The description implies it's for statistics but doesn't state conditions or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get auto attendants for a domain
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | Domain name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits like idempotency, permissions required, rate limits, or result format. The name suggests a read operation but this is not confirmed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that conveys the core purpose without extra words. It could be more structured (e.g., bullet points) but is efficient given the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple retrieval tool with one required parameter and no output schema, the description is minimally complete. It explains what the tool does and what input is needed, but lacks details about output, constraints, or any side effects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage for the single parameter 'domain' is 100% with a description 'Domain name'. The description adds no additional meaning beyond the schema, so it meets the baseline but does not exceed it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get auto attendants for a domain' clearly states the action (get) and the resource (auto attendants), and the scope (domain). It distinguishes the tool from siblings like 'get_agents' or 'get_call_queue' by resource type, though it does not elaborate on what auto attendants are.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 such as 'get_call_queues' or 'get_agents'. No context is provided about prerequisites or scenarios where this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get billing information for a domain
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | Domain name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must disclose behavior. It only states 'get billing information' without mentioning read-only nature, authentication needs, or potential side effects, leaving significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, direct and free of superfluous content. Every word serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description is adequate. However, it lacks details on the returned billing data format or any security considerations, which are relevant for billing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameters and provides a brief description for 'domain'. The tool description adds no extra meaning beyond that, meeting the baseline but not exceeding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool retrieves billing information for a domain. The verb 'get' and resource 'billing information' are specific, and no sibling tool relates to billing, distinguishing it well.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when or when not to use this tool. Given many sibling tools, clarification on context or prerequisites would be valuable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get details of a specific call queue
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | Domain name | |
| queueId | Yes | Call queue ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full responsibility for behavioral disclosure. It only states 'get details' without mentioning read-only nature, error conditions, or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no redundant information. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with no output schema, the description is adequate but fails to hint at return value structure or fields. It is minimally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear descriptions for both parameters ('Domain name', 'Call queue ID'). The description adds no extra meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get details of a specific call queue' clearly states the action (get) and the resource (a specific call queue). It differentiates from sibling tool 'get_call_queues' which lists queues.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. The description does not mention when-not-to-use or reference other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get agents assigned to a call queue
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | Domain name | |
| queueId | Yes | Call queue ID |
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 only states 'Get agents' implying a read operation, but does not disclose authentication needs, rate limits, or what is included in the response (e.g., agent names, IDs, status). This is insufficient for full transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 6 words, very concise and front-loaded. However, it could include a bit more context (e.g., 'for a given queue') without harming conciseness. It is efficient but not excessively terse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 params, no output schema), the description is minimal but covers the core purpose. It does not describe the return format or any constraints, but for a basic retrieval tool this may be minimally adequate. Lacks completeness for an ideal agent experience.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameters with descriptions ('Domain name', 'Call queue ID'), so the schema already provides clear semantics. The description does not add any additional meaning beyond what the schema offers, meeting the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get agents assigned to a call queue' clearly states the verb (Get), resource (agents), and scope (assigned to a call queue). It distinguishes from sibling tools like get_agents (all agents) and get_agent_statistics (statistics). The purpose is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. Sibling tools exist (e.g., get_agents, get_call_queue) but no context is given for differentiation. The agent must 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.
Get call queues for a domain
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | Domain name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description offers no behavioral details such as auth requirements, rate limits, or pagination.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One concise sentence, front-loaded, no superfluous words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Minimal but sufficient for a simple list tool. Lacks context about return format or limitations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Single parameter 'domain' with schema description 'Domain name'. Description adds no additional meaning beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb 'Get' and resource 'call queues' for a domain. Implicitly distinguishes from sibling 'get_call_queue' which likely targets a specific queue.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use vs alternatives like 'get_call_queue'. Only implied usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve call detail records (CDR)
| Name | Required | Description | Default |
|---|---|---|---|
| startDate | No | Start date for CDR search (YYYY-MM-DD format) | |
| endDate | No | End date for CDR search (YYYY-MM-DD format) | |
| user | No | Specific user to get CDR records for | |
| domain | No | Domain to search in (required if user is specified) | |
| limit | No | Maximum number of records to return (default: 100) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must convey behavioral traits. It does not disclose that this is a read-only operation, any authentication needs, or rate limits. The description adds little beyond the action name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise (one sentence), but it could include more useful context without becoming verbose. It is appropriately short but lacking in informative content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 5 parameters, no output schema, and no annotations, the description is incomplete. It does not explain the return format, pagination, or how the parameters interact. A tool this complex should provide more context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description does not add any meaning beyond what the parameter descriptions in the input schema already provide.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Retrieve call detail records (CDR)' clearly states the verb (retrieve) and the specific resource (call detail records). It distinguishes this tool from all sibling tools, which are about agents, billing, domains, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. There is no mention of when not to use it or how it differs from other get_* tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about a specific domain
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | Domain name to retrieve information for |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description does not disclose any behavioral traits such as error handling, authentication needs, or what 'detailed information' entails.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is a single efficient sentence, front-loaded with the action, with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite low complexity, the description lacks details about the return structure (no output schema) and does not explain what 'detailed information' includes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the description adds no additional meaning beyond what the schema already provides for the domain parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses specific verb 'Get' and resource 'domain', clearly differentiating from sibling 'get_domains' by indicating it retrieves information for a specific domain.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage when you have a specific domain name, but provides no explicit guidance on when to use versus alternatives like get_domains.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get list of domains in the NetSapiens system
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 omits any information about pagination, ordering, authentication requirements, or the effect of calling the tool (read-only). This is a significant gap for a listing tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words, but it is overly terse. A slightly expanded description could include scope (e.g., 'all domains in the system') without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema and annotations, the description should provide more context about the return format, whether results are paginated, and the nature of domains. As is, it is insufficient for an agent to fully understand the tool's behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so schema coverage is 100%. The description adds nothing beyond the empty schema, but the baseline score of 4 is appropriate because no parameter documentation is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves a list of domains in the NetSapiens system. However, it does not specify what constitutes a 'domain' or differentiate from the sibling 'get_domain' tool which likely retrieves a single domain.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 like 'get_domain'. An explicit mention that 'get_domain' is for a single domain would improve decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get music on hold files for a domain
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | Domain name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It only states the basic function without disclosing whether it's read-only, required permissions, or potential failure modes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence without waste. However, it could be more structured with additional context while remaining concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema and annotations, the description is too minimal. It doesn't explain what 'music on hold files' are or what the response contains, leaving incomplete context for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with a single parameter described as 'Domain name'. The description adds no additional meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Get) and resource (music on hold files) with a specific scope (for a domain). It distinguishes from sibling tools like get_agents, get_billing etc., which target different resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The context from sibling tool names implies it's for music on hold files, but no when-not or prerequisite information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get details of a specific phone number
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | Domain name | |
| phoneNumber | Yes | Phone number to lookup |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description only says 'Get details' without specifying what details, whether read-only, authentication needs, or side effects. For a read operation, basic transparency is missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise at 6 words, no filler. However, it may be too brief, missing important context that could be added without bloating.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, and the description fails to describe what 'details' are returned. For a tool with 2 required parameters, more context on return value structure is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters. The description adds no additional meaning beyond the schema, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves details of a specific phone number, with a clear verb and resource. The sibling tool "get_phone_numbers" implies plural listing, so this tool is distinguished by its singular focus, though not explicitly stated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like "get_phone_numbers" or search tools. No context on prerequisites or expected usage patterns.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get phone numbers for a domain
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | Domain name | |
| limit | No | Maximum number of results (optional) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits. It only states the basic action and scope, omitting details like whether the operation is read-only, requires authentication, handles pagination, or returns active vs. inactive numbers.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with no waste, but brevity sacrifices essential information. Appropriate length but under-specified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, so the description should clarify what is returned (e.g., list of phone numbers with attributes). It does not mention pagination, filtering, or how the optional 'limit' parameter affects results. Incomplete for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters ('domain' and 'limit'). The description adds no extra meaning beyond the schema, which is adequate but does not enhance understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb 'Get' and resource 'phone numbers', and scopes to 'for a domain'. It implies a list operation, distinguishing from sibling 'get_phone_number' (singular). However, no explicit differentiation from other sibling tools like 'get_agents' or 'get_call_queues'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as 'get_phone_number' for a single number. No context on prerequisites or limitations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about a specific user
| Name | Required | Description | Default |
|---|---|---|---|
| userId | Yes | User ID (username part) | |
| domain | Yes | Domain name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral traits. It does not disclose whether the operation is read-only, requires authentication, or has rate limits. The description is too brief.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, achieving conciseness. However, it could be more informative without being overly long.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no behavioral details, the description is incomplete. It does not specify return format, error conditions, or any contextual information an agent might need.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already explains the parameters. The description adds no additional meaning beyond what the schema provides, resulting in a baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves detailed information about a specific user, distinguishing it from sibling tools like get_agents or get_domain. However, it could be more specific about what 'detailed information' includes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like search_users or other entity-specific getters. The description provides no context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get specific answer rule for a user
| Name | Required | Description | Default |
|---|---|---|---|
| userId | Yes | User ID | |
| domain | Yes | Domain name | |
| timeframe | Yes | Timeframe for the answer rule |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description adds no behavioral context such as read-only nature, error handling, or authentication requirements. The description is minimal, leaving agents to guess important 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise but lacks structure. It is adequate but does not fully earn its place as it provides minimal added value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With three required parameters, no output schema, and no annotations, the description is too sparse. It does not explain the response format or any additional context about the rule, making it incomplete for a data retrieval tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema already documents all parameters. The description does not add any additional meaning beyond what the schema provides, meeting the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the purpose: retrieving a specific answer rule for a user. It distinguishes from the sibling tool 'get_user_answer_rules' (plural) which likely returns a list, indicating this is for a single rule.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 like 'get_user_answer_rules' for listing. An agent must infer usage from the tool name and sibling list without explicit direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get answer rules for a user
| Name | Required | Description | Default |
|---|---|---|---|
| userId | Yes | User ID | |
| domain | Yes | Domain name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for disclosing behavioral traits. It only states the action as 'Get', implying read-only, but does not mention permissions, rate limits, error cases, or side effects. The description is insufficient for safe usage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is very concise and front-loaded. However, it is arguably too brief, omitting important details. Still, it earns a 4 for efficiency, as every word is functional.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema and the existence of a sibling tool 'get_user_answer_rule', the description should clarify that this tool returns multiple rules. It fails to do so. Also, no examples or constraints are provided for the two required parameters. The description is incomplete for the task complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with basic descriptions for 'userId' and 'domain'. The tool description does not add any additional meaning beyond what the schema already provides. Baseline score of 3 is appropriate as no extra value is added.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get answer rules for a user' clearly states the action (get) and resource (answer rules for a user). However, it does not differentiate from the sibling tool 'get_user_answer_rule' (singular), which likely retrieves a single rule. The plural suggests multiple rules, but this is not explicitly stated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. The sibling list includes many get_* tools, but there is no mention of exclusions or specific context. The description does not help the agent decide between this and similar tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get devices assigned to a specific user
| Name | Required | Description | Default |
|---|---|---|---|
| userId | Yes | User ID | |
| domain | Yes | Domain name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as read-only nature, permissions required, or response behavior. The description simply states the action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no extraneous information. Every word is necessary and adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of annotations and output schema, the description is too minimal. It lacks details on return format, pagination, error handling, or behavior, making it incomplete for a tool with two required parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with descriptions for both parameters. The tool description does not add additional semantic meaning beyond the schema, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get devices assigned to a specific user' uses a specific verb and resource, clearly distinguishing from sibling tools like 'get_user' or 'get_user_greetings'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. There is no mention of use cases, prerequisites, or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get greetings for a user
| Name | Required | Description | Default |
|---|---|---|---|
| userId | Yes | User ID | |
| domain | Yes | Domain name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral traits. It does not mention that the operation is read-only or any side effects. Although 'get' implies idempotency, the description fails to explicitly confirm safety or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (one sentence) but at the expense of useful detail. It is under-specified, not efficiently concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema and annotations, the description fails to explain what data is returned or any constraints. It is incomplete for an agent to fully understand the tool's behavior and output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with basic descriptions for both parameters. The description adds no additional meaning beyond the schema. Baseline 3 is appropriate as it meets minimal adequacy.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get greetings for a user' clearly states the action and resource, matching the tool name. However, it does not differentiate from sibling tools like get_user or get_user_answer_rules, which could cause confusion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 such as get_user or get_user_voicemails. The description lacks any context on prerequisites or conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get voicemails for a user
| Name | Required | Description | Default |
|---|---|---|---|
| userId | Yes | User ID | |
| domain | Yes | Domain name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries full disclosure responsibility. It only mentions 'Get voicemails' without describing read-only behavior, pagination, or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is efficient but lacks structure or front-loading of key information like returned data format.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description should provide more context about return value structure or scope. It does not explain if voicemails include metadata or how to interpret results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds no extra meaning beyond what the schema already provides (userId and domain).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves voicemails for a user, which is a specific verb-resource combination. It distinguishes from sibling tools like 'get_user' or 'get_domain' by focusing on voicemails.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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, or any prerequisites like authentication or domain context. The description only states functionality.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Login an agent to a call queue
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | Domain name | |
| queueId | Yes | Call queue ID | |
| agentId | Yes | Agent ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only states 'login', failing to disclose idempotency, return value, or side effects. For a mutation tool, 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no fluff. However, it could be slightly expanded without losing conciseness to improve completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and a simple action, the description still lacks essential details like return behavior or prerequisites. It does not fully equip the agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, providing basic parameter descriptions. The description adds minimal context beyond schema, merely restating the action without clarifying parameter relationships.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Login an agent to a call queue' clearly identifies the verb and resource, distinguishing from siblings like logout_agent. However, it does not elaborate on the scoping to domain and queue, which is hinted by parameters.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., logout_agent or get_agents). The description lacks context about prerequisites or appropriate scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Logout an agent from a call queue
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | Domain name | |
| queueId | Yes | Call queue ID | |
| agentId | Yes | Agent ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It only states the action without disclosing behavioral traits such as side effects, required permissions, or what happens upon logout (e.g., state change vs removal).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no unnecessary words. It is efficient and directly conveys the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given three required parameters and no output schema, the description is adequate but lacks details on success behavior, error cases, or idempotency. It is minimal but functional.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear parameter names (domain, queueId, agentId). The description adds no extra meaning beyond the schema, so baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Logout an agent from a call queue') with a specific verb and resource. It distinguishes itself from sibling tool 'login_agent' by indicating the opposite operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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, prerequisites, or alternatives. The description does not mention any conditions or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for users in the NetSapiens system
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query (username or partial username) | |
| domain | No | Optional specific domain to search in | |
| limit | No | Maximum number of results to return (default: 20) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as whether the operation is read-only, requires specific permissions, or how the search query matching works. This is a significant gap for a search tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no fluff. While it lacks depth, it is not verbose and directly states the purpose, earning a high score for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema and annotations, the description is too minimal. It does not explain the output format, pagination behavior, or how domain affects results, leaving the agent underinformed for a search operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All three parameters have clear descriptions in the schema, covering the search query, optional domain, and limit. The tool description adds no extra meaning beyond what the schema already provides, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches for users, which is a specific verb and resource. However, among sibling tools like get_user, it does not explicitly differentiate that this is a search/list operation versus a single-user retrieval, missing a chance to clarify scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like get_user. The description provides no context about prerequisites, filtering behavior, or comparison to other search or retrieval tools, leaving the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Test connectivity to NetSapiens API
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description does not explain what 'test connectivity' entails (e.g., ping, authentication check, response format) or behaviors like failure modes. Full burden on description unmet.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single concise sentence, no extraneous words, appropriately sized for a trivial tool with no parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Description lacks context on output, error handling, or authentication requirements despite zero parameters and no output schema or annotations. Minimal but incomplete for practical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist; schema coverage is 100% trivial. Description adds minimal value beyond purpose, not explaining expected input or behavior, which would be beneficial for context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Test connectivity to NetSapiens API'. It uses a specific verb and resource, distinguishing it from sibling tools that retrieve data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs alternatives. While the purpose implies it's for initial connectivity checks, the description lacks when-not or alternative tool references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.0.0get_agent_statisticsget_agentsget_auto_attendantsget_billingget_call_queueget_call_queue_agentsget_call_queuesget_cdr_recordsget_domainget_domainsget_music_on_holdget_phone_numberget_phone_numbersget_userget_user_answer_ruleget_user_answer_rulesget_user_devicesget_user_greetingsget_user_voicemailslogin_agentlogout_agentsearch_userstest_connectionMost tools target distinct resources (agents, domains, users, call queues, phone numbers, etc.), but there are a few potentially confusing pairs like `get_call_queue` vs `get_call_queues` and `get_phone_number` vs `get_phone_numbers`, though descriptions clarify the singular/plural distinction.
The vast majority of tools follow the 'get_<resource>' pattern, with only three exceptions (`login_agent`, `logout_agent`, `test_connection`). This deviation is minor but prevents a perfect score.
23 tools is slightly above the typical range for a focused server, but the domain (VoIP management) has many distinct resource types, so the count is reasonable and each tool serves a clear purpose.
The tool surface is heavily read-oriented with almost all tools being getters. Only two mutation tools exist (login/logout agent). Missing CRUD operations for domains, users, phone numbers, etc., severely limits management capabilities.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
MCP server enabling AI agents to manage Bitrix24 features via standardized protocol
The Telnyx MCP server is an official implementation of the Model Context Protocol that enables AI clients (like Claude Desktop, Cursor, and OpenAI Agents) to interact with Telnyx's telephony, messaging, and AI assistant APIs. It provides comprehensive capabilities including making and managing phone calls, sending SMS/MMS messages, purchasing and configuring phone numbers, creating AI assistants with custom instructions, managing cloud storage buckets, scraping and embedding website content, and handling integration secrets. The server exists as both a local implementation and a remotely hosted version, allowing developers to integrate real-world communication infrastructure directly into AI applications.
Hosted MCP server connecting AI assistants to 9,000+ apps and 40,000+ actions via Zapier.
MCP server unifying ERPs, CRMs, APIs and knowledge base for Claude, ChatGPT and Gemini.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/OITApps/oitvoip-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
