receptionist-toolkit
Server Details
Free receptionist tools: phone scripts, IVR menus (EN+ES), ElevenLabs prompts, missed-call math
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 3.8/5 across 8 of 8 tools scored.
Each tool targets a distinct task: cost analysis, prompt generation, demo number retrieval, saving results, hiring assessment, call simulation, IVR writing, and phone script writing. No two tools have overlapping purposes, ensuring clear differentiation.
All tool names follow a consistent verb_noun pattern in snake_case (e.g., calculate_missed_call_cost, write_phone_script), making the naming predictable and easy to understand.
With 8 tools, the set is well-scoped for a receptionist toolkit. It covers analysis, creation, simulation, and saving without being excessive or insufficient.
The toolkit covers the full lifecycle: assessing need (should_i_hire_a_receptionist), calculating costs, creating scripts and prompts, simulating calls, providing a demo number, and saving results. No obvious gaps for the intended use case.
Available Tools
8 toolscalculate_missed_call_costCalculate what missed calls cost a businessBInspect
Computes the revenue a business loses to missed phone calls (monthly and yearly), plus the recovery math: recoverable revenue, suggested answering plan, break-even days, and ROI multiple.
| Name | Required | Description | Default |
|---|---|---|---|
| avgJobValue | Yes | Average value of one new customer or job, USD. | |
| callsPerWeek | Yes | Inbound calls per week. | |
| missedRatePct | Yes | Percent of calls missed or sent to voicemail. |
Output Schema
| Name | Required | Description |
|---|---|---|
| cta | No | One-line invite to try Lobby, with a signup link. |
| inputs | No | |
| yearly | Yes | |
| monthly | Yes | |
| recovery | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It indicates a pure computation tool with no side effects, but lacks disclosure of idempotency, authentication needs, or potential rate limits. The description does not contradict annotations because none exist.
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 one sentence that efficiently conveys the purpose and outputs. It is slightly long but all content is relevant. No wasted words, but could be broken into two sentences for readability.
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 that an output schema exists (though not provided), the description's enumeration of outputs (monthly/yearly lost revenue, recoverable revenue, suggested plan, break-even days, ROI multiple) is sufficient. It covers the key computations expected from such a 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 coverage is 100%, so parameters are already described. The description does not add new meaning beyond the schema, such as parameter relationships or constraints. 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 provides a specific verb ('Computes') and resource ('revenue a business loses to missed phone calls'), and details the outputs (monthly/yearly lost revenue, recoverable revenue, suggested plan, break-even days, ROI multiple). It clearly distinguishes from sibling tools like 'should_i_hire_a_receptionist' which are qualitative recommendations.
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 description implies use when quantifying missed call costs, but sibling tools like 'should_i_hire_a_receptionist' exist for related decisions. No 'when-not-to-use' or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
generate_elevenlabs_agent_promptGenerate an ElevenLabs agent system promptBInspect
Generates a production-grade system prompt for an ElevenLabs conversational agent acting as a business phone receptionist: identity, job, voice style, booking flow, guardrails, and escalation rules.
| Name | Required | Description | Default |
|---|---|---|---|
| biz | Yes | Business name (required). | |
| tone | No | Personality, e.g. warm, formal, upbeat. | |
| hours | No | Business hours in plain words. | |
| tasks | No | What the agent should do, e.g. book, faqs, leads. | |
| spanish | No | Whether the agent should also handle Spanish callers. | |
| industry | No | Industry, e.g. plumbing, hvac, dental, salon, law, restaurant. | |
| agentName | No | Name the agent should use for itself. |
Output Schema
| Name | Required | Description |
|---|---|---|
| prompt | Yes | The complete system prompt, ready to paste into ElevenLabs. |
| sections | No | The prompt broken into tagged sections. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It does not disclose any side effects, authentication needs, rate limits, or whether the operation is read-only or creates new data. The description only describes the output content, not 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, well-structured sentence that front-loads the main purpose. Every part is informative, with no wasted words. It is appropriately sized for the tool's complexity.
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 has 7 parameters, no enums, and an output schema, the description provides a good overview but lacks usage guidelines and behavioral transparency. It mentions key components but does not fully compensate for missing annotations. Adequate but with gaps.
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 baseline is 3. The description adds overall context but does not provide additional meaning per parameter beyond the schema. For example, it does not elaborate on valid values for 'tasks' or 'tone'. No extra value above 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 tool generates a system prompt for an ElevenLabs conversational agent acting as a phone receptionist. It lists specific components like identity, job, voice style, booking flow, guardrails, and escalation rules. This is a specific verb+resource+scope that distinguishes it from sibling tools like write_phone_script or calculate_missed_call_cost.
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. It does not mention when not to use it, nor does it compare with sibling tools. The description implies use for AI agent prompts but lacks explicit context or conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_demo_call_numberGet Lobby's live demo phone numberAInspect
Returns a real phone number anyone can call right now to talk to Lobby's AI receptionist live — plus suggested things to say (English and Spanish) and what to listen for (the mid-call language switch, booking flow).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| listenFor | No | |
| trySaying | No | |
| phoneNumber | Yes | |
| availability | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description provides useful behavioral details (live number, language switch, booking flow) but lacks information on limitations or edge cases like call availability.
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 efficiently communicates purpose and key features without waste.
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 no parameters, the description is complete for a simple tool with an output schema. It covers what is returned and the 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?
No parameters exist, so this dimension is inherently satisfied. A baseline of 4 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 returns a real phone number for calling Lobby's live AI receptionist, plus suggested prompts and listening guidance. It distinguishes from siblings like simulate_receptionist_call which simulates calls.
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 implies when to use (to actually call the demo) but does not explicitly state when not to use or mention alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
save_my_receptionistSave this receptionist and get the next stepAInspect
Saves the phone script, IVR menu, agent prompt, or simulated call you just built for a real business, and emails it to the person you're helping — with the live demo number to hear it and a signup link to turn it on for real. Offer this after write_phone_script, write_ivr_menu, generate_elevenlabs_agent_prompt, or simulate_receptionist_call, once the human seems to want to keep the result or try it live. Requires the person's explicit consent to be emailed — ask first, and only call this with consent: true if they say yes.
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | Email to send the saved result and one follow-up to (required). | ||
| notes | No | Any other context worth keeping — what the business does, what was discussed. | |
| consent | Yes | Required. The person must explicitly agree to have their saved result emailed to them, plus one follow-up. If false or omitted, do not save or email anything — refuse politely and explain you need their OK first. | |
| industry | No | Industry or trade, e.g. plumbing, dental, salon. | |
| language | No | Language for the follow-up email. Default: en. | |
| phone_script | No | The phone script, IVR menu text, or agent prompt to save, if one was generated earlier in this conversation. | |
| business_name | Yes | The business name (required). |
Output Schema
| Name | Required | Description |
|---|---|---|
| saved | Yes | |
| business | No | |
| emailSent | No | |
| signupUrl | No | |
| demoNumber | No | |
| confirmation | Yes | Friendly confirmation to relay to the person, including the live demo number and signup link. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that it saves and emails, requires explicit consent, and sends one follow-up. Describes behavior if consent is false/omitted. Lacks rate limit or auth details, but annotations are absent so description carries burden well.
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?
Three sentences, front-loaded with purpose, then condition and consent. No wasted words, well-organized.
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?
All parameters described, output schema exists, description covers when to use, what it does, and consent requirement. For a complex 7-param tool, it's quite complete, though it could mention the email content briefly.
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 baseline 3. Description adds extra context: e.g., notes is 'any other context worth keeping', consent is 'required' with explicit behavior, phone_script is 'if one was generated earlier'. This adds 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?
The description clearly states the tool saves phone scripts, IVR menus, agent prompts, or simulated calls and emails them with a demo number and signup link. It distinguishes from sibling tools by specifying when to offer it (after write_phone_script, write_ivr_menu, 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?
Explicitly says when to offer (after those tools) and condition (when human seems to want it). Emphasizes consent requirement and instructs to ask first, and only call with consent: true if they say yes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
should_i_hire_a_receptionistShould this business hire a receptionist?AInspect
Scores a business's phone coverage and returns a verdict — you're covered, get an AI front desk, or go hybrid — with the caller archetype, yearly leak, suggested plan, break-even days, and ROI.
| Name | Required | Description | Default |
|---|---|---|---|
| avgJobValue | Yes | Average value of one new customer or job, USD (snapped to the quiz's brackets). | |
| callsPerWeek | Yes | Roughly how many inbound calls per week (snapped to the quiz's brackets). | |
| currentSetup | No | Who answers today: the owner (self), voicemail (vm), staff between tasks (staff), or nobody consistently (none). Default: self. | |
| missedRatePct | Yes | Rough percent of calls that go unanswered (snapped to the quiz's brackets). | |
| coverageNeeded | No | When calls actually come in. Default: business-hours. | |
| spanishCallers | No | How often Spanish-speaking customers call. Default: no. |
Output Schema
| Name | Required | Description |
|---|---|---|
| cta | No | One-line invite to try Lobby, with a signup link. |
| score | Yes | Phone-coverage maturity score, 0-100. |
| verdict | Yes | covered = current setup is fine; lobby = an AI front desk pays for itself; hybrid = AI + existing staff. |
| recovery | No | |
| archetype | Yes | |
| yearlyLeak | Yes | USD lost per year with the current setup. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full behavioral burden. It describes the output (verdict, caller archetype, etc.) but does not disclose whether the operation is read-only, has side effects, or requires authentication. It gives enough to understand the return value structure but not underlying behavior.
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, information-dense sentence with no wasted words. It efficiently conveys the tool's purpose and output, fitting within the recommended front-loaded structure.
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 complexity (6 parameters, output schema), the description is adequate on the output side but lacks context on input requirements, prerequisites, or relationships to siblings. The output is well-summarized, but the description would benefit from usage guidance or behavioral 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 mention any parameters or add meaning beyond the schema's own descriptions (e.g., snapping to brackets). It provides no additional semantic context for the six input fields.
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 that the tool scores phone coverage and returns a verdict (you're covered, AI front desk, or hybrid) along with caller archetype, yearly leak, suggested plan, break-even days, and ROI. This specific verb+resource combination distinguishes it from siblings like calculate_missed_call_cost or simulate_receptionist_call.
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 gives no guidance on when to use this tool versus its siblings (e.g., calculate_missed_call_cost, get_demo_call_number). It implies a general recommendation scenario but lacks explicit when-to-use or when-not-to-use instructions, leaving the agent to infer context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
simulate_receptionist_callSimulate a call with the Lobby receptionistAInspect
Role-play a phone call with Lobby's receptionist call engine — the same pipeline behind the product demo: greeting, booking flow, lead capture, and automatic English/Spanish detection (live calls add a full AI brain on top). You play the caller: pass each thing the caller says, get the full transcript and outcome back. Free, text-only, max 6 caller lines.
| Name | Required | Description | Default |
|---|---|---|---|
| business | No | Business name the receptionist answers for. Default: Lobby Demo Services. | |
| callerSays | Yes | The caller's lines, in order. Try Spanish to hear the language switch — e.g. ['Hola, necesito una cita para mañana.'] |
Output Schema
| Name | Required | Description |
|---|---|---|
| booked | No | |
| outcome | Yes | |
| language | Yes | Language the receptionist detected and answered in. |
| hearItLive | No | Phone number to call to experience the same receptionist with a real voice. |
| transcript | Yes | |
| leadCaptured | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description takes full burden. It discloses the pipeline flow, language detection, output (transcript and outcome), and limitations (text-only, 6 lines). It does not cover potential error handling or data persistence, but overall provides solid behavioral context.
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 efficient paragraph, front-loading the purpose, then providing necessary details and constraints. Every sentence adds value without fluff, balancing informativeness and brevity.
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 complexity (simulating a multi-step call) and presence of output schema, the description covers the entire user-facing behavior: what to do, how it works, what to expect, and limitations. No gaps identified.
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 role-play guidance, sequential calling, and language switch tip, which goes beyond schema. It clarifies the caller's role and the 'callerSays' usage, making it more actionable.
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 is a role-play simulation of a receptionist call, detailing the pipeline (greeting, booking, lead capture, language detection) and distinguishing it from sibling tools like cost calculation or script writing. Uses specific verb 'role-play' and resource 'receptionist call engine'.
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 implies usage for testing or demos via role-play, specifies constraints (free, text-only, max 6 lines), and suggests trying Spanish. However, it does not explicitly mention when not to use or alternatives among siblings, though siblings are clearly different in function.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
write_phone_scriptWrite a business phone scriptAInspect
Writes a professional phone script for a business — greeting, voicemail message, on-hold message, or jingle lines — in English, Mexican Spanish, or both. Returns ready-to-record text.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | What kind of script to write. Default: greeting. | |
| vibe | No | Tone of voice. Default: warm. | |
| extra | No | Optional details to mention: hours, offers, callback promise. | |
| langs | No | Languages to write. Default: both. | |
| trade | No | Industry or trade, e.g. plumbing, dental clinic. | |
| business | Yes | Business name (required). |
Output Schema
| Name | Required | Description |
|---|---|---|
| cta | No | One-line invite to try Lobby, with a signup link. |
| scripts | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the tool generates ready-to-record text, implying no destructive side effects. However, it does not explicitly state read-only or safety traits beyond the generative nature.
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?
Two sentences with no redundant words. The first sentence front-loads the core action and key options, and the second concisely states the output format. Every sentence 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?
Given the output schema exists to explain return values, the description adequately covers the tool's scope: it lists script types, languages, and output format. It could mention the extra parameter and trade, but the schema already covers them, making the description sufficiently 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%, so the schema already describes each parameter. The description adds context about script types and languages but does not provide meaning beyond what the schema's property descriptions already offer.
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 writes professional phone scripts for businesses, listing specific script types (greeting, voicemail, hold, jingle) and language options (English, Mexican Spanish, or both). This specific verb-resource combination distinguishes it from sibling tools like calculate_missed_call_cost or generate_elevenlabs_agent_prompt.
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 include any 'when to use' or 'when not to use' statements, nor does it mention alternative tools for similar tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!