pearl-api-mcp-server
Server Details
Hybrid human + AI expertise for faster, trusted answers and decisions via MCP Server.
- 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 4.2/5 across 4 of 4 tools scored.
Tools are well-differentiated by clear usage guidelines, though askExpert and askPearlExpert both escalate to humans, which could cause slight confusion.
All tool names follow a consistent 'verbPurpose' pattern using camelCase, making the interface predictable.
Four tools is an appropriate size for a focused Q&A server, covering AI answers, expert escalation, and verification without excess.
Covers the primary workflows (AI answer, expert request, verification) but lacks a tool for searching past answers or managing feedback.
Available Tools
4 toolsaskExpertaskExpertAInspect
Use this when the user explicitly asks to speak with a real human expert, needs personalized advice in a complex or sensitive domain, or says something like 'Can I talk to a real expert?'. Supports phone callback — pass phoneNumber and contactPreference='phone' if the user wants a call.
| Name | Required | Description | Default |
|---|---|---|---|
| question | Yes | The user's question | |
| sessionId | No | Optional session ID for continuing a conversation | |
| chatHistory | No | Optional conversation history. This ensures experts see the complete context | |
| phoneNumber | No | Customer's phone number for expert callback in E.164 format (e.g., +15551234567). Only pass when the user explicitly provides it. | |
| contactPreference | No | Customer's preferred contact method. Set to 'phone' when the user wants a phone callback. | |
| enableMockResponse | No | When true, the API returns a hardcoded mock expert success response instead of routing to a real expert. Useful for testing downstream behavior. |
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 full behavioral disclosure. It mentions phone callback support but lacks details on response format, whether connection is real-time, or any limitations (e.g., hours, queue). Does not describe mock response behavior despite schema having that parameter.
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 efficient sentences with zero waste. Front-loaded with the core purpose and immediate usage guidance. Ideal structure for an AI agent prompt.
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?
Covers the main use case and key parameters well. Lacks explanation of what happens after invocation (e.g., response structure) and does not mention the enableMockResponse parameter's purpose in the description, but enough for most scenarios given the schema descriptions.
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, so baseline is 3. The tool description adds extra context for phone-related parameters (e.g., when to pass phoneNumber and set contactPreference to 'phone'), which is valuable beyond schema. However, it doesn't elaborate on sessionId, chatHistory, or enableMockResponse.
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?
Explicitly states the tool is for when the user asks to speak with a human expert or needs personalized advice, with concrete examples like 'Can I talk to a real expert?'. Clearly distinguishes from sibling tools like askPearlAi.
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?
Provides clear when-to-use conditions: 'Use this when the user explicitly asks to speak with a real human expert...' Implies when not to use by contrasting with siblings, but doesn't explicitly list exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
askPearlAiaskPearlAiAInspect
Use this when the user wants a rapid AI-generated answer, draft, or alternative perspective on a low-risk or exploratory topic that does not require human validation. Do not use for medical, legal, financial, or safety-critical questions — use askExpert or askPearlExpert instead.
| Name | Required | Description | Default |
|---|---|---|---|
| question | Yes | The user's question | |
| sessionId | No | Optional session ID for continuing a conversation | |
| chatHistory | No | Optional conversation history. This ensures experts see the complete context |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses key behavioral traits: it's for 'rapid' responses and 'does not require human validation,' which helps the agent understand speed and reliability expectations. However, it doesn't mention potential limitations like response length, format, or error handling.
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 highly concise and front-loaded: the first sentence defines the purpose and usage context, and the second provides critical exclusions and alternatives. Every sentence earns its place 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?
Given the tool's moderate complexity (AI response generation) and lack of annotations/output schema, the description is fairly complete. It covers purpose, usage boundaries, and alternatives, though it could benefit from more detail on behavioral aspects like response format or limitations to fully compensate for missing structured data.
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 documents all parameters thoroughly. The description adds no additional parameter semantics beyond what's in the schema, maintaining the baseline score of 3 for adequate coverage without extra value.
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: providing 'rapid AI-generated answer, draft, or alternative perspective' for 'low-risk or exploratory topics.' It specifies the resource (AI-generated content) and verb (ask/answer), though it doesn't explicitly distinguish from all siblings beyond the exclusions mentioned.
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 explicit guidance on when to use ('low-risk or exploratory topics') and when not to use ('medical, legal, financial, or safety-critical questions'), with clear alternatives named ('askExpert or askPearlExpert'). This directly helps the agent choose between sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
askPearlExpertaskPearlExpertAInspect
Use this when the problem is complex, ambiguous, high-stakes, or multidisciplinary and would benefit from AI intake followed by escalation to a human expert. Do not use for simple fact queries (use askPearlAi) or when the user explicitly requests a human directly (use askExpert). Supports phone callback — pass phoneNumber and contactPreference='phone' if the user wants a call.
| Name | Required | Description | Default |
|---|---|---|---|
| question | Yes | The user's question | |
| sessionId | No | Optional session ID for continuing a conversation | |
| chatHistory | No | Optional conversation history. This ensures experts see the complete context | |
| phoneNumber | No | Customer's phone number for expert callback in E.164 format (e.g., +15551234567). Only pass when the user explicitly provides it. | |
| contactPreference | No | Customer's preferred contact method. Set to 'phone' when the user wants a phone callback. | |
| enableMockResponse | No | When true, the API returns a hardcoded mock expert success response instead of routing to a real expert. Useful for testing downstream behavior. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description carries full burden. It discloses the tool performs AI intake then escalates to human experts, and supports phone callback. Lacks details on internal processing or potential delays, but still provides good transparency for an escalation workflow.
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 concise sentences with no wasted words. Front-loaded with primary purpose and usage conditions, followed by specific parameter guidance. Every sentence 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 complexity (6 params, escalation flow) and lack of output schema, the description does well to explain usage boundaries and key parameters. Slightly lacking on return value expectations (no output schema), but the tool's nature makes that acceptable. Could mention typical response 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%, and description adds valuable context beyond schema: explains when to use phoneNumber/contactPreference, the purpose of chatHistory for expert context, and enableMockResponse for testing. This significantly aids correct parameter usage.
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 handles complex, ambiguous, high-stakes, or multidisciplinary problems requiring AI intake followed by human expert escalation. It explicitly distinguishes from sibling tools askPearlAi and askExpert, making the purpose 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?
Provides explicit when-to-use and when-not-to-use guidance, naming specific alternatives (askPearlAi for simple queries, askExpert for direct human requests). Also details phone callback usage with conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
verifyAnswerverifyAnswerAInspect
Use this when a professional needs to validate the correctness, safety, or trustworthiness of a specific AI-generated answer, or when the user asks to have an answer double-checked by a real expert.
| Name | Required | Description | Default |
|---|---|---|---|
| answer | Yes | The AI-generated answer that requires human verification | |
| sessionId | No | Existing session ID to continue; generated if omitted | |
| chatHistory | No | Optional prior messages for context (ordered, oldest first) | |
| enableMockResponse | No | When true, the API returns a hardcoded mock expert success response instead of routing to a real expert. Useful for testing downstream behavior. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must carry full burden. It mentions 'real expert' but does not disclose whether the validation is synchronous/asynchronous, what happens if expert unavailable, or the format of the response. Lacks details on 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?
Single, front-loaded sentence clearly stating the condition for use. No unnecessary words, highly efficient.
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 4 parameters, no output schema, and no nested objects, the description covers the core purpose but omits what the tool returns (e.g., verification result). Could mention output format or actions expected after validation.
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. Description adds minimal context beyond schema: it reinforces 'answer' as AI-generated but does not explain sessionId or chatHistory purpose beyond schema descriptions.
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 validates AI-generated answers with a real expert, using specific verb 'validate' and resource 'AI-generated answer'. It distinguishes from sibling tools like 'askExpert' by focusing on verification of existing answers rather than general questioning.
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?
Explicit 'Use this when...' phrasing provides clear context for when to invoke the tool. It implies not to use for general questions, but does not explicitly compare to siblings or state when not to use.
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!