Epovest

Prepare a competitor scan

create_competitor_scan

Prepare a competitor scan on a basket of up to 5 companies of the same market. Three or more is what the scan is built for: from there the places rank by RECURRENCE, that is by how many companies of the basket each one covers. It is created as a DRAFT: nothing is charged, and the questions it derives come back in the answer for you to read before arming it with start_competitor_scan. Each subject needs a website: a whole domain found in a page is what tells two companies with the same name apart. category qualifies each company in the questions ("welding equipment manufacturer") and usage says what buyers use it for ("hobby welding"); both shape the questions, so name them from the market you are measuring. language is the language the questions are asked in and country the market they name; leave country out for a global one. One engine per scan, ChatGPT by default: a second engine is a second scan.

Input Schema

TableJSON Schema

Name	Required	Description
`title`	No	A name for the scan. Omitted, the category serves.
`usage`	No	What buyers use it for, for example "hobby welding". Omitted, the category serves.
`engine`	No	The engine asked, ChatGPT by default. One per scan.
`country`	No	The market the questions name, as an ISO 3166-1 alpha-2 code ("US"). Omitted, the questions name no country.
`category`	Yes	What qualifies each company in the questions, for example "welding equipment manufacturer".
`language`	No	The language the questions are asked in, written in en, fr, es, de, it, pt, ar, bg, cs, da, el, fi, he, hi, hu, id, ja, ko, ms, nl, no, pl, ro, ru, sk, sv, th, tr, uk, vi, zh, zh-hant. Omitted, the canonical language of the project. For another language, write to us with contact_support and we add it.
`subjects`	Yes	The basket: up to 5 companies of the same market, 3 or more being what the ranking by recurrence needs.
`templates`	No	Which questions to ask about each company, the four of them by default: `about_reputation` what is said about it, `about_price` whether it is worth its price, `about_customers` which companies use it and what they report, `compared_alternatives` what it is compared to. A sent list REPLACES that default, and the amount follows it: three companies and two templates make six questions.
`project_id`	Yes	UUID of the project the scan belongs to: call list_projects to find it. Its brand is the one the list answers "you are not there" about.

TDQS

A4.3/5.0

Behavior4/5

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

Annotations provide no safety signals (all false), so the description must disclose behavior. It does so by stating the scan is created as a DRAFT with no charge, that derived questions are returned for review, and that the engine is one per scan with ChatGPT as default. This adds significant context beyond the annotations, though it does not cover failure modes or detailed persistence.

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 longer than a simple two-sentence blurb but every sentence adds value. It is well-structured, covering purpose, draft behavior, parameter usage, and engine defaults. There is no filler or repetition, though it could be more scannable with bullet points.

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 9 parameters, no output schema, and no annotation hints, the description covers the essential flow: draft creation, no charge, questions returned, parameter meanings, and engine default. It is reasonably complete, although it doesn't describe the exact response format or edge cases like invalid websites.

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, but the description adds meaningful semantics: website is the whole domain to distinguish same-name companies, category and usage shape the questions, language is for the question wording, country for the market, and leaving country out means global. This goes beyond the schema's basic descriptions.

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: 'Prepare a competitor scan on a basket of up to 5 companies of the same market.' It distinguishes itself from sibling tools by explicitly mentioning the draft phase and referencing start_competitor_scan as the next step after arming. The verb 'prepare' is specific to creating a draft, not starting or listing scans.

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 on when to use this tool: before arming with start_competitor_scan, and it explains that a second engine requires a second scan, implying one scan per engine. It does not explicitly list alternatives like update_competitor_scan, but the workflow is clear enough for an agent to select this tool for creating a draft scan.

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

All Epovest tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4/5.0

Disambiguation4/5

Each tool maps to a distinct resource and action, and the descriptions go out of their way to separate near-neighbor concepts like surfaces vs corroborations and score series vs raw responses. A few related pairs (get_results/get_responses, get_credits/get_usage, create_surface/create_corroboration) could still be confused at a glance, so it is not a perfect 5.

Naming Consistency5/5

Tool names follow a highly consistent verb_noun snake_case pattern across all 67 tools, with clear families like create_, update_, get_, list_, archive_, restore_, and delete_. Minor quirks such as topup_credits as one word do not break the overall uniformity.

Tool Count1/5

67 tools is an extreme count for a single MCP server, even for a broad brand-monitoring domain. The surface is bloated with lifecycle variants per entity, and the sheer number makes the server hard to navigate and prompt against.

Completeness5/5

The server covers full lifecycles for projects, trackers, surfaces, corroborations, quests, logbook entries, keyword discoveries, competitor scans, link targets, sources, support, and billing. Archive/restore and soft-delete paths prevent dead ends, and nearly every obvious workflow has a corresponding tool.

Resources

Need Help?