plaza-vea-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation5/5
Each tool has a clear, distinct purpose: searching products, retrieving details, listing brands, fetching images, building cart links, and managing catalog refresh. No overlap or ambiguity.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern with lowercase underscores (e.g., search_products, get_product_image, start_catalog_refresh). Perfectly uniform.
Tool Count5/5
7 tools is well within the ideal range for a focused e-commerce catalog server, covering both read operations and background job management without excess.
Completeness5/5
The tool set comprehensively covers product discovery (search, get, brands, images), cart link generation, and catalog refresh management (start and status). No obvious gaps for the stated domain.
Average 3.5/5 across 7 of 7 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 4 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds useful context beyond annotations: it explicitly states the operation runs in the background and writes to local SQLite without modifying remote data. This complements the annotations (readOnlyHint=false, destructiveHint=false) by clarifying the side effects are local and non-destructive. However, it does not mention potential rate limits, resource usage, or how long the operation may take.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the core action (starts crawler in background) and follows with the data targets and the non-modification guarantee. There is no fluff or redundancy; every phrase adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is incomplete for a tool with an optional parameter and a sibling for status checking. It does not mention the category_id parameter, nor does it point to get_catalog_refresh_status for tracking progress or outcomes. While an output schema exists, the description should at least hint at the asynchronous nature and how to verify completion. This is a significant gap for an agent to call the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one optional parameter (category_id) with 0% description coverage, and the tool description does not mention this parameter at all. An agent would have no idea that it can filter the refresh by a specific category, nor what the parameter's format or effect is. The description completely fails to compensate for the missing schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: it starts a local Scrapy crawler in the background and writes catalog and price history to SQLite. It clearly distinguishes itself from siblings like get_catalog_refresh_status by emphasizing it initiates a refresh rather than checking status. The phrase 'sin modificar datos remotos' further clarifies its scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. It does not mention get_catalog_refresh_status as the way to check the result of a refresh, nor does it state any conditions or prerequisites (e.g., requiring an existing catalog). The description only explains what the tool does, not when it should be chosen.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, and non-destructive behavior, so the description does not need to restate those. It adds a little context by specifying the breadth of the returned data, but it does not disclose behavior beyond what the annotations and the stated return scope already imply, such as pagination, errors, or availability constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that directly states the action and the object. Every word carries meaning, and there is no redundant or filler content.
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?
The output schema and annotations cover return values and safety profile, and the single required parameter is simple. However, the description does not clarify how to obtain or interpret product_id, nor does it situate the tool relative to its siblings, leaving minor but real gaps for autonomous selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description would need to compensate by explaining product_id semantics. It does not clarify the format, source, or scope of product_id beyond the schema's type/length constraints and the property name, leaving some ambiguity for an agent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Devuelve') and identifies the resource ('un producto') while enumerating the exact data returned: variants, sellers, offers, and images. This clearly distinguishes the tool from siblings like get_product_image (single image) and search_products (search/browse).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no explicit guidance about when to use this tool versus alternatives, nor does it mention exclusions or prerequisites. Sibling tools such as search_products and get_product_image are not referenced, leaving the agent to infer usage from the resource scope.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds a behavioral caveat beyond the annotations: price and stock are revalidated when opening Plaza Vea, indicating data might be stale. This supplements the readOnlyHint and idempotentHint already provided.
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?
The description is a single, concise sentence that covers the core functionality without unnecessary verbosity. It is well-structured and easy to parse, though it could be slightly more explicit about the return type.
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?
Given that some parameters are not described and the output schema is not referenced, the description leaves some gaps. However, the core search behavior and the revalidation note provide enough context for typical usage, making it moderately complete.
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?
The description clarifies the semantics for 'name' (partial match) and 'brand' (exact match), and mentions sorting by price minimum. However, it does not explain limit, only_available, or the sort enum values, which remain inferred from context.
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?
The description clearly states the tool searches the public catalog by partial name and exact brand, and supports sorting. It distinguishes from siblings like get_product by focusing on catalog search, though it does not explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as list_brands or get_product. It only explains what it does, leaving the selection criteria implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, open-world, and idempotent behavior. The description adds the detail that only active brands are listed, which is a useful behavioral nuance. However, it does not mention output format or pagination, so transparency is partial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that directly conveys the tool's purpose. It is well-structured and contains no unnecessary words or details.
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?
Given the simplicity of the tool and the presence of an output schema, the description is adequate but not comprehensive. It lacks information about pagination, sorting, or any edge cases. Since the output schema exists, the description does not need to explain return values, but it could still benefit from additional context.
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?
The description explicitly explains the 'prefix' parameter by mentioning filtering by prefix. The 'limit' parameter is not described, but its meaning is fairly standard. The schema covers both parameters, but the description does not fully elaborate on their semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: listing active brands and filtering by prefix. This distinguishes it from sibling tools like search_products or get_product, which have different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide any guidance on when to use this tool versus alternatives such as search_products. No contextual hints or selection criteria are offered, leaving the agent to infer appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only and non-destructive behavior. The description adds explicit context by stating it does not open the browser, modify a cart, or make payments, enhancing transparency 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, two sentences, with no redundant information. It efficiently communicates the core function and key non-behaviors.
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?
While the description covers purpose and non-behaviors, it lacks parameter semantics and any mention of validation outcomes or error handling. However, the output schema is present, so return values are not required in the description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description provides no explanation of the 'items' parameter or its sub-fields (sku_id, quantity, seller_id). The agent receives no semantic guidance for correct input.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: validating SKUs and generating cart links. It is specific and distinct from sibling tools like search_products or get_product.
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?
The description implies usage for building cart links but does not explicitly state when to use this tool versus alternatives. It lists non-behaviors but lacks direct guidance on selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, and non-destructive behavior. The description adds specific data returned (progress, result, errors), which is useful but does not contradict the annotations. It stops short of describing error handling or edge cases.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that directly communicates the tool's purpose without unnecessary detail or redundancy.
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?
The description covers the basic function but lacks details on output structure, behavior for missing/invalid run_id, and its relationship to start_catalog_refresh is implied rather than explicit. Adequate for a simple status tool but with notable gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides run_id with length constraints but no description of its meaning. The tool description does not explain what run_id represents or how it should be obtained, leaving the parameter semantics ambiguous despite the self-explanatory name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: it queries progress, results, and errors of a Scrapy catalog refresh. This distinguishes it from sibling tools like start_catalog_refresh (which initiates a refresh) and the product search tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description lacks explicit guidance on when to use this tool, such as 'after starting a refresh' or 'to check if a refresh completed'. It only states the function without usage context or comparison to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate read-only, idempotent, and non-destructive behavior. The description aligns by stating it downloads and returns an image, with no contradictions. While it does not add extra behavioral details beyond the annotations, it is consistent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured, consisting of two sentences that convey the tool's function and a key usage instruction without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool, the description covers the main purpose, output format, and a usage tip. It does not discuss edge cases or detailed return structure, but it is sufficient for an agent to understand the tool's core functionality and use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions 'de un SKU' which hints at the sku_id parameter, but it does not explicitly define either parameter. The image_index parameter is completely unaddressed. With 0% schema coverage, the description fails to provide necessary parameter context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it downloads a public image from a SKU and returns it as ImageContent PNG for model vision, and further explains how to make it visible to the user in Codex. This distinguishes it from sibling tools like get_product or search_products, which focus on other aspects.
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?
It provides an explicit usage instruction: copying the markdown in TextContent to make the image visible to the user in Codex. However, it does not explicitly contrast with sibling tools (e.g., when to use this over get_product), leaving some inference required.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

