Public read-only MCP server to discover and compare maternity and nursing fashion.
Compare 2-10 Mamanida products on one storefront. Each product is returned with the same public contract as get_product (localized details, availability, retailer-authoritative and displayed prices, AFFILIATE / DIRECT / BLOCKED commercial state and its canonical Mamanida URL), so prices and availability are directly comparable within that storefront.
| Name | Required | Description | Default |
|---|---|---|---|
| slugs | Yes | Between 2 and 10 product slugs. | |
| storefront | Yes | Required storefront id, e.g. 'int', 'se', 'dk', 'no', 'fi', 'us'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the detailed return contract (localized details, availability, retailer-authoritative and displayed prices, commercial state, canonical URL) and notes that prices are directly comparable. It does not explicitly state read-only behavior or error handling, but the operation is clearly a query and the output behavior is well specified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with the core action and constraints front-loaded. The second sentence is dense but each element—return contract fields and comparability—adds meaningful information for selecting and invoking the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 does a good job explaining both input constraints and expected return values. It omits explicit error behavior or handling of invalid slugs, but for a 2-parameter comparison tool the essential information is present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides full descriptions for both parameters with 100% coverage, so the baseline is 3. The description reinforces the 2-10 range and single-storefront requirement, but adds no additional parameter-level semantics beyond what the schema already states.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Compare'), the exact resource ('Mamanida products'), the allowed quantity range (2-10), and the storefront scope. References get_product's contract, which helps distinguish this comparison tool from the single-product get_product tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Clearly conveys that this tool is for comparing multiple products within one storefront. It implies get_product is the alternative for a single product by referencing its contract, but it does not explicitly state when not to use this tool or name alternatives like search_products.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Mamanida's editorial buying guides for one storefront, in that storefront's own language. Called without guide it lists the published guides (metadata only: title, deck, meta description, pillar, topics, dates and the canonical Mamanida URL), optionally filtered by topic. Called with guide (the guide slug from the listing) it returns that one localized edition plus its structured body: paragraphs, headings, lists, comparison tables, callouts, links to other guides and category calls-to-action. A category_cta gives a category_slug you can pass straight to search_products, which is the intended guide → category → product path. Retailer and affiliate URLs are never returned.
| Name | Required | Description | Default |
|---|---|---|---|
| guide | No | Guide slug as it appears in the Mamanida guide URL. Omit to list guides. | |
| topic | No | Authoritative topic id, e.g. 'maternity-jeans'. Filters the listing. | |
| storefront | Yes | Required storefront id, e.g. 'int' (English), 'se', 'dk', 'no', 'fi', 'us'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure and does so thoroughly. It explains what is returned in list mode vs. detail mode, lists the metadata fields, describes the structured body components, and explicitly states that retailer and affiliate URLs are never returned — a useful negative guarantee.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but well-structured: it opens with the core purpose, then covers both invocation modes in logical order, then integration and exclusions. Every sentence adds value, and no information is wasted or redundant with the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema, the description does an excellent job of explaining return contents: metadata fields for listings and structured body elements for single guides. It also covers locale behavior, filtering, and the integration path with `search_products`, making the tool effectively self-documenting for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description adds meaningful semantics beyond the schema: `guide` is a slug from the listing, `topic` filters the listing, and `storefront` determines the localized language edition. This enriches the agent's understanding of how parameters change tool behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb-resource pair ('List or read Mamanida buying guides') and distinguishes the two invocation modes (listing vs. reading a single guide). It also differentiates this tool from product-focused siblings by emphasizing editorial guide content and the guide → category → product path.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit context for when to use each mode: omit `guide` to list, provide `guide` to read a specific localized edition. It also names the intended downstream tool, `search_products`, and how to pass `category_slug`, though it does not explicitly state when to prefer sibling tools like `get_product` or `list_categories`.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch full public details for one Mamanida product on a specific storefront: localized summary, fabric and bump-panel facts, sizes, colours, availability (IN_STOCK / OUT_OF_STOCK / UNKNOWN), the retailer's authoritative price plus the storefront's displayed price, and whether the outbound link is AFFILIATE, DIRECT or BLOCKED. Only the canonical Mamanida URL is returned.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Product slug as it appears in the Mamanida product URL. | |
| storefront | Yes | Required storefront id, e.g. 'int', 'se', 'dk', 'no', 'fi', 'us'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full disclosure burden. It discloses the exact categories of returned data, availability enum values, price semantics, outbound-link classification, and the canonical-URL-only constraint. It does not discuss error cases or rate limits, but for a public read operation this is reasonable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, information-dense sentence that front-loads the action and resource. It lists many relevant details without filler, though the length and nested clauses make it slightly dense to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description must explain the return shape, and it does so thoroughly by listing fields and enums. For a two-parameter public fetch tool, this is largely complete; minor omissions like error behavior are not critical here.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema covers both parameters with descriptions: slug and storefront, including examples and enum values. The tool description does not add much beyond 'specific storefront', but since schema coverage is 100%, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Fetch') and identifies the exact resource: full public details for one Mamanida product on a specific storefront. It enumerates the return fields, making the tool's purpose unambiguous and clearly distinct from siblings like search_products or compare_products.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: use this tool when you need detailed, single-product data for a specific storefront using slug and storefront. It does not explicitly name alternatives or when-not-to-use conditions, but the singular 'one product' scope and the canonical-URL constraint imply the right selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the canonical product categories available on one Mamanida storefront. Each entry gives the exact slug to pass to search_products, a label in the storefront's language, any existing localized aliases, and the number of products currently visible on that storefront. Only categories with at least one visible product are returned, and the order is Mamanida's own category order (never product counts).
| Name | Required | Description | Default |
|---|---|---|---|
| storefront | Yes | Required storefront id, e.g. 'int' (English), 'se', 'dk', 'no', 'fi', 'us'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It reveals that only categories with at least one visible product are returned, that ordering follows Mamanida's own sequence rather than product counts, and that labels are localized to the storefront language. It does not discuss pagination or error cases, but for a simple list operation this is solid coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences with no filler: it front-loads the action and resource, then efficiently conveys output fields, filtering, and ordering. Every sentence adds information relevant to invoking the tool correctly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has only one parameter, no annotations, and no output schema, the description adequately explains the output fields and key behavioral nuances (filtering and ordering). It stops short of describing response envelope or potential empty results, but those are minor gaps for a simple list endpoint.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and includes an enum plus examples, so the baseline is 3. The description adds useful semantic context by tying the storefront parameter to the localized label language and to the notion of 'one Mamanida storefront,' which helps an agent understand how the parameter affects the output without repeating the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource ('List the canonical product categories available on one Mamanida storefront') and goes beyond a generic phrase by detailing what each entry contains. It also differentiates the tool from the sibling search_products by noting the returned slugs are meant to be passed to that function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear usage context: it is the source for exact category slugs to use with search_products, and it explains the filter (only categories with visible products) and ordering behavior. It does not explicitly enumerate when not to use this tool or compare against all siblings, but the downstream use case is clearly conveyed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Mamanida's maternity and nursing clothing catalogue for one storefront. Returns only products a visitor of that storefront can actually see, with the retailer's authoritative price, the storefront's displayed price (marked when it is an approximate conversion), availability and the commercial state of the outbound link. Links returned are canonical Mamanida product URLs; retailer and affiliate URLs are never exposed.
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | relevance | |
| brand | No | Exact brand name filter. | |
| limit | No | ||
| query | No | Free-text query, max 100 characters. | |
| offset | No | ||
| on_sale | No | Only products currently discounted. | |
| category | No | Category slug, e.g. 'dresses'. | |
| storefront | Yes | Required storefront id, e.g. 'int' (English), 'se', 'dk', 'no', 'fi', 'us'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral burden, and it delivers: it discloses storefront-visibility filtering, the two price types (authoritative and displayed with approximate-conversion marking), availability, commercial state of outbound links, and the policy that retailer/affiliate URLs are never exposed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tightly written sentences: the first states the exact purpose and scope, the second packs the key return-field and URL-policy details. Every sentence earns its place with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers scope, visibility filtering, key returned fields, and link policy, which is strong for a no-output-schema tool. It leaves minor gaps around pagination/limit semantics and the exact output shape, but schema defaults and constraints cover part of that.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 63%, so some parameters already have descriptions. The description explains return behavior but adds little to the semantics of sort, limit, offset, or query/category interaction, so it does not significantly compensate for the undocumented parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Search Mamanida's maternity and nursing clothing catalogue for one storefront.' It clearly distinguishes this tool from siblings like get_product or compare_products by emphasizing storefront-scoped catalogue search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear usage context: search is scoped 'for one storefront' and 'returns only products a visitor of that storefront can actually see.' It does not explicitly name excluded alternatives, but the storefront-visibility framing allows an agent to select this over detail/comparison tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user or an account that owns the GitHub organization, then choose Claim with GitHub.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
Public MCP server for discovering open jobs. Search, filter, and get application links.
Read-only MCP server for public WeJob jobs, formations, and companies.
Federated commerce search across independent WooCommerce merchants. Keyless, read-only MCP server.
Read-only MCP server for ClassQuill, a tutoring-business-management platform.
Add one secure layer between your agents and this server.
Each tool has a clearly distinct purpose: listing categories, searching products, fetching a single product, comparing multiple products, and retrieving editorial guides. No two tools appear to perform the same function, even though compare_products reuses the product contract for comparability.
All tool names follow a consistent lowercase verb_noun pattern: compare_products, get_guides, get_product, list_categories, search_products. The verb clearly indicates the action and the noun clearly indicates the resource, making the set highly predictable.
Five tools is well-scoped for a catalogue-oriented MCP server. Each tool covers a distinct user need without redundancy, and the count feels neither thin nor bloated.
The tool surface covers the full browse-and-discover workflow: guides lead to categories, categories lead to search results, search results lead to product details, and products can be compared. There are no obvious dead ends or missing operations for the stated catalogue purpose.
