The Servicialo MCP server enables AI agents to discover, book, manage, and verify professional services (health, legal, education, home services, etc.) across a standardized protocol network.
Public capabilities (no authentication required):
Organization Search & Discovery: Search for organizations by vertical (e.g., kinesiology, dentistry, psychology), location, and country
Organization Details: Retrieve public info including services, providers, and booking configuration
Server Manifest: Access protocol version, name, description, and available endpoints
Service Catalog: List the public services offered by a specific organization
Availability Checking: Query available time slots using a 3-variable scheduler (provider ∧ client ∧ resource), filterable by service, provider, and/or physical resource
DNS-like Resolution: Resolve an organization slug to its MCP/REST endpoint and trust level
Global Resolver Search: Find registered organizations by country and service vertical
Trust Scoring: Get a trust score (0–100) and verification level (unverified / declared / vouched / verified) plus last activity
A2A Agent Card: Fetch an organization's Agent Card to discover its booking capabilities for agent-to-agent interactions
Onboarding Guide: Access the complete getting-started guide as structured data
Authenticated capabilities (requires SERVICIALO_API_KEY and SERVICIALO_ORG_ID):
Booking, confirming, rescheduling, and canceling services
Check-in/out with GPS and evidence recording
Service documentation and payment handling
Physical resource management (rooms, equipment)
Registering organizations and updating endpoints in the global resolver
The protocol-level MCP interface for the Servicialo standard — the destination layer for human services in the age of AI agents. HTTP made documents addressable. Servicialo makes services addressable. MCP and A2A are the transport. Servicialo is the destination agents arrive at.
This package is the protocol-level MCP interface for any Servicialo-compatible backend — not a connector to a specific platform. Coordinalo is the reference implementation (and the default), but you can connect your own backend.
Protocol: v0.10 (draft) · Spec: servicialo.com/spec · This package versions independently of the protocol (
0.9.xuntil 1.0).
The Servicialo protocol is entering its stabilization phase. The first formal RFC cohort is open for comments for a minimum 4-week window before moving to Final Comment Period. Until 1.0, releases remain 0.9.x patches, and any breaking protocol change requires its merged RFC and prior communication.
RFC cohort (PR #13): servicialo/mcp-server#13
1.0 Process / Discussion: servicialo/mcp-server#14
Milestone | Status |
RFC-001 — RFC Process & Deprecation Policy | Draft / Open for Comment |
RFC-002 — Prepayment & Client Credit Balance | Draft / Open for Comment |
RFC-003 — Refunds & Credit Notes (Forward-Only Ledger) | Draft / Open for Comment |
RFC-004 — PII / PHI Classification Framework | Draft / Open for Comment |
Stable Core declaration (8 dimensions · 6+3 cycle · 6 flows · 7 principles) with backwards-compat guarantees | Pending |
≥ 3 independent implementations in production | In progress |
Related MCP server: maiat-protocol
@servicialo/mcp-server → interfaz MCP a nivel de protocolo
↓ se conecta a cualquier backend compatible con Servicialo
Coordinalo → implementación de referencia (default)
Tu implementación → trae tu propio backendAI agents can browse the web, write code, and hold conversations. But ask one to book a kinesiology session, verify it happened, and process the payment — and it falls apart.
Today, every platform is a silo. There is no standard for:
Discovery — which provider, in which organization, offers what I need?
Identity — on whose behalf is this agent acting, and what is it authorized to do?
Lifecycle — what state is this service in? Who confirmed? Who attended?
Proof of delivery — did the session actually happen? For how long? Where?
Settlement — how much, to whom, under what contractual terms?
Without a shared protocol, every integration is handcrafted. Every agent-platform connection is a custom API. This doesn't scale.
Servicialo is an open protocol, not a platform. It defines how professional services move through their lifecycle — from discovery to payment — in a way that any AI agent or platform can implement.
The relationship is like HTTP with Apache, or SMTP with Gmail: Servicialo defines the rules, implementations bring them to life.
The protocol models each service through 8 dimensions, a 6+3 lifecycle (6 core states + 3 optional financial ones), 6 exception flows, and 7 fundamental principles — universal across verticals (health, legal, education, home services):
Solicitado → Agendado → Confirmado → En Curso → Completado → Documentado → Facturado → Cobrado → VerificadoAny service, in any vertical, follows this sequence. Vertical-specific logic lives inside each state, but the state machine is invariant.
This package exposes the Servicialo protocol as 40 MCP tools organized by the 7 phases of a service's lifecycle (0–6, including the discovery resolver — analogous to DNS, over HTTP), plus resource management, resolver administration, network intelligence (market.*), and cold-start discovery (registry.list_* to learn the taxonomy without knowing it beforehand). An agent doesn't call endpoints by database entity — it follows the natural flow of coordinating a service.
Tool | Description |
| Resolve an orgSlug to its MCP/REST endpoint and confidence level (equivalent to a DNS lookup) |
| Search registered organizations by country and vertical in the global resolver |
| Get an organization's trust score (score 0-100, level, last activity) |
Tool | Description |
| Search organizations by vertical, location, country |
| Get public details: services, providers, booking configuration |
| Get server manifest: capabilities, protocol version, organization metadata |
| Check availability (3 variables: provider ∧ client ∧ resource) |
| List an organization's public service catalog |
| Get an organization's A2A Agent Card for inter-agent discovery |
Tool | Description | Scopes |
| Get a service's 8 dimensions |
|
| Get contract terms: required evidence, cancellation policy, dispute window |
|
Tool | Description | Scopes |
| Resolve client identity by email/phone — look up or create in a single call |
|
| Book session → |
|
| Confirm booked session → |
|
Tool | Description | Scopes |
| Get current state, available transitions, and history |
|
| Execute a state transition with evidence |
|
| Reschedule to a new date/time (contractual policy may apply) |
|
| Cancel session (contract cancellation policy applies) |
|
Tool | Description | Scopes |
| Check-in with GPS + timestamp → |
|
| Check-out with GPS + timestamp → |
|
| Record evidence: |
|
Tool | Description | Scopes |
| Generate service record (clinical note, inspection report, etc.) → |
|
| Create charge for documented service → |
|
| Record payment received against a sale |
|
| Get payment status for a sale or client account balance |
|
Tool | Description | Scopes |
| List an organization's physical resources |
|
| Get resource details with its availability slots |
|
| Create a new physical resource (room, box, equipment) |
|
| Update resource (semantic patch) |
|
| Deactivate resource (soft delete: |
|
| Check resource availability by date range |
|
Tool | Description | Scopes |
| Register organization in the global resolver with MCP/REST endpoints |
|
| Update registered endpoints (portability between backends) |
|
| Send heartbeat to the resolver indicating the node is active |
|
Anonymized market benchmarks on operational telemetry contributed by nodes. Contribute-to-access policy (k-anonymity ≥ 5):
Tool | Description |
| List segments |
| Get the bucket distribution of a segment (e.g. share of each |
Cold-start: the agent does not need to know the protocol taxonomy in advance. Start here if it arrives without context:
Tool | Description |
| Verticals present on the network (declared + observed in 30d telemetry) |
| ISO 3166-1 alpha-2 countries/regions with activity on the network |
| Catalog of the 4 operational telemetry event types + their |
Tool | Description |
| Get the 5 quickstart steps as structured JSON — onboarding for agents with no prior context |
npx -y @servicialo/mcp-serverDiscovery mode — 15 public tools, no credentials. Try it right away:
{
"tool": "registry.search",
"arguments": { "vertical": "kinesiologia", "location": "santiago" }
}Register your organization at coordinalo.com/signup. Coordinalo is the reference implementation of the Servicialo protocol.
In Coordinalo: Settings → Servicialo → Generate MCP credentials. You will get two values:
SERVICIALO_ORG_ID — your organization's slug (e.g. clinica-dental-sur)
SERVICIALO_API_KEY — bearer token for authentication
Add to the configuration of Claude Desktop, Cursor, or any MCP client:
{
"mcpServers": {
"servicialo": {
"command": "npx",
"args": ["-y", "@servicialo/mcp-server"],
"env": {
"SERVICIALO_API_KEY": "<tu_api_key>",
"SERVICIALO_ORG_ID": "<tu_org_slug>"
}
}
}
}Omit the env block for discovery-only mode (15 public tools).
In Coordinalo: Settings → Servicialo → Publish. Your organization appears at servicialo.com/network and is discoverable by other agents.
Tip: An agent can get these 5 steps as structured JSON by calling the
docs.quickstarttool.
The Servicialo network is the global registry of organizations implementing the protocol. Each authenticated node sends a periodic heartbeat, and any agent can discover organizations by country, vertical, and trust score.
Explore the network: servicialo.com/network
Search by vertical: registry.search({ vertical: "kinesiologia", country: "cl" })
Resolve an org: resolve.lookup({ org_slug: "clinica-dental-sur" })
Variable | Required | Default | Description |
| No | — | Bearer token. Enables authenticated mode (25 additional tools = 40 total) |
| No | — | Organization slug. Enables authenticated mode |
| No |
| API endpoint of the Servicialo-compatible platform |
| No |
| Backend adapter: |
| No |
| Set to |
SERVICIALO_API_KEY and SERVICIALO_ORG_ID must be configured together. If only one is present, the server falls back to discovery mode with a warning.
These variables enable your node to contribute anonymized events to the network benchmarks and access real-time data (tier 2). See docs/telemetry-operational.md:
Variable | Required | Default | Description |
| No |
| Your vertical (e.g. |
| No |
| ISO 3166-1 alpha-2 of the operating country. Events are tagged with this |
| No | — | Your node's |
| No |
| Set to |
| No |
| Protocol version declared in emitted events |
| No |
| Operational telemetry receiving endpoint (only change for testing) |
How this relates to benchmark tiers: a node emitting ≥ 50 operational events in 30 days automatically reaches tier 2 and
market.get_benchmarkreturns real-time data (instead of the default tier 0/1 with 90-day delay). Full policy: GOVERNANCE.md#contribute-to-access-policy-v01.
Credentials are obtained at coordinalo.com → Settings → Servicialo → Generate MCP credentials.
This MCP server supports any Servicialo-compatible backend through the pluggable adapter layer. Two adapters are included:
coordinalo (default) — connects to a Coordinalo/Digitalo backend with org-scoped routes under /api/organizations/{orgId}.
http — connects to any implementation exposing the canonical endpoints of HTTP_PROFILE.md under /v1/*.
Step 1. Implement the REST endpoints defined in HTTP_PROFILE.md on your platform.
Step 2. Configure the MCP server to use the HTTP adapter:
SERVICIALO_ADAPTER=http \
SERVICIALO_BASE_URL=https://tu-plataforma.com \
SERVICIALO_API_KEY=tu_key \
npx -y @servicialo/mcp-serverStep 3. Add to your MCP client configuration:
{
"mcpServers": {
"servicialo": {
"command": "npx",
"args": ["-y", "@servicialo/mcp-server"],
"env": {
"SERVICIALO_ADAPTER": "http",
"SERVICIALO_BASE_URL": "https://tu-plataforma.com",
"SERVICIALO_API_KEY": "tu_api_key",
"SERVICIALO_ORG_ID": "tu_org_id"
}
}
}
}The HTTP adapter translates internal routes to canonical /v1/* endpoints and sends the organization context via the X-Servicialo-Org header. See HTTP_PROFILE.md for the full REST contract.
The protocol treats AI agents as first-class actors — but never trusts them implicitly. Every agent action requires a ServiceMandate: an explicit delegation of capability from a human principal to an agent.
A human (professional, patient, or organization) issues a mandate to an agent
The mandate specifies on whose behalf the agent acts, what it can do (scopes), and for how long
On each tool call, the MCP server validates the mandate against 8 checks before executing
Each action produces an audit entry — success or failure
{
"mandate_id": "550e8400-e29b-41d4-a716-446655440000",
"principal_id": "dra_barbara",
"principal_type": "professional",
"agent_id": "agent_booking_bot",
"agent_name": "Asistente de Agendamiento",
"acting_for": "professional",
"context": "org:clinica-kinesia",
"scopes": ["schedule:read", "schedule:write", "patient:write"],
"constraints": {
"max_actions_per_day": 50,
"allowed_hours": {
"start": "08:00",
"end": "20:00",
"timezone": "America/Santiago"
},
"require_confirmation_above": {
"amount": 100000,
"currency": "CLP"
}
},
"issued_at": "2026-03-01T00:00:00Z",
"expires_at": "2026-06-01T00:00:00Z",
"status": "active"
}When actor.type is "agent", include the mandate_id:
{
"tool": "scheduling.book",
"arguments": {
"service_id": "srv_123",
"provider_id": "prov_111",
"client_id": "cli_789",
"starts_at": "2026-03-03T10:00:00",
"actor": {
"type": "agent",
"id": "agent_booking_bot",
"mandate_id": "550e8400-e29b-41d4-a716-446655440000"
}
}
}Each agent tool call is validated against:
# | Check | What it prevents |
1 | Status — mandate must be | Use of revoked or expired mandates |
2 | Temporal validity — | Time-based attacks |
3 | Agent identity — | Agent impersonation |
4 | Scope coverage — mandate scopes cover the tool's requirements | Privilege escalation |
5 | Context — mandate context matches the request | Cross-org access to data |
6 | Conflict of interest — agent cannot act for both parties | Dual-agency violations |
7 | Restrictions — allowed schedules, daily limits, financial thresholds | Over-autonomous agents |
8 | Audit — every action logged with sanitized inputs | Non-repudiation |
Non-agent actors (client, provider, organization) do not go through mandate validation.
Agents can search the registry and match providers to a patient's needs using structured queries.
{
"tool": "registry.search",
"arguments": {
"vertical": "kinesiologia",
"location": "santiago",
"country": "cl"
}
}Returns organizations matching their services and providers.
{
"tool": "scheduling.check_availability",
"arguments": {
"org_slug": "clinica-kinesia",
"service_id": "srv_rehab_pelvica",
"provider_id": "prov_111",
"date_from": "2026-03-10",
"date_to": "2026-03-14"
}
}The 3-variable scheduler checks provider, client, and physical resource availability simultaneously.
1. registry.search({ vertical: "kinesiologia", location: "santiago" })
→ encuentra org "clinica-kinesia"
2. services.list({ org_slug: "clinica-kinesia" })
→ lista servicios disponibles
3. scheduling.check_availability({ org_slug: "clinica-kinesia", date_from: "2026-03-10", date_to: "2026-03-14" })
→ retorna slots disponibles
4. contract.get({ service_id: "srv_123", org_id: "org_456" })
→ cancelación: 0% si >24h, 50% si 2-24h, 100% si <2h
→ evidencia requerida: check_in + check_out + registro_clinico
5. clients.get_or_create({ email: "maria@mail.com", name: "Maria", last_name: "Lopez" })
→ client_id: "cli_789"
6. scheduling.book({ service_id: "srv_123", provider_id: "prov_111", client_id: "cli_789", starts_at: "2026-03-12T10:00:00" })
→ session_id: "ses_001", estado: "solicitado"
7. scheduling.confirm({ session_id: "ses_001" })
→ estado: "confirmado"
8. delivery.checkin({ session_id: "ses_001", location: { lat: -33.45, lng: -70.66 } })
→ estado: "en_curso"
9. delivery.checkout({ session_id: "ses_001", location: { lat: -33.45, lng: -70.66 } })
→ estado: "entregado", duración: 42min
10. documentation.create({ session_id: "ses_001", content: "Sesión de rehabilitación de piso pélvico..." })
→ estado: "documentado"
11. payments.create_sale({ client_id: "cli_789", service_id: "srv_123", unit_price: 35000 })
→ sale_id: "sale_001", estado: "cobrado"
12. lifecycle.transition({ session_id: "ses_001", to_state: "verified" })
→ estado: "verificado" ✓The full Servicialo protocol specification is available at:
Repository: github.com/servicialo/protocol
Website: servicialo.com
Current stable version: 0.9
JSON Schemas: service.schema.json, service-order.schema.json, service-mandate.schema.json, resolution.schema.json, servicialo-config.schema.json
The spec covers the 8 service dimensions, the 6+3 lifecycle, 6 exception flows, 7 fundamental principles, the two-entity architecture (atomic Service + Service Order), the Delegated Agency Model, DNS resolution, and A2A interoperability.
Digitalo is the first production implementation of the Servicialo protocol, operating in healthcare in Chile. It implements the full lifecycle — from provider discovery to payment settlement — and serves as a validation ground for the protocol's evolution.
This MCP server connects to any Servicialo-compatible backend via SERVICIALO_BASE_URL. Digitalo is one such backend. The protocol is designed so that any CRM, HIS, or platform can implement it as a sovereign node.
Servicialo follows semantic versioning for the protocol specification:
Patch (0.7.x) — clarifications, typo fixes, non-breaking additions
Minor (0.x.0) — new optional fields, new tool definitions, new exception flows
Major (x.0.0) — breaking changes to schemas, state machine, or core semantics
Open an issue describing the problem and the proposed solution
For significant changes, write an RFC in spec/ with the section number it affects
Protocol changes require at least one reference implementation before merge
Schema changes must include updated JSON Schema and Zod types in the MCP server
Vertical-specific evidence requirements (beyond healthcare)
Multi-language support for lifecycle state names
Inter-node federation (how two Servicialo implementations interoperate)
Agent SDK patterns for Python and TypeScript
On startup, the MCP server sends a single anonymous POST to https://servicialo.com/api/telemetry/instance with:
{
"event": "node_initialized",
"version": "0.9.8",
"node_id": "a1b2c3d4-...",
"ts": 1711300000000
}Field | Description |
| Always |
| Package version |
| Persistent UUID stored in |
| Timestamp in milliseconds |
That is all that is sent. No organization information, API keys, patient data, or any personal identifiers are transmitted. The IP is hashed (SHA-256) on the server before being stored. The ping is fire-and-forget: if it fails, the error is silently discarded and never blocks server operation.
The first time it runs with telemetry enabled, the server prints a notice to stderr indicating what is sent and how to disable it.
SERVICIALO_TELEMETRY=false npx -y @servicialo/mcp-serverOr in the MCP configuration:
{
"env": {
"SERVICIALO_TELEMETRY": "false"
}
}More details: servicialo.com/network
When you install @servicialo/mcp-server, your node automatically registers in the network telemetry. This helps the ecosystem measure real protocol adoption — without collecting personal data or data about your clients.
Telemetry reports only: package version, a persistent node UUID, and an IP hash (for approximate geolocation — we do not store IPs). You can disable it at any time with SERVICIALO_TELEMETRY=false.
The server writes two informational notices to stderr — never to stdout, which carries JSON-RPC and would be corrupted by anything else:
The RFC-005 comment window, while it remains open. It has built-in expiration: it stops printing after 2026-09-13, the close of the final comment period. A node installed in October does not see a dead announcement.
If your node is anonymous, how to identify it (below).
Both are printed once per process and are silenced with SERVICIALO_QUIET=true:
{
"env": {
"SERVICIALO_QUIET": "true"
}
}That variable affects only these two notices. The mode banner and the first-run telemetry notice keep their previous behavior.
By default your node is anonymous: the ping carries event, version, node_id, and timestamp, nothing else. If you operate your own implementation of the protocol, these three optional variables identify it and nominate it as a verified implementor:
SERVICIALO_IMPL_NAME="Mi Plataforma" # Nombre de tu implementación
SERVICIALO_IMPL_URL="https://example.com" # Tu sitio web o repositorio
SERVICIALO_IMPL_CONTACT="admin@example.com" # Email de contacto — se hashea antes de salirVariable | What travels | What does not travel |
| The plain-text name, as | — |
| The URL in plain text, as | — |
| Only | The email. It never leaves the host, is not logged, is not stored, and is not shown anywhere. |
With no variables configured, none of these fields appear in the ping. An unconfigured node behaves exactly the same as before this version.
anonymous → pending → verified
anonymous — no variables configured. This is the default state, and an anonymous node is fully conformant.
pending — the first time a new impl_name appears, the record is left pending and the team receives a notification with the name, URL, and country. The contact hash is not in that notification, and could not be: it would be useless.
verified — after manual review against the conformance checklist, your implementation appears on servicialo.com/implementors with its level and the number of hosts it reports.
Verification is manual today. The automated conformance suite is on the roadmap; it is not a current capability.
What the contact hash is for — and what it is not for. It is a one-way digest: no one can write to you from it, and configuring it does not subscribe you to any announcement or list. It serves the opposite purpose: when you write about your implementation, the hash of your email confirms that you are the operator who sent those pings.
Remove the variables from your MCP configuration (or unset SERVICIALO_IMPL_NAME SERVICIALO_IMPL_URL SERVICIALO_IMPL_CONTACT) and restart the server. The next ping is anonymous again, with no identity fields. Pings already sent retain what they sent; to request deletion of existing records, open an issue in the repository.
The registry emits benchmark.weekly_snapshot every Monday at 00:00 UTC to subscribed endpoints, with a payload signed by HMAC-SHA256. These three variables do not enable it. It requires a registry entry and an explicit subscription via the Webhooks API, and it delivers benchmark data, not protocol announcements.
Apache-2.0 — any implementation, commercial or not, is welcome. See LICENSE.
Get the A2A (Agent-to-Agent) Agent Card for an organization, enabling inter-agent discovery. Use this when your agent needs to communicate with another agent managing this organization — the card declares supported capabilities, endpoints, and authentication requirements. Do NOT use for human-facing discovery (use registry.get_organization) or service listing (use services.list). Returns a JSON-LD Agent Card following the A2A v0.3 specification.
| Name | Required | Description | Default |
|---|---|---|---|
| org_slug | Yes | Organization slug (e.g. "clinica-dental-sur") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description takes full responsibility for behavioral disclosure. It indicates the return format: 'Returns a JSON-LD Agent Card following the A2A v0.3 specification.' It also explains the content of the card: 'declares supported capabilities, endpoints, and authentication requirements.' This gives a clear picture of what the tool does and what the agent will receive.
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 three sentences with no wasted words. The first sentence states the core purpose. The second provides usage guidelines. The third details return format and exclusions. Information is front-loaded and efficiently structured.
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 simplicity (one required string parameter, no output schema, no nested objects), the description covers all necessary aspects: purpose, usage alternatives, behavioral details, and return format. It is complete for the tool's complexity.
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?
The input schema has 100% description coverage for the single parameter 'org_slug', so the baseline is 3. The description does not add additional semantic information beyond the schema's example ('clinica-dental-sur'), but this is acceptable as the schema already provides sufficient detail.
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 'Get the A2A Agent Card for an organization, enabling inter-agent discovery.' It specifies the verb (Get), the resource (Agent Card), and the context (inter-agent discovery). It also distinguishes itself from sibling tools like registry.get_organization and services.list, which are explicitly 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 explicitly states when to use: 'when your agent needs to communicate with another agent managing this organization.' It also provides explicit alternatives: 'Do NOT use for human-facing discovery (use registry.get_organization) or service listing (use services.list).' This leaves no ambiguity about the appropriate context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the complete 5-step onboarding guide as structured JSON data. Use this when helping a new organization join the Servicialo network — covers installation, signup, credentials, MCP client config, and publishing. Do NOT use for searching services (use registry.search) or checking availability (use scheduling.check_availability). Returns step-by-step instructions, config templates, and links. No parameters required.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes what the tool returns (instructions, config templates, links) and implies a read-only operation. Lacks mention of any authentication or access requirements, but given the nature of a quickstart guide, this is a minor gap.
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 sentences, each with clear purpose: definition, usage guidance with exclusions, and output description. No wasted words, well-structured and front-loaded.
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?
Fully covers the tool's purpose, when to use, what it returns, and exclusions. No missing information given the simplicity of the tool (no params, no output schema).
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?
No parameters exist, so baseline is 4. Description correctly states 'No parameters required' and does not need to add parameter meaning.
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?
Clearly states the tool retrieves the 5-step onboarding guide as structured JSON data. Distinguishes from siblings by explicitly excluding use for searching or availability checks.
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 (helping a new organization join) and when-not-to-use with alternative tool names (registry.search, scheduling.check_availability).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the full public profile of a specific organization: services offered, providers, and booking configuration. Use this after registry.search when you have an org_slug and need detailed info before booking. Do NOT use for searching across organizations (use registry.search). Returns service catalog with prices/durations, provider list, and booking policies.
| Name | Required | Description | Default |
|---|---|---|---|
| org_slug | Yes | Slug de la organización (ej: clinica-dental-sur) | |
| country | No | País ISO 3166-1 alpha-2 (ej: cl, mx, ar). Default: cl | cl |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It implies a read operation by using 'Get' but does not explicitly state it is read-only, nor does it mention authentication, rate limits, or other behavioral traits. It does list return contents, which provides some transparency.
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 three sentences with no waste. The first sentence immediately states the purpose, the second provides usage context, and the third summarizes the return content. Perfectly front-loaded.
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 output schema and only 2 simple parameters, the description adequately covers what the tool returns (service catalog, provider list, booking policies). It also provides usage context. Slight improvement could be to mention that the response is a full profile object, but it is largely 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 100%, so the schema fully documents both parameters. The description does not add any additional meaning or context about the parameters beyond what the schema provides.
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 gets the full public profile of a specific organization, listing contents (services, providers, booking configuration). It distinguishes from sibling registry.search by explicitly saying not to use it for searching.
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?
Explicitly says when to use this tool ('after registry.search when you have an org_slug and need detailed info before booking') and when not to use it ('Do NOT use for searching across organizations'), with a named alternative (registry.search).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the Servicialo server manifest: protocol version, server name, and available capabilities. Use this to verify server identity and protocol compatibility before interacting with tools. Do NOT use for organization discovery (use registry.search) or service details (use services.list). Returns static metadata about this MCP server instance, not about any specific organization.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must fully disclose behavior. It explains the tool returns static metadata about the server instance and not about organizations. It omits details like authentication or side effects, but for a read-only, parameterless tool, this is sufficient.
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 sentences are efficient and front-loaded: purpose, usage guidance, and scope clarification. 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?
Given no parameters, no output schema, and no annotations, the description is fully complete. It clearly explains what the tool does, when to use it, and what it returns.
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?
The input schema has no parameters and 100% coverage. The description does not need to explain parameters since there are none. The baseline of 4 is appropriate as it adds context beyond the empty schema.
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 retrieves the server manifest with specific fields (protocol version, server name, capabilities) and distinguishes it from sibling tools by explicitly stating what it does not do.
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?
Explicitly says when to use (verify server identity and protocol compatibility) and when not to use, providing alternative tools (registry.search, services.list) for other purposes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for Servicialo-compatible organizations by vertical, location, and country. Use this as the primary discovery tool when a user needs a service (e.g., "find a physiotherapist in Santiago"). Do NOT use if you already have an org_slug (use registry.get_organization instead). Returns a ranked list of organizations with names, slugs, and service summaries.
| Name | Required | Description | Default |
|---|---|---|---|
| vertical | No | Vertical del servicio. Valores comunes: tecnologia, consultoria, kinesiologia, psicologia, dental, nutricion, fonoaudiologia, terapia-ocupacional, medicina, veterinaria, educacion, fitness, legal, belleza, hogar. Omitir para buscar en todas las verticales. | |
| location | No | City or district to filter by (e.g. "santiago", "providencia"). Omit for country-wide results. | |
| country | No | ISO 3166-1 alpha-2 country code (e.g. "cl", "mx", "ar"). Default: "cl" | cl |
| limit | No | Max results to return (1-100). Default: 10 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so description carries full burden. It discloses that results are ranked and returns names, slugs, and service summaries, but does not explain ranking criteria, authentication needs, rate limits, or pagination beyond the limit parameter. Adequate but not fully detailed.
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 sentences with no fluff. First sentence states purpose, second gives usage guidance, third describes output. Front-loaded 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?
No output schema, but description partially compensates by mentioning return fields (names, slugs, service summaries). However, it lacks details on response structure (e.g., array format). Overall, sufficient for a search tool with optional parameters.
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 for all 4 parameters. The description adds minimal extra meaning beyond summarizing the use case (e.g., 'by vertical, location, and country'). No new parameter details, so baseline 3 is appropriate.
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 'Search for Servicialo-compatible organizations by vertical, location, and country' with a specific verb and resource. It also distinguishes from sibling tool registry_get_organization by noting when not to use it.
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?
Explicitly says to use as primary discovery tool and provides an example ('find a physiotherapist in Santiago'). Also states not to use if org_slug is known, directing to registry_get_organization. No exclusions but clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Resolve an organization slug to its MCP/REST endpoints and trust level — the DNS of professional services. Use this when you know the org_slug and need its API endpoint before calling any other tool. Do NOT use for searching by vertical or location (use resolve.search or registry.search instead). Returns: endpoint URLs, trust score (0-100), trust level, and last heartbeat timestamp.
| Name | Required | Description | Default |
|---|---|---|---|
| org_slug | Yes | Slug de la organización (ej: clinica-dental-sur) | |
| country | No | País ISO 3166-1 alpha-2 (ej: cl, mx, ar). Default: cl | cl |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It lists returned fields (endpoint URLs, trust score, trust level, last heartbeat timestamp), adding behavioral context. Could explicitly state read-only nature, but implied.
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 sentences: purpose, usage guideline, return values. No fluff, front-loaded, 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?
No output schema, but description details return structure. Purpose, parameters (via schema), usage, and returns are covered. Fully adequate for a simple lookup 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 coverage is 100%, so baseline is 3. Description does not add extra meaning beyond schema; it implies country is for regional endpoint but doesn't elaborate. Adequate but not improved.
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 resolves an organization slug to endpoints and trust level, using a strong metaphor ('DNS of professional services'). It distinguishes itself from siblings like resolve_search and registry_search by specifying what it does vs. what it doesn't.
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?
Explicitly tells when to use (when you know org_slug and need API endpoint before other tools) and when not to use (searching by vertical/location, directing to resolve.search or registry.search).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the global Servicialo resolver for registered organizations by country and vertical. Use this for broad discovery when you need to find all organizations in a country/vertical (e.g., "what physiotherapy clinics exist in Chile?"). Do NOT use if you already have an org_slug (use resolve.lookup instead). Unlike registry.search, this queries the DNS-level resolver and returns endpoint URLs + trust levels.
| Name | Required | Description | Default |
|---|---|---|---|
| country | No | País ISO 3166-1 alpha-2 (ej: cl, mx, ar). Default: cl | cl |
| vertical | No | Vertical del servicio. Valores comunes: tecnologia, consultoria, kinesiologia, psicologia, dental, nutricion, fonoaudiologia, terapia-ocupacional, medicina, veterinaria, educacion, fitness, legal, belleza, hogar. Omitir para buscar en todas las verticales. | |
| limit | No | Cantidad máxima de resultados (1-100). Default: 20 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior. It mentions 'queries the DNS-level resolver and returns endpoint URLs + trust levels,' but lacks details on pagination, rate limits, or error handling. Adequate but not comprehensive.
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 sentences, each with clear purpose: functional description, usage example, and differentiation. Efficient and well-organized.
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 search tool with 3 optional params and no output schema, the description covers purpose, usage, and basic behavior. Lacks details on response format beyond 'endpoint URLs + trust levels,' but overall 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 100%, so baseline is 3. The description adds little beyond schema: it repeats default values and provides an example vertical list, but does not significantly enhance param meaning.
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 'Search the global Servicialo resolver for registered organizations by country and vertical.' It specifies the action, resource, and filtering dimensions, and distinguishes from siblings like resolve.lookup and registry.search.
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?
Explicitly provides when to use ('broad discovery', example given), when not to use (if you have org_slug, use resolve.lookup), and differentiates from registry.search by highlighting the DNS-level query and returned data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Query available time slots for booking at an organization. No authentication required. Use this after services.list when you know the org and need to find open slots before booking. Checks 3-way availability: provider schedule AND client conflicts AND physical resource (room/equipment). Do NOT use for searching organizations (use registry.search) or listing services (use services.list). Returns available slots grouped by date, each with start time, end time, provider, and resource.
| Name | Required | Description | Default |
|---|---|---|---|
| org_slug | Yes | Organization slug (e.g. "clinica-dental-sur"). Get this from registry.search results. | |
| service_id | No | Filter by service ID. Get valid IDs from services.list. Omit to check all services. | |
| provider_id | No | Filter by provider ID. Omit to check all available providers. | |
| resource_id | No | Filter by physical resource (room, equipment). Only needed if the service requires a specific resource. | |
| date_from | Yes | Start date in ISO format (e.g. "2026-03-01"). Must be today or later. | |
| date_to | Yes | End date in ISO format (e.g. "2026-03-07"). Max range: 30 days from date_from. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses no authentication required, checks 3-way availability, and describes return format. Lacks details on error handling or empty results, but sufficient for a query tool.
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 sentences, front-loaded with purpose, each sentence adds value. No waste.
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 tool with 6 parameters, no output schema, and no annotations, the description is quite complete: explains purpose, usage context, what it checks, and output format. Minor lack of error handling info, but overall 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 description coverage is 100%, but description adds extra context (e.g., 'No authentication required', 'resource_id: Only needed if the service requires a specific resource'). Adds meaning beyond schema.
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 'Query' and resource 'available time slots for booking at an organization'. It distinguishes from siblings like registry.search and services.list by explicitly stating what not to use it for.
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?
Explicitly states when to use ('after services.list when you know the org and need to find open slots before booking') and when not to use ('Do NOT use for searching organizations...'). Provides context of 3-way availability check.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the public service catalog of an organization: names, prices, durations, and modalities. Use this after registry.search to see what services an organization offers before checking availability. Do NOT use for organization discovery (use registry.search) or checking time slots (use scheduling.check_availability). Returns active, publicly bookable services only — internal or draft services are excluded.
| Name | Required | Description | Default |
|---|---|---|---|
| org_slug | Yes | Slug de la organización |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses key behavioral trait: 'Returns active, publicly bookable services only — internal or draft services are excluded.' No contradictions. Lacks mention of pagination or limits, but acceptable for simple list.
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 sentences efficiently convey purpose, usage context, and constraints. No 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?
For a simple list tool with one parameter and no output schema, description covers return content, constraints, and predecessor/successor tools completely.
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% (single param org_slug described in schema as 'Slug de la organización'). Description does not add new meaning beyond schema, but context of usage indirectly helps. Baseline 3 is appropriate.
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 lists public service catalog (names, prices, durations, modalities) and distinguishes from siblings by explicitly contrasting with registry.search (organization discovery) and scheduling.check_availability (time slots).
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: 'Use this after registry.search...' and lists two cases with alternatives: 'Do NOT use for organization discovery (use registry.search) or checking time slots (use scheduling.check_availability).'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the trust score of an organization from the Servicialo resolver. Use this to evaluate reliability before booking — returns score (0-100), trust level (unverified → declared → vouched → verified), and last activity timestamp. Do NOT use this to find organizations (use resolve.search). Trust accumulates passively from verified service history; it cannot be purchased or self-declared.
| Name | Required | Description | Default |
|---|---|---|---|
| org_slug | Yes | Slug de la organización (ej: clinica-dental-sur) | |
| country | No | País ISO 3166-1 alpha-2. Default: cl | cl |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description discloses return values (score range, trust levels, timestamp) and key behavioral trait: trust accumulates passively, cannot be purchased. Lacks details on error handling or permissions but covers core behavior.
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 sentences, front-loaded with verb and resource, no redundant words. Every sentence serves a purpose: action, usage guidance, and behavioral insight.
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 annotations or output schema, description covers purpose, return values, usage boundaries, and key behavioral constraints. Sufficient for agent to correctly select and invoke.
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 100% coverage with descriptions for both parameters. Description adds no new parameter-level semantics beyond context already present in schema; baseline 3 is appropriate.
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?
Clearly states verb 'Get' and resource 'trust score', and explicitly distinguishes from sibling 'resolve.search' by saying 'Do NOT use this to find organizations (use resolve.search)'.
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?
Explicitly says 'Use this to evaluate reliability before booking' and provides a clear negative use case 'Do NOT use this to find organizations' with alternative. Also explains passive accumulation, guiding appropriate use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.1a2a_get_agent_carddocs_quickstartregistry_get_organizationregistry_manifestregistry_searchresolve_lookupresolve_searchscheduling_check_availabilityservices_listtrust_get_scoreEach tool targets a distinct function, with clear separation through 'Do NOT use' guidance. However, registry_search and resolve_search both perform discovery with different outputs, and registry_get_organization and resolve_lookup both operate on a specific org_slug but return different data, creating minor ambiguity.
Names use underscores but follow mixed patterns: some are verb_noun (a2a_get_agent_card, registry_get_organization), others are noun_verb (registry_search, services_list), and some lack a verb (registry_manifest, docs_quickstart). This inconsistency could confuse agents.
10 tools is a well-scoped set for a service discovery and scheduling platform, covering discovery, profiles, services, availability, and trust without being overwhelming.
The tool surface covers discovery and pre-booking steps but lacks any tool for actual booking (create, update, cancel). This is a significant gap as users cannot complete the core action implied by the server's purpose.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Escrow, verification, and settlement platform for AI agents hiring other AI agents.
Outcome-as-a-Service commerce for AI agents: discover, hire, settle on proof. Live on devnet.
Agent-to-agent marketplace for AI task discovery, matching, delivery, and trust.
MCP layer for local businesses: discover, query, book, and transact with verified SMB AI agents.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/servicialo/mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