plaza-vea-mcp MCP server — quality and maintenance score on Glama

Copy to your README.md:

[![plaza-vea-mcp MCP server — quality and maintenance score on Glama](https://glama.ai/mcp/servers/jeffreymonjacastro/plaza-vea-mcp/badges/card.svg)](https://glama.ai/mcp/servers/jeffreymonjacastro/plaza-vea-mcp)

Score Badge

Copy to your README.md:

[![plaza-vea-mcp MCP server — quality and maintenance score on Glama](https://glama.ai/mcp/servers/jeffreymonjacastro/plaza-vea-mcp/badges/score.svg)](https://glama.ai/mcp/servers/jeffreymonjacastro/plaza-vea-mcp)

shields.io Endpoint

For READMEs with an existing badge row. Append &style=flat-square (or any other shields.io style) to match the rest, and &metric=tools, &metric=maintenance or &metric=claim to badge a different dimension.

[![plaza-vea-mcp MCP server — quality and maintenance score on Glama](https://img.shields.io/endpoint?url=https%3A%2F%2Fglama.ai%2Fmcp%2Fservers%2Fjeffreymonjacastro%2Fplaza-vea-mcp%2Fbadges%2Fshields.json)](https://glama.ai/mcp/servers/jeffreymonjacastro/plaza-vea-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/jeffreymonjacastro/plaza-vea-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server