A
licenseNot graded
qualityD
maintenanceEnables integration with Vapi's voice AI platform to manage assistants, create and schedule phone calls with dynamic variables, and manage phone numbers through function calling.
601
MIT
AI Directory MCP Server
by sonnyflylock
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., "@AI Directory MCP Serverlist all AI services"
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.
AI Directory MCP Server
MCP (Model Context Protocol) server for the Voxie AI Phone Number Directory. Allows AI assistants to query information about AI services and get webchat URLs to interact with them.
Installation
cd mcp-server
npm installRelated MCP server: Telique MCP
Usage with Claude Desktop
Add to your Claude Desktop config (claude_desktop_config.json):
{
"mcpServers": {
"ai-directory": {
"command": "node",
"args": ["C:/Users/es/textmei-frontend/mcp-server/index.js"]
}
}
}Access Modes
Public Mode (Default)
By default, the server runs in public mode which only exposes webchat URLs for Voxie services. This is the mode used when publishing to npm.
Full Access Mode
For partners or internal use, set the environment variable to expose SMS/voice numbers:
{
"mcpServers": {
"ai-directory": {
"command": "node",
"args": ["C:/Users/es/textmei-frontend/mcp-server/index.js"],
"env": {
"VOXIE_FULL_ACCESS": "true"
}
}
}
}Available Tools
list_ai_services
List all AI services or filter by provider type.
provider: "all", "voxie", or "third-party"
get_ai_service
Get details about a specific service by ID.
id: Service ID (e.g., "voxie-us", "chatgpt-us")
find_ai_services_by_country
Find services available in a specific country.
country: Country name or partial match
chat_with_ai
Get a webchat URL to chat with a Voxie AI persona (recommended).
persona: "voxie", "rhodey", "soarie", "mia", or "wallie"
Available Resources
ai-directory://services/all- All servicesai-directory://services/voxie- Voxie AI personasai-directory://services/third-party- Third-party services
API Endpoint
The directory is also available as a REST API at:
https://voxie.network/api/ai-directory
Query parameters:
id- Get specific serviceprovider- Filter by "voxie" or "third-party"country- Filter by country namechannel- Filter by "sms", "voice", or "webchat"
Publishing to npm
npm publish --access publicThe public npm package only exposes webchat URLs, protecting your SMS/voice costs.
Available Tools
4 toolschat_with_aiA
Get a webchat URL to chat with a Voxie AI persona. This is the recommended way to interact with Voxie AIs.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| persona | Yes | Which AI persona to chat with: voxie (main, conversational), rhodey (direct answers), soarie (Canadian, EN/FR), mia (Puerto Rico, EN/ES), wallie (Mexico, EN/ES) |
TDQS
A4/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description describes a read-only action (getting a URL) and does not mention auth, rate limits, or side effects. Adequate but minimal.
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?
Two sentences, no redundancy, front-loaded with the key action. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool without output schema, the description covers purpose and recommended usage. Could add expiry or usage details of the URL, but not essential.
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 detailed enum explanations. Tool description adds no additional parameter context beyond the schema, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get', resource 'webchat URL', and purpose 'chat with a Voxie AI persona'. It distinguishes from siblings which are about managing AI services, not chatting.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
States 'recommended way to interact with Voxie AIs', implying primary use case. Does not explicitly exclude alternatives or provide when-not-to-use guidance, but sibling tools provide enough context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
find_ai_services_by_countryB
Find AI services available in a specific country or region
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| country | Yes | Country name or partial match (e.g., 'United States', 'Canada', 'Mexico') |
TDQS
B3.1/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. It only states the tool finds AI services by country but does not disclose behavioral traits such as whether partial matching is allowed (the schema does mention it), return format, read-only nature, or any limitations.
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 short sentence, which is concise and front-loaded. However, it could be expanded slightly to include key behavioral context without losing conciseness. Still, it is not bloated.
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 simplicity (one parameter, no output schema, no annotations), the description is too minimal. It does not explain what the tool returns (e.g., 'returns a list of AI service names and details'), how it handles partial matching, or any edge cases. More context is needed for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a clear description of the 'country' parameter including examples. The tool description adds no new semantic value beyond the schema; it simply restates the parameter's purpose. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Find AI services available in a specific country or region'. It uses a specific verb and resource, and the tool name effectively distinguishes it from siblings like 'list_ai_services' (which likely lists all services) and 'get_ai_service' (singular).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'list_ai_services'. It does not mention prerequisites, exclusions, or preferred scenarios, leaving the agent to rely solely on the tool name for context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_ai_serviceA
Get details about a specific AI service by its ID (e.g., 'voxie-us', 'chatgpt-us')
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The service ID |
TDQS
A4.2/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It states 'get details' but does not explain what the details include, return format, or any side effects. For a simple read operation, minimal behavior is implied, but more clarity on the response structure would be beneficial.
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, front-loaded sentence with no extra words. Every word is essential and informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema, no annotations), the description is mostly complete. It identifies the resource and lookup method, though it could mention the expected return type or error scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with the parameter described as 'The service ID'. The description adds concrete examples of valid IDs, providing added meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly uses 'Get details about a specific AI service by its ID', specifying the verb, resource, and method. It distinguishes from siblings like list_ai_services (listing all) and find_ai_services_by_country (filtering by country).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you have a specific service ID and want details, especially with examples ('voxie-us', 'chatgpt-us'). However, it lacks explicit guidance on when not to use it or comparisons to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_ai_servicesA
List AI services that can be accessed via webchat (and phone for some). Returns all services or filter by provider type.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| provider | No | Filter by provider: 'voxie' for Voxie AI personas, 'third-party' for other services, 'all' for everything |
TDQS
A4/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It adds behavioral context about access methods (webchat and phone for some), but does not disclose other traits like pagination, ordering, or rate limits. For a simple list tool, this is adequate but not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded with the core functionality and efficiently covers purpose and optional filter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with one optional parameter and no output schema, the description is largely complete. It explains the filter options and access methods. It could mention absence of pagination or ordering details, but overall it meets the needs.
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% coverage with a detailed description of the provider parameter. The tool description mentions filtering but does not add value beyond the schema's parameter description. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and resource 'AI services', adds context about access via webchat (and phone for some), and effectively distinguishes from siblings like chat_with_ai, find_ai_services_by_country, and get_ai_service.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates usage for listing all services or filtering by provider type, providing clear context. However, it lacks explicit guidance on when not to use this tool or direct comparison with sibling tools, though the distinction is implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
TDQS
A3.9/5.0
Disambiguation5/5
Each tool has a distinct purpose: chatting with an AI, filtering services by country, getting details by ID, and listing all services. No overlap or confusion.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern with snake_case (chat_with_ai, find_ai_services_by_country, get_ai_service, list_ai_services), making the set predictable and easy to navigate.
Tool Count5/5
With 4 tools, the server is well-scoped for an AI directory: listing, detail, filtered search, and interaction. The count feels natural and not excessive.
Completeness4/5
The tool set covers core directory operations (list, get, search) and interaction (chat). Minor gaps exist (e.g., no filtering by provider type or category), but the surface is largely complete for the domain.
Maintenance
ActivityInactive
ResponsivenessUnresponsive
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
Give AI agents secure access to RevDesk calling, SMS, phone numbers, caller IDs, and usage.
Directory of APIs, merchants, and tools AI agents can actually use.
Create and manage DialNexa AI voice agents, campaigns, calls, phone numbers, workflows, and more.
Carbon Voice MCP serves as a bridge that connects AI assistants like ChatGPT, Claude, and Cursor to a user's Carbon Voice account, turning voice messages and conversations into a private, on-demand knowledge base. It provides 28 specialized tools for comprehensive voice messaging management, including creating and sending messages, accessing conversation history with instant transcription, running AI actions (summarization, TLDR generation, meeting notes), and managing workspace collaboration through folders, contacts, and team communications.
Related MCP Servers
- AlicenseAqualityBmaintenanceEnables querying telecom routing data (LRN, CNAM, DNO, LERG, toll-free routing) directly from AI assistants like Claude, ChatGPT.1424MIT
- AlicenseNot gradedqualityDmaintenanceEnables AI assistants to manage Davoxi voice agent platform resources such as businesses, agents, call logs, webhooks, analytics, and billing through natural language conversations.15MIT
- AlicenseNot gradedqualityBmaintenanceEnables AI assistants to purchase virtual phone numbers, retrieve SMS verification codes, and manage activations through natural language by wrapping the VirtualSMS Consumer API.18MIT
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/sonnyflylock/voxie-ai-directory-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server