grokipedia-mcp-server

get_page_citations

Read-onlyIdempotent

Return the citations / references for a page, with where each is cited.

Instructions

Return the citations / references for a page, with where each is cited.

Each citation has "sections": the headings under which its inline marker appears in the article text (matched by exact URL; [] if never cited inline). When the article text has no usable inline markers (e.g. HTML fallback), "sections" is null and "section_mapping" is "unavailable"; mappings are never guessed.

Args: slug: Page slug. include_context: Also return up to 3 short text snippets preceding each marker.

Input Schema

Name	Required	Description	Default
`slug`	Yes
`include_context`	No

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv0.1.2Oct 22, 2026

addedInput schema / properties / include_context

Added value: +{
+  "default": false,
+  "title": "Include Context",
+  "type": "boolean"
+}

First observedv0.1.1Oct 18, 2026

TDQS

A4.1/5.0

Behavior4/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld), so the description correctly invests in what annotations cannot say: 'sections' is matched by exact URL and is [] when never cited inline; when the article has no usable inline markers (HTML fallback) 'sections' is null and 'section_mapping' is 'unavailable', and mappings are never guessed. That edge-case disclosure meaningfully tells the agent when to distrust the mapping.

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?

Front-loaded with the one-line purpose, then the return-shape detail, then terse Args. Every sentence carries information, though the mid-paragraph fallback/null explanation is dense and slightly harder to scan than a short bullet would be.

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?

An output schema exists, so return values needn't be spelled out, and yet the description goes further by explaining the semantics of 'sections' and 'section_mapping'. With two well-narrated parameters and annotations covering safety, an agent has what it needs; only the absence of any routing guidance versus siblings keeps it short of perfect.

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?

Schema description coverage is 0%, so the description must compensate. It defines include_context semantically ('also return up to 3 short text snippets preceding each marker'), which is more than the schema's bare boolean-with-default, and names the context behavior. The slug parameter gets only 'Page slug', leaving its format still implicit.

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 verb and resource ('Return the citations / references for a page') plus the added value ('with where each is cited'). This is clearly distinct from the siblings get_page, get_page_section, and search, so an agent can pick it 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 Guidelines3/5

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

Usage is implied — you call it to get citations for a known page slug — but the description never states when to prefer it over get_page/get_page_section or any prerequisites (e.g. that the slug must resolve to an existing page). It offers no explicit exclusions or alternatives.

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

Deploy Server