Skip to main content
Glama
Sign In
Crawlora MCP

Crawlora MCP

Official
by Crawlora-org
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

modaoperandi_product

Fetch a Moda Operandi product by URL to retrieve its name, designer, price, images, available sizes, and stock status for product research or catalog enrichment.

Instructions

Get a Moda Operandi product. Returns one Moda Operandi product by its product page url: id, name, designer, color, price and currency, description, details, images, and the available sizes. It also reports availability and an in_stock flag for the product.

Input Schema

NameRequiredDescriptionDefault
urlYesModa Operandi product URL

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.17.5

TDQS

A3.5/5.0
Behavior3/5

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

No annotations are provided, so the description carries the full behavioral burden. It does disclose the payload shape and that availability/in_stock are reported, which is genuine behavioral detail, but it says nothing about failure modes (invalid or non-product URL), authentication, or rate limiting for a single-URL fetch.

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 sentences, front-loaded with the action and then the returned fields; no filler or repetition of the tool name beyond the opening. The field enumeration is list-like but earns its place given there is no output schema.

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 no output schema and no annotations, the description compensates by enumerating returned fields and noting availability/in_stock. Enough for an agent to call it correctly; only error handling and the search-to-URL workflow are 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?

One parameter with 100% schema description coverage, so the schema already defines `url` as the Moda Operandi product URL. The description only restates that it must be a product page URL, adding marginal semantics 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 (Get) and resource (Moda Operandi product) and clarifies retrieval is keyed by the product page URL, which implicitly separates it from modaoperandi_search/modaoperandi_categories. It never names those siblings explicitly, so the differentiation is inferred 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 "by its product page `url`" implies the prerequisite (you must already have a product URL), which is useful usage context. However, there is no explicit when-to-use guidance and no mention of modaoperandi_search as the way to obtain a URL in the first place.

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