Skip to main content
Glama

find_recipe

List saved step-by-step recipes for a site domain, then match one to your task and replay it to avoid repeating manual browser steps.

Instructions

[Real Chrome browser via the OctoLimb extension — drive the user's browser; use only when the task requires acting on a real website.] List every previously saved step-by-step trajectory for this domain, before doing the task manually. Returns each saved recipe's own instruction text plus its fingerprint and success/failure counts — no steps yet. Read the instructions like retrieved documents and judge for yourself whether any of them is the same task you're about to do, even if worded differently ('post a tweet' vs 'tweet something'); ignore recipes that don't actually match. If one fits, pass its fingerprint straight into run_recipe to replay the whole task in one call instead of one tool call per step. Always try this first for any task that sounds like something you (or a prior session) may have already done on this site.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
domainYesThe site's domain the task runs on (e.g. 'x.com')

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A4.6/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and does so: it states the environment (real Chrome via OctoLimb extension), what is returned ('instruction text plus its fingerprint and success/failure counts - no steps yet'), and that matching is fuzzy so the agent must judge similarity. This is richer behavioral context than most definitions provide.

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 browser-requirement caveat and the when-to-use instruction are front-loaded, which is good structure. It is a dense five-sentence block; the parenthetical example ('post a tweet' vs 'tweet something') earns its place, but the closing sentence partially restates the opening instruction.

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 must explain the return shape, and it does (per-recipe instructions, fingerprint, success/failure counts, no steps yet). Combined with the routing to run_recipe, an agent has everything needed to call it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Only one parameter, documented at 100% schema coverage with its own example ('x.com'), so the schema already does the work. The description adds only the implicit notion that recipes are scoped per-domain; no additional syntax or format meaning is supplied, so the baseline 3 applies.

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?

It names a specific verb+resource ('list every previously saved step-by-step trajectory for this domain') and clearly distinguishes itself from the sibling run_recipe, which is where matches get replayed. An agent can tell this apart from read_page or search_google without opening any schema.

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?

Explicit when-to-use ('always try this first for any task that sounds like something you may have already done'), what to do with results ('read the instructions like retrieved documents and judge for yourself'), when to ignore ('ignore recipes that don't actually match'), and the named alternative ('pass its fingerprint straight into run_recipe').

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