Skip to main content
Glama

get_corroborated

Read-onlyIdempotent

What separate sources agreed on in the published window — the maintained record's corroboration layer. Each event carries the claim as its sources state it, the corroboration tier, two counts — publisherCount (distinct outlets that carried it) and originCount (separate evidentiary origins: a wire republished by fifteen outlets, two pages behind one address, or three outlets relaying what one named outlet reported each count once) — the publishers by name with wires marked, the earliest report date when the run carries one, and the entities. The tier is computed from originCount minus originsUnknownUpstream: an origin whose text could not be read may relay any other, so it is shown but never counted toward the tier. Neither count is verification: an outlet whose readable text names no upstream still counts as its own origin, and many outlets echoing one official statement is consensus. knownOriginCount is the origins whose upstream is known, the count the tier stands on; independentOrigins is a deprecated alias that mirrors knownOriginCount (never the publisher count, never larger than the tier count). No probability here is ours. Returns state="cannot-measure" with a reason when the corroboration pass could not be read — never an empty list dressed as a quiet week.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
tierNoOptional filter: 'strong' (carried from 4 or more separate origins) or 'moderate' (2 or 3 separate origins). An unknown value is refused, never answered with an empty list.
limitNoHow many events (default 20, max 60)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / tier / description
      Previous value: -"Optional filter: 'strong' (independently corroborated) or 'moderate' (corroborated). An unknown value is refused, never answered with an empty list."New value: +"Optional filter: 'strong' (carried from 4 or more separate origins) or 'moderate' (2 or 3 separate origins). An unknown value is refused, never answered with an empty list."
  2. Changed2 schema fields changed
    • changedInput schema / properties / tier / description
      Previous value: -"Optional filter: 'strong' (independently corroborated) or 'moderate' (corroborated)"New value: +"Optional filter: 'strong' (independently corroborated) or 'moderate' (corroborated). An unknown value is refused, never answered with an empty list."
    • addedInput schema / properties / tier / enum
      Added value: +[
      +  "strong",
      +  "moderate"
      +]
  3. Added

TDQS

B3.4/5.0
Behavior4/5

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

Annotations already establish the safe-read profile (readOnlyHint, idempotentHint, openWorldHint=false), so the bar is lower, and the description clears it by disclosing genuinely non-obvious behavior: a 'cannot-measure' state with a reason rather than an empty list, the rule that unreadable origins are shown but never counted toward the tier, and the deprecated independentOrigins alias. These are traits no annotation conveys.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The content is mostly load-bearing for a domain this intricate, but the delivery is a single dense paragraph of nested em-dashes and parentheticals, and the opening sentence leads with a metaphor rather than a verb. The deprecated-alias digression and 'No probability here is ours' line cost space without helping an agent invoke the tool.

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 no output schema, the description carries the full burden of explaining the return shape, and it does: the per-event claim, tier, publisherCount, originCount, named publishers with wires marked, earliest report date, entities, plus the cannot-measure fallback. What remains unstated is pagination/limit behavior and how the 'published window' is scoped.

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?

Schema description coverage is 100% and the schema already documents both parameters, including the enum meanings ('strong' = 4+ origins, 'moderate' = 2 or 3) and the limit default/max. The description restates the tier thresholds and the refuse-unknown-value rule but adds no syntax or format detail beyond what the schema provides, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The opening clause identifies the resource precisely — corroborated events ('what separate sources agreed on') within the published window — and the phrase 'the maintained record's corroboration layer' frames it as a distinct view. The verb is implicit rather than stated, and no sibling (e.g. get_events, get_record, get_signals) is named as the alternative, so an agent must infer the boundary itself.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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

There is no when-to-use or when-not-to-use guidance: nothing tells the agent to reach for this instead of get_events or todays_brief. The description covers output semantics exhaustively but never states the triggering condition or any prerequisite, leaving routing to the reader.

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