MODULE 03 · LESSON 3.3
Design tools the model can use correctly
Make tool contracts precise enough for reliable model decisions.
Lesson 13 of 86 · FabrCore 2.0
Overview
A tool description is part of the model's operational interface. Narrow operations with typed inputs and bounded results are easier to select and validate than a generic “execute anything” function. Structured output gives application code an explicit result shape.
Descriptions help the model choose; validation protects execution
Describe when the lookup should be used, what a request ID looks like, and what a not-found result means. Keep the inputs limited to business values. Validate them in code, because descriptions influence model behavior but cannot enforce authorization, input length or identifier format. The illustrated middleware shows where tool-call behavior can be observed or constrained.
Return useful facts in a bounded shape
A result should expose the fields the assistant needs, such as identifier, status and summary, without dumping an entire database row or sensitive internal record. A structured result makes not-found and error cases distinguishable. A mutation such as closing a request should be a separate operation with separate validation, so “look up a request” cannot unexpectedly change it.
Design the lookup contract
Download the Operations Desk source. The README lists project setup, package prerequisites and local ports.
- Describe what each function does, required identifiers, and side effects. Separate lookup, draft and commit operations.
- Return typed records and explicit not-found/conflict results. Validate identifiers and authorization in trusted code before touching storage.
- For mutations, pass an application request/idempotency key and record the outcome. Validate structured model output before using it as an instruction to a business service.
var agent = originalAgent
.AsBuilder()
.Use(async (agent, context, next, ct) =>
{
Console.WriteLine($"Calling: {context.Function.Name}");
var result = await next(context, ct);
Console.WriteLine($"Result: {result}");
return result;
})
.Build();
Exercise selection and invalid input
- Ask a plain greeting. Expect no request lookup; inspect tool-call capture rather than assuming the absence of a visible lookup message means no tool ran.
- Ask for SR-1042. Expect one relevant lookup with a validated ID and a bounded record. Compare the response to the returned fields.
- Call the tool directly with an invalid or unauthorized ID in a test. It must reject the operation regardless of what a prompt says. Test not-found separately so the assistant can explain missing records without confusing them with permission failures.
Successful tool design covers when to call, what can execute, and how to interpret the returned data. A good description cannot replace those code-level checks.
If the result is different
A schema validates shape, not truth. Keep permissions, input validation and result verification outside model discretion.
Go deeper
Explore the related documentation.