Skip to main content
Glama

Nuvemshop

by io.github.mcp-dir

nuvemshop_orders_list

Read-onlyIdempotent

Leitura de pedidos da loja Nuvemshop. Ações:

  • list: pedidos paginados (params: page, per_page, status, payment_status, shipping_status, created_at_min, updated_at_min, q).

  • get: pedido por id (requer order_id).

[Flattened action: list]

Bulk support: accepts order_ids for batched execution.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
qNo
pageNo
statusNo
accountNo
order_idNo
per_pageNo
order_idsNo
created_at_minNo
payment_statusNo
updated_at_minNo
shipping_statusNo

TDQS

B3.3/5.0
Behavior2/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds no significant behavioral context beyond repeating 'reading' and listing parameters. No disclosure of rate limits, data volume, or side effects, which would add value 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.

Conciseness3/5

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

The description is somewhat verbose and mixes Portuguese with English. It has bullet-like structure but includes redundant introductory text and a flattened action note that could be integrated more cleanly. Not overly long but could be tighter.

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 11 parameters, no output schema, and low schema coverage, the description covers list and get actions, pagination, and bulk support. However, it misses documentation for the 'account' param, does not describe return format, error behavior, or rate limits, leaving gaps.

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?

With 0% schema description coverage, the description attempts to explain parameters (page, per_page, filters, q, order_id, order_ids). However, it omits the 'account' parameter and provides minimal detail on format or constraints, thus partially compensating but not fully.

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 'Leitura de pedidos' (reading orders) and distinguishes between list (paginated) and get (by id) actions, providing a specific verb and resource scope that separates it from sibling tools like nuvemshop_orders_get and write tools.

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 explains basic usage (list vs get) and mentions bulk support, but lacks explicit guidance on when to use this tool versus alternatives like nuvemshop_orders_get for single orders or write tools for modifications. No 'when not to use' context is provided.

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

All Nuvemshop toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

C2.6/5.0
Disambiguation2/5

Many tools have overlapping functionality, especially the get/list pairs for customers, orders, and products which have identical descriptions except for the default action. The multiple order write tools (cancel, close, fulfill, etc.) also share the same underlying description, making it difficult for an agent to select the correct one.

Naming Consistency2/5

Tool names mix patterns: some use simple <resource> (nuvemshop_categories), others use <resource>_<action> (nuvemshop_customers_get), and others use <resource>_write_<action> (nuvemshop_orders_write_cancel). The get/list split for customers, orders, and products is inconsistent with the categories tool which lacks such a split.

Tool Count2/5

With 24 tools, the server has an excessive number for its scope. Many tools are redundant (e.g., separate get and list tools for each resource, and individual write tools for order status transitions). Consolidating these would reduce the count and improve usability.

Completeness3/5

The server covers the main e-commerce resources (categories, coupons, customers, orders, products) with read and write operations. However, there are gaps: no ability to create or delete customers, delete products, or delete coupons. The set is workable but not fully comprehensive.

Resources