Shipment Document Check

• 

  The starting shipment pack, with five documents, nine checks and the WebMCP review workflow in one place.

• 

  The agent has prepared two corrections for exporter-owned documents. Both remain staged until a person approves them.

• 

  The Bill of Lading remains locked while the application prepares an unsent correction request for the carrier.

• 

  The goods descriptions are shown side by side so a person can review the evidence and confirm the final decision.

Inspiration

Export shipments involve several documents, and those documents are not all controlled by the same person. The exporter prepares some of them, while others come from a bank, carrier or public authority. What interested me was that finding a mismatch is only half the job. The reviewer also needs to know who is allowed to correct it. An exporter can fix its own invoice, but it cannot rewrite a Bill of Lading issued by a carrier. Some differences are also unclear enough that a person still needs to make the final decision. I built Shipment Document Check to explore how an agent could help with this work without being given permission to change everything.

What it does

The application reviews one fictional shipment pack containing five documents:

• Letter of Credit
• Commercial Invoice
• Packing List
• Bill of Lading
• Certificate of Origin

It runs nine consistency checks and starts with five findings. For documents controlled by the exporter, the agent can prepare a correction. The correction is shown in the page, but a person must approve it before it is applied. For documents issued by a carrier or authority, the original document stays locked. The agent can prepare a correction request, but it cannot change the document or send the request. There is also a goods-description difference that needs human judgement. The agent can show the evidence and record a proposed decision, but a person must confirm it. After the approved corrections and confirmed decision, the preflight is run again. Seven of the nine checks pass. The remaining two issues still need action from the external issuers.

How WebMCP is used

I did not want to add another chatbot inside the application. Instead, the page exposes six WebMCP tools directly to a compatible browser agent:

• get_pack_state
• get_finding_evidence
• stage_exporter_corrections
• draft_external_correction_requests
• stage_human_decision
• rerun_preflight

These tools give the agent a clear set of actions instead of making it guess from buttons and page text. The agent and the person reviewing the shipment work with the same visible state. When the agent stages a correction or decision, it appears in the page for review. Approval is deliberately kept outside the agent's control. The application also contains an instruction hidden inside a fictional trade document. That text is treated as document content, not as an instruction the agent should follow.

How I built it

The project is a client-side React and TypeScript application built with Vite. The shipment data and all nine checks are deterministic. React useReducer manages the workflow, and Zod validates the document data and WebMCP tool inputs. The WebMCP tools are registered through document.modelContext.registerTool. The tools and the manual interface use the same reducer actions, so the agent cannot bypass rules that apply in the page. There is no backend, login, database, OCR service or document upload. Everything in the shipment pack is fictional and stays in the browser.

Challenges I ran into

The main challenge was keeping the agent useful without giving it too much control. A staged correction must not be mistaken for an approved correction. A drafted request must not be mistaken for a sent request. The WebMCP result and the visible page also need to show the same workflow state after every action. It was equally important to prove that locked documents are actually protected. If the agent tries to modify the carrier-issued Bill of Lading, the application returns DOCUMENT_LOCKED and leaves the document unchanged.

What I am proud of

The project has only six tools, and each one has a clear purpose. The final result is also honest. The application ends with seven passing checks and two issues still waiting for external action. It does not pretend that every problem can be solved automatically.

What I learned

This project changed how I think about agent access. Giving an agent more control does not always make the product better. In this case, the useful part is the separation of responsibilities. The agent handles repetitive checking and preparation. The application enforces the rules. The person keeps control over approvals and judgement.

What is next

A future version could accept real documents, use OCR and support different shipment rules. Before adding those features, I would want to do a proper privacy and security review. For this challenge, I kept the project small, deterministic and limited to fictional data.

Built With

• playwright
• react
• typescript
• vercel
• vite
• vitest
• webmcp
• zod