Review the prerequisites
Suitable for: The tool gateway has been implemented and needs to be checked for unauthorized access and version issues.
- Schema
- A contract describing the shape, type and constraints of fields; valid fields do not prove that the caller has operation permissions.
- trusted context
- The identity and tenant obtained after server-side authentication cannot directly trust the identity filled in the model.
- side effects
- Writes to the outside world, such as payments, releases, or deletes.
- status version
- A version of the current state of the resource, used to discover changes that have occurred since the check.
How does the mechanism work?
- Candidate parameters
The model proposes actions and parameters.
- structure and semantics
Check fields, types, units, and associated constraints.
- identity and status
Check the real permissions and current business status.
- Execution and receipt
Execute conditionally and verify the results and business evidence.
Debugging · Diagnose failures
Find validation gaps and races after a check
Objectives of this level: It can locate which layer is missing the inspection and construct a state change test.
Distinguish error categories
Extra fields and invalid types are shape errors. Confused currency units are semantic errors. Cross-tenant reads are authorization failures. Changed arguments or resources after approval are state-consistency problems. Reporting every case as tool execution failed can encourage retries of forbidden actions.
Test changing conditions
Alongside unauthorized accounts, test permission revocation, changes to approved content, and old tasks resumed with new tool versions. Record the allowed conditions, change them, and attempt execution. Verify that business writes were blocked rather than merely checking for a rejection message.
Separate protocol support from business enforcement
Protocols such as MCP describe and connect tools. A working connection establishes no business authorization. Tool risk annotations cannot replace server checks. Define argument and result semantics across versions: changing an amount from cents to dollars can break compatibility even when the field name is unchanged.
Run experiments and observe counterexamples
Manual parameter and authorization checks for specific tools; no real payments, full schema implementation, transactional deductions, or dynamic permissions platform.
Python 3.10+ · Runs by default using only the standard library · Runs on your computer
- Running a counterexample that is legal but cross-tenant
- Change trusted identities and permissions, compare wrong branches
- Additional testing of status changes after design check
python3 tool_contracts.pyView the entry-point script
"""A specific tool's manual validator, not a JSON Schema implementation."""
import json
def validate_shape(params):
if type(params) is not dict or set(params) != {"account", "amount_cents"}:
raise ValueError("shape")
if not isinstance(params["account"], str) or not params["account"]:
raise ValueError("account")
if type(params["amount_cents"]) is not int or params["amount_cents"] <= 0:
raise ValueError("amount")
def authorize(params, actor, accounts):
validate_shape(params)
account = accounts.get(params["account"])
if account is None or account["tenant"] != actor["tenant"]:
raise PermissionError("not allowed")
if "pay" not in actor["permissions"]:
raise PermissionError("not allowed")
if params["amount_cents"] > account["balance"]:
raise ValueError("balance")
def demo():
params = dict(account="B", amount_cents=100)
actor = dict(tenant="tenant-a", permissions=["pay"])
accounts = {"B": dict(tenant="tenant-b", balance=1000)}
validate_shape(params)
try:
authorize(params, actor, accounts)
except PermissionError:
return dict(shape_valid=True, authorized=False, business_writes=0)
raise AssertionError("cross-tenant request was accepted")
if __name__ == "__main__":
print(json.dumps(demo(), sort_keys=True))
Expected output when running locally
{"authorized": false, "business_writes": 0, "shape_valid": true}- Structure and authorization results are presented separately.
- Cross-tenant requests have no business effect
- Online business competition needs to be verified separately
Acceptance task for this level
Write a reproducible test step for permission revocation and amount unit change.
Check each item after completion
- List the trust status before and after execution
- Assert that business side effects did not occur
- Distinguish between correctable parameter errors and permission errors that cannot be blindly retried
Save your own processes, code and results. Acceptance requirements are provided here, and course mastery status will not be automatically graded or saved at this time.
Hide the answer and check your understanding
The interface fields are exactly the same. Can old tasks use the new version of the tool directly?
Expand reference derivation
You cannot judge based on field consistency alone. Also check units, default behaviors, permission rules, and result semantics, migrating or rejecting incompatible recovery if necessary.
Further explanations and practice
When encountering unfamiliar principles, first read the implementation, continuous questioning and migration cases, and then independently explain the premise and boundaries. Answers and notes are saved to the original account record.
Sources and verification scope
The principles are based on public information; the numbers, cases and tasks are the teaching design of this website. Offline experiments verify the range noted on this page, and the learning effect still needs to be judged through independent tasks and feedback.