Agent Broker
Server Details
AI agents find, message & book SMBs; pay per call in USDC on Base via x402. 14 tools, compliant.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- basilalshukaili/agentbroker
- GitHub Stars
- 0
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.6/5 across 14 of 14 tools scored.
Each tool targets a distinct task: finding businesses, booking via URL or voice, messaging, lead capture, escalation, and async operation tracking. Descriptions clearly differentiate purposes, minimizing ambiguity.
All tool names follow a consistent verb_noun pattern (e.g., call_business, find_business, send_message), with no mixing of conventions or vague verbs.
14 tools is well-scoped for a business agent broker, covering discovery, verification, booking, communication, lead capture, escalation, and operational support without being excessive.
The tool set covers the full lifecycle from finding and verifying SMBs to booking, messaging, handling inbound, capturing leads, and escalating. Async handling and cost estimation round it out, with no obvious gaps.
Available Tools
14 toolscall_businessADestructiveInspect
Place a conversational voice-AI phone call to a business on a consumer's behalf and return a structured answer. THE differentiated capability: reach the ~60M long-tail SMBs that have NO API and NO booking page — only a phone number. An AI agent cannot pick up a phone and hold a conversation; this tool does. Give a plain-language objective; the voice AI navigates the call and extracts the answer. Business-directed (B2B), far less restricted than calling consumers — but the compliance gate still enforces recording consent per jurisdiction. Async: returns a call handle; poll get_outcome for the transcript + extracted fields.
WHEN TO USE: Use when the target business has NO booking URL and NO API — only a phone number — and the consumer asked the agent to reach them (e.g. 'call this plumber and ask if they can come Tuesday', 'ask the salon if they take walk-ins this afternoon'). Also use to confirm details a booking page doesn't expose (real-time availability, custom quotes). WHEN NOT TO USE: Do NOT use when the business has a booking URL — use import_booking_url + schedule_appointment (cheaper, faster, deterministic). Do NOT use for calls to consumers/individuals (this tool is for reaching businesses). Do NOT use for marketing or telemarketing — the compliance gate and the B2B-only framing reject that. COST: $0.5 per_call LATENCY: ~45000ms EXECUTION: async_by_default (use get_outcome to retrieve result)
| Name | Required | Description | Default |
|---|---|---|---|
| smb_id | No | Known SMB identifier with a phone on record. Provide this OR business_phone. | |
| objective | Yes | What the call should accomplish, in plain language. | |
| country_code | No | ISO 3166-1 alpha-2 for compliance + recording-consent routing. | |
| on_behalf_of | No | Name of the consumer the call is placed for. | |
| business_phone | No | Business phone in E.164 (e.g. +14045550123). Provide this OR smb_id. | |
| extract_fields | No | Structured fields to pull from the answer, e.g. ['available_tomorrow','price_quote','earliest_slot']. | |
| max_duration_seconds | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (destructiveHint=true, readOnlyHint=false), the description discloses key behaviors: async execution, polling via get_outcome, cost ($0.5), latency (~45s), compliance gate, recording consent, and B2B focus. No contradictions with annotations.
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 well-structured with sections and front-loaded with purpose. While it is somewhat lengthy, every sentence conveys valuable information without redundancy. Minor trim could improve conciseness, but it remains clear and 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?
Despite no output schema, the description explains the async flow, return value (call handle), and how to retrieve results (get_outcome). It covers cost, latency, compliance, and usage context, making it complete for a complex tool with 7 parameters and multiple sibling tools.
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?
With 86% schema coverage, the schema already documents most parameters. The description adds value by explaining the mutual exclusivity of smb_id and business_phone, and the purpose of objective and extract_fields. It could provide slightly more detail on max_duration_seconds, but overall it complements the schema well.
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 function: placing a voice-AI call to a business on a consumer's behalf. It emphasizes the unique capability of reaching SMBs without digital interfaces, and explicitly distinguishes from sibling tools like import_booking_url and schedule_appointment.
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 'WHEN TO USE' and 'WHEN NOT TO USE' sections, detailing appropriate scenarios (e.g., business with only phone number) and contraindications (e.g., existing booking URL, consumer calls, marketing). It names alternative tools for the excluded cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
capture_leadAInspect
Structured intake of a prospect into an SMB's funnel with validation, enrichment hooks, and deduplication. Inserts into the SMB's CRM or direct-booking pipeline if available.
EXAMPLE USER QUERIES THAT MATCH THIS TOOL: user: "Tell smb_xyz I'm interested and want a callback" -> call capture_lead({"smb_id": "smb_xyz", "prospect": {"name": "Jane", "phone": "+15551234567", "email": "jane@example.com"}, "source": "agent"})
WHEN TO USE: Use when a potential customer has expressed interest in an SMB's service and you want to ensure they are registered in the SMB's pipeline for follow-up. WHEN NOT TO USE: Do not use for confirmed bookings — use schedule_appointment. Do not use for bulk list imports. COST: $0.05 per_lead LATENCY: ~600ms EXECUTION: sync_fast (use get_outcome to retrieve result)
| Name | Required | Description | Default |
|---|---|---|---|
| smb_id | Yes | ||
| source | No | Where the consumer-initiated request originated (e.g., 'consumer_request', 'inbound_quote_form', 'agent_referral_from_find_business'). | |
| prospect | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses cost ($0.05/lead), latency (~600ms), execution mode (sync_fast, use get_outcome), and behavioral traits like deduplication and hooks. Annotations (readOnlyHint=false, destructiveHint=false) are consistent, and no contradictions 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 well-structured with headings and bullet-like points, efficiently packing purpose, usage guidelines, and example. The example is integrated without excessive length, earning 4 for near-optimal 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?
Covers all necessary aspects: purpose, when to use, behavior, cost, latency, and result retrieval via get_outcome. Despite no output schema, the description is complete for this moderate complexity tool with good annotations.
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 33%, so description partially compensates with example usage and general behavior, but lacks detailed explanations for each parameter (e.g., smb_id, prospect fields like phone). The example adds clarity but does not fully describe all parameters.
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 for structured intake of a prospect into an SMB's funnel, with specific actions like validation, enrichment, and deduplication. It distinguishes from siblings like schedule_appointment and provides example queries.
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 'WHEN TO USE' and 'WHEN NOT TO USE' sections, along with alternative tool names (schedule_appointment) and instructions to avoid bulk imports. Example user queries further clarify context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
escalate_to_humanADestructiveInspect
Hand off an in-flight task to a human operator with a full context bundle: transcript, prior actions, identifiers, and a recommended next step.
EXAMPLE USER QUERIES THAT MATCH THIS TOOL: user: "I'm stuck — get a human at smb_xyz to call me back" -> call escalate_to_human({"smb_id": "smb_xyz", "reason": "agent_blocked", "summary": "Cannot resolve via automated channels"})
WHEN TO USE: Use when automated resolution has failed after channel-fallback exhaustion, when the task requires human judgment, or when the customer has explicitly requested human contact. WHEN NOT TO USE: Do not use as a first resort. Escalate only after automated resolution attempts. COST: $0.2 per_escalation LATENCY: ~2000ms EXECUTION: async_by_default (use get_outcome to retrieve result)
| Name | Required | Description | Default |
|---|---|---|---|
| reason | Yes | ||
| smb_id | Yes | ||
| context | Yes | ||
| priority | No | normal |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds significant behavioral context beyond annotations: cost ($0.2 per escalation), latency (~2000ms), and execution (async_by_default, use get_outcome to retrieve result). Annotations indicate destructiveHint=true, and the description aligns by stating it hands off to a human, implying non-reversible action. No contradictions.
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 concise and well-structured: one clear statement of purpose, a relevant example, explicit usage guidelines, and cost/latency/execution notes. Every sentence adds value, and the structure is front-loaded for quick understanding.
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 (4 parameters, nested objects, no output schema), the description covers purpose, usage, behavioral details, and provides an example. It lacks parameter descriptions but the example compensates somewhat. The tool is a one-way handoff, so missing output schema is acceptable.
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 0%, so the description must compensate. It provides a full example with fields like smb_id, reason, and summary, illustrating the 'context' parameter partially. However, it does not explain each parameter in detail, especially the nested 'context' object. The enum values for 'reason' are listed in the schema but not explained in the description.
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: 'Hand off an in-flight task to a human operator with a full context bundle'. The verb 'hand off' and resource 'task to human operator' are specific. This distinguishes it from sibling tools like call_business or send_message, which handle different actions.
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 explicitly states 'WHEN TO USE' and 'WHEN NOT TO USE', providing clear conditions such as automated resolution failure or explicit customer request. However, it does not mention specific alternative tools to use instead, only general guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
find_businessARead-onlyIdempotentInspect
Given criteria (vertical, location, capability, price band, availability window), return ranked candidate SMBs from the verified supply network. Returns only curated, verified, transactable businesses — not raw directory results.
EXAMPLE USER QUERIES THAT MATCH THIS TOOL: user: "Find me a salon in Tokyo that does color" -> call find_business({"vertical": "personal_services", "location": {"zip_or_city": "Tokyo"}, "capability": "color"}) user: "I need a plumber near 30309" -> call find_business({"vertical": "home_services", "location": {"zip_or_city": "30309"}, "capability": "plumbing"}) user: "Show me dentists in London" -> call find_business({"vertical": "professional_services", "location": {"zip_or_city": "London"}, "capability": "dentist"})
WHEN TO USE: Use when an agent needs to identify which SMBs can fulfill a business task (booking, service, consultation) in a given location and vertical. Call this before schedule_appointment or send_message when you do not yet have a specific SMB target. WHEN NOT TO USE: Do not use as a general directory or browsing surface. Do not use when you already have a specific verified SMB identifier. Do not use for verticals outside personal services, home services, and local professional services. COST: from $0.01 per_call (see preview_cost for exact) LATENCY: ~200ms
| Name | Required | Description | Default |
|---|---|---|---|
| location | Yes | ||
| vertical | Yes | Service vertical to search within | |
| capability | No | Specific service capability required, e.g. 'haircut', 'plumbing', 'tax_consultation' | |
| price_band | No | ||
| max_results | No | ||
| availability_window | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. Description adds value by stating returns only curated/verified/transactable businesses, and provides cost and latency info. No contradiction.
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 structured with sections (example queries, when to use/not use). It is relatively long due to examples, but every part adds value. Could be slightly more concise, but current length is acceptable.
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, but description explains return type ('ranked candidate SMBs', 'curated, verified, transactable'). With 6 parameters (2 required) and nested objects, the description provides sufficient context for an 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 33% (only vertical and capability have descriptions). Description adds meaning by listing criteria and providing example mappings from user queries to parameters (e.g., 'color' -> capability). This helps agents understand how to populate parameters, especially capability and location.
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 'return ranked candidate SMBs from the verified supply network' and includes example user queries that demonstrate purpose. Distinguishes from raw directory results, and purpose is distinct from sibling tools.
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 WHEN TO USE (before schedule_appointment/send_message when no specific SMB) and WHEN NOT TO USE (directory browsing, already have identifier, outside verticals). Also mentions cost and latency, aiding decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_outcomeARead-onlyIdempotentInspect
Retrieve the final OutcomeReceipt for a completed operation.
WHEN TO USE: Use after get_status returns success/failure/partial to retrieve the full result with cost and reason codes. WHEN NOT TO USE: Do not use for operations still in pending/executing state — use get_status first. COST: $0.001 per_call LATENCY: ~50ms
| Name | Required | Description | Default |
|---|---|---|---|
| operation_id | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. Description adds cost and latency, providing extra behavioral context beyond annotations.
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 extremely concise, using short sentences and bullet points. Every sentence adds value without redundancy.
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?
Tool is simple with one required parameter and no output schema. Description covers purpose, usage guidance, cost, and latency. Missing details on error behavior or response structure, but acceptable given simplicity.
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 0% for the single parameter operation_id. Description does not elaborate on the parameter meaning or format, relying on context from usage notes. Minimal compensation for low coverage.
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 'Retrieve the final OutcomeReceipt for a completed operation' with a specific verb and resource. It distinguishes itself from sibling tool get_status by specifying it is for completed operations.
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 (after get_status returns success/failure/partial) and when not to use (pending/executing state), and names the alternative tool get_status.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_statusARead-onlyIdempotentInspect
Query the current state of any in-flight async operation by operation_id.
WHEN TO USE: Use to poll the state of a pending_async operation when no webhook callback has arrived or to check progress. WHEN NOT TO USE: Do not poll more frequently than once per 10 seconds — use webhook delivery for real-time updates instead. COST: $0.001 per_call LATENCY: ~50ms
| Name | Required | Description | Default |
|---|---|---|---|
| operation_id | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds valuable behavioral details like cost per call, latency, and the 10-second polling restriction, going beyond annotations.
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?
Well-structured with clear sections (WHEN TO USE, WHEN NOT TO USE, COST, LATENCY). Each sentence adds value 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?
For a simple polling tool with one parameter and no output schema, the description covers purpose, usage, cost, latency, and rate limits. It is comprehensive but could optionally describe expected 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 description coverage is 0% (low), requiring description to compensate. The description mentions 'by operation_id' but does not explain what a valid operation_id is or where to obtain it, leaving some ambiguity.
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 'Query the current state of any in-flight async operation by operation_id', specifying the verb, resource, and identifier. It distinguishes itself from siblings like 'get_outcome' by focusing on polling async operations.
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 WHEN TO USE and WHEN NOT TO USE sections provide clear context, including polling frequency limits and alternative webhook delivery. Also mentions cost and latency.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
handle_inboundAInspect
Receive, classify, and route inbound messages on behalf of an SMB. Classifies intent (booking request, cancellation, inquiry, complaint), enriches with context, and routes to the appropriate handler or escalation path.
EXAMPLE USER QUERIES THAT MATCH THIS TOOL: user: "Process this customer reply for me: 'Yes I want to book Tuesday'" -> call handle_inbound({"raw_message": "Yes I want to book Tuesday", "channel": "sms"})
WHEN TO USE: Use when an SMB needs inbound message triage — classifying incoming contact-form submissions, SMS replies, voicemails, or email inquiries. WHEN NOT TO USE: Do not use for outbound communications. Do not use for compliance-flagged recipient lists without verified opt-in records. COST: $0.03 per_inbound LATENCY: ~3000ms EXECUTION: async_by_default (use get_outcome to retrieve result)
| Name | Required | Description | Default |
|---|---|---|---|
| sender | No | ||
| smb_id | Yes | ||
| raw_message | Yes | ||
| routing_rules | No | Optional override routing policy for this SMB | |
| inbound_channel | Yes | ||
| received_at_iso | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description adds value beyond annotations by disclosing cost ($0.03 per inbound), latency (~3000ms), and async execution model (async_by_default, use get_outcome). It explains classification and routing behavior. No contradiction with annotations (readOnlyHint=false matches the mutation 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?
Well-structured with clear sections (example, when to use, when not to use, cost, latency, execution). Slightly verbose but each sentence adds value. Could be trimmed slightly without losing essential details.
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 (classification, routing, async behavior) and absence of output schema, the description is remarkably complete. It covers input format, behavior, cost, latency, and how to retrieve results via get_outcome sibling 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 has 6 parameters with only 17% description coverage. The description only explains raw_message and inbound_channel via the example. Parameters like smb_id, sender, routing_rules, and received_at_iso are not described in text, leaving gaps for the agent.
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: 'Receive, classify, and route inbound messages on behalf of an SMB.' It lists specific intents (booking request, cancellation, inquiry, complaint) and provides a concrete example, differentiating it from sibling tools like send_message which are outbound.
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 'WHEN TO USE' and 'WHEN NOT TO USE' sections provide clear guidance. It specifies inbound message triage scenarios and explicitly advises against outbound communications or compliance-flagged lists without verified opt-in records.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
import_booking_urlAIdempotentInspect
Turn ANY public booking URL (Cal.com, Calendly, Doctolib, Booksy, Fresha, OpenTable, Setmore, Square, Acuity, Schedulista, Squarespace, BookMyCity) into a callable smb_id you can immediately use with schedule_appointment, send_message, or capture_lead. Idempotent — calling twice returns the same smb_id.
EXAMPLE USER QUERIES THAT MATCH THIS TOOL: user: "Book me a haircut at https://cal.com/jane-salon" -> call import_booking_url({"booking_url": "https://cal.com/jane-salon", "vertical": "personal_services"}) -> then schedule_appointment({"smb_id": "", "action": "book"}) user: "Schedule with this dentist: https://www.doctolib.fr/dentiste/paris/jean-dupont" -> call import_booking_url({"booking_url": "https://www.doctolib.fr/dentiste/paris/jean-dupont"}) user: "Reserve a table at https://www.opentable.com/r/acme-bistro" -> call import_booking_url({"booking_url": "https://www.opentable.com/r/acme-bistro", "vertical": "restaurants"})
WHEN TO USE: Call this FIRST whenever the user provides a specific booking URL (cal.com/handle, calendly.com/handle/event, doctolib.fr/..., booksy.com/..., opentable.com/r/..., etc.). User patterns that match: 'book me at https://cal.com/...', 'schedule with calendly.com/jane/intro', 'reserve a table at opentable.com/r/...', 'I want to book this dentist: https://www.doctolib.fr/...'. After importing, the returned smb_id can be passed straight to schedule_appointment. WHEN NOT TO USE: Do not use if the user only describes a business by name without a URL — call find_business instead. Do not use for arbitrary websites that are not on the supported booking-platform list (use /supply/platforms to see all 12). COST: $0.005 per_call LATENCY: ~600ms
| Name | Required | Description | Default |
|---|---|---|---|
| vertical | No | Best-guess vertical. If omitted, inferred from the platform (e.g., Doctolib -> healthcare, OpenTable -> restaurants). | |
| booking_url | Yes | Full URL the user supplied. Must point at one of the 12 supported booking platforms; auto-detected from the host. | |
| capabilities | No | Free-form capability tags (e.g., ['haircut','color','blowdry']). | |
| country_code | No | ISO 3166-1 alpha-2 (e.g. 'US', 'FR'). Used for compliance routing on later send_message calls. | |
| business_name | No | Optional override. If omitted, the business name is auto-extracted from the page's <title> or og:title. | |
| contact_email | No | Optional. | |
| contact_phone | No | Optional. If omitted, the platform integration handles outreach. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide idempotentHint=true and destructiveHint=false. The description reinforces idempotency and adds cost ($0.005 per call) and latency (~600ms), which are useful behavioral details beyond annotations.
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 well-structured with clear sections, front-loaded with core purpose. Every sentence adds value, and examples and usage guidelines are efficiently presented.
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?
The tool has 7 parameters and no output schema. The description explains the return value (smb_id) and how to use it, but does not detail the full response structure. For an agent, it is mostly complete, missing only explicit output 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 description coverage is 100%, so baseline is 3. The description does not add significant parameter semantics beyond the schema, but it illustrates usage via examples. No extra value beyond 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 tool converts public booking URLs into an smb_id for use with other tools. It uses a specific verb-resource pairing ('Turn...into a callable smb_id') and distinguishes from sibling tools like find_business.
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 'WHEN TO USE' and 'WHEN NOT TO USE' sections provide clear context, including alternatives like find_business for non-URL queries. Example user queries further clarify matching scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
preview_costARead-onlyIdempotentInspect
Return an expected cost estimate, latency estimate, and success-probability estimate for a proposed call before execution. Accuracy SLO: actual cost within ±5% of preview.
EXAMPLE USER QUERIES THAT MATCH THIS TOOL: user: "How much will this SMS cost me?" -> call preview_cost({"operation": "send_message", "params": {"channel_preference": "sms"}}) user: "Estimate the cost of booking via voice fallback" -> call preview_cost({"operation": "schedule_appointment"})
WHEN TO USE: Use before any operation when the agent is operating under a budget constraint and needs to decide whether to proceed. WHEN NOT TO USE: Do not use in a hot loop — cache the result for at least 60 seconds if repeating the same preview. COST: $0.001 per_call LATENCY: ~100ms
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes | The same request body you would pass to the operation | |
| operation | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that the tool is a non-destructive preview (consistent with annotations), includes an accuracy SLO of ±5%, and states cost ($0.001 per call) and latency (~100ms), going beyond annotation fields.
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 concise and well-structured, using clear sections (purpose, examples, when to use, cost, latency) to convey essential information without extraneous text.
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?
While the description covers key aspects, it lacks explicit specification of the output format (e.g., whether a JSON object is returned) and does not address error scenarios. Given the absence of an output schema, a bit more detail would be ideal.
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?
With 50% schema description coverage, the description adds value by providing concrete examples for 'operation' (e.g., 'send_message') and context for 'params' (same as request body). However, explicit parameter meanings are partially clarified.
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 returns expected cost, latency, and success-probability estimates. Examples of user queries match the tool's purpose, and it is distinct from sibling tools like send_message or schedule_appointment.
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 WHEN TO USE and WHEN NOT TO USE sections guide the agent: use before operations under budget constraints and avoid hot loops by caching results for 60 seconds. Also provides cost and latency details.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
schedule_appointmentADestructiveInspect
Availability lookup, hold, confirm, reschedule, or cancel appointments with an SMB. Routes through the SMB's native booking system if available, falls back to voice AI or web form.
EXAMPLE USER QUERIES THAT MATCH THIS TOOL: user: "Book the haircut for next Tuesday at 3pm" -> call schedule_appointment({"smb_id": "smb_imp_abc", "action": "book", "service": "haircut"}) user: "Cancel my Friday appointment at smb_xyz" -> call schedule_appointment({"smb_id": "smb_xyz", "action": "cancel"}) user: "Reschedule my dental cleaning to next week" -> call schedule_appointment({"smb_id": "smb_imp_xyz", "action": "reschedule"})
WHEN TO USE: Use when an agent needs to book, reschedule, or cancel a specific appointment with a specific SMB. Requires a verified smb_id. WHEN NOT TO USE: Do not use for bulk scheduling. Do not use without a verified SMB — call find_business and verify_business first if needed. COST: from $0.15 per_booking_attempt (see preview_cost for exact) LATENCY: ~5000ms EXECUTION: async_by_default (use get_outcome to retrieve result)
| Name | Required | Description | Default |
|---|---|---|---|
| notes | No | ||
| action | Yes | ||
| smb_id | Yes | ||
| service | No | ||
| customer | No | ||
| requested_time | No | ||
| existing_appointment_id | No | Required for reschedule/cancel |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate destructive, read-write behavior. Description adds cost, latency, async execution, and routing details. No contradiction with annotations; description enriches understanding beyond structured fields.
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?
Well-structured with clear sections (DESCRIPTION, EXAMPLES, WHEN TO USE, etc.). Front-loaded and each section adds value. Slightly verbose due to examples and cost/latency details, but overall 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?
Covers overall purpose, usage conditions, and operational traits (cost, latency, async). Lacks parameter-level detail and return value description (no output schema). Adequate for typical use but not fully comprehensive.
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 only 14%; description does not systematically explain parameters. However, examples illustrate usage of smb_id, action, service, and existing_appointment_id. Partial compensation but insufficient for all 7 parameters.
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 explicitly states the tool's purpose: 'Availability lookup, hold, confirm, reschedule, or cancel appointments'. It differentiates from siblings like find_business and verify_business through the WHEN TO USE/WHEN NOT TO USE sections and example queries.
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 sections, specifying prerequisites (verified smb_id) and exclusions (bulk scheduling). Also mentions fallback behavior and references sibling tools for verifications.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
self_testARead-onlyIdempotentInspect
Live capability probe that verifies the service is healthy, each claimed operation is reachable, and supply network size is current. Use to verify integration before production use.
EXAMPLE USER QUERIES THAT MATCH THIS TOOL: user: "Run a health check before I send the broadcast" -> call self_test({})
WHEN TO USE: Use at agent startup, before high-stakes task sequences, or after receiving unexpected errors to check if the service is degraded. WHEN NOT TO USE: Do not call more than once per minute in production. COST: free LATENCY: ~200ms
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds useful context: it is a live probe, free, ~200ms latency, and checks supply network size. No contradictions, but annotations already cover safety.
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?
Well-structured with clear sections (example, when to use, when not, cost, latency). Slightly verbose but every sentence adds value. Could be slightly tighter without losing meaning.
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 parameters, no output schema, and good annotations, the description is fairly complete. It covers purpose, usage, cost, latency, and context. Could mention what happens if the test fails, but still adequate.
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?
Input schema has zero parameters, so baseline is 4. No parameter documentation needed. The description correctly implies no parameters are required.
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 'live capability probe' that verifies service health, operation reachability, and supply network size. It uses specific verbs and a distinct resource, differentiating it from sibling tools like get_status or get_outcome.
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 guidance on when to use (agent startup, before high-stakes tasks, after errors) and when not to use (more than once per minute). Includes an example user query and mentions cost and latency.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
send_messageADestructiveInspect
Send a message on behalf of an agent's user or an SMB across SMS, email, or voice. Five message types: transactional, reminder, follow_up, notification, marketing. Every send routes through a non-bypassable compliance gate (TCPA, GDPR, CASL, PDPL across 22 jurisdictions) that enforces opt-in consent for marketing/promotional content — marketing without recorded consent is rejected at runtime with a structured compliance_violation receipt. Channel is abstracted: specify intent and recipient; the service selects and falls back across channels.
EXAMPLE USER QUERIES THAT MATCH THIS TOOL: user: "Text the salon I'll be 10 minutes late" -> call send_message({"recipient_id": "smb_xyz", "channel_preference": "sms", "message": {"body": "Will be 10 minutes late."}, "country_code": "US"}) user: "Email the dentist about insurance" -> call send_message({"recipient_id": "smb_xyz", "channel_preference": "email", "message": {"body": "Do you accept Cigna?"}})
WHEN TO USE: Use to: (a) confirm a booking the agent just made, (b) reply to a customer who messaged the SMB first, (c) follow up on a quote the user requested, (d) send appointment reminders the SMB owes its customer, (e) send marketing messages to recipients who have opted in (with consent_record_id). The gate verifies consent on every send. WHEN NOT TO USE: Do NOT use for OTPs or critical transactional confirmations — use send_transactional_confirmation. Do NOT attempt to send marketing without a consent_record_id pointing at a real opt-in — the gate will reject the send and log a compliance_violation. Do NOT attempt bulk / list-based / drip / cold outreach — those are out of scope and the rate limiter will throttle abuse. COST: from $0.02 per_message (see preview_cost for exact) LATENCY: ~800ms EXECUTION: sync_fast (use get_outcome to retrieve result)
| Name | Required | Description | Default |
|---|---|---|---|
| content | Yes | ||
| recipient | Yes | ||
| send_at_iso | No | Schedule for future delivery; omit for immediate | |
| message_type | Yes | Intent tag for the message. Five permitted types. 'marketing' is allowed only when paired with a valid consent_record_id; the compliance gate verifies the consent at send time and rejects (compliance_violation receipt) if it's missing, expired, or revoked. | |
| preferred_channel | No | auto |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (destructiveHint=true, readOnlyHint=false), description discloses compliance gate, marketing consent requirement with rejection mechanism, rate limiting, cost per message, latency, execution mode, and result retrieval via get_outcome. No contradictions.
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?
Although lengthy, the description is well-structured with sections, examples, and bullet-like lists. All sentences are informative; no redundancy. The length is justified by tool 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?
Covers purpose, usage guidelines, behavioral traits, parameter semantics, error conditions, cost, latency, execution mode, and alternative tools. With no output schema, description sufficiently informs the agent about expected behavior and result retrieval.
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 40% (low), but description compensates by explaining message types, channel abstraction, consent_record_id for marketing, scheduling, and providing examples with parameter values. Could explicitly describe each parameter's role more clearly.
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 verb 'send', resource 'message', and scope across SMS/email/voice. Distinguishes from sibling tools like send_transactional_confirmation and handle_inbound by specifying use cases and not-to-use scenarios.
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 'WHEN TO USE' and 'WHEN NOT TO USE' sections list specific use cases (confirm booking, reply, follow-up, reminders, marketing with consent) and exclusions (OTPs, marketing without consent, bulk outreach). References sibling send_transactional_confirmation for OTPs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
send_transactional_confirmationADestructiveInspect
Idempotent transactional messages: OTPs, booking confirmations, payment receipts, cancellation notices. Guaranteed delivery via redundant channels.
EXAMPLE USER QUERIES THAT MATCH THIS TOOL: user: "Send the booking confirmation receipt to my email" -> call send_transactional_confirmation({"recipient_id": "user@example.com", "channel_preference": "email", "confirmation_type": "booking"})
WHEN TO USE: Use for any message that MUST be delivered reliably — OTPs, booking confirmations, receipts. Do not use for marketing. WHEN NOT TO USE: Do not use for marketing or promotional messages. Do not use for conversational messages. COST: $0.02 per_message LATENCY: ~500ms EXECUTION: sync_fast (use get_outcome to retrieve result)
| Name | Required | Description | Default |
|---|---|---|---|
| data | Yes | Type-specific payload; e.g., {otp_code} for otp, {appointment_time, smb_name} for booking_confirmation | |
| recipient | Yes | ||
| confirmation_type | Yes | ||
| preferred_channel | No | sms |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds useful behavioral info (cost, latency, execution mode, outcome retrieval) beyond annotations. However, it claims idempotency while the annotation sets idempotentHint=false, creating a contradiction that lowers trust.
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 concise, well-structured with clear headings, and every sentence adds value (use cases, examples, constraints, cost, latency).
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 moderate parameter count, the description covers key aspects (cost, latency, outcome retrieval) but the annotation contradiction undermines completeness slightly.
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?
With only 25% schema coverage, the description partially compensates via an example that maps to parameters, but the parameter names differ (e.g., recipient_id vs recipient). Offers helpful context for data payload.
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 explicitly states the tool is for idempotent transactional messages like OTPs, booking confirmations, payment receipts, and cancellation notices. It clearly distinguishes itself from marketing messages.
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 WHEN TO USE (reliable transactional messages) and WHEN NOT TO USE (marketing, promotional, conversational) guidelines, along with example user queries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
verify_businessARead-onlyIdempotentInspect
Confirm that an SMB is real, currently operating, and capable of the requested service. Performs a live capability probe against the business's channel.
EXAMPLE USER QUERIES THAT MATCH THIS TOOL: user: "Confirm smb_imp_abc actually does emergency plumbing" -> call verify_business({"smb_id": "smb_imp_abc", "capability_to_verify": "emergency_plumbing"})
WHEN TO USE: Use before sending communications or scheduling if you have an unverified SMB identifier, or if the agent's task requires confirmed capability (e.g., 'I need to be sure they do emergency plumbing'). WHEN NOT TO USE: Do not use if the SMB was returned from find_business within the last 24 hours — those results are already verified. COST: $0.02 per_call LATENCY: ~500ms
| Name | Required | Description | Default |
|---|---|---|---|
| smb_id | Yes | ||
| capability_to_verify | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses behavioral traits beyond annotations: live probe, cost ($0.02), latency (~500ms), and idempotent and read-only nature are already captured in annotations, but added details are valuable.
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?
Well-structured with sections and example, but could be more concise. Every sentence adds value, but the example block is slightly verbose.
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?
Addresses key contextual aspects (cost, latency, when to use), but lacks information about error states or return format. For a simple verification tool, it is mostly 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 description coverage is 0%, and the description only provides one example query without explaining parameter meanings or constraints. The parameters 'smb_id' and 'capability_to_verify' lack definitions.
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 'confirm' and resource 'SMB', includes specific actions 'live capability probe', and differentiates from sibling tool find_business by noting freshness of verification.
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 WHEN TO USE and WHEN NOT TO USE sections, directly referencing sibling tool find_business and providing clear context for decision.
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!