Joule Studio Part 3: Joule Studio Tools, Joule Skills and MCP

📌 KEY POINTS
✅ Skill Builder (general availability mid-2025) is where you define a Joule Skill: inputs, the API action it calls, and outputs presented back conversationally.
✅ Action projects (also used elsewhere in SAP Build) wrap API operations so they're callable as structured actions — the same building block skills are built from.
✅ MCP (Model Context Protocol) is an open standard for agents to discover and call external tools in a consistent way, rather than each integration being bespoke.
✅ SAP has been extending Joule and Joule Studio's MCP support so agents can reach tools beyond SAP's own connector catalog.
⚠️ Not every capability needs a custom skill — check whether an MCP server or an existing action project already exposes what you need before building from scratch.

━━━━━━━━━━━━━━━━━━━━
▶ WHERE WE ARE
Part 2 built one agent. Now the toolbox in depth.

━━━━━━━━━━━━━━━━━━━━
▶ 1. SKILL BUILDER

• Inputs, API action, outputs.

━━━━━━━━━━━━━━━━━━━━
▶ 2. ACTION PROJECTS

• Wrapping API operations as structured actions.\n\n━━━━━━━━━━━━━━━━━━━━\n▶ 3. MCP\n• Standardized tool discovery/invocation for agents.

━━━━━━━━━━━━━━━━━━━━
▶ 4. SAP'S MCP SUPPORT

• Reaching tools beyond SAP's native connectors.

━━━━━━━━━━━━━━━━━━━━
▶ 5. REUSE BEFORE BUILD

• Check existing skills/MCP servers first.

━━━━━━━━━━━━━━━━━━━━
▶ STEP BY STEP

1. Search existing skills/action projects for your capability.
2. If none exists, build a skill with the skill builder.
3. Evaluate whether an MCP server would serve better for external tool reach.

✅ CHECKPOINT: you can justify why you built new vs reused existing tooling.

An integration team was about to build a custom skill to query a third-party logistics API, then discovered the vendor already exposed an MCP server for exactly that purpose. Connecting to the existing MCP server instead of building and maintaining a bespoke skill saved weeks of work and an ongoing maintenance burden.

• Building a custom skill without checking for an existing MCP server or action project.
• Treating MCP as identical to a proprietary SAP connector (it's an open standard).
• Assuming current MCP support is fixed rather than actively expanding.
• Duplicating skills across teams instead of sharing them.
• Skipping the reuse check to save a few minutes of searching.

• Check for existing skills, action projects and MCP servers before building.
• Understand MCP as an open, standardized protocol, not an SAP-proprietary one.
• Verify current MCP support and available servers before planning integrations.
• Share and catalog skills for reuse across teams.
• Build new tooling only when nothing suitable already exists.

Questions: "What is the difference between a Joule Skill and an action project?", "What is MCP and why does it matter for agents?", "How would you decide whether to build a new skill or connect to an existing MCP server?"
Strong answer: skill builder mechanics, action projects as the underlying building block, MCP as an open standard for tool discovery, reuse-before-build discipline, current-state caveat.