Skip to main content
Glama

MCC Solutions

Send a service request for the person

request_service

Send MCC Solutions a request on behalf of the person you are helping, with their name, email and phone. Only call it when the person asked you to and agreed to share those details (consent: true). Nothing is charged. Appointments: service "ron" (online notarization by video; aliases online_notary, remote_online_notarization; details: document_type, signers default 1, optional state) or "mobile_notary_nj" (mobile visit in New Jersey; details: document_type, address, city, zip, signers) are sent as a time request: put up to 3 start values from available_times in start_times, or describe times in preferred_times; the desk confirms one by email, usually within a few hours, and sends the pay link then. Exception: an online (ron) session starting at 5 PM New Jersey time or later is booked right away when it is the first start time sent, and the person gets the pay link by email. Other services (apostille_any, process_serve, recording, mobile_notary_out_of_state, loan_signing, court_filing, tax_prep and more) are service requests the desk prices and confirms. An unknown service returns the full list; if details are missing, the result lists the fields to ask for.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "service": "<service>",
      "name": "<name>",
      "email": "<email>",
      "phone": "<phone>",
      "consent": "<consent>"
    },
    "name": "request_service"
  }
}

Input Schema

NameRequiredDescriptionDefault
nameYes
emailYes
notesNo
phoneYes
companyNo
consentYestrue when the person asked you to send this and agreed to share their contact details
detailsNoService fields by key (an incomplete request returns the field list)
serviceYesService id, e.g. ron, mobile_notary_nj, apostille_any, process_serve, recording, mobile_notary_out_of_state, loan_signing, tax_prep, court_filing. An unknown id returns the list.
start_timesNoron and mobile_notary_nj: up to 3 slot start values (ISO) from available_times
preferred_timesNoTimes in words, e.g. 'Thursday after 5 PM or Friday 4-6 PM' (any time of day)

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only declare non-readOnly/openWorld/non-idempotent; the description adds substantial behavior the annotations cannot carry: nothing is charged, the desk confirms by email within hours and sends the pay link later, and the 5 PM New Jersey online-session exception is booked immediately. It also discloses the failure-mode responses (unknown service returns the list; missing details return the fields to ask for).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Zero filler sentences and the consent gate is front-loaded in the second sentence. However, the service-variant paragraph is one very long sentence with nested parentheses, which makes it harder to scan than a short list would be.

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

Completeness4/5

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

Ten parameters with a nested details object and no output schema demand a lot; the description covers request semantics, routing, timing, pricing posture, and even error responses. What is thinner is the shape of a successful response (confirmation vs. immediate booking payload), left to be discovered at call time.

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 only 50%, and the description compensates heavily: it maps service ids and aliases (ron = online_notary, remote_online_notarization), specifies which details keys each service needs, caps start_times at 3 values drawn from available_times, and clarifies preferred_times is free text for any time of day.

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?

States a specific verb and resource ('Send MCC Solutions a request on behalf of the person you are helping') and enumerates the concrete service ids the tool accepts. An agent can distinguish this from inform/list siblings like get_services_and_prices or available_times without opening the schema.

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

Usage Guidelines5/5

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

Gives an explicit when-to-call gate ('Only call it when the person asked you to and agreed... consent: true') and routes slot selection to available_times via start_times/preferred_times. It also distinguishes the two notarization flows from 'other services' and explains the fallback when the service id is unknown.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources