Skip to main content
Glama
Sign In
leanfare

leanfare

by pouriaetab
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Hand a task to a cheaper model

delegate

Hands reading, summarizing, searching, or reviewing work to a cheaper model through Leanfare, keeping large files and logs out of your context and returning a short answer with a cost receipt.

Instructions

Hand a piece of work to a cheaper model through Leanfare, to save your own context and usage. Best for work that reads a lot and answers briefly: search or summarize big files, logs or many documents, review a file, draft a section. Name the files in files: Leanfare reads them itself, so their text never enters your context. Leanfare picks the cheapest model the user ticked that rates well enough for the kind and effort, and returns a short answer with a receipt (the model, the cost, the tokens kept out of your context). Every high effort answer, and a sample of the others, is checked by a stronger model, blind and from another company when one can take it; a failed check is asked again one tier up. One that takes more than about 40 seconds answers with an id instead and keeps working: call delegate again with only that id to get the answer. Costs count toward the user's Leanfare budget.

Input Schema

NameRequiredDescriptionDefault
idNoThe id an earlier delegate answered with while it was still working: give only this to get that answer.
kindNoread: find, pull out or summarize from the files. write: draft text or code. reason: work something out (a bug's cause, a plan, a proof). Leave it out to let Leanfare guess.
taskNoWhat to do, written for a model that has not seen this conversation: the goal, what to look for, and the form of answer you want (for example: a list of file:line, one line each).
checkNoauto (the default) has a stronger model check every high effort answer, 1 in 4 medium ones and 1 in 10 low ones.
filesNoText files for Leanfare to read and hand over with the task: full paths, ~/ paths, or paths relative to folder. At most 50 files, 2 MB each, 4 MB in all. Files that hold secrets (.env files, private keys, credentials) are refused.
levelNoThe Leanfare level for this chat or session, as the level tool or Leanfare's prompt line gave it. Leave it out when none was given.
speedNoAt the same quality: "cheapest" (however long it takes), "balanced" (time and cost weighed alike), "fastest" (whatever it costs), or a number of seconds to answer within, like "30". Default: the user's choice in Leanfare.
effortNoHow good the model must be: low takes the cheapest rated within 80 points of the best model the user ticked, medium within 40, high within 15. Also the thinking effort for models that think. Default medium.
folderNoThe folder relative paths start from. By default, the folder the MCP client started Leanfare in (in Claude Code, the project).
privateNotrue keeps this task on the user's computer: only models there (Ollama) take it, and its check too. Use it for anything sensitive or personal, or when the user asks.
max_tokensNoThe longest answer to allow, in tokens (default 8,192).
your_modelNoThe model you run on, as your own instructions name it (for example claude-opus-5-5). Leanfare names it for the work that stays with you, and the report shows it as the prompt's main model.
your_effortNoThe thinking effort you run at, when you know it. The report shows it with your model.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.15.1

TDQS

A4.3/5.0
Behavior5/5

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

Beyond the annotations it discloses what matters operationally: costs count against the user's Leanfare budget, answers are verified by a stronger model with a re-ask one tier up on failure, runs over ~40 seconds return an id that must be re-submitted alone, and files holding secrets are refused. It also explains that named files never enter the caller's context, which is the core behavioral payoff.

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?

Purpose is front-loaded and almost every sentence carries new information about cost, verification, or the async path. It is delivered as one dense block, so the retry mechanics and receipt semantics are harder to scan than they need to be, but there is little outright filler.

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?

With 13 optional parameters, no output schema, and an asynchronous id-based continuation path, the description still covers the call, the return shape (short answer plus receipt), the timeout behavior, and the cost model. Nothing an agent needs to invoke it correctly appears to be 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 100%, so the baseline would be 3; the description adds real meaning on top, notably the files contract (Leanfare reads them itself so their text never enters your context) and the id retry protocol (call delegate again with only that id). Remaining parameters are left to the schema, which already carries adequate enum and default documentation.

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 names a specific action and target: hand a piece of work to a cheaper model via Leanfare, to save context and usage, and it characterizes the work shape (reads a lot, answers briefly). It is clear what the tool does, but it never contrasts itself with siblings such as ask or local_model, which overlaps on the private/local path.

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

Usage Guidelines4/5

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

It gives concrete when-to-use guidance (search or summarize big files, logs or many documents, review a file, draft a section) and a when-to-choose-private rule for sensitive or personal work. It stops short of explicit exclusions or naming an alternative tool for cases this one should not handle.

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