Skip to main content
Glama

Which sources AI engines cite

mri_get_cited_sources
Read-onlyIdempotent

Ranked source domains that AI answer engines cite, pooled across engines, for one category and question shape, with citation rate (share of monitored answer runs citing the domain), rank, percentile and source role (editorial publication, vendor-owned, analyst research, community, academic/government, market database, wire distribution). This rate is not split by engine. For one engine, use mri_get_engine.

Input Schema

NameRequiredDescriptionDefault
limitNo
cursorNoPage token from the previous response's next.cursor. When set, offset is ignored.
offsetNo
categoryYesCategory key, e.g. cybersecurity.
source_roleNoOptional filter, e.g. editorial_media for publications only, vendor_owned, analyst_research, community_social.
question_shapeYesBuyer question pattern: best_x (best X tools), how_choose (how to choose), is_x_worth (is it worth it), news_topic (recent news), problem_first (how to solve a problem), top_list (top platforms), x_vs_y (A vs B).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / cursor
      Added value: +{
      +  "description": "Page token from the previous response's next.cursor. When set, offset is ignored.",
      +  "type": "string"
      +}
  2. First observed

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already cover safety traits (readOnly, idempotent, non-destructive, closed-world), and the description adds useful behavioral context: the rate is pooled across engines and not split by engine, and it names the returned metrics and source-role taxonomy. It does not discuss freshness or pagination behavior, so it is strong but not exhaustive.

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 purpose is front-loaded and the description uses only three sentences. The first sentence is dense with parenthetical metric and source-role details, but the content is relevant and there is little wasted space.

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 six-parameter tool with no output schema, the description does well by explaining the returned metrics, source-role taxonomy, and pooled-across-engines scope. It could be more complete by explaining pagination/default limit behavior and the source_role filter, but the core information an agent needs is present.

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 67%, and the schema already documents category, question_shape, cursor, and source_role. The description defines citation rate and enumerates source roles, but it does not clarify the limit/offset/cursor parameters or explicitly frame source_role as a filter, so it adds only moderate meaning beyond the schema.

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 states a specific resource (ranked source domains cited by AI answer engines) and scope (one category and question shape, pooled across engines). It explicitly distinguishes the tool from mri_get_engine for per-engine data, so an agent can identify its purpose without opening the schema.

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 gives a clear usage boundary: this tool returns pooled data and is not split by engine, while mri_get_engine should be used for one engine. That is an explicit alternative and selection condition, leaving little ambiguity for the main usage decision.

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.