Skip to main content
Glama

Update a corroboration

update_corroboration
Idempotent

Update the sheet of a corroboration: only the fields you send change (an empty label goes back to the derived one, an empty notes or published_on clears it). Correcting the url ALWAYS recomputes the source: the two never drift apart. It also carries monitoring, the cadence at which the page is read again on its own, which is why watching a page needs no tool of its own. To say a page is gone, use archive_corroboration instead: editing never takes anything down.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
urlNoAbsolute http(s) address of the EXACT page where the third party talks about the brand, never the home page of the site.
labelNoDisplay 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.
notesNoFree notes: the passage that mentions the brand, the contact, how the page came about.
monitoringNoHow often the page is read again on its own: "off" (the default), "daily", "weekly" or "monthly". Each executed check costs 0.02 USD from the prepaid balance and returns the same two findings as verify_corroboration, on the mention and on the link, plus an email when the text of the passage changed or the link is gone. It states a STATE, so sending the same value again does nothing. It applies to a live line whose page reads (readability "html"): elsewhere the reply is 409 corroboration_archived or 409 page_not_readable, and "off" is always accepted.
published_onNoThe 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_channelNoWhether 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.
corroboration_idYesThe UUID of the corroboration: call list_corroborations to find it.

TDQS

A4.9/5.0
Behavior5/5

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

The description adds rich behavioral detail beyond the annotations: empty label reverts to derived, empty notes/published_on clears, URL recomputation keeps source in sync, and monitoring details including cost, state semantics, and 409 error conditions. This is far more than the annotations alone convey and gives the agent a complete safety and side-effect profile.

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?

The description is dense but every sentence carries operational value: field-level update behavior, URL/source coupling, monitoring inclusion, and the archive alternative. It is well-organized, front-loaded with the core purpose, and avoids redundancy with the schema.

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?

Given the tool's complexity (7 parameters, partial update semantics, monitoring side effects, error conditions), the description covers all key aspects: what changes, what clears, what recomputes, cost/state, and when to use a different tool. No output schema exists, but the description does not need to explain return values for a mutation tool, and the provided guidance is complete for safe invocation.

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 already describes all parameters with 100% coverage, giving a baseline of 3. The description adds extra meaning beyond the schema, such as clarifying that an empty notes or published_on clears those fields (not in schema) and that correcting the URL always recomputes the source. This extra context justifies a 4.

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 verb 'Update' and the resource 'the sheet of a corroboration', then explains exactly which fields change and how. It explicitly distinguishes itself from the sibling tool 'archive_corroboration' for the 'page is gone' case, making its scope unambiguous.

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?

It explicitly says 'To say a page is gone, use archive_corroboration instead' and explains that editing never takes anything down, which is a clear when-not/alternative. It also notes that monitoring is handled by this tool, so no separate watching tool is needed, giving clear context for when to use this update.

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.

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