Skip to main content
Glama
mercadolibre-mcp

mercadolibre-mcp

Conectar cuenta de MercadoLibre

ml_conectar
Read-only

Connects a MercadoLibre seller account by returning a browser authorization URL or completing the link with the OAuth code.

Instructions

Vincula una cuenta de MercadoLibre. Sin argumentos devuelve la URL para autorizar en el navegador; con code (el código que muestra la página al autorizar) completa la conexión. Requiere ML_APP_ID y ML_APP_SECRET configurados.

Input Schema

NameRequiredDescriptionDefault
codeNoCódigo que devolvió MercadoLibre al autorizar
sitioNoPaís: MLC (Chile, default), MLA, MLB, MLM, MCO, etc.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.15.0

TDQS

B3.2/5.0
Behavior1/5

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

Annotations declare readOnlyHint=true, but the description says calling with `code` 'completa la conexión', which persists OAuth credentials and mutates account state. That is a direct contradiction between the declared read-only profile and the described behavior, and no further behavioral context (token lifetime, effect on the existing connection) is offered.

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

Conciseness4/5

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

Two compact sentences that front-load the account-linking action and then the branching behavior, with the prerequisite appended last. No filler.

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

Completeness3/5

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

Covers the main call paths and configuration prerequisites, but for an auth/credential tool it omits what happens to an existing connection, whether tokens are stored and refreshed, and what the no-argument response contains. The readOnlyHint contradiction also leaves the agent with an inaccurate safety picture.

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

Parameters3/5

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

Schema coverage is 100% and the `code` property is already documented in-schema; the description only restates where the code comes from. The `sitio` parameter (country/site selection) is never mentioned in the description, so it adds little beyond the schema.

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

Purpose4/5

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

States a specific verb and resource ('Vincula una cuenta de MercadoLibre') and clearly splits the two operating modes (no args = URL, with `code` = complete). It doesn't explicitly name the counterpart ml_desconectar, so sibling differentiation is left to inference.

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

Usage Guidelines4/5

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

Gives a clear two-step flow: call without arguments to get the authorization URL, then call with the `code` shown by the page to finish. It also states the prerequisite configuration (ML_APP_ID, ML_APP_SECRET). No explicit 'don't use when already connected' exclusion is given.

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