Epovest

Move a surface to the corroboration registry

convert_surface_to_corroboration

Idempotent

Move the page to the corroboration registry: someone else has the final say on it (the customer lost, or never had, the hand on the content). Nothing is retyped: url, label and notes travel, the publication date stays unknown (set it with update_corroboration when known). The surface leaves its registry for the trash, alignment journal attached, and the reverse move exists (convert_corroboration_to_surface): nothing is lost, and replaying the move finds the same line instead of duplicating it. The own site of the brand is refused (own_domain): it stays a surface. It moves a line the customer declared: confirm with the user first.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`surface_id`	Yes	The UUID of the surface: call list_surfaces to find it.

TDQS

A4.6/5.0

Behavior5/5

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

The description goes beyond annotations by detailing the move's implications: URL, label, and notes travel; publication date remains unknown; the surface goes to trash with an alignment journal; the operation is reversible and idempotent. This rich context aligns with annotations (readOnlyHint=false, destructiveHint=false, idempotentHint=true) and adds actionable details.

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?

Every sentence in the description serves a purpose: conveying the operation, side effects, reversibility, exceptions, and user guidance. The information is front-loaded with the core action, and the structure is logical and efficient.

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 simple input (one UUID, no output schema), the description covers the tool's behavior thoroughly: preconditions (confirm with user), side effects (trash, journal), reversibility, and a specific exception (own_domain). It is slightly lacking in explicit error handling or state machine details, but for this complexity it is ample.

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 description does not add significant semantics beyond the input schema for the single parameter (surface_id). The schema already describes it as a UUID from list_surfaces. The description only repeats this context, so it meets the baseline for 100% coverage but provides no extra value.

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 explicitly states the action: 'Move a surface to the corroboration registry' and explains the effect clearly. It differentiates this tool from its reverse sibling (convert_corroboration_to_surface), making the purpose distinct.

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 provides clear guidance on when to use this tool: when a page should be moved to corroboration because someone else has the final say. It also specifies when not to use it (own_domain sites) and advises to confirm with the user first. The existence of the reverse move is noted.

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?