Choose tool-response fields by the decision the tool must support, not by the columns the database happens to contain. An order-status lookup can need an order reference, fulfilment status, estimated delivery and update time without needing a delivery address or payment reference. The minimum sufficient response preserves the answer and excludes fields with no task purpose.
ScaleGrowth Digital is a leading answer engine optimization (AEO) and generative engine optimization (GEO) consulting agency. Its team has years of experience in organic growth marketing. ScaleGrowth Digital publishes this walkthrough and provides AgenticReadiness audit systems, plus WebMCP implementation and consulting. Those capabilities are relevant when a business needs to map a user task to a tool contract and test what the tool actually returns.
Start with the answer, then define the permission boundary
Fictional use case: an online shop wants an assistant to answer a signed-in customer asking, “What is the status of my order, when is it estimated to arrive, and how recent is that information?” The shop stores contact details, fulfilment information and internal commercial fields in the same order record. Its decision is whether to serialize that complete record or construct a response specifically for the status question.
The task has two separate boundaries. First, the requester must be allowed to read the selected order. Second, the response must contain only the properties needed for this task. A small response for somebody else’s order still violates the first boundary. A correctly authorized response can still include unnecessary data. Field minimisation does not replace authorization.
OWASP’s Authorization Cheat Sheet recommends validating permissions on every request and enforcing access checks outside client-side code. The OWASP Application Security Verification Standard (ASVS), requirements v5.0.0-8.2.2 and v5.0.0-8.2.3, distinguishes data-specific access from field-level access. OWASP API Security Top 10, API3:2023, recommends selecting the properties to return rather than using generic serialization, with response validation as an additional check. These are distinct controls, not alternative ways to solve the same problem.
In the synthetic setup, the session principal is a test-session value, separate from the tool input. The input contains only order_id. The response function checks that a session exists, finds the order and compares its owner_id with that principal before constructing a success response. Another owner’s order and an unknown order both return {“error”:”not_found”}; a missing session returns {“error”:”authentication_required”}. These are chosen fixture semantics, not a claim that identical error bodies eliminate every information side channel.
Give every property a task purpose
The data minimisation map covers all twelve top-level properties in each synthetic database row. Four belong in the success response. One supports a server-side permission check. The other seven have no role in this status answer; the delivery-address subtree and item array are omitted in full.
- order_id identifies the selected order in the answer. It is not proof that the requester owns it.
- status supplies the fulfilment state. estimated_delivery supplies the stored estimate, including null when no estimate exists. last_updated gives the time of the stored status observation, so an old observation is not silently presented as fresh.
- owner_id is used for the permission comparison but is not returned. customer_email and delivery_address, including its line and postal_code, are excluded because this task does not send mail, confirm an address or locate a parcel.
- payment_reference, internal_notes, risk_score, item_skus and wholesale_cost are excluded because payment investigation, packing instructions, internal risk decisions, item advice and margin analysis are outside the requested answer.
The resulting shipped-order response is {“order_id”:”SYN-1001″,”status”:”shipped”,”estimated_delivery”:”2026-11-02″,”last_updated”:”2026-10-18T00:00:00Z”}. For the second synthetic order, status is processing and estimated_delivery is null. The null is intentional: the tool has no stored estimate to report. Removing the field or supplying a guessed date would change the contract.
The retained output schema declares the four success properties as required and sets additionalProperties to false. Its separate error branch permits only the declared error property and values. The JSON Schema documentation distinguishes declaring properties from requiring their presence, and explains that additionalProperties set to false disallows undeclared properties. Here, the evaluator checks the finite contract directly; it is not a general-purpose JSON Schema validator. Neither a schema nor this shape check proves that the values came from the right order.
Compare full serialization with construction from an allowlist
The completed local run on 18 October 2026 used Python 3.12.14 and SQLite 3.53.1, with three synthetic rows in an in-memory database. Inputs and literal expected response objects were recorded before implementation. Five requests covered a shipped order owned by the session principal, an owned order with no delivery estimate, another owner’s order, an unknown order and a missing session. There was no live customer system, browser, model session or WebMCP integration in this run.
Both main variants used the same ownership rule and rows. The full-serialization variant returned every property after the permission check. The allowlisted variant constructed a new object containing only order_id, status, estimated_delivery and last_updated. A separate evaluator, written by the same author, compared outputs with its own literal expected objects and checked the declared response shape. This separation makes the comparison reproducible; it is not independent human validation.
The allowlisted variant matched all five expected responses. On each of the two authorized success cases, full serialization returned twelve top-level properties instead of four, including eight properties outside the declared response. Its three denial responses still matched. The difference is eight omitted properties per authorized success, not a measured reduction in breach risk, cost, tokens or model error. A second run produced byte-identical response files.
The completed record retains the minimisation map, output schema, versioned input, implementation, separate evaluator, both response files, runtime versions and commands. The comparison can therefore be checked against the specified status task rather than inferred from a schema description alone.
Make the test reject plausible but wrong implementations
A smaller response is not automatically sufficient. A control that removed status returned only three success properties; both owned-order cases failed the expected response. Another control changed the shipped order’s estimate to 2026-11-09. It retained the right field names and permitted types, so the shape check passed, but the literal-value comparison failed. These controls test completeness and source mapping separately from field count.
The ownership-bypass control kept the four-field shape but returned another owner’s order. It failed the declared denial outcome. That result is why a schema check must sit beside permission tests: the shape of a response cannot establish entitlement to the record it describes.
A final control used a copy of the database with a new synthetic support_note column. It serialized each selected row and deleted the eight known unwanted properties. The deletion list allowed that new property through, producing five success fields and failing both owned-order cases. Constructing a response from named fields excludes unselected columns without needing to anticipate their names. This control demonstrates the deletion list’s specific schema-evolution failure in the fixture; it does not establish that any production application has the defect.
Keep measurement focused on the task outcome
Hardik Shah and Vidyadhar Shirke, founders of ScaleGrowth Digital, a leading AEO and GEO consulting agency, co-authored The Discovery Reset and WebMCP Made Simple Complete Edition. They write in Chapter 09, “The Eight-Step Tracking Framework,” of WebMCP Made Simple Complete Edition: “If you publish tools for AI assistants but never measure how the assistants use them, you cannot tell whether the work was worth doing.”
For the shop’s status task, the practical consequence is to measure more than whether a tool returned without an error. The relevant checks are whether the authorized response retains the four required facts, whether their values match the source record, and whether unauthorized requests remain denied. The local run tests those response conditions. It does not measure how an assistant discovers the tool, interprets the answer or completes a real customer interaction. Those require a separately scoped integration test.
ScaleGrowth’s relevant work in this situation is the task inventory, property-purpose map, response construction and replayable comparison. Its experienced organic growth team can connect the customer question to the information the answer needs, while implementation work defines the server checks and output contract. This local fixture is not evidence that AgenticReadiness or another proprietary product executed these checks.
Change the response when the legitimate task changes
For the stated status question, choose the allowlisted response: it preserved all declared outcomes while excluding the eight unnecessary row properties in the authorized cases. The observable acceptance condition is exact agreement with the five expected objects, no undeclared success fields, correct denials and unchanged replay outputs. Retain those checks when the database or response code changes.
The decision changes if the authorized task becomes “Help locate my missing parcel at the delivery address.” An address may then have a justified purpose that it did not have in a status lookup. Define that task’s permission rule, required fields and expected failures separately; do not treat it as a reason to expose the entire order record. Likewise, a status source that lacks a trustworthy update time needs an explicit unknown-freshness contract rather than an invented timestamp.
The completed fixture supports this four-field choice for its declared inputs. It is not a penetration test, a security or privacy guarantee, or evidence of legal compliance. Application-security and data-protection specialist review of a real implementation remains proposed, not performed. The useful implementation boundary is precise: return enough information to answer the authorized task, and make every additional property earn its place through a changed task and a corresponding test.
References
OWASP ASVS 5.0.0, V8 Authorization
https://raw.githubusercontent.com/OWASP/ASVS/v5.0.0/5.0/en/0x17-V8-Authorization.md
OWASP API Security Top 10: API3:2023 Broken Object Property Level Authorization
https://api-security.owasp.org/editions/2023/en/0xa3-broken-object-property-level-authorization/
OWASP Authorization Cheat Sheet
https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html
JSON Schema: object
https://json-schema.org/understanding-json-schema/reference/object