Skip to main content
Glama

get_topic

Retrieve verified claims and exact quotes about a topic across all creators, sorted newest first, with timestamped source URLs for citation.

Instructions

Everything the brain has verified about one topic (e.g. 'Protein Intake') across all creators: claims with exact quotes and timestamp URLs, newest first. Names and synonyms are matched loosely. Cite the timestamp URLs when you use a claim.

Input Schema

NameRequiredDescriptionDefault
nameYes

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.9/5.0
Behavior4/5

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

No annotations exist, so the description carries the full load, and it does disclose meaningful behavior: results are ordered newest first, name resolution is loose across names and synonyms (a fuzzy-match caveat that matters), and output includes exact quotes plus timestamp URLs. It stops short of limits, pagination, or what happens when a topic has no verified claims.

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

Conciseness5/5

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

Three short sentences, front-loaded with what is returned, then matching semantics, then the citation requirement. Every sentence carries distinct information with zero filler.

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 explaining return values is a bonus rather than a necessity, and the description still characterizes the payload well for a single-parameter read tool. The one missing piece is disambiguation from search_brain, which would materially help an agent choose correctly.

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 coverage is 0%, so the description must compensate, and it does: it supplies an example value ('Protein Intake') and explains the matching rule (names and synonyms matched loosely). Remaining unknown is case/format sensitivity of the input, but the essential semantics of the single parameter are conveyed.

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?

States a specific verb and resource: returns everything verified about one topic, with an example topic and a precise description of the payload (claims, exact quotes, timestamp URLs). It is clear what the tool does, though it never names how it differs from its closest sibling search_brain or from list_topics.

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 only implied by the payload description; the one explicit instruction ('Cite the timestamp URLs when you use a claim') governs downstream behavior, not tool selection. With 18 siblings including search_brain and list_topics, the absence of any 'use this instead of X when Y' guidance is a real gap.

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