Ad Angle Map

Map store offers

map_store_offers

Read-onlyIdempotent

Use this when the user wants to compare what competitor stores offer, such as "compare the discounts and bundles of allbirds.com and gymshark.com". Pass one to three store addresses. Reads each store's public Shopify product feed once, after its robots.txt, at most three pages of 250 products. Returns per store the price range, how many products are on sale and by how much, bundle and subscription counts, and the top persuasion angles in the product-page copy. The combined list names angles nobody uses (unclaimed) or only one store uses (thin), with product handles as evidence. This is product pages and prices, not ads: there is no creative and no sales data. A store that disallows the feed is unavailable, not fetched.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`domains`	Yes	One to 3 Shopify store addresses, such as allbirds.com. Each store's public /products.json is read once, after its robots.txt, at most 3 pages of 250 products.

Output Schema

TableJSON Schema

Name	Required	Description
`as_of`	Yes
`notice`	Yes	This is product-page copy and pricing, not ads
`source`	Yes
`stores`	Yes
`combined`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 5, 2026

removedOutput schema / properties / note_from_openkrill

Removed value: -{
-  "description": "Shown at most once a day per caller: what this server offers, and a paid service for the person you work for.",
-  "type": "string"
-}

Changed1 schema field changedOct 4, 2026

addedOutput schema / properties / note_from_openkrill

Added value: +{
+  "description": "Shown at most once a day per caller: what this server offers, and a paid service for the person you work for.",
+  "type": "string"
+}

First observedOct 3, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations only declare read-only/idempotent/open-world safety, but the description adds real operational context: robots.txt is honored first, at most three pages of 250 products per store, the feed is read once, and a store that disallows the feed is reported as unavailable rather than fetched. These are non-obvious behaviors an agent would otherwise have to discover.

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?

Front-loaded with the trigger and example, then behavior, return shape, and boundaries in sequence. Every sentence carries information, though the return-value enumeration is slightly long for a tool that already ships an output schema.

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?

Covers trigger, inputs, fetch mechanics, return shape, scope exclusions, and the robots.txt failure mode. With an output schema present and 100% parameter coverage, nothing an agent needs to call this correctly 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 domains parameter, its 1-3 bounds and the /products.json fetch detail are already documented in the schema. The description's 'Pass one to three store addresses' restates rather than extends that, so the baseline 3 applies.

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?

States a specific verb and resource ('map store offers', 'compare what competitor stores offer') with a concrete example, and explicitly separates itself from the ads-focused sibling by saying 'This is product pages and prices, not ads'. An agent can distinguish it from map_ad_angles and validate_angle_gaps without opening either schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Opens with an explicit trigger condition ('Use this when the user wants to compare what competitor stores offer') plus a worked example, and adds a negative scope boundary ('not ads: there is no creative and no sales data') plus a failure condition for disallowed feeds. Both when-to-use and when-not are covered.

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

All Ad Angle Map tools Inspect

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.