- Pamela Fox argued that a tool's name, description and types are prompts, and vague ones led models to pass arguments she had not asked for.
- The model only proposes a call. Fox said the developer's code runs it, so the developer owns the result.
Pamela Fox, a Principal Cloud Advocate at Microsoft, made a point on the AI Engineer show. A tool's schema is prompt engineering, she argued. Its names, types and descriptions decide how a model calls it. Vague wording leads to wrong calls, and the developer's own code still carries them out.
What was said
Fox spoke in the episode on swapping models. She ran the same scenarios on GPT-5.5, Kimi, DeepSeek and Mistral. She then turned to tool calling, which she said is the basis of all agents. The developer describes a function in JSON schema, a structured format listing its name, description and inputs. The model reads that and the user's message. It then replies with which function to call and with what arguments.
Her example was a create-calendar-event tool. The user asked for a team sync tomorrow at 1:30 p.m., virtual on Microsoft Teams. Fox said GPT-5.5 added her as an attendee, which she did not want. DeepSeek did the same. It also wrote the location as virtual with Microsoft Teams in brackets, which she said was not what she asked for.
Her conclusion was that wrong arguments point to ambiguity in the schema. She would fix the descriptions, for example by telling the model to list only named attendees. She put it this way: "even though this is like an object, this is prompt engineering here." She also stressed who acts: "The LLM itself doesn't call the function, that's up to us to do."
Why it matters
Our reading: a tool schema is an interface whose audience is a model. It deserves the review a customer-facing page or public API gets. Fox's demo shows why. The same schema produced different arguments from different models. A description that works on one model may not work on another.
The model only proposes a call. The developer's code is where it becomes an action. Teams that build agent tools should treat names and descriptions as part of the product. Buyers can ask who wrote them and how they were tested.
The other side
The demo was small. One calendar tool produced mild slips: an extra attendee and odd location text. The excerpts do not show how Mistral did, or whether rewritten descriptions fixed the problems. Fox described those fixes as the next step, not as a result.
Her setting was an app builder's own tools, not the open web. Applying her point to a web full of outside agents is our extension.
Fox also said testing is a weak spot. It is hard to bootstrap evaluations before production, she said, and people hear they must run evals but "no one's running evals". Clearer schemas help only if teams test them.
Written by the WebPulse Newsroom with AI assistance, and checked by our editorial review: every quotation was verified against the recording's transcript. How we use AI.
The conversation this talking point comes from
- AI Engineer: The Model Swap Workshop: GPT-5.5 vs Kimi vs DeepSeek vs Mistral (2026-10-19)
