Epovest

Record a corroboration

create_corroboration

Record a page about the brand where someone else has the final say. URL-FIRST: the exact address of the page is the only thing needed, the source on the map and the display name are derived from it. It is a statement of fact: only record a page you have actually read, and confirm with the user. A page the customer controls (their own profile, their own listing) belongs to Surfaces instead: use create_surface. The test that settles it: if the customer changes the page, does the change stay? No means someone else has the final say, so it is a corroboration; yes means they have it, so it is a surface. Being able to edit a page is not the test, a wiki anyone can edit is a corroboration, and a directory listing they hold is a surface even though a third party runs the site. Three refusals answer with their own slug: unplaceable_url (the address has no registrable domain), own_domain (this is the own site of the brand, where they have the final say: use create_surface), duplicate (the page is already in the registry, 409).

Input Schema

TableJSON Schema

Name	Required	Description
`url`	Yes	Absolute http(s) address of the EXACT page where the third party talks about the brand, never the home page of the site.
`label`	No	Display name of the page. OMIT IT: it is derived from the address (domain and path). Send an empty string to go back to the derived one.
`notes`	No	Free notes: the passage that mentions the brand, the contact, how the page came about.
`project_id`	Yes	UUID of the project: call list_projects to find it.
`published_on`	No	The day the page was PUBLISHED, as YYYY-MM-DD. Distinct from the recording day, and the one that means something against the citation curves. Omit it when unknown: it is never guessed.
`request_channel`	No	Whether someone can be asked to change the page: "available" (a contact or a process exists), "none" (nobody to ask), "unknown" (not filled in, the default). It gates the refresh suggestions of the quest file; the contact itself belongs in the notes.

TDQS

A4.3/5.0

Behavior4/5

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

Annotations only say readOnlyHint=false, openWorldHint=false, idempotentHint=false, destructiveHint=false, which is thin. The description adds essential behavioral context: the agent must actually read the page and confirm with the user, and the page is a statement of fact. It also documents refusal behaviors. This goes beyond annotations without contradicting them.

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 average but every sentence earns its place: it defines the resource, explains the URL-first rule, mandates a human check, gives the surface exclusion test, and lists error refusals. It is front-loaded with the core purpose before branching into 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?

The tool is conceptually nuanced (corroboration vs surface), and the description handles this thoroughly with the customer-control test and refusal slugs. It doesn't describe the success return payload, but no output schema exists and for a create operation this is a minor omission given the rich usage and error guidance.

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?

Input schema covers 100% of parameters with descriptions, so the baseline is 3. The description adds context about URL-first derivation and label omission, but this largely echoes the schema. No extra parameter-level semantics beyond what the schema already provides.

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: 'Record a page about the brand where someone else has the final say.' It immediately distinguishes from the sibling tool create_surface using the control test ('if the customer changes the page, does the change stay?'), 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 Guidelines5/5

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

Explicitly says when to use this tool versus create_surface ('A page the customer controls ... belongs to Surfaces instead: use create_surface'), provides a decision test, and lists three refusal slugs (unplaceable_url, own_domain, duplicate) so the agent knows likely failure modes and how to respond.

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?