Skip to main content
Glama

create_editorial_velocity_comparison

create_editorial_velocity_comparison

Compare the editorial velocity of competitors, paid in tokens (account only)

Measures how many articles each site publishes per month, for a list of sites or for the sites ranking in the Google top 10 of a keyword, then returns the median of the competitors and a recommendation for your own site. Each site is an editorial velocity analysis (same engine as createEditorialVelocity).

Paid, ONLY WITH THE USER'S EXPLICIT AGREEMENT. 20 tokens per site analysed. With sites, the price is 20 tokens times the number of distinct sites, your site included. With keyword, the number of sites is only known once Google is read, so the maximum is charged, 5 tokens for the search results plus 20 tokens for each of the 10 places (plus one for ownSite), 205 or 225 tokens, and the unused places are given back as soon as the results are read. Before calling, tell the user the price and their token balance, and call only after they agree. Never retry on your own after an error.

What is given back. The tokens of a site that cannot be measured (blocked, no sitemap, no dates, unreachable, timeout, daily capacity reached), of a site served by an analysis of the same domain less than 7 days old or already running (nothing was read for you), of an unused place, and everything when the search results cannot be read or the comparison cannot start. Refunds happen at the first read that sees them, whoever reads, or within the next hours if nobody reads. charged in the answer is what stays charged after the refunds already made by this request.

Asynchronous, poll the result. This call answers HTTP 202 with a comparisonId and a pollUrl. Call GET /api/v1/tools/editorial-velocity/comparisons?comparisonId=... every 15 seconds until status is done or failed. Sites are analysed a few at a time, a comparison takes from a few minutes to 3 hours. MCP clients must call the get_editorial_velocity_comparison tool again until the status is terminal.

Input. Exactly one of sites (2 to 11 distinct host names or URLs after normalisation, your site included) or keyword with lang (a market code such as fr-fr, en-us, de-de, es-es, it-it). ownSite is optional; it is added to the list when missing, counted once, and left out of the median.

Errors. 401 without an account. 402 INSUFFICIENT_TOKENS when the balance is below the price, nothing is charged or started. 400 for an invalid body, nothing is charged. 429 RATE_LIMITED when 3 comparisons of the account are still running or 20 were started in the current UTC hour, nothing is charged. A 503 means the comparison was not started, and the tokens are given back (details.billing). A 502 means the analysis service did not answer in time: the tokens are given back (details.billing), and the comparison may still have started, in which case it is free (its comparisonId is not known, do not retry without the user). A 500 TOKENS_NOT_CONSUMED means the outcome of the debit could not be confirmed and nothing was started; if tokens were taken, they are given back automatically within the next hours.

Request format. JSON body with Content-Type: application/json (415 otherwise). Without an Authorization header, a request sent by a web page of another site returns 403.

Input Schema

NameRequiredDescriptionDefault
langNoMarket of the keyword, a code such as fr-fr, en-us, en-gb, de-de, es-es, it-it.
sitesNoHost names or URLs of the sites to compare. Reduced to their host, subdomain kept, www removed, duplicates removed. 2 to 11 distinct sites, ownSite included. Do not send with keyword.
keywordNoA search query. The distinct sites of its Google organic top 10 are compared. Requires lang. Do not send with sites.
ownSiteNoOptional. Host name or URL of your own site. Analysed and shown apart, never part of the median. With keyword, it adds one place to the maximum charged.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.8/5.0
Behavior5/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 and does so: cost model (20 tokens/site, 205-225 maximum with keyword), refund rules per failure mode, async 202 with comparisonId/pollUrl, 15-second polling cadence, daily/rate limits (3 concurrent, 20/hour), and a complete error-code table with billing implications. This is far beyond what any annotation could convey.

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 purpose before cost and mechanics, and organised under bold headers, so an agent can navigate it. It is however very long for a tool description and repeats the polling instruction twice ('poll every 15 seconds' and 'MCP clients must call get_editorial_velocity_comparison again'), which costs some density.

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?

With no output schema, the description supplies the return contract (comparisonId, pollUrl, status, charged), the terminal states, and the full failure/refund matrix. For a paid, asynchronous, multi-error tool this leaves nothing an agent needs to call it correctly unstated.

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 baseline is 3, but the description adds semantics the schema only partially states: the mutual exclusivity is framed as 'Exactly one of sites or keyword with lang', the 2-11 bound is expressed after host normalisation, and ownSite is described as counted once and excluded from the median. Marginal value over the schema, hence 4 rather than 5.

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 first sentence states a precise verb and resource ('Compare the editorial velocity of competitors') and immediately defines the measurement (articles per month, median of competitors, recommendation for own site). It explicitly distinguishes itself from siblings by naming createEditorialVelocity as the same engine and get_editorial_velocity_comparison as the polling tool.

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?

Explicit when-to-use (list of sites or the Google top 10 of a keyword), when-not (only with the user's explicit agreement, never retry on error, exactly one of sites/keyword), and named alternatives (createEditorialVelocity, get_editorial_velocity_comparison). It even prescribes the pre-call ritual of telling the user the price and balance.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources