F
licenseNot graded
qualityC
maintenanceDTC competitor intelligence: catalog snapshots, price history, cross-brand product comparison, and drop/restock detection for 84 Shopify-powered brands. Pay-per-call via Apify.
-
guapissimas
Server Details
Catálogo de 328 produtos em 26 categorias — servido via Scrypta.
If you are the author of this connector, you can claim ownership by verifying the domain or GitHub account it belongs to. Claimed connector authors can inspect health checks, view analytics, and manage their listing.
- Status
- Healthy
- Uptime
- 100.0% over 28 days
- Last Tested
- Transport
- Streamable HTTP · MCP 2025-06-18
- URL
- Repository
- scrypta-mcp/scrypta-mcp
- GitHub Stars
- 0
- ChatGPT
- –
- Claude
- –
TDQS
B3.4/5.0
Scored across 5 tools
Disambiguation3/5
There is meaningful overlap between buscar_produtos and produtos_por_categoria, since the former already accepts a category filter. info_empresa also overlaps with listar_categorias by returning categories, so an agent may hesitate between tools. Descriptions help, but boundaries are not fully clean.
Naming Consistency3/5
Most names are readable, but the set mixes verb-led actions (buscar_, listar_) with noun-phrase names (info_empresa, produtos_por_categoria). The pattern is understandable but not predictable enough to be considered consistent.
Tool Count5/5
Five tools is well-scoped for a small product catalog server. Each operation maps to a reasonable read-only query or information need without obvious bloat.
Completeness4/5
The surface covers the main read-only workflows: product search, company info, categories, plans, and category browsing. Minor gaps remain, such as fetching a single product's full details by ID or URL, but agents can mostly work around them.
Available Tools
5 toolsbuscar_produtosBuscar ProdutosARead-onlyIdempotentInspect
Busca produtos no catálogo. Aceita filtros combinados: termo no nome, categoria, faixa de preço e apenas em estoque. Retorna lista paginada com nomes, preços e URLs.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | Termo de busca por nome do produto (ex: 'colar', 'vestido'). Aceita acentos ou não. | |
| limite | No | Número máximo de produtos por resposta (1 a 100). Default: 20. | |
| offset | No | Quantos resultados pular (paginação). Default: 0. | |
| categoria | No | Nome exato da categoria (ex: 'Colares'). Use listar_categorias antes para descobrir nomes válidos. | |
| preco_max | No | Preço máximo em BRL (inclusivo). Ex: 100.00 para até R$ 100. | |
| preco_min | No | Preço mínimo em BRL (inclusivo). Ex: 50.00 para a partir de R$ 50. | |
| apenas_em_estoque | No | Se true, retorna apenas produtos em estoque. Default: false. |
Output Schema
| Name | Required | Description |
|---|---|---|
| total | Yes | Total de produtos que casam com os filtros. |
| has_more | Yes | True se há mais páginas. |
| products | Yes | |
| returned | Yes | Quantos vieram nesta página. |
TDQS
A3.8/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, closed-world behavior, so the safety profile is covered. The description adds useful context beyond them by noting that results are paginated and what fields come back (nomes, preços, URLs), though it omits any note on default page size or empty-result behavior (the latter is covered by the schema).
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?
Two short sentences: the first states the action, the second states filters and return shape. Front-loaded and free of filler, with nothing repeated from the title.
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?
With seven optional parameters, full schema coverage, annotations, and an output schema, the definition supplies what is needed to call it correctly. It is slightly thin on routing to siblings and on pagination defaults, but nothing critical is missing.
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 the baseline is 3. The description restates four of the seven parameters (name term, category, price range, in-stock) but adds no syntax or format detail beyond the schema, and never mentions limit/offset pagination controls.
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 produtos no catálogo") and enumerates the filter facets it accepts, so the agent knows exactly what the tool does. It does not name or contrast with siblings like produtos_por_categoria or listar_categorias, so differentiation is left implicit.
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 phrase "Aceita filtros combinados" implies this is the general-purpose filtered search, but there is no explicit when-to-use or when-not guidance versus produtos_por_categoria (already-filtered listing) or listar_categorias. Usage must be inferred from the parameter list rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
info_empresaInformações da EmpresaARead-onlyIdempotentInspect
Retorna informações gerais sobre a empresa: URL, total de produtos, categorias, planos e faixa de preço.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| url | Yes | |
| slug | Yes | |
| plans_count | Yes | |
| price_range | No | |
| products_count | Yes | |
| categories_count | Yes |
TDQS
A3.7/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint and a closed-world scope, so the safety profile is covered. The description contributes by signaling the response shape is an aggregate summary (counts, categories, price range) rather than a full listing, which helps set expectations, but adds no other behavioral context.
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?
A single front-loaded sentence with no filler; the field enumeration is the substance and earns its space.
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?
An output schema exists, so the return values need not be spelled out, and annotations carry the safety profile. For a zero-parameter read tool this covers what an agent needs, though it could note the overview-vs-listing relationship to siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Zero parameters, so there is nothing to disambiguate; baseline 4 applies. The description correctly implies a no-argument call.
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 names a specific verb and resource ('Retorna informações gerais sobre a empresa') and enumerates the returned fields (URL, total de produtos, categorias, planos, faixa de preço), which distinguishes it from the itemized siblings like buscar_produtos and listar_categorias. It never names a sibling explicitly, so differentiation is implicit rather than stated.
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 phrase 'informações gerais' hints this is the overview/aggregate entry point rather than a filtered listing, but the description never says when to call this instead of listar_categorias or listar_planos. Usage is inferable, not instructed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
listar_categoriasListar CategoriasARead-onlyIdempotentInspect
Lista todas as categorias de produtos disponíveis no catálogo, com contagem por categoria.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| categories | Yes | |
| total_categories | Yes |
TDQS
A3.5/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint and openWorldHint=false, so the safety profile is covered. The description contributes the fact that results are aggregated with per-category counts, but says nothing about ordering, whether empty categories appear, or whether the catalogue is static (caching). Adequate but thin given annotations carry most of the load.
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?
A single sentence that front-loads the verb and scope, with the one extra detail (per-category counts) placed where it is most useful. No filler to trim.
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?
An output schema exists, so return-shape details need not be repeated, and annotations cover the read-only, idempotent nature. For a simple zero-param listing tool the description is sufficient, though a note on ordering or on how to follow up with produtos_por_categoria would close the remaining gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so there is no parameter semantics to explain and the baseline of 4 applies. The description correctly implies the call is argument-free by scoping the result to 'todas as categorias'.
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 ('Lista todas as categorias de produtos') and adds the meaningful detail that each entry includes a count ('com contagem por categoria'). It does not, however, distinguish itself from the sibling 'produtos_por_categoria', which an agent could easily confuse with it.
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 when-to-use guidance and no mention of the obvious alternative (produtos_por_categoria) for drilling into a single category's products. The agent must infer the workflow from the description alone; only the zero-parameter signature makes the intent relatively self-evident.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
listar_planosListar PlanosARead-onlyIdempotentInspect
Lista todos os planos e assinaturas oferecidos, com preços, período (mensal/anual/trial) e descrições.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| plans | Yes | |
| total | Yes |
TDQS
A3.8/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and openWorldHint=false, so safety behavior is covered. The description adds useful return-content context (prices, monthly/annual/trial periods, descriptions), but does not discuss pagination, filtering, or rate limits.
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?
A single front-loaded sentence with no redundant or filler content. Every clause contributes to what is listed and what data is returned.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple zero-parameter, read-only listing tool with an output schema and clear annotations, the description provides enough context to call it correctly. No critical behavioral or usage information is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there are no parameter semantics to explain. Baseline 4 applies.
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: listing all offered plans/subscriptions, including prices and billing periods. The resource is clearly distinct from sibling product/category tools, though it does not explicitly name them for differentiation.
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?
Usage is implied by 'Lista todos' and the zero-parameter schema, but there is no explicit guidance on when to choose this tool over alternatives or whether filters exist elsewhere.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
produtos_por_categoriaProdutos por CategoriaCRead-onlyIdempotentInspect
Lista todos os produtos de uma categoria específica.
| Name | Required | Description | Default |
|---|---|---|---|
| categoria | Yes | Nome exato da categoria (ex: 'Colares', 'Vestidos'). Use listar_categorias antes. |
Output Schema
| Name | Required | Description |
|---|---|---|
| total | Yes | |
| products | Yes |
TDQS
C2.9/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true and openWorldHint=false, so the safety profile is covered structurally. The description adds nothing beyond that — no note on pagination, result ordering, or what happens when the category name is not an exact match, which matters given the schema insists on 'Nome exato'.
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?
A single front-loaded sentence with no filler, appropriately sized for a one-parameter list tool. It is efficient but so terse that it leaves obvious questions unaddressed rather than spending a sentence to close them.
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?
An output schema exists, so return values need not be explained, and the only parameter is fully documented in the schema. What remains missing is differentiation from buscar_produtos and any behavior around inexact category names, which an agent would need to call this correctly in a multi-tool environment.
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% and the single parameter is well documented in the schema, including the exact-name requirement and the listar_categorias prerequisite. The description itself adds no parameter meaning beyond restating the category filter, so the baseline of 3 applies.
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 ('Lista todos os produtos de uma categoria específica'), so the agent knows exactly what it retrieves. It does not, however, distinguish itself from the sibling buscar_produtos, leaving the agent to infer the boundary between listing by category and searching products.
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 contains no when-to-use or when-not-to-use guidance and never mentions buscar_produtos or listar_categorias as alternatives. The only prerequisite hint ('Use listar_categorias antes') lives in the schema property, not in the description itself.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
5 tool updates
- Changed
buscar_produtos9 fields changed- added
Input schema / properties / apenas_em_estoqueAdded value: +{ + "description": "Se true, retorna apenas produtos em estoque. Default: false.", + "type": "boolean" +} - added
Input schema / properties / categoriaAdded value: +{ + "description": "Nome exato da categoria (ex: 'Colares'). Use listar_categorias antes para descobrir nomes válidos.", + "type": "string" +} - added
Input schema / properties / limiteAdded value: +{ + "description": "Número máximo de produtos por resposta (1 a 100). Default: 20.", + "maximum": 100, + "minimum": 1, + "type": "integer" +} - added
Input schema / properties / offsetAdded value: +{ + "description": "Quantos resultados pular (paginação). Default: 0.", + "minimum": 0, + "type": "integer" +} - added
Input schema / properties / preco_maxAdded value: +{ + "description": "Preço máximo em BRL (inclusivo). Ex: 100.00 para até R$ 100.", + "type": "number" +} - added
Input schema / properties / preco_minAdded value: +{ + "description": "Preço mínimo em BRL (inclusivo). Ex: 50.00 para a partir de R$ 50.", + "type": "number" +} - changed
Input schema / properties / query / descriptionPrevious value: -"Termo de busca para encontrar produtos por nome (ex: 'colar', 'vestido')."New value: +"Termo de busca por nome do produto (ex: 'colar', 'vestido'). Aceita acentos ou não." - changed
Input schema / requiredPrevious value: -[ - "query" -]New value: +[] - changed
Output schema / (root)Previous value: -nullNew value: +{ + "properties": { + "has_more": { + "description": "True se há mais páginas.", + "type": "boolean" + }, + "products": { + "items": { + "properties": { + "category": { + "type": "string" + }, + "in_stock": { + "type": "boolean" + }, + "name": { + "type": "string" + }, + "price": { + "type": "number" + }, + "url": { + "type": "string" + } + }, + "required": [ + "name", + "price" + ], + "type": "object" + }, + "type": "array" + }, + "returned": { + "description": "Quantos vieram nesta página.", + "type": "integer" + }, + "total": { + "description": "Total de produtos que casam com os filtros.", + "type": "integer" + } + }, + "required": [ + "products", + "total", + "returned", + "has_more" + ], + "type": "object" +}
- Changed
info_empresa1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "properties": { + "categories_count": { + "type": "integer" + }, + "plans_count": { + "type": "integer" + }, + "price_range": { + "properties": { + "max": { + "type": "number" + }, + "min": { + "type": "number" + } + }, + "type": "object" + }, + "products_count": { + "type": "integer" + }, + "slug": { + "type": "string" + }, + "url": { + "type": "string" + } + }, + "required": [ + "slug", + "url", + "products_count", + "categories_count", + "plans_count" + ], + "type": "object" +}
- Changed
listar_categorias1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "properties": { + "categories": { + "items": { + "properties": { + "count": { + "type": "integer" + }, + "name": { + "type": "string" + } + }, + "required": [ + "name", + "count" + ], + "type": "object" + }, + "type": "array" + }, + "total_categories": { + "type": "integer" + } + }, + "required": [ + "categories", + "total_categories" + ], + "type": "object" +}
- Changed
listar_planos1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "properties": { + "plans": { + "items": { + "properties": { + "description": { + "type": "string" + }, + "included_items": { + "type": "integer" + }, + "name": { + "type": "string" + }, + "period": { + "type": "string" + }, + "price": { + "type": "number" + } + }, + "required": [ + "name", + "price", + "period" + ], + "type": "object" + }, + "type": "array" + }, + "total": { + "type": "integer" + } + }, + "required": [ + "plans", + "total" + ], + "type": "object" +}
- Changed
produtos_por_categoria2 fields changed- changed
Input schema / properties / categoria / descriptionPrevious value: -"Nome exato da categoria de produtos (ex: 'Colares', 'Vestidos')."New value: +"Nome exato da categoria (ex: 'Colares', 'Vestidos'). Use listar_categorias antes." - changed
Output schema / (root)Previous value: -nullNew value: +{ + "properties": { + "products": { + "items": { + "properties": { + "in_stock": { + "type": "boolean" + }, + "name": { + "type": "string" + }, + "price": { + "type": "number" + }, + "url": { + "type": "string" + } + }, + "required": [ + "name", + "price" + ], + "type": "object" + }, + "type": "array" + }, + "total": { + "type": "integer" + } + }, + "required": [ + "products", + "total" + ], + "type": "object" +}
2 tool updates
- Changed
buscar_produtos1 field changed- added
Input schema / properties / query / descriptionAdded value: +"Termo de busca para encontrar produtos por nome (ex: 'colar', 'vestido')."
- Changed
produtos_por_categoria1 field changed- added
Input schema / properties / categoria / descriptionAdded value: +"Nome exato da categoria de produtos (ex: 'Colares', 'Vestidos')."
1 tool update
- Added
listar_planos
2 tool updates
- Changed
buscar_produtos1 field changed- removed
Input schema / properties / query / descriptionRemoved value: -"Termo de busca"
- Changed
produtos_por_categoria1 field changed- removed
Input schema / properties / categoria / descriptionRemoved value: -"Nome exato da categoria"
4 tool updates
- First observed
buscar_produtos - First observed
info_empresa - First observed
listar_categorias - First observed
produtos_por_categoria
Related MCP Connectors
Catálogo de 163 produtos em 9 categorias — servido via Scrypta.
Catálogo de 130 produtos em 7 categorias e 4 planos — servido via Scrypta.
Catálogo de 2 produtos em 1 categorias e 2 planos — servido via Scrypta.
25M+ products by GS1 barcode (GTIN/EAN): name, brand, photo, Brazilian NCM and CEST tax codes.
Related MCP Servers
- AlicenseAqualityBmaintenanceStructured product data from the open web — where platform APIs don't reach. Schema.org + AI extraction. Pay per call via Stripe MPP.241 npm3Apache 2.0
- FlicenseNot gradedqualityDmaintenanceRemote MCP Server for industrial vacuum cleaner configuration. Query 150+ products across 24 industrial sectors with full ATEX certification data, technical specs, and accessory compatibility. No authentication required.2-
- AlicenseNot gradedqualityBmaintenanceEnables MCP clients to search Webhallen’s product catalog, browse categories, compare products, check current and 30-day-lowest prices, inspect physical-store stock, and read customer reviews.9 npm1MIT
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd
Glama MCP Gateway
Add one secure layer between your agents and this server.