get_quest
Retrieve complete details for a specific quest within a campaign by supplying the campaign ID and quest ID.
Instructions
Get details of a quest
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| campaignId | Yes |
Retrieve complete details for a specific quest within a campaign by supplying the campaign ID and quest ID.
Get details of a quest
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| campaignId | Yes |
Changes observed during successful MCP inspections.
v2.1.1Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden of disclosing behavior. 'Get details' clearly indicates a read/retrieval operation rather than a mutation, but it does not mention error behavior, authentication needs, or what the returned details actually contain.
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 efficient sentence with no redundant wording. It is front-loaded with the action and object, though the minimal length means some useful information is missing.
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 simple retrieval tool with two numeric required parameters and no output schema, the description is minimally usable. However, it omits the relationship between campaignId and id and provides no info on response shape or edge cases, leaving room for ambiguity.
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?
Schema description coverage is 0%, and the description adds no explanation of the two required parameters. The names id and campaignId are somewhat self-explanatory, but the description does not clarify how campaignId scopes or relates to the quest id.
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 ('Get') and resource ('quest'), and the sibling list_quests makes it clear this is the singular retrieval tool. It is not tautological, though it lacks any scope or detail about what 'details' includes.
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 guidance is given about when to use get_quest versus list_quests or other alternatives. The sibling tools imply a distinction, but the description itself provides no context, exclusions, or routing hints.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.