Skip to main content
Glama

AdvocateMCP

by com.advocatemcp

Request a business quote

request_service
Idempotent

Open a quote-request form for a specific business using its public slug or provider_business_id obtained from search or the business feed. Shows the business and service catalog; does not send a request or book anything. The customer must review the form and explicitly consent before submitting. Operational access is logged.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
business_idYesExact public business slug or provider_business_id obtained from search or the business feed

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameYes
addressNo
disclosureYes
business_idYes
context_tokenYes
service_namesYes

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Changed2 schema fields changed
    • changedInput schema / properties / business_id / description
      Previous value: -"Exact provider_business_id from the business feed, also the public business slug"New value: +"Exact public business slug or provider_business_id obtained from search or the business feed"
    • changedOutput schema / required
      Previous value: -[
-  "business_id",
-  "name",
-  "address",
-  "service_names",
-  "context_token",
-  "disclosure"
-]New value: +[
+  "business_id",
+  "name",
+  "service_names",
+  "context_token",
+  "disclosure"
+]
  2. Added

TDQS

A4.5/5.0
Behavior5/5

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

The description goes well beyond annotations by disclosing that the tool only shows the business and service catalog, does not submit or book, requires explicit customer consent, and logs operational access. This gives the agent clear expectations about side effects and usage constraints.

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 concise and well-structured, front-loading the core action and identifier source, then adding key behavioral caveats in short sentences. Every sentence earns its place with no redundancy.

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?

For a single-parameter tool with a full schema description and an output schema, the description is complete. It explains when to use it, what it does and does not do, the consent requirement, and logging behavior, leaving no important gap for an agent.

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

Parameters3/5

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

The schema already fully describes business_id as an exact public slug or provider_business_id obtained from search or the business feed. The description repeats this same information without adding new parameter-level meaning, so the baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool opens a quote-request form for a specific business, using a specific identifier. It explicitly distinguishes itself from submitting a request or booking anything, which separates it from siblings like submit_quote_request and confirm_booking.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context for when to use the tool: after obtaining a business slug or provider_business_id from search or the business feed. It also implies exclusions by saying it does not send a request or book, though it does not explicitly name alternative tools.

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

All AdvocateMCP toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.9/5.0
Disambiguation3/5

The booking and quote lifecycles are generally separated well, but some boundaries are blurry: query_business_agent explicitly covers 'policies,' overlapping with get_cancellation_policy, and initiate_handoff/request_callback both route notifications through lead routing. The detailed descriptions help, but an agent could still misselect between those pairs.

Naming Consistency5/5

Every tool uses snake_case with an imperative verb + noun object pattern (get_*, list_*, request_*, reserve_*, confirm_*, submit_*, etc.). The few longer names like get_payment_handoff_url and subscribe_to_updates still follow the same predictable style.

Tool Count4/5

Fifteen tools is at the high end of the typical range, but each maps to a distinct workflow step across discovery, quotes, booking, handoff, and subscription. It feels slightly heavy because several notification/contact tools could potentially be consolidated, but it is not bloated.

Completeness3/5

The quote and booking flows are well covered from search through reserve and confirm, but there is no way to cancel or reschedule a booking, and no direct booking-status lookup beyond repeating confirm_booking. Discovery, payment handoff, and subscription flows are otherwise reasonably complete.

Resources