Skip to main content
Glama

Show topic details

get_topic
Read-onlyIdempotent

Fetch details for a Circle community topic using its topic ID to review discussion content and metadata for community administration.

Instructions

Show topic details. Reads community data.

Input Schema

NameRequiredDescriptionDefault
accountNoNamed private Circle account; selects credentials, not a remote community ID.
topic_idYesTopic ID

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv2.0.0

TDQS

C2.4/5.0
Behavior2/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is fully covered. "Reads community data" merely restates the readOnly hint rather than adding context such as authentication requirements, credential selection via the account parameter, or visibility/rate-limit behavior. No contradiction, but no added value.

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

Conciseness3/5

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

Two short sentences that are front-loaded, but the second sentence ("Reads community data") is redundant filler given the readOnly annotation. Minimal size is a virtue here, yet the content per sentence is low.

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?

For a simple, idempotent read tool with a fully documented two-parameter schema and complete annotations, the description is adequate to invoke it correctly. However, with no output schema, it could at least hint at what a topic's details include or note the required topic_id scope, leaving it only minimally sufficient.

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 both parameters are already documented, including the non-obvious distinction that account selects credentials rather than a remote community ID. The description adds nothing beyond the schema, so the baseline of 3 applies.

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

Purpose2/5

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

"Show topic details" is a verbatim restatement of the tool title and name, contributing no information beyond them. "Reads community data" is a generic addendum that does not identify which resource is read or how this differs from sibling getters like get_post, get_space, or get_event. This is effectively a tautology.

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 statement of when to use this tool versus alternatives (get_post, get_space, list_topics, update_topic) and no prerequisites or exclusions. The agent must infer usage solely from the name.

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

Deploy Server

Other Tools