Skip to main content
Glama

request_demo

Schedule a personalized demo of Ravira for your dental practice. Provide your name, practice name, email, and preferred time to receive a call from founder Purnima for a 20-minute live demo.

Instructions

Request a live demo of Ravira for your dental practice.

Submit your contact info and Purnima (Ravira's founder) will reach out to schedule a personalized 20-minute demo.

Args: name: Your name (e.g. "Dr. Sarah Johnson" or "Mike - Office Manager") practice_name: Name of your dental practice email: Best email to reach you phone: Phone number (optional) best_time: Best time to call (e.g. "Tuesday morning", "weekday afternoons")

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameYes
practice_nameYes
emailYes
phoneNo
best_timeNoanytime

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Implementation Reference

  • server.py:453-453 (registration)
    Tool registration via @mcp.tool() decorator on the request_demo function.
    @mcp.tool()
  • The request_demo handler function that accepts contact info (name, practice_name, email, optional phone, best_time) and returns a confirmation message saying Purnima will reach out within 1 business day.
    def request_demo(
        name: str,
        practice_name: str,
        email: str,
        phone: Optional[str] = None,
        best_time: str = "anytime",
    ) -> str:
        """
        Request a live demo of Ravira for your dental practice.
    
        Submit your contact info and Purnima (Ravira's founder) will reach out
        to schedule a personalized 20-minute demo.
    
        Args:
            name: Your name (e.g. "Dr. Sarah Johnson" or "Mike - Office Manager")
            practice_name: Name of your dental practice
            email: Best email to reach you
            phone: Phone number (optional)
            best_time: Best time to call (e.g. "Tuesday morning", "weekday afternoons")
        """
        log.info(
            "Demo request: name=%s practice=%s email=%s phone=%s time=%s",
            name, practice_name, email, phone, best_time,
        )
    
        return (
            f"# Demo Request Received!\n\n"
            f"Thank you, {name}! Here's a summary of your request:\n\n"
            f"- **Practice:** {practice_name}\n"
            f"- **Contact:** {email}" + (f" / {phone}" if phone else "") + f"\n"
            f"- **Best time:** {best_time}\n\n"
            f"**Purnima will reach out within 1 business day** to schedule your "
            f"personalized 20-minute Ravira demo.\n\n"
            f"In the meantime, you can:\n"
            f"- Visit [ravira.ai](https://ravira.ai) to see the product\n"
            f"- Try the tools in this MCP server to explore Ravira's capabilities\n\n"
            f"We look forward to showing you how Ravira can help {practice_name} "
            f"capture more patients and free up your front desk!"
        )
  • Input schema defined via type annotations: name (str), practice_name (str), email (str), phone (Optional[str]), best_time (str, default 'anytime').
    def request_demo(
        name: str,
        practice_name: str,
        email: str,
        phone: Optional[str] = None,
        best_time: str = "anytime",
    ) -> str:
  • server.py:50-57 (registration)
    The FastMCP server instance named 'ravira' that hosts all tools including request_demo.
    mcp = FastMCP(
        "ravira",
        instructions=(
            "You are connected to Ravira — an AI receptionist built specifically for dental practices. "
            "Use the available tools to demonstrate how Ravira handles patient questions, show its features, "
            "and help dental practice owners or staff understand the product."
        ),
    )
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description outlines the outcome: Purnima reaches out to schedule a 20-minute demo. No annotations exist, so the description carries full burden. It could add idempotency or data handling details, but the disclosed behavior is clear and sufficient for a simple demo request.

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 brief but complete: a two-sentence overview followed by a structured Args list. Every sentence adds value, and the format is easy for an AI to parse.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers purpose, parameters, and outcome. An output schema exists but not shown; the description doesn't need to repeat return values. No critical gaps remain.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, but the description provides meaningful examples and format guidance for each parameter (e.g., name format, best_time examples). This adds significant value beyond the schema's type definitions.

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 explicitly states the tool requests a live demo of Ravira for a dental practice, including the process after submission. It clearly distinguishes from sibling tools like ask_ravira or get_ravira_features.

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 usage context is implied: use this to request a demo. Siblings cover different functions (Q&A, features, conversations, search), so no ambiguity. However, there is no explicit 'when not to use' or alternative tools mentioned.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Latest Blog Posts

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/pvijaya645/ravira-mcp'

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