WhizzyCommerce

seo_set

Set how the shop describes itself to search engines. Money is integer minor units (cents). Calling this changes nothing: it returns a preview of what would change and a confirmation link. Only the merchant, on that page, can make it happen.

Input Schema

Name	Required	Description
`llmsTxt`	No	The shop's llms.txt (llmstxt.org), served at /llms.txt for AI assistants: markdown, an H1 with the shop's name, a > summary line, short facts (delivery, returns, contact), then ## sections of [links](url). Write {{catalogue}} where the generated product, category and page lists should go so they stay current. Empty goes back to the generated file, which is already served for every shop.
`seoTitle`	No	The title search results show for the shop, cut at about 60 characters. Empty falls back to the shop's name.
`robotsTxt`	No	The shop's robots.txt as crawlers read it. Empty, or the same as the platform's own, goes back to the platform's rules.
`robotsPolicy`	No	What every page tells crawlers. index_follow is the normal choice; noindex takes the shop out of search results.
`robotsSitemaps`	No	Which sitemaps robots.txt names, as paths like /sitemap.xml or /pt/sitemap.xml. null names all of them, including languages published later.
`seoDescription`	No	The line under the title in search results, cut at about 155 characters. Empty falls back to the tagline.
`socialImageUrl`	No	The picture shown when the shop's address is shared on social networks, as a full https:// URL. Empty clears it.
`structuredData`	No	What search engines are told about the business beyond its other settings, on every page: Settings > Search engines > Business in search results. Only the fields given change.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 7, 2026

addedInput schema / properties / llmsTxt

Added value: +{
+  "description": "The shop's llms.txt (llmstxt.org), served at /llms.txt for AI assistants: markdown, an H1 with the shop's name, a > summary line, short facts (delivery, returns, contact), then ## sections of [links](url). Write {{catalogue}} where the generated product, category and page lists should go so they stay current. Empty goes back to the generated file, which is already served for every shop.",
+  "maxLength": 50000,
+  "type": "string"
+}

Changed1 schema field changedOct 22, 2026

addedInput schema / properties / structuredData / properties / verifications

Added value: +{
+  "description": "Site ownership tags to put in the head of every page, pasted as the service gives them, one <meta> per line: Trustpilot's trustpilot-one-time-domain-verification-id, Google's google-site-verification, Bing's msvalidate.01, Pinterest's p:domain_verify, Meta's facebook-domain-verification. Replaces the list; only verification tags are kept. Settings, Search engines, Verification tags.",
+  "maxLength": 4000,
+  "type": "string"
+}

First observedOct 15, 2026

TDQS

B3.4/5.0

Behavior1/5

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

The description states 'Calling this changes nothing' and describes a preview/confirmation flow, which directly contradicts the readOnlyHint=false annotation. This is an annotation contradiction; the useful disclosure about merchant-only confirmation is overshadowed by the conflict.

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?

Four short sentences, front-loaded with purpose and followed by the critical preview behavior; no wasted words. The money-unit note is compact and relevant.

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 an 8-parameter nested tool with no output schema, the description supplies the essential return behavior (preview and confirmation link) and the merchant-only constraint. It doesn't cover persistence or how unchanged fields behave, but the schema description handles field-level semantics, so it's mostly 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% and nested object descriptions are thorough, so the schema carries parameter meaning. The description adds a global note that money is integer minor units (cents), but this is largely redundant with the per-field schema text; no additional parameter routing or constraints are provided.

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 (set) and resource (how the shop describes itself to search engines), clearly distinguishing this SEO configuration tool from general settings and branding siblings. An agent can identify the intent without opening the schema.

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?

Implies use when configuring SEO metadata and explains the two-step confirmation workflow, but does not name alternatives such as settings_details or policies_write or clarify when to use this versus them. The preview caveat is useful context but not explicit routing guidance.

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

All WhizzyCommerce 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.

Resources

Need Help?