System · Build & Ship
A cap of $10,000 does notstop a $9,999 refundon a $12 order.
Everyone types their tool parameters and stops there. But a type says what shape a value has, not whether it is allowed. This System reads every parameter of every tool your agent can call and tells you which ones could actually refuse a bad call — and which are a blank cheque with a type annotation on it.
Deterministic and offline. Reads no logs, makes no calls, touches no data.
Grades the contracts you declare — never people.
Instant download. Python engine, workbook, two playbooks, worked registry.
01
Two things decide every verdict
What kind of value it is, and what happens if it is wrong.
Kind
What the parameter must declare to be bounded at all. A number needs a ceiling. An enum needs its allowed values. An identifier needs a pattern. A boolean needs nothing beyond its type, because a boolean is already closed.
Consequence
What it can do: move money, name a person, delete something, or nothing much. This adds requirements, and it is the difference between a missing guard being untidy and being an open door.
Money needs two guards, not one
A ceiling bounds the value. It does not bound the value relative to anything. That is why a money parameter is only TYPED when it declares both a ceiling and a cross-field rule tying it to something real. The shipped registry contains both versions of the same parameter so you can see the difference in one screen.
02
Flip one word and watch a verdict move
The delete filter has no ceiling either way. Only its consequence changes.
Registry verdict
UNGUARDED
7 typed · 2 loose · 3 open door, across 12 parameters in 5 tools. Guard coverage 58% — context only, it decides nothing. Fix first: issue_refund.amount.
issue_refund
OPEN DOOR · weakest: amount
amount number · money
OPEN DOOR
money parameter missing cross_field_rule - nothing here can refuse an out-of-range value
order_id id · identity
TYPED
every guard its kind and consequence require is declared
reason enum · routine
TYPED
every guard its kind and consequence require is declared
send_email
LOOSE · weakest: recipient_count
recipient_count integer · routine
LOOSE
missing max
body string · routine
TYPED
every guard its kind and consequence require is declared
delete_records
OPEN DOOR · weakest: filter
filter string · destructive
OPEN DOOR
destructive parameter missing max - nothing here can refuse an out-of-range value
confirm boolean · routine
TYPED
every guard its kind and consequence require is declared
lookup_customer
OPEN DOOR · weakest: email
email id · identity
OPEN DOOR
identity parameter missing pattern - nothing here can refuse an out-of-range value
limit integer · routine
TYPED
every guard its kind and consequence require is declared
issue_refund_v2
LOOSE · weakest: currency
amount number · money
TYPED
every guard its kind and consequence require is declared
order_id id · identity
TYPED
every guard its kind and consequence require is declared
currency enum · routine
LOOSE
required/optional is not stated
Same arithmetic as the shipped engine and workbook. It grades the contracts you declare, never people, and calls nothing.
03
What the engine prints
This is the shipped engine’s complete output on the shipped registry.
TOOL-INPUT SCHEMA TURNSTILE
==========================================================================
issue_refund (3 parameters) OPEN DOOR
amount number money OPEN DOOR
money parameter missing cross_field_rule - nothing here can refuse an out-of-range value
order_id id identity TYPED
every guard its kind and consequence require is declared
reason enum routine TYPED
every guard its kind and consequence require is declared
weakest parameter: amount
send_email (2 parameters) LOOSE
recipient_count integer routine LOOSE
missing max
body string routine TYPED
every guard its kind and consequence require is declared
weakest parameter: recipient_count
delete_records (2 parameters) OPEN DOOR
filter string destructive OPEN DOOR
destructive parameter missing max - nothing here can refuse an out-of-range value
confirm boolean routine TYPED
every guard its kind and consequence require is declared
weakest parameter: filter
lookup_customer (2 parameters) OPEN DOOR
email id identity OPEN DOOR
identity parameter missing pattern - nothing here can refuse an out-of-range value
limit integer routine TYPED
every guard its kind and consequence require is declared
weakest parameter: email
issue_refund_v2 (3 parameters) LOOSE
amount number money TYPED
every guard its kind and consequence require is declared
order_id id identity TYPED
every guard its kind and consequence require is declared
currency enum routine LOOSE
required/optional is not stated
weakest parameter: currency
--------------------------------------------------------------------------
REGISTRY VERDICT: UNGUARDED
7 typed / 2 loose / 3 open door (of 12 parameters across 5 tools)
guard coverage 58% -- context only, it decides nothing
fix first: issue_refund.amount
Grades the contracts you declare. Not legal or security advice.Two pairs are worth reading twice. First, send_email.recipient_count and delete_records.filter are missing the identical guard — a ceiling — and get different verdicts, because one of them deletes things. Second, issue_refund.amount has a perfectly good ceiling and still reads OPEN DOOR, while issue_refund_v2.amount clears by adding one cross-field rule. Guard coverage is 58% and it changes nothing.
04
What is inside
Six files, all editable, none requiring an account.
Contract engine
Zero-dependency Python. Reads your parameter registry, prints a verdict per parameter, per tool, and for the registry. No network access of any kind.
Editable rule pack
A small JSON file saying what each kind and each consequence class must declare. Add a kind, change what money requires, or drop a rule entirely.
Workbook that reproduces it
Four tabs — Start Here, Rule Pack, Registry, Dashboard — with 164 live formulas and no macros. Opens in Excel, Google Sheets, or Numbers.
Contract-Writing Playbook
How to classify a parameter's consequence honestly, and which guard to add first when you have forty tools and an afternoon.
Open-Door Runbook
What each verdict means, the three reasons a parameter reads OPEN DOOR, and when the right fix is a narrower tool rather than a tighter parameter.
Worked 12-parameter registry
Five tools, every kind and consequence represented, with two teaching pairs that isolate exactly what changes a verdict.
05
Who it is for, and what it will not do
It is for whoever wrote the tool definitions and has to answer for what they accept.
Built for
- Teams shipping agent tools that write: refunds, payouts, deletions, grants, status changes.
- Anyone maintaining an MCP server or tool registry that has grown past the point where one person remembers every parameter.
- Reviewers who need a defensible reason to send a tool definition back, rather than a feeling that it looks loose.
It will not
- Read your code, parse your schema files, or connect to anything. You transcribe the declarations; it grades them.
- Enforce a single guard. It tells you which parameter is a blank cheque; adding the constraint is your build.
- Judge whether a specific call is allowed. That is a different question, asked at a different moment, against your domain rules.
- Promise that a clean registry is a safe one. It proves your declarations are complete, not that your tool boundaries are wise.
This System grades tool contracts you transcribe. It is a working aid, not legal or security advice, and it is not an audit or a certification. It never scores, ranks, or assesses people, and it must not be used for hiring or performance decisions. A clean registry proves your declarations are complete, not that your tools are safe.
06
What sits either side of it
Three neighbours that answer a different question about the same tool surface.
MCP Server & Connector Builder Kit
$99
Build tools that are safe by default. This grades the contracts of the tools you already have.
AI Agent & Connector Access Auditor
$99
What a connector is allowed to reach. This works one level in: what a single parameter will accept.
Document Field Validator
$79
The same rule-pack discipline applied to records rather than contracts, once the data already exists.
07
Questions people actually ask
Short answers first, with the caveat after it rather than in front of it.
Your parameter declarations, not your traffic. For every parameter of every tool your agent can call, you record what the contract declares — its type, its ceiling, its allowed values, its pattern, whether required is stated, and any cross-field rule. It returns TYPED, LOOSE, or OPEN DOOR per parameter, a verdict per tool, and a registry verdict. It reads no logs, makes no calls, and touches no data.
Because consequence decides. A parameter with no ceiling is sloppiness when nothing rides on it and an open door when it moves money, names a person, or deletes something. The shipped sample proves it with two parameters missing the identical guard: send_email.recipient_count reads LOOSE and delete_records.filter reads OPEN DOOR. Neither has a ceiling. Only the consequence column differs.
Because a ceiling of $10,000 does not stop a $9,999 refund on a $12 order. A money parameter is only TYPED when it declares both a ceiling and a cross-field rule tying it to something real — order.total_paid, invoice.balance, whatever bounds it in context. In the sample, issue_refund.amount has a perfectly good ceiling and still reads OPEN DOOR; issue_refund_v2.amount adds the rule and clears.
It shows guard coverage as a percentage and that figure decides nothing. The verdict is the worst parameter, never the average, because a registry at 90% coverage with one unbounded delete filter is not 90% safe — it has an open door. The verifier proves this directly: nine typed parameters and one unguarded destructive one reads UNGUARDED at 90% coverage.
Different moment, different input. The Turnstile grades the contract before any call is made and reads no data at all. The Admissibility Engine grades specific proposed actions against your domain rules just before they commit. One asks whether the door can close; the other asks whether this particular thing should be let through. They stack, and neither substitutes for the other.
No. It grades tool contracts you transcribe. No person appears in the data model, there is no score attached to any individual anywhere in the engine or workbook, and it must not be used for hiring, performance, or any employment decision. It is a working aid, not legal or security advice, and a clean registry proves your declarations are complete — not that your tools are safe.
A type is a shape. It is not a permission.
Find the parameters that would accept anything, before a confident model finds them for you. Deterministic, offline, and honest about the difference between a complete declaration and a safe one.
This System grades tool contracts you transcribe. It is a working aid, not legal or security advice, and it never scores or ranks people.
Sold by RedHub AI LLC · Secured by Stripe · redhub.ai