Skip to main content
Glama

Explain the source and review status behind a chart topic

explain_chart_sources
Read-onlyIdempotent

Returns book-section locators and rule-review status without treating discovered prose as executable doctrine.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
topicYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

C2.8/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds one piece of interpretive context—that discovered prose is not to be treated as executable doctrine—but omits anything about the review-status semantics it reportedly returns. With annotations carrying the burden, this is an adequate 3.

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?

A single tightly written sentence with the return content front-loaded. Dense but no filler; slightly jargon-heavy wording ('executable doctrine') is the only cost.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so the return values need not be re-explained, and annotations cover the safety profile. Still, the sole parameter is undocumented and no usage context is given, leaving the definition minimally sufficient for a retrieval/explanation tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% and the description does not explain what 'topic' means, what form it takes, or how it maps to a chart. With a single undocumented required parameter, the description should compensate but does not.

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

Purpose3/5

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

The description states what it returns (book-section locators and rule-review status) tied to a chart topic, which is a specific output. However, it does not clearly distinguish itself from siblings like search_reviewed_rules, search_source_passages, or explore_lal_kitab_sources, leaving the agent unsure when this explanation tool is the right one. The trailing phrase about 'executable doctrine' is a caveat rather than a purpose statement.

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 explicit when-to-use guidance and no named alternatives, despite several sibling tools that also retrieve sources and reviewed rules. The agent must infer the selection criteria entirely on its own.

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.