Connect an existing server
Make a controlled first call
Test one read-only operation against disposable data and inspect the proposed arguments before approving the call.
8 minute lesson
Ask the host to read or search one file in the practice folder. Use a request whose expected result you already know.
If the host shows an approval screen, inspect the server name, tool name, and arguments. Approval is meaningful only when you read what will run.
Compare the result with the source file. Then ask for a path outside the allowed practice folder and confirm the request is rejected.
Test the contract in layers:
- Make one valid call with a known result.
- Send a missing or wrong-type argument and inspect the validation error.
- Request a nonexistent item and distinguish “not found” from a server crash.
- Attempt the known permission boundary.
- Confirm the server wrote nothing during read-only tests.
A friendly host response is not enough evidence. Check the server log, the disposable directory, and the exact returned content. A model can summarize a result incorrectly even when the underlying tool call succeeded.
Approval should describe the real effect at a useful level. If the screen shows only an opaque tool name or a giant unreviewable payload, improve the server name, description, and arguments before trusting higher-impact operations.
Record the server version, configuration scope, successful call, and rejected boundary. This becomes a small trust test you can repeat after an upgrade.
Do not move to real data until both the intended capability and denied boundary behave as designed. A positive test without a negative test proves very little about scope.
Lesson completed