AI GUIDEFrom a message to a record
Imagine a tennis coach receives this fictional message: “Alex wants Saturday lessons, has played for a year and prefers practising the backhand.” The coach wants a student record and a draft practice outline. A single tool named manage_everything gives the model no useful boundary between reading, drafting and saving.
Start with the actual work: extract what the message says, mark what is unknown, let the coach correct it, save the approved record, then use that record to draft an outline for review. No medical conclusions or training prescriptions follow from this short message. The lesson concerns record architecture, not sports advice.
Prerequisite: the tool cycle in CA02. The entire example is synthetic and is not connected to a student database.
A small tool contract
One proposed interface is prepare_student_draft(message), followed by save_approved_student(draft_id, approval_id). The first produces no persistent record. The second must verify a real approval in the application; an approval_id invented by the model is not sufficient.
Illustrative draft: {"name":"Alex","availability":"Saturday","reported_experience":"about one year","goal":"backhand practice","unknown":["contact details","lesson time"]}. Keep reported experience labelled as reported. Do not turn it into a measured skill level.
A good tool description names its purpose, required inputs, effect and limits: “Prepare an unsaved student-record draft from supplied text; preserve missing fields as unknown; do not infer health or skill assessments.” Validate arguments in code as well. Helpful descriptions improve selection; they do not enforce authorisation.
Where MCP fits
MCP, the Model Context Protocol, standardises communication between an AI application and servers exposing capabilities. A host application manages the experience; clients communicate with servers. Tools expose callable operations. Resources expose material the application may read. A connection does not make every operation appropriate for every user.
In our design, an MCP server could expose the student-draft and record operations. The coaching application still checks the coach's identity and which students that coach may access. Connecting a server is not a substitute for those checks.
Keep result meanings distinct: a successful empty search, invalid input, access denied and a temporary service failure need different responses. Return understandable errors. Do not tell the agent to keep retrying until something works when the problem is missing permission.
Approval and recovery exercise
After coach approval, an illustrative save receipt might contain student_id “S101” and record_version 1. Draft the practice outline using that approved version. If the coach corrects the goal afterwards, invalidate the old outline or visibly mark it stale. Do not silently attach it to the revised record.
Exercise: list which operations may read, which only draft and which write. Add three failures: the student already exists, approval expired, and the save response was lost. A reasonable design offers a potential match for review, asks for renewed approval where needed and checks save status before retrying a write. It never merges students because their first names match.
You pass when the coach can inspect every saved fact, the system can explain who approved which version, and a failed write cannot masquerade as success. Next: CA04 applies the same distinction between instructions and permissions to coding work.
Sources
Read the original sources to explore the topic and check specific claims.