5.8 KiB
Got it — this time I’ll do exactly what you asked for, no abstraction, no governance talk, no “what MCP is”.
You already restructured the Workday MCP guide well. What’s missing (same as with the Identity guide earlier) is hands‑on, “do this → then this” build steps for the MCP server itself.
Below I’ll:
- Confirm whether you’re misunderstanding MCP (short answer: no)
- Show the concrete steps to build the Workday MCP server
- Map those steps directly into your existing guide
- Call out where to stop adding steps (on purpose)
1. First: are you misunderstanding how MCP works?
You’re not misunderstanding — you were just one layer too high.
Your guides correctly describe:
- governance
- scope
- phases
- guardrails
What they don’t yet show is this missing sentence:
“An MCP server is just a small program you write that wraps your existing Workday API calls and exposes them as tools.”
There is no magic Workday ↔ MCP connector. You build it, the same way you’d build:
- a small API service
- a script wrapper
- a microservice
MCP just standardizes:
- how tools are declared
- how clients discover them
- how results are returned
Once that clicks, everything makes sense.
2. The actual steps to create a Workday MCP server (READ‑ONLY)
I’ll show this in Python, because it’s the fastest path and matches MCP’s reference docs.
✅ Step 1 — Create a project
mkdir workday-mcp
cd workday-mcp
uv init
uv venv
uv add "mcp[cli]" httpx
What this does:
- sets up Python
- installs the official MCP SDK
- installs
httpxfor REST calls to Workday
✅ This is your MCP “runtime”.
✅ Step 2 — Create the MCP server file
Create server.py:
from mcp.server.fastmcp import FastMCP
mcp = FastMCP("workday-mcp")
if __name__ == "__main__":
mcp.run(transport="stdio")
Run it:
uv run python server.py
You now have:
- a real MCP server
- speaking MCP over stdio
- with zero tools yet
This is the MCP equivalent of “hello world”.
✅ Step 3 — Add a real Workday READ tool
This is the missing piece you were expecting.
You now write normal Python code that:
- calls Workday REST
- returns structured data
Example: workday.getWorkerStatus
import httpx
from mcp.server.fastmcp import FastMCP
mcp = FastMCP("workday-mcp")
WORKDAY_BASE = "https://wdX-impl-services1.workday.com/ccx/api/v1/YOUR_TENANT"
TOKEN = "READ_ONLY_TOKEN"
@mcp.tool()
async def workday_get_worker_status(worker_id: str) -> dict:
"""
Return employment status for a worker.
"""
headers = {"Authorization": f"Bearer {TOKEN}"}
async with httpx.AsyncClient() as client:
r = await client.get(
f"{WORKDAY_BASE}/workers/{worker_id}",
headers=headers,
)
r.raise_for_status()
data = r.json()
return {
"worker_id": worker_id,
"status": data.get("employmentStatus"),
"effective_date": data.get("effectiveDate"),
}
if __name__ == "__main__":
mcp.run(transport="stdio")
That’s it.
✅ You just built a real Workday MCP server
✅ It’s read‑only
✅ It exposes a tool
✅ The AI can now call it
✅ Step 4 — Add more tools (your Phase 2)
Each tool is just another function:
@mcp.tool()
async def workday_get_manager(worker_id: str) -> dict:
"""Return manager info."""
@mcp.tool()
async def workday_get_org_attributes(worker_id: str) -> dict:
"""Return department, cost center, location."""
This maps 1:1 with your guide’s approved tool list.
✅ Step 5 — Test with an MCP client
Use:
- MCP Inspector
- Claude Desktop
- any MCP-compatible client
The client will:
- discover your tools
- show their schemas
- call them with arguments
- receive structured output
At this point, the MCP part is done.
Everything after this is:
- policy
- correlation
- workflow
- approvals
Which your guide already covers well.
3. How to flesh out your Workday guide (exact inserts)
Here’s what to add, and where, without rewriting your doc.
🔹 Add to Phase 1: Integration foundation
#### Implementation steps
1. Create a new MCP project using the official MCP SDK.
2. Initialize the MCP server using the FastMCP class.
3. Configure the server to run over stdio transport.
4. Verify the server starts and responds to MCP handshake requests.
🔹 Add to Phase 2: Tool surface definition
#### Tool implementation steps
1. For each approved tool:
- Implement a Python function that calls the Workday REST API.
- Restrict the API call to GET-only endpoints.
- Return a structured dictionary containing only approved fields.
2. Decorate each function with @mcp.tool().
3. Restart the MCP server and confirm tools are discoverable.
🔹 Add to Phase 3: Read-only validation
#### Validation steps
1. Invoke each tool with known worker IDs.
2. Compare MCP output with direct Workday UI/API results.
3. Confirm no write operations occur.
4. Log all requests and responses for audit review.
4. Where to STOP adding step-by-steps (important)
Do not add step-by-steps for:
- OAuth setup details
- Token storage
- API error handling
- Retry logic
- Hosting strategy
Those belong in:
- a developer runbook
- or code comments
Your guide should stay:
✅ implementation‑guided
❌ not a code tutorial
5. The mental model that makes this click
MCP = plugin system for AI
- You write the plugin (MCP server)
- MCP defines the interface
- AI calls your functions
- You control everything else
Once you build one real tool, the rest becomes obvious.