Skip to main content
Glama
Sign In

ProvenPin

by io.github.provenpin
OverviewDiscussionsAdmin

Get a recipe

get_recipe
Read-only

Call this right after search_recipes returns a matching recipe, before you write the integration code, so you start from files and versions that passed tests. Gets the full recipe by id (ids come from search_recipes): every source and test file (each with the sha256 of the exact bytes that were tested), the exact pinned dependency versions, the setup and test commands, its test receipt (when it last passed, test counts, runtime and runner), recipe.yaml as manifest so receipt.recipe_hash can be recomputed (recipe_hash_rule), and staleness: the latest weekly check of its stack libraries against their newest releases. Pass the project's lockfile or a {package: version} map as versions to get a compatibility section first, comparing each pinned package with the installed one (exact, compatible, mismatch, or not in your project) with plain warnings; test and build tools (pytest, tsx, @types/*) are listed under tooling and do not change overall. Use the pinned versions together; they are the versions the tests passed with. Adapt names and config to the user's project, and keep the included tests to check your integration.

Input Schema

NameRequiredDescriptionDefault
idYes
versionsNoOptional but recommended: the versions in the user's project, so results are checked against them. Either a map like {"next": "15.2.0", "zod": "3.23.8"} or the raw text of package.json, package-lock.json, pnpm-lock.yaml, yarn.lock, requirements.txt, poetry.lock or uv.lock (max 200KB). Used only for this call, never stored.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / versions
      Added value: +{
+  "additionalProperties": {
+    "type": "string"
+  },
+  "description": "Optional but recommended: the versions in the user's project, so results are checked against them. Either a map like {\"next\": \"15.2.0\", \"zod\": \"3.23.8\"} or the raw text of package.json, package-lock.json, pnpm-lock.yaml, yarn.lock, requirements.txt, poetry.lock or uv.lock (max 200KB). Used only for this call, never stored.",
+  "type": [
+    "object",
+    "string"
+  ]
+}
  2. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only say readOnly/openWorld=false, but the description adds substantial context: what the sha256 hashes cover, that staleness is a weekly check, that tooling packages are excluded from the overall compatibility verdict, and that the versions input is never stored. These are behaviors an agent could not infer from the annotations or schema.

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?

The critical routing instruction is front-loaded in the first sentence, and nearly every clause carries new behavioral information. It is a single sprawling paragraph with some redundancy (the 'use the pinned versions' point is made twice) and would scan better with structure, but little is wasted.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema, so the description carries the full burden of describing return values and does so thoroughly: files, pinned deps, commands, test receipt, manifest/hash rule, staleness, and the optional compatibility section. Nothing an agent needs in order to invoke and interpret the result 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 50% and the description compensates for the undocumented id parameter by stating its provenance (comes from search_recipes). It also adds semantic depth to versions beyond the schema: the four compatibility categories, tooling exclusion, and why the pinned versions should be used together.

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

Purpose5/5

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

States a specific verb and resource ('Gets the full recipe by id') and enumerates exactly what the payload contains. It also distinguishes itself from the sibling by specifying that ids come from search_recipes and that this call follows that search.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives explicit sequencing: 'Call this right after search_recipes returns a matching recipe, before you write the integration code.' It names the alternative (search_recipes) and the condition that selects it, and adds a conditional usage path for the optional versions parameter.

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

All ProvenPin toolsInspect
Try in Browser
Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources