Tool parameters: structure, authorization, and business constraints

LEARN · PRACTICE · REFLECT

Knowledge learning and personal records

First read along the principles, Q&A and migration cases. When you need to check your understanding, switch to reinforcement exercises or start personal recording.

Answers and personal notes

my answer0 / 20,000

Each modified commit will be kept as an independent history. Your level of mastery is up to you to evaluate yourself against the standards.

Core concept · Tool parameters: structure, authorization, and business constraints

Understand the core principles first

Preparatory concepts:JSON Schema, authentication session, database transaction

The valid structure only proves that the input shape is parsable. Identity, resource ownership and executable business status are facts that change with the request context and must be verified by the server; there is still a time window between inspection and submission, and consistency rules need to be clarified.

Parameters and identity come from different sources

Model-supplied account_id identifies a desired target; the server session identifies the caller. A schema constrains ID format without establishing ownership. Direct requests can forge fields even if a model is compliant, so every entry point needs authorization.

Separate validation layers

Parsing checks fields and types. Semantic checks handle date ordering, units, and cross-field relationships. Authorization checks subject-resource access. Business-state checks protect balances, inventory, and transitions. Prompts cannot enforce these boundaries. Calling every failure a parameter error encourages repeated guesses at permissions.

Passing a check does not freeze state

Another request may spend a balance between reading and debiting it. Conditional writes, locks, or suitable isolation enforce the invariant. Asking the model again cannot close the race. MCP schemas describe protocol contracts; database consistency and error classes remain tool-implementation responsibilities.

Check understanding with a question

Are tool parameters safe if they conform to JSON Schema? What other verifications are needed?

JSON Schema checks shape and local constraints without establishing account ownership or sufficient balance. Validate structure, derive identity and tenant from a trusted session, check access and business state, then execute and validate results. Model-supplied tenant_id or approved fields cannot grant authority. Return redacted structured errors; authorization denial must not trigger unlimited parameter guessing.

Implementation and trade-offs

Schemas establish limited properties

Required fields, enums, lengths, ranges, and extra-field rules constrain shape. MCP inputSchema and optional outputSchema, or typed OpenAI function tools, improve consistency. A string account_id does not establish ownership; positive amounts do not establish funds; a valid date does not establish an open settlement window.

Enforce four validation layers

Parse and validate structure; check semantics such as date ordering and minor currency units; derive identity and tenant from authentication and authorize resources; then enforce business conditions transactionally or with versioned writes. Models cannot supply trusted identities. Hiding tools on a client does not protect direct API access.

Errors and outputs are contracts too

Return field paths for correctable parameters, stable access-denial categories without cross-tenant existence leaks, and redacted transient errors. Successful outputs include state, resource ID, and evidence within size limits. Uncontrolled downstream text cannot grant permissions or alter rules. Runtime retains approval and authentication decisions independently of “the user agreed” in tool text.

Test invalid and adversarial inputs

The example manually validates one tool with the standard library, rejecting extra fields and booleans posing as integers, and checking ownership through trusted context. It is not a general schema engine. Add negative amounts, oversized inputs, cross-tenant IDs, and changed state. Production needs mature validators, transactions, and centralized authorization. Persist tool contracts; block incompatible recovery and require migration.

code example

Parameter and ownership verification of running a specific tool

Save it as demo.py and execute it using Python 3; it only demonstrates manual verification and trusted identity injection, without network calls.

import json

ACCOUNTS = {"a1": "tenant-a", "a2": "tenant-b"}

def validate(raw, trusted_tenant):
    args = json.loads(raw)
    if not isinstance(args, dict) or set(args) != {"account_id", "limit"}:
        raise ValueError("INVALID_FIELDS")
    if not isinstance(args["account_id"], str):
        raise ValueError("INVALID_ACCOUNT_ID")
    # bool is a subclass of int in Python; require the exact type.
    if type(args["limit"]) is not int or not 1 <= args["limit"] <= 100:
        raise ValueError("INVALID_LIMIT")
    if ACCOUNTS.get(args["account_id"]) != trusted_tenant:
        raise PermissionError("RESOURCE_UNAVAILABLE")
    return args

samples = [
    '{"account_id":"a1","limit":10}',
    '{"account_id":"a1","limit":true}',
    '{"account_id":"a2","limit":10}',
]
for raw in samples:
    try:
        print("OK", validate(raw, "tenant-a"))
    except (ValueError, PermissionError) as exc:
        print("REJECT", str(exc))

expected output

OK {'account_id': 'a1', 'limit': 10}
REJECT INVALID_LIMIT
REJECT RESOURCE_UNAVAILABLE

Engineering deduction

scene: Assume engineering scenario: the balance query tool accepts account_id, and the model obtains the account ID of another department from the user text.
design decisions: Remove identity fields controlled by the model. The gateway uses tenant_id from the signed-in session and checks account ownership before querying.
Verify target: Demonstration expectations: Valid arguments of the same tenant are passed; extra fields, Boolean amounts, and cross-tenant accounts are rejected.
applicable boundary: The code only shows manual verification of a specific call and does not include authentication, real balance query or general Schema implementation.

Continuous questions and answers

Continue reading along with the premises and constraints of the problem. Understand the reference answers first, then try to put away the answers and explain the cause and effect and trade-offs in your own words.

Level 1Why can’t the server trust the tenant_id passed by the model?
Extend from structure verification to data source credibility to avoid identity fields from crossing boundaries.
Reference answer
tenant_id is a controllable input of the model and cannot prove the current identity. The server reads the accessible tenant from the authenticated session or delegation token, and queries and writes both include this range; if the user legally switches tenants, membership is checked first and then a trusted context is selected. You can let the model express the intent of the target tenant, but the final authorization cannot come from the value it fills in.
Level 1The Schema is legal but the balance is insufficient. How to return an error?
Valid shapes may still violate business conditions, and the error type determines the next behavior.
Reference answer
Returns a business error, such as the category is insufficient_funds, retry is false, and gives the current user the amount allowed to be known or a correction prompt. Do not retry this as though it were a network failure, and do not allow the model to reduce the amount without authorization and continue execution. If the user modifies the action, re-authorize, approve and check the balance; errors cannot reveal the balance of other accounts.
Level 1After the verification is passed, the permission is revoked. How to avoid the time difference problem?
An authorization snapshot cannot permanently approve future operations.
Reference answer
For sensitive actions, authorization is re-verified at the actual submission point, and the effective boundary of permission revocation is designed. If permissions and writes are in the same database, permission versions can be locked or compared in the transaction; if across services, version conditions, short-term credentials, and execution-side verification can be used to reduce the window, but cross-system atomic guarantees cannot be claimed. How to handle submitted actions requires clear business rules.
Follow this answer further
1. Level 2There is an independent service for authorization. Is there no race condition after checking again before submitting?
  Revalidation reduces the window but does not eliminate cross-service time differences, and the consistency goal needs to be clearly stated.
  Reference answer
  No. Privilege may still be revoked between query return and remote writing. It is clear whether the request is authorized at the beginning, authorized at the time of submission, or requires strong synchronization and revocation; high-impact actions can use short-term authorization that can be verified by the execution side or a centralized submission entry. If immediate revocation is necessary, a coordination mechanism and its availability cost are required, and cannot be checked only once.
  Follow this answer further
  1. Level 3The action has been submitted when the user cancels permission. Should it be rolled back?
    Side effects that have already occurred require consistency rules to account for revocation and compensation.
    Reference answer
    First confirm the submission facts and decide whether to initiate compensation according to the withdrawal strategy. Actions after general permission revocation and blocking will not automatically erase legal submissions; if the business requires recovery, compensation also requires independent permissions, receipts and failure status. The log retains the authorized version and submission time to avoid changing success to never execution later.

Draw inferences from one example: If the conditions change, how to deduce it?

First find out the conditions for change, and then determine which premises in the original plan still hold true. The following cases are teaching deductions to facilitate the transfer of principles to new problems.

Tenant Administrator Agent Operations

Changing conditions:Single-user resources become restricted delegation

Extended question:Can administrators ignore resource ownership?

Derivation and reference solutions

No. Check its administrator scope, delegated objects and action permissions, and audit while recording the operator and beneficiary subjects. Restricted delegation may allow viewing but not export or transfer. The same Schema does not mean the same permissions; query results are tailored to the actual scope.

The principles that remain unchanged:Subjects, resources and actions must be jointly judged in a trusted context.

Read-only batch query

Changing conditions:Single resource write becomes cross resource read

Extended question:Does read-only require Schema?

Derivation and reference solutions

It is still necessary to authorize resources on a per-resource basis or filter by permissions when querying, and to limit paging, result size, and sensitive fields. No write side effects reduce transaction problems, but do not eliminate privacy and existence leaks; forbidden resources can return a unified rejection, and batch results cannot expose their names.

The principles that remain unchanged:Structural correctness is always separate from having access, and read permission is also a real boundary.

Easy to make mistakes

Pass Schema legality as authorization
Only hide tools on the front end, no verification on the server side
Direct isinstance(value, int) in Python unexpectedly accepts bool

References

It is designed based on public technical information; the reference materials support the technical mechanism, and the scenarios and scoring standards are designed by this website and do not represent the original interview questions of a certain company. New Q&A and migration cases are added for principle explanation, and source verification and case operation verification are recorded separately.

Check how far you understand

After reading, you can explain the principles, boundaries, and trade-offs against these standards. It is up to you to evaluate your mastery; if further verification is needed, complete the small tasks below.

Basic standards met: Distinguish between correct field format and business execution.
Intermediate and advanced signals: Verify identity, entity ownership, scope, unit and cross-field constraints.
Senior criteria: Can handle dynamic permissions, stale entity state and post-validation race conditions.

View verification records for independent examples

Continue to do advanced research experiments

Push the read-only tool boundary to the approval boundary

First observe whether business effects have been generated while waiting for approval, and then press README to check action binding and recovery.

Read full text and fault analysis → · Download Reliability Experiment v3 ↓

python3 approval_cli.py submit
python3 approval_cli.py run
python3 approval_cli.py inspect
# 审查 draft 和 action_json 后，按 README 使用对应 binding_hash 批准并恢复

Keep evidence and check item by item

Status waiting_approval, no reports service has written yet.
Review actions, targets, scopes, inputs, and content summaries before approving the corresponding binding_hash.
Run tests to reject, cancel and modify content respectively to explain why old approvals cannot be reused.

Local approval fixture; --actor is not a login or production authentication. No network by default.

Hands-on verificationComplete on demand · Suggestions15 minutes

Checks for a valid JSON payment request, indicating what validation is required outside of the Schema.

Expand acceptance requirements and checkpoints

The amount unit is clear
Independent check of account ownership
Parameter changes will result in re-verification.

Key inspections

Distinguish between structure verification, business rules and resource authorization
Identity comes from trusted server context rather than model parameters
Be able to illustrate the risks of additional fields, Boolean values, and result validation

Tool parameters: structure, authorization, and business constraints

Which step do you want to learn from this knowledge point?

Understand first

Implement next

Debug failures

Compare designs

Knowledge learning and personal records

Understand the core principles first

Parameters and identity come from different sources

Separate validation layers

Passing a check does not freeze state

Check understanding with a question

Are tool parameters safe if they conform to JSON Schema? What other verifications are needed?

Implementation and trade-offs

Schemas establish limited properties

Enforce four validation layers

Errors and outputs are contracts too

Test invalid and adversarial inputs

code example

Parameter and ownership verification of running a specific tool

Engineering deduction

Continuous questions and answers

Draw inferences from one example: If the conditions change, how to deduce it?

Tenant Administrator Agent Operations

Read-only batch query

Easy to make mistakes

References

Check how far you understand

Continue to do advanced research experiments

Push the read-only tool boundary to the approval boundary

Keep evidence and check item by item

Hands-on verificationComplete on demand · Suggestions15 minutes

Key inspections

Which step do you want to learn from this knowledge point?

Understand first

Implement next

Debug failures

Compare designs

Knowledge learning and personal records

Understand the core principles first

Parameters and identity come from different sources

Separate validation layers

Passing a check does not freeze state

Check understanding with a question

Are tool parameters safe if they conform to JSON Schema? What other verifications are needed?

Implementation and trade-offs

Schemas establish limited properties

Enforce four validation layers

Errors and outputs are contracts too

Test invalid and adversarial inputs

code example

Parameter and ownership verification of running a specific tool

Engineering deduction

Continuous questions and answers

Draw inferences from one example: If the conditions change, how to deduce it?

Tenant Administrator Agent Operations

Read-only batch query

Easy to make mistakes

References

Check how far you understand

Continue to go deeper

Continue to do advanced research experiments

Push the read-only tool boundary to the approval boundary

Keep evidence and check item by item

Hands-on verificationComplete on demand · Suggestions15 minutes

Key inspections