This server provides a read-only interface to Muovi's LATAM service marketplace, enabling discovery of verified professionals, browsing of service catalogs, viewing reviews, and generating deep-links for task creation. Contact details (phone, email, WhatsApp) are never returned — all professional contact happens through Muovi's on-platform flow.
Search professionals (muovi_search_professionals): Find verified service professionals in Argentina by service type, city, neighborhood, identity verification, professional license (matrícula), minimum rating, and minimum review count.
Get a professional's profile (muovi_get_professional): Retrieve a full public profile including bio, portfolio images, specialties, services offered, city/neighborhoods, ratings, verifications, and a profile_url.
List services (muovi_list_services): Browse the complete service catalog (e.g. electricidad, plomería, pintura), each with a slug, human-readable name, and a requires_matricula flag.
List cities (muovi_list_cities): Get every Argentine city and its nested neighborhoods that Muovi serves, to resolve user location input into valid city/neighborhood slugs.
Get reviews (muovi_get_reviews): Fetch paginated, most-recent-first reviews for a professional, including ratings, comments, service category, and author details.
Create a task deep-link (muovi_create_task_link): Generate a canonical URL that drops the user into Muovi's on-platform task creation flow pre-filled with a specific professional and service (pure URL formatter — no network call).
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@@muovi/mcp-server I need an electrician in Palermo with high ratings"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Model Context Protocol (MCP) server for Muovi — LATAM's trust-first local services marketplace.
This package lets MCP-aware clients (Claude Desktop, Cursor, Claude Code, and any other MCP host) discover Muovi's verified LATAM service professionals, browse the service catalog and city list, read reviews, and deep-link a user into the on-platform task-creation flow. It is a thin, read-only wrapper over Muovi's public /v1 REST API.
Stdio mode. The package ships an npx-runnable binary that speaks JSON-RPC over stdin/stdout. The hosted HTTP/SSE variant is tracked separately (Muovi MOB-142).
Six tools, all read-only:
Tool | Wraps | Purpose |
|
| Search verified pros by service, city, neighborhood, verification status, min rating, min review count. |
|
| Fetch a single pro's full public profile (bio, portfolio, specialties, verifications). |
|
| The full live service catalog. |
|
| Every Argentine city Muovi serves, with neighborhoods. |
|
| Paginated reviews for a pro, most-recent first. |
| (pure formatter) | Builds the canonical deep-link the user should follow to start a task with a specific pro for a specific service. Makes no HTTP call. |
Related MCP server: Marketplace Search MCP
Muovi is on-platform-only. Phone, email, and WhatsApp handles are never returned by the public API — contact between consumers and professionals happens exclusively through Muovi's in-app conversation flow, reachable from each pro's profile_url.
This server enforces the policy twice:
The /v1 API strips contact data server-side.
Every tool response in this package also runs through a local anti-leakage detector (a Node-compatible mirror of src/lib/anti-leakage/detector.ts in the Muovi web repo). If a leak is detected at the agent boundary the tool returns a stable error to the LLM client and refuses to surface the payload.
Hosts that integrate this server must not synthesise off-platform contact handles from any field. Driving the user to profile_url (optionally with the deep-link query string) is the only sanctioned contact channel.
Open ~/Library/Application Support/Claude/claude_desktop_config.json (macOS) or %APPDATA%\Claude\claude_desktop_config.json (Windows) and add the server under mcpServers:
{
"mcpServers": {
"muovi": {
"command": "npx",
"args": ["-y", "@muovi/mcp-server"]
}
}
}If you have a Muovi API key (see Authentication below), pass it via env:
{
"mcpServers": {
"muovi": {
"command": "npx",
"args": ["-y", "@muovi/mcp-server"],
"env": {
"MUOVI_API_KEY": "your-key-here"
}
}
}
}Restart Claude Desktop after editing the config.
Add to ~/.cursor/mcp.json (or your workspace's .cursor/mcp.json):
{
"mcpServers": {
"muovi": {
"command": "npx",
"args": ["-y", "@muovi/mcp-server"]
}
}
}Register the server with the Claude Code CLI:
claude mcp add muovi --command "npx" --args "-y" "@muovi/mcp-server"Or add it manually to your Claude Code settings:
{
"mcpServers": {
"muovi": {
"command": "npx",
"args": ["-y", "@muovi/mcp-server"]
}
}
}npx -y @muovi/mcp-serverThe process reads JSON-RPC on stdin and replies on stdout. All log output goes to stderr.
All /v1 endpoints are public and unauthenticated by default. If your client has been issued a Muovi API key (higher rate-limit tier), set MUOVI_API_KEY in the server's environment and the package will forward it as the X-API-Key header on every request.
You can also override the API base URL for testing:
MUOVI_API_BASE_URL=https://staging.muovi.com.ar/api/v1 npx -y @muovi/mcp-serverA typical Claude conversation that uses these tools:
User asks for "an electrician in Palermo who's properly licensed".
Agent calls muovi_list_services to map "electrician" → electricidad.
Agent calls muovi_list_cities to confirm palermo is a valid neighborhood under caba.
Agent calls muovi_search_professionals with { service: "electricidad", city: "caba", neighborhood: "palermo", has_matricula: true, min_rating: 4.5 }.
Agent picks the top pro and calls muovi_get_professional for the full bio + portfolio.
Agent optionally calls muovi_get_reviews for social proof.
Agent calls muovi_create_task_link with { professional_slug, service_slug: "electricidad" } and surfaces the resulting URL.
User follows the link, lands on Muovi, completes the on-platform task creation flow.
Step 8 — the on-platform flow — is Muovi's enforcement point for trust, payments, and disputes. MCP never bypasses it.
This package is the standalone muovi-latam/mcp-server repo. Clone it, install, and run tests:
git clone git@github.com:muovi-latam/mcp-server.git
cd mcp-server
npm install
npm test # unit + integration + OpenAPI drift checks
npm run typecheck # strict TypeScript
npm run build # emits dist/The OpenAPI drift test parses public/openapi.yaml and asserts each tool's input schema matches the corresponding operation's parameters exactly — adding a query param to /v1 requires updating the corresponding tool (and vice versa).
npm publish is intentionally not wired into CI. Releases are cut manually from a clean tag:
npm version patch # or minor / major
npm publish --access public
git push --follow-tagsprepublishOnly runs clean + build + test before any publish.
Beyond npm, this server is listed in the Model Context Protocol registry via the committed server.json manifest. Publishing to the registry is a manual step — there is deliberately no CI auto-publish (the registry is a low-frequency, human-gated surface, and namespace auth is interactive).
Committed namespace: ar.com.muovi/mcp-server — the reverse-DNS form of muovi.com.ar. This value lives in both server.json (name) and package.json (mcpName) and the two must stay byte-identical (the server-json test enforces equality). It must also match the identity you authenticate as with mcp-publisher (see below).
Prove ownership of the ar.com.muovi namespace once, before the first publish:
DNS (preferred): add the TXT record that mcp-publisher login dns prints to the muovi.com.ar zone, then authenticate against that domain. This ties the namespace to the domain we already control.
GitHub OAuth (fallback): mcp-publisher login github — authenticates via the muovi-latam GitHub org. Only use this if DNS verification is unavailable; the authenticated identity still has to line up with the committed ar.com.muovi/mcp-server namespace.
If the committed namespace and the authenticated identity disagree, mcp-publisher publish will reject the manifest — fix the namespace (in both files) or the login, do not force it.
mcp-publisher validate ./server.json # checks against the live registry schema
mcp-publisher publish # publishes server.json under the authenticated namespacevalidate is the step that confirms the manifest matches the current registry schema version — run it every time; the pinned $schema in server.json is a hint, not a guarantee the live schema hasn't moved.
The server-json test asserts that four version fields agree. On every version bump, update all of them together, then re-publish to both npm and the registry:
package.json → version
src/server.ts → PACKAGE_VERSION
server.json → version
server.json → packages[0].version
The manifest advertises capabilities that are not yet fully live. Keep these caveats in mind (and do not overstate them to users):
Remote transport (remotes[].url = https://mcp.muovi.com.ar/) is only truthful once that endpoint reliably answers JSON-RPC initialize over streamable-HTTP. That hosted surface is tracked in MOB-207; until it lands, the stdio package (npx @muovi/mcp-server) is the only transport that actually works.
muovi_get_professional and muovi_get_reviews remain broken against production until MOB-263 deploys the backing /v1 endpoints. The tools are registered and pass drift checks, but live calls will fail until then.
MIT.
Build the canonical Muovi deep-link that opens the on-platform task creation flow pre-filled with a specific professional and service. Returns a URL of the form https://muovi.com.ar/p/{slug}?create_task=1&service={service-slug}. This is a pure formatter — it makes no network call and creates no task. After running it, surface the URL to the user so they can complete the booking on Muovi. Muovi never lets agents create tasks server-side; the consumer always sees the on-platform flow to confirm details.
| Name | Required | Description | Default |
|---|---|---|---|
| service_slug | Yes | The service slug to pre-fill in the task flow (from `muovi_list_services`). | |
| professional_slug | Yes | The professional's URL-safe slug (from `muovi_search_professionals` or `muovi_get_professional`). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (readOnlyHint=true, idempotentHint=true, destructiveHint=false) are fully supported: the description states 'makes no network call and creates no task' and 'pure formatter'. It adds context that the URL follows a specific format, which is useful beyond the 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?
Four sentences, each essential: tool purpose, URL format, no-side-effect assertion, and usage guidance. Front-loaded and efficient with 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?
Even without an output schema, the description fully explains the return format and the broader workflow (user completes booking on-platform). It clarifies the limitation of agent-side task creation, making the tool's role in the flow 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 coverage is 100%, maintaining a baseline of 3. The description adds value by specifying the source of each slug (e.g., professional_slug from search or get, service_slug from list), providing execution context not in the 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 it builds a deep-link URL for the Muovi task creation flow, pre-filled with a professional and service. It distinguishes this from sibling tools by explicitly labeling it as a 'pure formatter' that makes no network calls or task creation.
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 says the tool should be used after selecting a professional and service, and the URL should be surfaced to the user for completing the booking on Muovi. It also warns that the agent cannot create tasks server-side, guiding appropriate use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch the full public profile for a single Muovi-verified professional by slug. Returns display name, headline, bio, portfolio image URLs, specialties, city + neighborhoods, services, ratings, verifications, and the canonical profile_url. The profile_url is the only sanctioned contact channel — phone, email, and whatsapp are never returned. Append ?create_task=1&service={slug} to profile_url (or use muovi_create_task_link) to deep-link a user into the on-platform task creation flow targeted at this pro.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | The professional's URL-safe slug (e.g. "juan-p-electricista-caba"). Obtain from `muovi_search_professionals`. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, but the description adds valuable behavioral context: it states that phone, email, and whatsapp are never returned, and that the profile_url is the only sanctioned contact channel. This goes beyond annotations to manage expectations about what the tool does not return. 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 a single fluid paragraph that lists the returned fields and key usage notes. It is efficient and covers necessary details without excessive verbosity. While a bullet list might improve scannability, the current structure is clear and concise.
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 simple input schema and lack of an output schema, the description adequately explains what the tool returns by listing fields manually. It also covers an important nuance (the sanctioned contact channel) and how to deep-link. Could be slightly improved by mentioning if pagination or rate limits apply, but overall complete for a single-param read 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 provides a description for the 'slug' parameter, but the description adds value by explaining how to obtain the slug ('Obtain from muovi_search_professionals') and clarifying it is a 'URL-safe slug'. This improves an AI agent's ability to provide the correct input.
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 fetches the full public profile for a single verified professional by slug. It lists the specific fields returned (display name, headline, bio, etc.) and distinguishes from sibling tools like muovi_create_task_link by mentioning the sanctioned contact channel and deep-linking.
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 clear context for use: retrieve a professional's profile by slug. It does not explicitly state when not to use this tool, but it implies that muovi_search_professionals is for search and muovi_create_task_link for deep-linking, giving enough guidance for an AI agent to choose appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch paginated reviews for a single Muovi-verified professional, sorted most-recent first. Each review has a 1-5 rating, an optional title and free-text comment, the author's reduced display name (e.g. "María G." — full surnames are never returned), the author role (client or worker), the service category the review is associated with, and an ISO created_at timestamp. Use this to surface social-proof when recommending a professional.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | The professional's URL-safe slug. Obtain from `muovi_search_professionals` or `muovi_get_professional`. | |
| limit | No | Maximum number of reviews per page (default 20, max 50). | |
| offset | No | Zero-based offset into the review list for pagination. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint. The description adds critical behavioral details: pagination, sorting, fields returned (rating, title, comment, truncated author name, role, service category, timestamp), and notably that full surnames are never returned. 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 two sentences, each carrying essential information. The first sentence states the core functionality and sorting; the second details output fields and usage context. 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?
Despite lacking an output schema, the description thoroughly explains the return structure (rating, title, comment, author display name, role, service category, timestamp) and pagination behavior. This is complete for a read-only paginated list 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%, but the description adds value by explaining the 'slug' parameter's provenance (obtain from muovi_search_professionals or muovi_get_professional) and clarifying the default limit (20) which is not in the schema. This enhances understanding.
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 fetches paginated reviews for a single professional, sorted most-recent. It specifies the resource (reviews) and action (fetch), and differentiates from sibling tools which focus on professionals, cities, or services.
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 the use case: 'Use this to surface social-proof when recommending a professional.' While it doesn't mention when not to use or alternatives, the context is clear and the statement provides direct guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List every Argentine city Muovi serves, with active neighborhoods nested under each. Each city has a stable slug (used as the city parameter on muovi_search_professionals) and a human-readable name. Each neighborhood has its own slug (used as the neighborhood parameter on muovi_search_professionals). Call this when you need to resolve a user's location wording to a Muovi city or neighborhood slug.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true and openWorldHint=true. Description adds that each city has a stable slug and human-readable name, and neighborhoods are nested. No contradictions; adds 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?
Three sentences, each earning its place. Front-loaded with purpose, then details about slugs and usage. 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 zero-parameter list call with no output schema, the description fully explains what is returned (cities with nested neighborhoods, slugs, human-readable names) and how to use it. 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?
No parameters exist, so schema coverage is 100% (empty). The description adds value by explaining the slug usage and output structure, which is the baseline expectation.
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 Argentine cities with active neighborhoods, and specifies that slugs are used for other tools. It distinguishes itself from sibling tools like muovi_search_professionals by explaining how the output maps to parameters.
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 'Call this when you need to resolve a user's location wording to a Muovi city or neighborhood slug.' This is clear guidance. It doesn't explicitly state when not to use it, but the context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List every service category Muovi supports in Argentina (electricidad, plomería, pintura, etc.). Each entry has a stable slug (used as the service parameter on muovi_search_professionals and muovi_create_task_link), a human-readable name, an optional description, and a requires_matricula flag indicating whether listed professionals must hold a verified professional license. Call this first when you need to map a user's natural-language request to a Muovi service slug.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the bar is lower. The description adds value by disclosing that each entry has a stable slug, a human-readable name, optional description, and especially the requires_matricula flag. This behavioral detail aids agent reasoning beyond what annotations supply.
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?
Single paragraph, no filler. Front-loads the purpose, then details output fields, and ends with usage recommendation. Every sentence earns its place.
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 no parameters and no output schema, this description is fully complete. It explains the return structure, the meaning of each field, and the tool's role in the larger workflow (mapping natural language to slugs for 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?
No parameters exist (0 params), and schema coverage is 100%. Per rubric baseline 4, since there is nothing to add. The description could not add parameter meaning because there are none.
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 verb 'List' and the resource 'every service category Muovi supports in Argentina'. It explicitly distinguishes the tool from siblings by explaining how its output (slugs) feeds into muovi_search_professionals and muovi_create_task_link, making its role unique.
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 guidance: 'Call this first when you need to map a user's natural-language request to a Muovi service slug.' Also explains that slugs are stable and reused elsewhere, giving clear context for invocation order.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for verified service professionals in Argentina by service type, city, neighborhood, verification status, minimum rating, and minimum review count. Returns a paginated list of professionals with display name, headline, ratings, verifications, and a profile_url that is the only sanctioned contact channel (no phone/email/whatsapp is ever returned). Use this for discovery; use muovi_get_professional for the full detail payload.
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | City slug (e.g. "caba"). Matches `City.slug` in the catalog. | |
| limit | No | Maximum number of results per page (default 20, max 50). | |
| offset | No | Zero-based offset into the result set for pagination. | |
| service | No | Service slug (e.g. "electricidad"). Matches `Service.slug` in the catalog. | |
| min_rating | No | Minimum blended average rating, 0-5 inclusive. | |
| min_reviews | No | Minimum blended review count. | |
| neighborhood | No | Neighborhood slug (e.g. "palermo"). Matches `Neighborhood.slug` in the catalog. | |
| has_matricula | No | When true, only return pros with a verified professional matrícula on file (electricians, gas fitters, etc.). | |
| verified_identity | No | When true, only return pros whose identity has been verified by Muovi. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint and openWorldHint. The description adds important behavioral details: returns a paginated list, lists specific fields (display name, headline, ratings, verifications, profile_url), and crucially states that no phone/email/whatsapp is ever returned. This goes beyond annotations, though no mention of rate limits or error handling.
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: first sentence defines purpose and filters, second explains return content and a key constraint, third gives usage guidance. It is front-loaded and every sentence adds value with no fluff.
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 9 optional parameters and no output schema, the description adequately covers core information: filters, return fields, pagination, and direction to the detail tool. However, it could hint that slugs come from catalog endpoints (muovi_list_cities, muovi_list_services) to improve completeness for an agent.
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 100% schema description coverage, the schema already documents each parameter. The description provides a high-level summary of filter criteria but does not add new semantic information beyond what is in the schema. Thus, 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 explicitly states the verb 'search', the resource 'verified service professionals in Argentina', and lists multiple filtering criteria (service type, city, neighborhood, etc.). It clearly distinguishes from sibling muovi_get_professional by stating use for discovery vs. full detail.
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 guidance: 'Use this for discovery; use muovi_get_professional for the full detail payload.' This directly tells the agent when to use this tool versus the sibling, fulfilling the dimension well.
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.
v0.1.2muovi_create_task_linkmuovi_get_professionalmuovi_get_reviewsmuovi_list_citiesmuovi_list_servicesmuovi_search_professionalsScored across 6 tools
Each tool targets a unique functionality: creating a deep-link, fetching a professional profile, fetching reviews, listing cities, listing services, and searching professionals. There is no overlap or ambiguity between them.
All tool names follow a consistent 'muovi_verb_noun' pattern using snake_case, such as muovi_list_cities and muovi_search_professionals. The naming is predictable and clear.
With 6 tools, the server is well-scoped for its purpose of accessing Muovi professional services. Each tool is essential and covers distinct operations without unnecessary bloat.
The tool set covers the full lifecycle for the domain: listing locations and services, searching professionals, viewing detailed profiles and reviews, and generating a task creation link. No obvious gaps exist given Muovi's constraints (no server-side task creation).
ProxyLink MCP server for finding and booking home service professionals
Search 33,000+ MCP servers by job, see safety grades and reviews, and call them from one endpoint.
The Mercado Pago MCP Server implements the Model Context Protocol to provide AI agents and LLMs with access to Mercado Pago's APIs and tools within compatible development environments. It acts as an intermediary that translates Mercado Pago resources into executable functions (tools) that AI applications can invoke to perform actions and automate flows. The server simplifies integration, enables using documentation to implement or improve code, and optimizes operations through natural language interactions without manual implementations.
Discover, hire, and verify real-world physical capability through MCP.
