Skip to main content
Glama
AutomateLab-tech

Citation Intelligence MCP

citations_provenance

Read-onlyIdempotent

Fan out a query across multiple AI engines to reveal each cited URL and show which URLs have cross-engine consensus.

Instructions

Fan a query out across multiple AI engines and report per-URL cross-engine consensus. Returns each unique cited URL with the list of engines that cited it, plus a consensus_urls list (URLs cited by ALL engines). High engine_count = strong cross-engine citation signal; engine_count=1 = engine-specific.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
queryYesSearch query to fan out across multiple engines.
enginesNoEngines to query. If omitted, uses all LLM engines with a configured API key (perplexity, claude, openai, gemini, google_ai_mode). Include bing_serp/brave_serp only when you explicitly want web_rank comparison.
max_resultsNoMax citations per engine.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
noteNo
queryYesThe query that was fanned across engines.
enginesYesPer-engine run summary.
per_urlYesAll unique cited URLs sorted by cross-engine consensus (engine_count desc).
summaryYes
fetched_atYesUTC ISO-8601 timestamp.
consensus_urlsYesURLs cited by ALL succeeding engines (requires >=2 engines).
engines_queriedYes
engines_succeededYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.1.2

TDQS

A3.9/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is covered. The description adds real context beyond that: it names the engines queried by default, the return shape, and how to interpret engine_count. It does not discuss latency, rate limits, or cost of fanning out across engines, which would fully round it out.

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?

Three sentences, front-loaded with the core action and output shape, with the engine_count interpretation placed last as a useful reading aid. No filler sentences, though the trailing interpretation sentence slightly overlaps with output-schema territory.

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?

For a read-only, idempotent fan-out tool with annotations covering safety, 100% schema coverage, and an output schema already present, the description is essentially complete. It even voluntarily explains return values despite the output schema existing, which covers the remaining ambiguity.

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%, so all three parameters (query, engines, max_results) are already documented in the schema with strong detail (enum list, maxItems, defaults, defaults-on-omission). The description adds nothing parameter-specific, so the baseline 3 for high coverage is correct.

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?

States a specific action (fan a query out across multiple AI engines) and resource (per-URL cross-engine citation consensus), and goes further to name the exact outputs (per-URL engine lists, consensus_urls). This is specific enough to distinguish it from sibling tools like citations_evidence or citations_check that lack the multi-engine consensus angle.

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

Usage Guidelines3/5

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

Usage is implied rather than stated: the description explains engine_count semantics (1 = engine-specific, high = strong signal), which hints at when the tool is valuable, but it never names an alternative or states an explicit when/when-not condition against siblings like citations_evidence. No exclusions or routing guidance.

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