Developers · Agent harness
The harness for succession and M&A work.
General-purpose assistants know nothing about what a practice is worth, who may see a target's numbers, or when a move is proven. ValuationMCP runs that work as governed agent loops, with checkpoints, permission tiers and owner approvals, in the workbench or inside the assistant you already use.
Every tool call, sorted by tier
margin loop · engine 1.8.0
- The model asks for a tool, and every call passes the tier check.
- Read: runs now. The engine runs it, and figures come only from the engine.
- Propose: parks a card for the owner. Nothing runs, and pulls start only when the owner starts them.
- Approve: anything that changes the record waits at the gate until the owner clicks.
- Never: refused and logged. No handler exists.
- Each step is written once to the run record and never edited.
Run record · append only
written once, never edited
- 01 · readread_margin_facts
- 02 · readdraft_steps
- 03 · proposepropose_pnl_pull
- 04 · approveapply_steps
- 05 · neverrefused: send_email
- 06 · neverrefused: change_figure
Six parts of a harness, built for this domain.
A harness is the system around a model that runs the loop, calls the tools, keeps state and enforces the rules. Here is what ValuationMCP does for each part.
Agent loop
ValuationMCP runs three loops: the data check before every compute, the operating-margin loop, and the hosted agent that works an assigned move on its cadence. Each run has step, model-call and time caps, and stops when it is done, needs the owner or reaches a limit.
Tool calling
Tools run on the server against a deterministic seven-method engine. The model orders issues and words questions; it never states or computes a figure.
Context management
Skills are served fresh on every call. The model sees issue types and category order, never client rows or ledger lines.
Checkpointing
Every step is written once to a step log that cannot be edited, with an idempotency key. An interrupted run resumes from its last step and never repeats a write.
Permissions and sandboxing
Four permission tiers on every tool. Read-only pulls, only when you start them. A buyer's loop never pulls from a target's systems; it asks through a data request under the NDA.
Guardrails
Model text carries no digits. A compute stops on blocking gaps until they are answered or acknowledged. Only a saved run marks a move verified. Drafts are never sent.
Four permission tiers
Every tool a loop can call is registered with one tier. A call outside its tier is refused and the refusal is logged as a step.
| Tier | What happens | Examples |
|---|---|---|
| read | What happens:Runs freely | Examples:Practice record, source map, saved runs, data requirements |
| propose | What happens:Becomes a card for the owner; nothing runs | Examples:Pull from a connected ledger, use one source's figure, ask the target |
| execute after approval | What happens:Runs only after the owner's click | Examples:Start the pull, save a chosen value with its source, compute, add steps to the plan |
| never | What happens:Not callable; any attempt is refused and logged | Examples:Send a message, change a figure on its own, mark a move verified, delete, contact a client |
A loop, step by step.
The data check that runs before every compute. Clean data computes straight through. Here two sources disagree, so the loop stops for the owner.
- 1Read the practice, its sources and the latest saved run
- 2Detect issues deterministically: missing, unverified, inconsistent, currency, ambiguous, default value
- 3Word one plain question per issue; the model writes words only and fixed wording takes over if it fails
- 4Wait for the owner: pick a source, enter a value, start a pull, or compute anyway as provisional
- 5Compute on the owner's click; open items are saved with the run and listed on the report
Step log · illustrative
| seq | kind | tool | tier |
|---|---|---|---|
| 1 | tool | read_preflight | read |
| 2 | model | order_issues | |
| 3 | system | waiting_owner | |
| 4 | owner | answer:pick_source | |
| 5 | tool | write_value | execute_after_approval |
| 6 | tool | read_preflight | read |
| 7 | owner | compute | |
| 8 | tool | compute | execute_after_approval |
Over MCP.
The same rules hold when the work runs in Claude, ChatGPT or any MCP client.
compute_valuation
Runs the data check first. With blocking issues it returns the typed issues and questions instead of a valuation, unless the call passes gaps_acknowledged: true, which saves the run as provisional.
validate_practice
An explicit check. format: "issues" returns each issue's type, a question and the sources that can fill it, so the assistant can work through them with the owner.
Pulls stay with the owner
In your AI assistant, your own connectors do the reading, and ValuationMCP never receives their credentials. Only the totals you approve are saved, each with its source.
Loops today
Every move on a plan also has its own lifecycle: planned, in progress, done and verified against the next saved run.
| Loop | When it runs | What it does |
|---|---|---|
| validate | When it runs:Before every compute, in the workbench and over MCP | What it does:Finds missing, conflicting, unverified and default inputs and asks only about those. |
| margin | When it runs:On the operating-margin move, and re-checked on the move's cadence | What it does:Reads the P&L the owner pulls, shows the expense mix and the gap to the size-tier median, drafts steps the owner applies. |
| hosted agent | When it runs:On an assigned move's cadence, or Run now | What it does:Works the next open step, drafts the deliverable the move's playbook names, and leaves every change as a card for the owner. |
Run it in your assistant
Connect ValuationMCP to Claude or ChatGPT and ask for a valuation. The plain-English versions of these rules are on How it works and Trust & data use.