Skip to main content
Glama

aiworkhub_manager_recipe_show

Read-only

MANAGER READ: one persisted recipe in its exact canonical manifest form.

Instructions

MANAGER READ: one persisted recipe in its exact canonical manifest form.

With version omitted the highest stored version wins, ordered by the registry's own version key. The returned manifest is exactly the payload the recipe digest hashes, so the reported digest is independently checkable.

Input Schema

NameRequiredDescriptionDefault
versionNo
recipe_idYes

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.8/5.0
Behavior4/5

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

readOnlyHint=true is consistent with the 'READ' framing. Beyond the annotation, the description discloses real behavior: version omission resolves to the highest stored version using the registry's own version key, and the returned manifest is exactly the payload the digest hashes, which makes the digest independently verifiable.

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

Conciseness4/5

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

Three sentences, front-loaded with the identifying clause and the version-default rule in the second. No filler, though 'MANAGER READ' and 'canonical manifest form' lean on project jargon an outside agent may not parse.

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 return values need not be enumerated; the description still adds the manifest-to-digest linkage, which is the key semantic. For a two-parameter read-only fetch, nothing critical is missing.

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 carry parameter meaning. It explains the non-obvious default resolution for `version` (highest stored, ordered by the registry's version key), but says nothing about `recipe_id`, which is at least self-describing by name.

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?

The description opens with a specific verb+resource+scope: 'MANAGER READ: one persisted recipe in its exact canonical manifest form.' The word 'one' implicitly distinguishes it from the plural listing sibling, though no sibling (recipe_list, recipe_run, recipe_usage) is named explicitly.

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?

The 'MANAGER READ' prefix gives context and the single-recipe framing implies a fetch-by-id use case, but there is no explicit statement of when to prefer this over recipe_list or recipe_run, nor any precondition for the version argument.

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