Skip to main content
Glama

Multiservicios services

Apply for a business to sell its services through Multiservicios

apply_as_provider

For a BUSINESS that wants to offer its own services through the Multiservicios affiliate network — not for a customer looking for a service (use request_service) and not for someone who wants to refer customers as an affiliate. It sends an application that a person reviews; it does not list the business, promise approval, or create any service.

Ask for the business name, a contact name, email, phone, the kind of service, the US states where it is offered and a short description. Ask for consent in the person's own words — "is it alright if Multiservicios contacts you about this?" — and send consent: true only once they have said so. No document, ID number or immigration status is asked for or accepted.

A successful call comes back with status: "received". Do not send it again.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
emailYesWhere we write back about the application.
phoneYesA number to reach the contact, as they write it.
localeYesThe language the person is writing in. The reply comes back in it.
statesYesTwo-letter codes of the US states where the business offers the service.
consentYesThe person has said, in their own words, that Multiservicios may contact them about this application. Ask them; never assume it.
websiteNoThe business's website, if it has one.
categoryYesThe closest kind of service. Use `other` when nothing fits.
descriptionYesWhat the business offers, to whom, and in which languages — in its own words.
contact_nameYesWho we should talk to about the application.
business_nameYesThe business's name, as its owner writes it.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
noteYes
statusYes
messageYesWhat to tell the person, in their language.

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 the write/open-world/non-idempotent/non-destructive profile; the description adds real behavioral context: a human reviews the application, it does not list the business or promise approval, it creates no service, it returns status 'received' on success, and it must not be resubmitted. It also discloses a data-collection restriction (no document, ID number or immigration status is asked for or accepted), which no structured field conveys.

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?

Front-loads the negative scoping and alternatives, then the required intake, then the outcome warning — a sensible order with no filler sentences. The middle paragraph's enumeration of fields largely mirrors the schema, which is the only mild 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?

An output schema exists, so return values need not be explained, and the description nonetheless flags the 'received' status the agent will see. With 10 params at 100% schema coverage plus annotations, the definition covers preconditions, intake, outcome and follow-up completely.

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

Parameters4/5

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

Schema coverage is 100%, so per the rubric the baseline is 3; the description earns above that by explaining how to elicit the values conversationally, how to obtain consent in the person's own words before sending consent: true, and by defining what is deliberately NOT collected. It does not add format detail beyond the schema (enum, state codes, email pattern), so it is not a 5.

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 (apply) and resource (business provider application) plus the network it targets, and explicitly names the sibling it is not for: 'not for a customer looking for a service (use request_service)'. An agent can distinguish it from request_service, my_referrals and list_services without opening any 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 explicit when-to-use (a business offering its own services) and two explicit when-not-to-use cases (customer seeking service, affiliate referring customers), each with a routing alternative. It also states the prerequisite consent flow and the follow-up rule ('Do not send it again').

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