get_recipe
Retrieve a specific public recipe using its exact recipe ID.
Instructions
Get one public recipe by exact recipe ID.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| recipe_id | Yes |
Output Schema
| Name | Required | Description | Default |
|---|---|---|---|
| result | Yes |
Retrieve a specific public recipe using its exact recipe ID.
Get one public recipe by exact recipe ID.
| Name | Required | Description | Default |
|---|---|---|---|
| recipe_id | Yes |
| Name | Required | Description | Default |
|---|---|---|---|
| result | Yes |
Changes observed during successful MCP inspections.
v0.2.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds that the recipe is 'public' and that lookup is by exact ID, but it does not disclose error behavior or what happens when the ID is not found. Given the annotations, this is adequate but not rich.
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 concise sentence with no wasted words. It front-loads the core action ('Get'), the scope ('one public recipe'), and the key constraint ('exact recipe ID').
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?
Given the tool's low complexity, one simple parameter, a read-only annotation, and an output schema, the description covers everything essential for correct invocation. No additional context about return values is needed because an output schema is present.
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 input schema already defines recipe_id as a required integer greater than zero. The description adds the meaningful semantic that this is an exact ID match, not a fuzzy or partial search, which helps an agent pass the correct value. For a single, well-constrained parameter, this is sufficient compensation for the 0% schema description coverage.
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') with a clear resource ('one public recipe') and a precise lookup criterion ('by exact recipe ID'). It clearly distinguishes this tool from siblings like search_recipes, since it targets a single recipe by exact ID rather than a search query.
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?
The phrase 'by exact recipe ID' clearly implies this tool should be used when the caller already has a specific recipe ID, which is useful context for choosing between this and search_recipes. However, it does not explicitly name the alternative or state when not to use this tool, so it stops short of full guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.