Skip to main content
Glama
Sign In
Mercado Libre MCP Server

Mercado Libre MCP Server

by MarcosNahuel
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

traid_feature_lookup

Search a configured knowledge base for reusable Mercado Libre features by keyword, slug, or category, returning top matches with reuse guidance and trade-offs.

Instructions

Busca features reusables en la base de conocimiento configurada (TRAID_KNOWLEDGE_MODE=filesystem y TRAID_KNOWLEDGE_PATH; el paquete no trae ninguna base incluida). Devuelve top N matches con descripción, cómo reusar y trade-offs. Ej: query="repricing".

Tool call template

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

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "query": "<query>"
    },
    "name": "traid_feature_lookup"
  }
}

Input Schema

NameRequiredDescriptionDefault
limitNoMáx hits a devolver (default 5)
queryYesSlug exacto, keyword o frase descriptiva (ej: "repricing", "oauth multi tenant ml", "bot preventa")
categoryNoFiltrar por categoría primaria

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.2.0-alpha.3

TDQS

A3.6/5.0
Behavior4/5

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

No annotations exist, so the description carries the full burden and does reasonably well: it discloses the environment prerequisite, warns that the package contains no bundled knowledge base, and tells the caller what each match contains. It does not mention read-only status or behavior when no matches are found.

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 tight sentences that front-load purpose followed by the configuration caveat, then the return shape. The trailing example duplicates the schema's own example and could be dropped, but overall there is little waste.

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?

For a simple 3-parameter search with no output schema, it covers purpose, prerequisite and return contents adequately. It still leaves gaps an agent would want: whether results are cached/static, what an empty result means, and how to react when the knowledge base is not configured.

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 description coverage is 100%, so query, limit and category are already documented with an enum and a default. The description's example query="repricing" merely repeats the schema example and adds nothing about limit or category semantics, making 3 the baseline.

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 ("Busca features reusables en la base de conocimiento") and outlines the shape of the result (matches with description, reuse guidance, trade-offs). It is clearly a knowledge lookup rather than one of the operational commerce siblings, though it never names a sibling explicitly.

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

Usage Guidelines3/5

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

Gives a concrete usage example (query="repricing") and a critical prerequisite: the lookup only works when TRAID_KNOWLEDGE_MODE=filesystem and TRAID_KNOWLEDGE_PATH are configured, since no knowledge base ships with the package. It does not say when to prefer this over other siblings or how to proceed when the KB is unconfigured.

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

Deploy Server

Other Tools