Step 6 of 8 Advanced 20 min

Wiring It Into Joule Studio: Instructions, Grounding & Testing

Lesson 6 — This is the moment your MCP server stops being a standalone service and becomes an actual agent someone can talk to. Instructions, tool discovery, and the one test case that matters more than all the others combined.

S
s4ready.ai Team

Prerequisites

  • Lesson 5: Deploying your MCP server

Everything until now has been infrastructure — a tool, deployed, reachable. This is the lesson where it becomes an agent someone can hold a conversation with.

Narrow beats exhaustive — seen, not just said

Narrow instruction vs. exhaustive instructionA narrow instruction states what the agent can do, names the one non-obvious constraint explicitly, and gives one confirmation behaviour — short, testable, predictable. An exhaustive instruction tries to enumerate every possible scenario, grows unbounded, and becomes harder for the model to reliably follow, not easier.NARROW ✓“You are a Business Partner assistant.You can read, create, update, block.BPs cannot be deleted — block instead.”Short. Testable.Predictable refusals.EXHAUSTIVE ✗“You can do X, unless Y, exceptwhen Z, but also consider W, andremember not to do V unless…”Grows unbounded.Harder to follow, not easier.
The instructions below are the narrow version, in full — nothing hidden, nothing assumed.

Auto-discovery, and where Lesson 2 finally pays off

Register your deployed server — from Lesson 5 — as a tool source in Joule Studio, via the BTP destination. Every schema you wrote in Lessons 3–4 shows up automatically; that’s the entire point of building on an open protocol instead of a bespoke integration. All that’s left is the instructions:

You are a Business Partner management assistant. You can:
- Read and search Business Partners
- Create new Business Partners (organisation or person)
- Update Business Partner details
- Block a Business Partner (note: BPs cannot be deleted, only blocked)
Always confirm the BP number after a successful create.
For organisations, category is 2. For persons, category is 1.

Notice what this does not do: it doesn’t try to cover every conceivable Business Partner scenario in SAP. It states exactly what this agent does, names the one non-obvious constraint from Lesson 4 explicitly, and gives one concrete confirmation behaviour. A precise, narrow instruction beats an exhaustive one — every time.

The test that matters more than all your others combined

Test the ordinary paths first. But the test that actually tells you whether this agent is safe isn’t any of those — it’s the one it should refuse.

“Delete Business Partner 1000042.” Good agent: “I can’t delete Business Partners — would you like me to block it instead?”

That single response proves the agent understands its own boundary. A dozen successful happy-path demos only prove it’s never been asked to cross one yet.

Try it yourself

Write your system prompt with the same three-part structure: what it can do, the one constraint it must never violate, one confirmation behaviour. Then write the exact refusal question you’ll test first — before anything else — and what the ideal refusal response says.

Where this shows up in SAP

Both Business Partner and Sales Order tutorials show this exact registration flow with real system prompts to copy and adapt.

Key takeaways

  • MCP tools auto-discover in Joule Studio via the BTP destination — no manual re-declaration.
  • Instructions should be narrow and specific — state non-obvious constraints explicitly, don’t hope the model infers them.
  • Test the refusal case first. It tells you more about safety than any number of happy-path demos.

Next: one tool works beautifully. Should you add a second — and when does “more tools” quietly become “too many agents”?