get_question
Retrieve a single question and its complete set of answers by providing its unique ID.
Instructions
Fetch one question with all its answers.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
Retrieve a single question and its complete set of answers by providing its unique ID.
Fetch one question with all its answers.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The verb 'fetch' conveys a read-only operation, and 'with all its answers' states the primary return content, which is useful given there are no annotations or output schema. However, it does not disclose error behavior, permissions, or response structure beyond that.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single seven-word sentence that is front-loaded with the verb and resource. No filler, repetition, or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter fetch tool, the core invocation contract (id input, question and answers output) is present. But with no annotations and no output schema, the absence of usage guidance and any behavior around invalid or missing ids leaves it only minimally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, and the description does not explicitly explain the 'id' parameter. It only ties the parameter to a single question by the word 'one question,' which is minimal compensation for the missing schema description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Fetch' and a precise resource: one question with all its answers. This clearly differentiates it from list_questions (plural listing) and answer_question (creating/answering), even without naming those siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use or when-not-to-use guidance is provided, and no alternative tools are named. The singular 'one question' vaguely implies use for single-question retrieval, but the agent is left to infer context from sibling names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/charonferries/mnemosyne'
If you have feedback or need assistance with the MCP directory API, please join our Discord server