merch-connector

by grahamton

Overview Schema Related Servers Score Discussions

JavaScript

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v2.1.0
Disambiguation4/5
Most tools have clear, distinct purposes with explicit guidance (e.g., acquire is the primary entry point, scrape_pdp is for PDPs, scrape_page is deprecated). However, some analytical tools (merch_roundtable, analyze_products, ask_page) have overlapping functionality, though descriptions clarify input sources.
Naming Consistency4/5
Tool names generally follow a verb_noun snake_case pattern (scrape_pdp, compare_storefronts, list_evals). A few exceptions like 'acquire', 'site_memory', and 'merch_roundtable' deviate slightly, but the overall pattern remains consistent and readable.
Tool Count5/5
With 14 tools, the server is well-scoped for its purpose, covering scraping, analysis, interaction, comparison, memory, and evaluation. Each tool earns its place, and the count is within the optimal range.
Completeness4/5
The server covers the full workflow: acquire data, scrape specific products, interact, compare, ask questions, analyze offline, and save/list evals. Minor gaps include no explicit delete for evals or memory, but these are not critical to the core functionality.
Average 4.4/5 across 14 of 14 tools scored. Lowest: 3.9/5.
See the Tool Scores section below for per-tool breakdowns.
This repository is archived. Archived repositories automatically receive an F maintenance tier.
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full load. It discloses that actions are executed sequentially, session cookies carry over automatically, and it returns page data. However, it does not explain the shape of the returned data, failure behavior, or any side effects beyond cookie handling, leaving notable transparency gaps for a stateful interaction tool.
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 sentences, front-loaded with the primary action and result, then a brief note on modes and cookies. Every word earns its place with no redundancy.
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?
The tool has no output schema, so the description must clarify return values. 'Return the resulting page data' is vague about the format. It also omits error handling and any prerequisites beyond the URL. For a 6-parameter tool with nested action objects, this is under-specified.
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 reinforces the single-action vs. array distinction and gives a concrete example, but this does not add substantially beyond what the schema already explains for each parameter.
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 uses a specific verb ('Execute'), specifies the resource ('storefront page'), and defines the scope ('search/click actions in sequence'). It clearly distinguishes itself from sibling tools like scrape_page by emphasizing interaction (actions) rather than passive extraction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear context for when to use this tool: for single or multi-step interactions, with an example flow ('search → filter → click'). However, it does not explicitly mention when not to use it or name alternatives, so it falls short of full exclusions guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral disclosure. It explains the multi-step process (independent evaluation, debate, synthesis) and the 'EXPERIMENTAL' status. It also discloses the caching behavior with scrape_page. This provides substantial insight beyond a simple 'analyzes the page' statement, though it does not explicitly state side-effect-free behavior or referential details like timeout 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a well-structured paragraph with front-loaded purpose, followed by persona details, process, and caching behavior. Each sentence adds informative value, though it is slightly longer than necessary. For a complex tool, this level of detail is justified, and it remains concise overall.
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?
Given the tool's complexity, the description covers the key contextual elements: personas, process, output (prioritized recommendations with endorsements), and cache reuse. There is no output schema, so the description's mention of the output format partially compensates. Missing details about edge cases (e.g., invalid URL) or auth are not critical for an experimental analysis tool. It is reasonably complete.
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% for all three parameters, so the baseline is 3. The description adds no additional meaning beyond the schema; it does not elaborate on how 'depth' or 'max_products' affect the analysis, nor does it clarify the 'url' parameter beyond its schema definition. The description relies on the schema for parameter semantics.
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 the tool's specific verb and resource: 'Run a multi-perspective merchandising analysis' with three named personas. It distinguishes from siblings by describing the unique multi-persona debate and consensus process, and the output of prioritized recommendations. This is a specific, non-tautological purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool: for a multi-perspective merchandising analysis. It also hints at the relationship with scrape_page by mentioning cache reuse. However, it does not explicitly contrast with sibling tools like ask_page or compare_storefronts, nor does it state when not to use it. Clear context but no exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses key behavioral traits: no live network requests, requires configured AI provider keys, computes a page fingerprint, and runs either a single persona or full roundtable. It also clarifies the 'auto' behavior. This is good disclosure for a complex analysis tool, though it does not mention side effects or return format, which would be helpful.
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?
The description is two sentences, front-loaded with the core purpose and key constraints. It packs in the input format, behavior, use cases, and requirements without unnecessary filler. Every phrase earns its place, making it concise and well-structured.
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?
The tool has 7 parameters, no output schema, and no annotations. The description covers its purpose, inputs, behavior, use cases, and prerequisites thoroughly. The only notable gap is the absence of information about the return value or result structure, but given the tool's clear analysis function and the lack of an output schema, this is a minor omission. Overall, it is sufficiently complete for an agent to understand when and how to invoke it.
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 coverage is 100%, so the baseline is 3. The description adds some context (e.g., 'computes a page fingerprint' to explain the persona selection), but it largely mirrors what the schema already describes for products, facets, and persona. No additional parameter-level details beyond the schema are provided, which is acceptable given the schema's thoroughness.
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 opens with a specific verb and resource: 'Run full persona analysis on pre-scraped product data.' It clearly distinguishes this from live-scraping siblings like scrape_pdp and acquire by emphasizing 'without making any live site requests.' The mention of offline analysis and persona roundtables makes the tool's purpose unmistakable and differentiates it from other tools in the list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit use cases: 're-analyze acquire payloads offline' and 'analyze data from external sources (CSV exports, internal APIs, DTC Research server handoffs).' It also states a prerequisite (AI provider configuration). However, it does not explicitly name an alternative tool for live-scraping scenarios, though siblings like scrape_pdp imply those cases. This is clear context but lacks an explicit 'if you need live data, use X instead' statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the in-memory buffer nature, the 500-entry cap, newest-first ordering, and filter capabilities. While it doesn't mention side effects or permissions, it is a read-only operation and the details provided offer sufficient transparency.
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?
Three concise, front-loaded sentences. The first sentence gives the core functionality, the second explains ordering/filtering, and the third provides practical use cases. No wasted words.
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 three optional parameters and no output schema, the description explains the return order and buffer limits, but could say a bit more about the structure of each log entry. Still, it provides enough for an agent to understand the tool's scope and purpose.
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 baseline is 3. The description confirms filtering by level or tool name, matching the schema, but does not add extra semantic detail beyond what the parameter descriptions already provide.
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 the action ('Retrieve'), the resource ('server log entries from the in-memory buffer'), and specific constraints (last 500 entries, newest-first). It distinguishes this tool from its web-scraping siblings by focusing on server logs, a unique function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context for when to use the tool ('reviewing roundtable notification streams, debugging tool calls, capturing logs...'). No explicit exclusions or alternatives, but the use cases are specific and helpful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 burden. It discloses the output signals including performance timing, but does not explicitly state read-only behavior, potential failure modes, or any side effects. This is adequate but not comprehensive.
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 sentences, direct, no filler. The first sentence states purpose and lists outputs; the second provides usage guidance.
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?
For a single-parameter tool with no output schema, the description covers the purpose, key outputs, and usage distinction. It lacks explicit return structure but is reasonably complete.
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?
The schema has one param 'url' with a clear description, and schema coverage is 100%. The description adds context that the URL should be a PDP, but parameters are well-documented in the schema, so baseline 3 is appropriate.
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 uses the specific verb 'scrape' and identifies the resource as 'product detail page (PDP)', listing concrete signals returned. It explicitly distinguishes from sibling scrape_page by naming it and stating when to use this alternative.
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?
The description explicitly states 'Use this instead of scrape_page when the target is a single product page,' providing a clear alternative and condition. This satisfies the 'when/when-not/alternatives' criterion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well: it discloses caching behavior (10-minute reuse), what data the AI sees (product data, facets, performance metrics, screenshot), and a practical usage tip. No side effects or contradictions are present.
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?
The description is slightly long but every sentence adds value: what it does, what the AI sees, caching, use cases, and a tip. It is well-structured and front-loaded with the core purpose, though it could be trimmed slightly without losing essential info.
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?
Given no output schema and no annotations, the description adequately covers the tool's behavior, data exposure, caching, and ideal use cases. It does not mention error handling or edge cases, but for a query tool with 4 parameters and no output schema, it is sufficiently complete.
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 coverage is 100%, so each parameter is already described. The description adds some context by explaining that the AI sees full product data and that a cached scrape may be reused, but it does not elaborate on depth or max_products beyond the schema. Baseline 3 is appropriate.
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 a specific verb ('Ask') and resource ('storefront page'), and differentiates from siblings like scrape_page and interact_with_page by emphasizing natural language ad-hoc questions. It also lists concrete example questions, making the tool's purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context with example questions and a performance tip about calling scrape_page first. However, it does not explicitly state when not to use this tool or compare it to alternatives like analyze_products, so it lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses important behaviors: memory persists across sessions and restarts, and it auto-accumulates on every scrape. This adds context beyond the schema, though it could further describe what happens on delete or how reads are returned.
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?
The description is two sentences plus examples, with the main action front-loaded. Every sentence adds information: purpose, auto-accumulation, persistence, and realistic usage examples. No filler or redundancy.
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?
The tool has multiple actions (read/write/list/delete) and no output schema. The description explains the overall concept but does not specify return values or action-specific behavior (e.g., what 'read' returns or what 'list' outputs). This is a notable gap for a multi-action tool, though the schema's action descriptions partially fill it.
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 schema already covers all parameters (100% coverage), so the baseline is 3. The description adds value by giving example keys ('waitTime', 'customSelector') and note content, which clarifies how 'key' and 'note' might be used in practice. This pushes it above baseline.
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 the tool's function: 'Read, write, or list persistent memory about websites.' It uses specific verbs and a specific resource, and the examples (wait time, custom selectors, login cookies) make the purpose concrete. While 'delete' is omitted from the verb list, the core purpose is unmistakable and distinguishes it from sibling tools focused on scraping and interaction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage scenarios with 'Use this to add custom notes' and concrete examples. It also notes that memory auto-accumulates, implying it's the place for persistent data. However, it does not mention when not to use the tool or compare against alternatives, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 key behaviors: scraping category page with caching ('or uses cached data'), strategy-based URL selection, and parallel calls to scrape_pdp. It also explains the three strategies in detail. This goes beyond the schema and gives the agent a clear picture of the tool's execution model.
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?
The description is concise and well-structured: it opens with the primary purpose, explains the workflow, states the use case, and lists strategies. Each sentence earns its place, with no unnecessary filler. The density of useful information is high.
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?
For a tool with three parameters, full schema coverage, and no output schema, the description is comprehensive. It covers what the tool does, how it works, when to use it, and parameter semantics. It doesn't describe return values, but given the tool's simplicity and the sibling scrape_pdp's likely role, this is a minor gap. Overall, it's complete enough for reliable selection and invocation.
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?
Schema coverage is 100%, so the baseline is 3. The description adds value by explicitly defining the strategy enum values ('spread' as low/mid/high price tiers, 'random', 'top' as first N products). This is not present in the schema descriptions, enhancing the agent's understanding of how to choose a strategy.
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 the tool's purpose: 'Sample a set of PDPs from a category page.' It distinguishes this from sibling tools like scrape_pdp by describing its multi-step workflow (scrape category page, pick URLs, call scrape_pdp in parallel). The verb 'sample' is specific and differentiates from direct scraping.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description says it's 'Useful for PDP spot-checks without manual URL selection,' which provides clear context for when to use it. It doesn't explicitly name alternatives or exclusions, but the mention of calling scrape_pdp implies it's a higher-level alternative. This meets the 'clear context, no exclusions' level.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does so thoroughly. It discloses the scraping engine order (Puppeteer first, Firecrawl fallback), cost implications, offline-analysis design, and the warnings[] array with specific quality flag examples. This exceeds expectations.
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?
The description is dense yet front-loaded with a clear summary, then usage guidance, fallback details, and warnings. Each sentence earns its place, but the length and single-paragraph structure make it slightly less scannable than ideal; a 5 would require tighter organization.
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?
For a tool with no output schema, the description lists the major data categories returned (products, screenshots, metrics, trust signals, etc.) and mentions warnings[] for quality issues. It does not specify the exact payload format, but given the breadth of the tool, the description is largely complete; minor absence of return-type detail prevents a 5.
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 coverage is 100% and both parameters have detailed descriptions. The tool description does not add meaningful parameter-specific semantics beyond referencing 'automatically sampled PDP details', which the schema already covers. Baseline 3 is appropriate.
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 uses a specific verb ('Acquire') and resource ('complete structured payload from a storefront page'), immediately clarifying the tool's core function. It further distinguishes itself from sibling tools by declaring itself 'the primary entry point for any storefront audit'.
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?
The description explicitly tells when to use this tool ('Use this as the primary entry point'), when not to rely on alternatives ('designed for offline analysis'), and provides conditional guidance for the Firecrawl fallback ('only when Puppeteer is blocked... and FIRECRAWL_API_KEY is set'), including that Firecrawl is reserved for WAF-protected sites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the destructive behavior of wiping cookies and cached data, and notes the domain scope. It doesn't mention irreversibility or session storage details beyond cookies/cache, but for a simple tool this is adequate.
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?
The description is two sentences: first states the purpose and mechanics, second gives usage examples. Every word earns its place with no redundancy or filler.
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 one-parameter, no-output-schema tool, the description is complete. It covers what the tool does, what it affects, and when to use it. No additional context is needed.
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?
Schema coverage is 100% with a clear parameter description. The tool description adds value by clarifying that any URL on the domain works, not just the exact homepage, and provides an example. This goes beyond the schema's basic description.
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 the tool's function with a specific verb and resource: 'Clear the stored session for a domain' and specifies exactly what is wiped (cookies and cached page data). This distinguishes it from sibling tools like scrape_pdp or interact_with_page.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use this to start fresh' and provides concrete example use cases (testing logged-out vs logged-in, forcing a fresh scrape). It lacks explicit when-not-to-use guidance or alternative tool references, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
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. It explicitly states that the tool scrapes URLs, discloses caching behavior ('reuses cached page data if either URL was scraped in the last 10 minutes'), and lists the exact outputs. This goes well beyond what a minimal description would provide and gives the agent a strong basis for predicting side effects and performance.
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?
The description is three sentences, front-loaded with the primary action, and uses compact list-style phrasing for the diff components. Every sentence earns its place, and the caching note is efficiently integrated into the final sentence. There is no fluff or redundancy.
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?
Despite the absence of an output schema, the description enumerates all major return components, covering product count, facets, trust signals, sort options, B2B mode, and performance. It also mentions caching behavior and the default product count context. This is sufficient for an agent to understand what the tool produces and how it behaves, even without an output schema.
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%, with clear descriptions for url_a, url_b, and max_products. The tool description adds overall context about the diff output but does not add meaningful parameter-level semantics beyond what the schema already provides. A baseline of 3 is appropriate because the schema handles parameter explanation 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 opens with a specific verb ('Scrape') and a clear resource ('two storefront URLs'), then enumerates the exact comparison dimensions returned (product count delta, facet gaps, trust signal coverage, sort option gaps, B2B mode, performance delta). This clearly distinguishes it from sibling tools like scrape_pdp or scrape_page, which focus on individual pages rather than side-by-side storefront comparisons.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes the use case explicit: comparing two storefront URLs and receiving a structured diff. It does not explicitly state when not to use it or name alternatives, but the detailed output summary and the caching note imply a comparison workflow that is distinct from the sibling scraping tools. It provides clear context without exclusions, which fits a 4.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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. It does that by specifying output details (newest first, convergence scores, top concerns, moderator summaries) and the full-run retrieval behavior via run_id. It could add more about pagination or rate limits, but the core behavior is clearly disclosed.
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?
The description is three sentences with no fluff. It leads with the primary purpose, then explains the branching behavior, then gives application use cases. Every sentence earns its place.
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?
The tool is simple (3 optional params, no output schema), and the description covers all functional branches: with URL, without URL, and using run_id for deep inspection. It also lists what the returned data contains, making it complete for an agent to invoke correctly.
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 schema covers 100% of parameters, so the baseline is 3. The description adds meaningful context beyond the schema: it clarifies that url filters by domain, run_id retrieves 'complete persona outputs', and limit controls record count. This enriches parameter understanding enough to warrant a 4.
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 the tool 'List saved eval runs from the eval store', which is a specific verb+resource combination. It distinguishes itself from siblings like save_eval and get_logs by focusing on the eval store and the conditional behavior (per-domain history vs. all domains).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use guidance: 'If a URL or domain is provided, returns... If no URL is provided, returns...' and includes example use cases like tracking trends and comparing runs. It does not mention when not to use it or name alternatives, so it falls just short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses network interception, caching behavior, automatic session cookie management, and the absence of AI analysis. This is rich behavioral context beyond the raw schema.
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?
The description is a single dense paragraph, but it is front-loaded with the deprecation notice and every sentence adds meaningful detail. A bit long, but appropriate given the tool's complexity and lack of 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?
Given high complexity, no output schema, and no annotations, the description is remarkably complete. It covers return categories, caching, session handling, platform fingerprinting, and deprecation, leaving little ambiguity about what the tool does and its side effects.
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 coverage is 100%, so the baseline is 3. The description does not add parameter-level explanation, but it provides domain context about what the scraped data will contain. Since each parameter is already fully documented in the schema, 3 is appropriate.
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 the tool extracts raw structured data from storefront URLs without AI analysis, enumerates the returned data categories, and explicitly marks the tool as deprecated with a direct alternative. This distinguishes it from siblings like scrape_pdp and acquire.
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?
The deprecation notice explicitly directs users to use 'acquire instead', providing a clear when-not-to-use instruction. It also notes that results are cached and reused by audit_storefront or ask_page, giving additional context for downstream usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully takes on the transparency burden. It discloses that the tool reads from session cache, returns an eval ID with a convergence score, and details persistence behavior (storage path, 100 compact records + 10 full runs per domain). This goes beyond simple 'saves data' and gives the agent a clear model of side effects and persistence.
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?
The description is three sentences, each earning its place: purpose/prerequisite, return values, and persistence/history guidance. It is front-loaded with the primary action, avoids redundancy, and maintains a logical flow from what the tool does to how to use it. No filler is present.
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?
Given the tool's moderate complexity and lack of annotations/output schema, the description is remarkably complete. It covers prerequisites, return values, storage semantics, limits, and relationship to a sibling tool. An agent could invoke save_eval correctly and understand the consequences without external documentation.
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?
The input schema already has 100% coverage with clear descriptions for all three parameters (url, note, save_full_run), so the baseline is 3. The description adds no substantial parameter-level detail beyond what the schema provides; it only contextualizes the overall workflow. It does not repeat or enhance the schema's parameter explanations.
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 opens with a clear verb-resource pairing: 'Save the current roundtable or audit persona results for a URL to the eval store.' This distinguishes save_eval from sibling tools like list_evals (which reviews history) and merch_roundtable (which produces the results). It accurately states the tool's core function without ambiguity.
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?
The description explicitly states the prerequisite: 'call merch_roundtable or audit_storefront first on the same URL.' It also directs users to list_evals for reviewing history, creating a clear when-to-use versus alternative-tool distinction. This gives concrete context for when save_eval is appropriate and what must occur before invoking it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![merchGent MCP server](https://glama.ai/mcp/servers/grahamton/merchGent/badges/card.svg)](https://glama.ai/mcp/servers/grahamton/merchGent)

Score Badge

Copy to your README.md:

[![merchGent MCP server](https://glama.ai/mcp/servers/grahamton/merchGent/badges/score.svg)](https://glama.ai/mcp/servers/grahamton/merchGent)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/grahamton/merchGent'

If you have feedback or need assistance with the MCP directory API, please join our Discord server