Added current MCP working files

2026-03-27 15:26:14 -04:00
parent a1397c7bcd
commit 96a04e6535
24 changed files with 5787 additions and 0 deletions
@@ -0,0 +1,280 @@
+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:
+
+1.  **Confirm whether you’re misunderstanding MCP (short answer: no)**
+2.  **Show the concrete steps to build the Workday MCP server**
+3.  **Map those steps directly into your existing guide**
+4.  **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
+
+```bash
+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 `httpx` for REST calls to Workday
+
+✅ This is your MCP “runtime”.
+
+***
+
+### ✅ Step 2 — Create the MCP server file
+
+Create `server.py`:
+
+```python
+from mcp.server.fastmcp import FastMCP
+
+mcp = FastMCP("workday-mcp")
+
+if __name__ == "__main__":
+    mcp.run(transport="stdio")
+```
+
+Run it:
+
+```bash
+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:
+
+1.  calls Workday REST
+2.  returns structured data
+
+Example: `workday.getWorkerStatus`
+
+```python
+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:
+
+```python
+@mcp.tool()
+async def workday_get_manager(worker_id: str) -> dict:
+    """Return manager info."""
+```
+
+```python
+@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:
+
+1.  discover your tools
+2.  show their schemas
+3.  call them with arguments
+4.  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**
+
+```md
+#### 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**
+
+```md
+#### 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**
+
+```md
+#### 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.
+
+***
@@ -0,0 +1,217 @@
+# Deployment Plan — Workday READ‑ONLY MCP
+
+## Purpose & Scope
+
+### What this MCP is
+
+A **Workday Context MCP** that exposes **authoritative workforce data** to downstream identity and device workflows **without performing HR actions**.
+
+### What this MCP is *not*
+
+*   ❌ Not provisioning users
+*   ❌ Not triggering hires/terminations
+*   ❌ Not modifying worker records
+*   ❌ Not replacing PECI or HR integrations
+
+> MCP is used to **observe and reason**, not execute HR transactions.
+
+***
+
+## Phase 0 — Governance & alignment (mandatory)
+
+### Stakeholders
+
+*   HRIS (Workday owner)
+*   IAM / AD owners
+*   Security
+*   Deskside / IT Ops
+
+### Explicit agreements (write these down)
+
+*   Workday remains **sole Source of Truth**
+*   MCP access is **read‑only**
+*   Identity actions remain **IT‑owned**
+*   MCP insights may **recommend**, not execute
+
+This mirrors how Workday integrations are typically consumed by downstream systems today. [\[sqlservercentral.com\]](https://www.sqlservercentral.com/articles/model-context-protocol-mcp-a-developers-guide-to-long-context-llm-integration)
+
+✅ **Exit criteria:**  
+Security and HR sign off on *read‑only contextual access*.
+
+***
+
+## Phase 1 — Integration foundation (no AI yet)
+
+### Objective
+
+Create a **Workday MCP server** that safely wraps existing Workday APIs.
+
+### Technical model
+
+*   Workday **Integration System User (ISU)**
+*   OAuth 2.0 / API credentials
+*   Scoped to **GET‑only endpoints**
+*   No custom UI access
+*   No background jobs
+
+This matches standard Workday REST integration practices. [\[sqlservercentral.com\]](https://www.sqlservercentral.com/articles/model-context-protocol-mcp-a-developers-guide-to-long-context-llm-integration)
+
+***
+
+## Phase 2 — Tool surface definition (critical)
+
+### Only expose identity‑relevant context
+
+These tools already exist conceptually in HRIS integrations and are widely used by downstream systems:
+
+#### Core MCP tools
+
+    workday.getWorker(identifier)
+    workday.getWorkerStatus(identifier)
+    workday.getWorkerOrgAttributes(identifier)
+    workday.getWorkerManager(identifier)
+    workday.getWorkerEffectiveDates(identifier)
+
+### Data allowed
+
+*   Worker ID
+*   Name / email
+*   Employment status (active, terminated, future‑dated)
+*   Job profile
+*   Cost center / department
+*   Location
+*   Manager
+
+### Explicit exclusions
+
+*   Compensation
+*   Performance
+*   Benefits
+*   Payroll
+*   Medical / protected fields
+
+✅ **Exit criteria:**  
+HR confirms fields exposed align with least‑privilege HRIS policy.
+
+***
+
+## Phase 3 — Read‑only validation & drift detection
+
+### Objective
+
+Use Workday MCP to **detect identity drift**, not fix it.
+
+### Example read‑only use cases
+
+*   “User active in AD but terminated in Workday”
+*   “User manager mismatch between AD and Workday”
+*   “Future‑dated hires missing in AD”
+*   “Contractors whose Workday end date has passed”
+
+These patterns are already common in Workday → downstream sync architectures. [\[artificial...school.com\]](https://artificialintelligenceschool.com/model-context-protocol-mcp-guide/)
+
+✅ **Exit criteria:**  
+Workday MCP reliably answers identity state questions without writes.
+
+***
+
+## Phase 4 — Correlation with Identity MCP (key value)
+
+### Objective
+
+Let AI reason across **Workday → AD / Entra → Intune**.
+
+### Architecture
+
+    Workday MCP (SoT)
+         ↓
+    Identity MCP (AD / Entra)
+         ↓
+    Device / Access Decisions
+
+### Example insight queries
+
+*   “Who *should* exist vs who *does* exist”
+*   “Which users still have access but are no longer employees”
+*   “Which new hires are future‑dated and should not be provisioned yet”
+
+✅ **Important**
+Workday MCP **never** updates AD.  
+It only provides authoritative context.
+
+***
+
+## Phase 5 — Human‑approved remediation workflows
+
+### Objective
+
+Use Workday MCP insights to **support existing SOPs**, not replace them.
+
+### Pattern
+
+1.  AI detects mismatch
+2.  AI explains *why* (Workday vs AD)
+3.  Human chooses remediation
+4.  Identity MCP or existing automation executes change
+5.  Ticket updated
+
+This preserves separation of duties and auditability.
+
+***
+
+## Phase 6 — Audit, security, and lifecycle controls
+
+### Logging
+
+*   Every MCP request logged
+*   Tool name + parameters + timestamp
+*   No PII expansion beyond approved fields
+
+### Change management
+
+*   Tool definitions version‑controlled
+*   HR schema changes reviewed
+*   Workday biannual releases validated (standard HRIS practice) [\[dev.to\]](https://dev.to/jamie_thompson/mcp-servers-explained-how-ai-assistants-connect-to-your-tools-598o)
+
+### Access lifecycle
+
+*   Integration user rotated per policy
+*   MCP server access limited to approved hosts
+
+***
+
+## Risk analysis (why this is safe)
+
+| Risk                  | Mitigation                 |
+| --------------------- | -------------------------- |
+| HR data misuse        | Read‑only + scoped fields  |
+| AI acting as HR       | No write tools exposed     |
+| Privilege creep       | Fixed tool manifest        |
+| Audit gaps            | Full request logging       |
+| Integration fragility | Uses standard Workday APIs |
+
+This is **safer than CSV exports or ad‑hoc scripts**, which bypass observability.
+
+***
+
+## Deployment sequencing (recommended)
+
+1.  ✅ Workday MCP (read‑only)
+2.  ✅ Identity MCP (read‑only)
+3.  ✅ Correlation & reporting
+4.  ✅ Human‑approved remediation
+5.  ❌ Never allow Workday writes via MCP
+
+***
+
+## Executive‑level summary (one paragraph)
+
+> This deployment introduces a read‑only Workday MCP that exposes authoritative workforce data to IT identity systems without allowing AI or automation to modify HR records. Workday remains the Source of Truth, while AD and Entra remain enforcement systems. MCP improves visibility, reduces identity drift, and strengthens auditability without changing ownership boundaries or compliance posture.
+
+***
+
+## One‑sentence takeaway
+
+> **A read‑only Workday MCP gives IT perfect awareness of “who should exist” without ever letting AI touch “who exists.”**
+
+***
@@ -0,0 +1,139 @@
+---
+title: "Workday MCP — implementation and auth plan"
+description: "Execution plan to build a read-only Workday MCP server using the proven Identity MCP pattern."
+type: "Implementation Plan"
+version: "v1"
+author: "N. Castaldi"
+date: "2026-03-11"
+---
+
+## Objective
+
+Build a read-only Workday MCP server by reusing the implementation pattern that succeeded in the Identity MCP server, while replacing the AD/PowerShell adapter with a Workday REST/OAuth adapter.
+
+## Scope for first release
+
+Included:
+- Read-only tools only:
+    - workday.getWorker(identifier)
+    - workday.getWorkerStatus(identifier)
+    - workday.getWorkerOrgAttributes(identifier)
+    - workday.getWorkerManager(identifier)
+    - workday.getWorkerEffectiveDates(identifier)
+- Workday MCP project scaffolding equivalent to the Identity MCP structure
+- In-memory backend for local contract testing
+- API backend for Workday REST integration
+- Unit tests and integration smoke tests
+- Logging and audit controls
+
+Excluded:
+- Any write actions to Workday
+- Any HR transaction support
+- Ticketing automation from Workday MCP
+- Correlation/remediation execution logic beyond read-only outputs
+
+## Current decisions captured
+
+- API family for v1: REST only
+- Security model: least privilege, read-only field scope
+- Deployment model: phased rollout aligned to existing Workday install guide
+- Architecture pattern: dual backend (`memory` default, `api` production)
+
+## Build plan (execution sequence)
+
+1. Clone the Identity MCP skeleton into Workday equivalents.
+2. Create Workday backend contract with five async tool methods.
+3. Implement in-memory backend with safe sample worker payloads.
+4. Implement FastMCP server entrypoint and tool wrappers.
+5. Implement Workday REST adapter with OAuth token handling.
+6. Add config and secret-loading contract.
+7. Add adapter unit tests with mocked HTTP/token responses.
+8. Add non-prod integration smoke tests for end-to-end validation.
+9. Validate output schema allowlist and excluded fields.
+10. Publish runbook updates and final verification checklist.
+
+## Files to create for parity with Identity MCP
+
+- workday_mcp_server.py
+- workday_backend.py
+- workday_adapter.py
+- debug_workday_connectivity.py
+- pyproject.toml
+- .gitignore
+- tests/test_workday_adapter.py
+- tests/test_integration.py
+
+## Authentication implementation requirements
+
+1. Use Workday REST API with OAuth 2.0 for API calls.
+2. Use a dedicated Integration System User (ISU) for MCP access.
+3. Register and manage a dedicated Workday API client for this service.
+4. Restrict security group and domain permissions to approved read-only fields.
+5. Keep separate credentials and client configuration for non-production and production.
+6. Store client secret/token material in approved secret storage, never in code.
+7. Enforce token refresh, timeout, retry, and rate-limit handling in adapter logic.
+
+## Data to gather (required before build proceeds)
+
+### A. Workday auth and tenant details
+- Tenant name(s) for non-production and production
+- Base API host URL(s)
+- Approved OAuth grant type for this integration
+- Token endpoint details and expected token lifetime
+- Refresh token policy and rotation requirements
+
+### B. Identity and access control details
+- ISU account name and owner
+- Integration security group name
+- Exact domain permissions approved for read-only use
+- Explicit list of denied domains/fields
+
+### C. Endpoint and schema contract
+- Exact Workday REST endpoints for each of the 5 tools
+- Required request parameters and lookup identifiers
+- Expected success payload shape per endpoint
+- Error payload examples for 401/403/404/429/5xx
+
+### D. Operations and observability
+- Required logging sink and retention policy
+- Required audit fields per MCP invocation
+- Retry/backoff thresholds and timeout limits
+- Rate-limit constraints provided by tenant admins
+
+## Current blockers
+
+1. OAuth grant type is not finalized.
+2. Ownership for credential and security-group provisioning is not assigned.
+3. Non-production Workday tenant/sandbox access is not yet available.
+4. Exact endpoint-to-tool mapping is not finalized.
+5. Approved field allowlist and denylist are not yet locked to testable schema contracts.
+
+## Dedicated next steps
+
+1. Assign owner for Workday auth provisioning (HRIS or IAM/Security) and confirm accountable approver.
+2. Finalize OAuth grant type and token lifecycle policy in a short design decision record.
+3. Provision non-production tenant access and generate non-prod API client credentials.
+4. Confirm ISU + security group + domain permissions for read-only scope.
+5. Produce endpoint mapping table (tool -> endpoint -> fields -> error contract).
+6. Create initial Workday project scaffold and run server in memory mode.
+7. Implement adapter token flow and one tool end-to-end in non-prod.
+8. Expand to all five tools and complete unit plus integration test gates.
+9. Validate logs and outputs for secret safety and field-scope compliance.
+10. Update install guide with exact run/test commands once implementation is proven.
+
+## Verification checklist
+
+- [ ] All blocker items are resolved and documented.
+- [ ] Server starts in memory mode and API mode.
+- [ ] All five tools return only approved fields.
+- [ ] Unit tests pass with mocked auth and API error scenarios.
+- [ ] Integration tests pass against non-production tenant.
+- [ ] No secrets appear in logs.
+- [ ] Audit logs capture tool name, parameters, timestamp, and result status.
+
+## Related documents
+
+- [workday-mcp-install-guide.md](./workday-mcp-install-guide.md)
+- [CoPilot Generated Deployment Plan.md](./CoPilot%20Generated%20Deployment%20Plan.md)
+- [CoPilot Generated Additional Steps.md](./CoPilot%20Generated%20Additional%20Steps.md)
+- [../Identity/implementation-guide.md](../Identity/implementation-guide.md)
@@ -0,0 +1,287 @@
+---
+title: "Workday MCP — Deployment and install guide"
+description: "Step-by-step guide for deploying a read-only Workday MCP server for identity context, drift detection, and controlled remediation workflows."
+type: "Install Guide"
+version: "v1"
+author: "N. Castaldi"
+date: "2026-03-11"
+---
+
+<!-- Guide Title and Logo Row -->
+<div style="display: flex; align-items: center; justify-content: space-between; margin-bottom: 1.5em;">
+  <h1 style="margin: 0; font-size: 2em;">Workday MCP — Deployment and install guide</h1>
+  <img src="https://rwdn-uploads.s3.amazonaws.com/mcgl15001/production/54b7a8d305541296303508cec6e5dfb6.png" alt="Company Logo" style="height:60px; max-width:180px; object-fit:contain;">
+</div>
+
+## Table of contents
+
+- [Introduction](#introduction)
+- [Definitions](#definitions)
+- [Prerequisites / Required tools & access](#prerequisites--required-tools--access)
+- [Installation procedure](#installation-procedure)
+- [Post-installation actions](#post-installation-actions)
+- [Troubleshooting / Escalation procedures](#troubleshooting--escalation-procedures)
+- [References / Related documents](#references--related-documents)
+- [Revision history](#revision-history)
+
+---
+
+## Introduction
+
+### Purpose
+
+This guide explains how to deploy a **read-only Workday MCP** that provides authoritative workforce context to downstream identity and device workflows. The deployment is designed to improve visibility and drift detection without enabling any HR record modification.
+
+### Audience
+
+HRIS owners, IAM and AD owners, Security, and Deskside or IT Operations teams responsible for identity governance and integration controls.
+
+### Scope
+
+This guide covers phased implementation of a Workday Context MCP from governance alignment through operational controls. It intentionally excludes any capability to perform HR write actions.
+
+The MCP in this guide:
+
+- Observes workforce data through scoped read-only endpoints
+- Correlates workforce state with AD, Entra, and device context
+- Supports human-approved remediation through downstream IT-owned systems
+
+The MCP in this guide does not:
+
+- Provision users
+- Trigger hires or terminations
+- Modify worker records
+- Replace PECI or existing HR integrations
+
+---
+
+## Definitions
+
+| Term | Definition |
+| --- | --- |
+| **MCP** | Model Context Protocol interface exposing approved tools and context to AI clients |
+| **Workday MCP** | Read-only MCP server that surfaces workforce attributes from Workday for downstream identity reasoning |
+| **HRIS** | Human Resources Information System; Workday is the source-of-truth HRIS in this design |
+| **ISU** | Integration System User in Workday used for API-based integration access |
+| **Identity drift** | Mismatch between authoritative workforce state and downstream identity or access state |
+| **Source of Truth (SoT)** | Authoritative system of record; Workday remains SoT for workforce status |
+
+---
+
+## Prerequisites / Required tools & access
+
+Complete all prerequisites before implementation work begins.
+
+- [ ] Security and HR sign-off on read-only contextual access
+- [ ] Stakeholder alignment across HRIS, IAM or AD owners, Security, and IT Ops
+- [ ] Workday Integration System User (ISU) created for the MCP service
+- [ ] OAuth 2.0 or approved API credential method configured
+- [ ] API access scoped to GET-only endpoints
+- [ ] Repository established for version-controlled tool manifests
+- [ ] Logging destination approved for request-level audit events
+
+> **No AI-facing deployment begins until governance agreements are documented and approved.**
+
+---
+
+## Installation procedure
+
+Deploy the Workday MCP in seven controlled phases.
+
+```mermaid
+flowchart LR
+    phase-governance[Phase 0: Governance and alignment] --> phase-foundation[Phase 1: Integration foundation]
+    phase-foundation --> phase-tools[Phase 2: Tool surface definition]
+    phase-tools --> phase-validation[Phase 3: Read-only validation]
+    phase-validation --> phase-correlation[Phase 4: Correlation with identity]
+    phase-correlation --> phase-remediation[Phase 5: Human-approved remediation]
+    phase-remediation --> phase-controls[Phase 6: Audit and lifecycle controls]
+```
+
+| Phase | Capability | Risk level |
+| --- | --- | --- |
+| 0 | Governance and read-only agreement | None |
+| 1 | Integration foundation | Low |
+| 2 | Approved tool surface and field scope | Low |
+| 3 | Drift detection and read-only validation | Low |
+| 4 | Cross-system correlation | Low |
+| 5 | Human-approved remediation orchestration | Medium (controlled) |
+| 6 | Audit and lifecycle controls | Low |
+
+---
+
+### Step 1: Governance and alignment (Phase 0)
+
+**Objective:** Establish ownership boundaries and non-negotiable control agreements before technical build.
+
+1. Confirm required stakeholders are assigned and accountable:
+    - HRIS (Workday owner)
+    - IAM or AD owners
+    - Security
+    - Deskside or IT Ops
+2. Record and approve the following agreements:
+    - Workday remains the sole Source of Truth for workforce status
+    - MCP access is read-only
+    - Identity actions remain IT-owned
+    - MCP insights may recommend but do not execute
+3. Obtain Security and HR sign-off on read-only contextual access.
+
+✅ **Exit criteria:** Signed governance agreement with read-only scope and ownership boundaries.
+
+---
+
+### Step 2: Integration foundation (Phase 1)
+
+**Objective:** Build a secure Workday MCP integration layer without exposing AI tooling yet.
+
+1. Configure a dedicated Workday ISU for the MCP server.
+2. Configure OAuth 2.0 (or approved equivalent) for API authentication.
+3. Restrict access to GET-only endpoints required for approved context fields.
+4. Confirm there is no custom UI access and no background mutation jobs.
+
+✅ **Exit criteria:** Workday MCP server can authenticate and retrieve data through read-only API paths only.
+
+---
+
+### Step 3: Tool surface definition (Phase 2)
+
+**Objective:** Expose only identity-relevant workforce context under least privilege.
+
+1. Implement the approved core tools:
+
+    ```powershell
+    workday.getWorker(identifier)
+    workday.getWorkerStatus(identifier)
+    workday.getWorkerOrgAttributes(identifier)
+    workday.getWorkerManager(identifier)
+    workday.getWorkerEffectiveDates(identifier)
+    ```
+
+2. Limit output fields to:
+    - Worker ID
+    - Name and email
+    - Employment status (active, terminated, future-dated)
+    - Job profile
+    - Cost center or department
+    - Location
+    - Manager
+3. Explicitly exclude:
+    - Compensation
+    - Performance
+    - Benefits
+    - Payroll
+    - Medical and protected fields
+4. Validate field exposure with HRIS policy owners.
+
+✅ **Exit criteria:** HR confirms exposed fields align to least-privilege policy.
+
+---
+
+### Step 4: Read-only validation and drift detection (Phase 3)
+
+**Objective:** Prove the MCP can detect drift accurately without triggering changes.
+
+1. Validate representative read-only scenarios:
+    - User active in AD but terminated in Workday
+    - User manager mismatch between AD and Workday
+    - Future-dated hires missing in AD
+    - Contractor end date passed in Workday
+2. Document expected versus actual results for each validation case.
+3. Confirm all outputs are informational only and do not trigger remediation actions.
+
+✅ **Exit criteria:** Workday MCP reliably answers identity-state questions with no write behavior.
+
+---
+
+### Step 5: Correlation with Identity MCP (Phase 4)
+
+**Objective:** Enable AI reasoning across workforce, identity, and device context.
+
+1. Integrate data flow in this order:
+    - Workday MCP (Source of Truth)
+    - Identity MCP (AD and Entra state)
+    - Device or access decision context (for reporting and recommendations)
+2. Validate cross-system insights, including:
+    - Who should exist versus who does exist
+    - Users with access who are no longer employees
+    - Future-dated hires that should not be provisioned yet
+3. Confirm Workday MCP remains context-only and never issues AD updates.
+
+✅ **Exit criteria:** Cross-system insights are accurate and no direct identity writes originate from Workday MCP.
+
+---
+
+### Step 6: Human-approved remediation workflows (Phase 5)
+
+**Objective:** Use detected drift to support existing SOPs while preserving separation of duties.
+
+1. Implement the operational pattern:
+
+    ```text
+    1. AI detects mismatch
+    2. AI explains cause (Workday vs AD or Entra)
+    3. Human selects remediation path
+    4. Identity MCP or existing automation executes
+    5. Ticket is updated with result
+    ```
+
+2. Ensure remediation remains in IT-owned systems and not in Workday MCP.
+3. Validate tickets include decision, execution details, and closure evidence.
+
+✅ **Exit criteria:** Remediation is human-approved, auditable, and executed by approved downstream systems.
+
+---
+
+### Step 7: Audit, security, and lifecycle controls (Phase 6)
+
+**Objective:** Harden operational controls for steady-state use.
+
+1. Enable request-level logging for every MCP invocation.
+2. Record at minimum: tool name, parameters, timestamp, and result status.
+3. Ensure no expansion of PII beyond approved fields.
+4. Version-control all tool definitions and review changes through standard change control.
+5. Validate for Workday release cycles and schema changes before production rollout changes.
+6. Rotate integration credentials per policy and restrict server access to approved hosts.
+
+✅ **Exit criteria:** Logging, change management, and access lifecycle controls are operating and verified.
+
+---
+
+## Post-installation actions
+
+- Run a weekly control review for the first 60 days after go-live.
+- Review drift-detection false positives and tune query logic where needed.
+- Reconfirm field-level scope with HRIS and Security before adding any new tool.
+- Re-validate after each Workday release window and after identity schema changes.
+- Keep remediation SOP references current and linked to ticket templates.
+
+---
+
+## Troubleshooting / Escalation procedures
+
+| Issue | Resolution |
+| --- | --- |
+| Workday MCP authentication fails | Verify ISU status, OAuth credentials, token scope, and API endpoint allow-list. |
+| Tool returns incomplete worker attributes | Confirm requested fields are in approved scope and available in Workday API response mapping. |
+| Drift query results appear inconsistent with AD | Validate identity correlation key mapping (worker ID, email, or employee ID) and check for stale cache. |
+| Read-only contract is violated by a new tool proposal | Reject deployment, remove tool from manifest, and route through security and HR governance review. |
+| Audit log entries missing | Pause production use until logging is restored and event flow validation passes. |
+| Unexpected PII appears in output | Immediately disable affected tool, remove unapproved fields, and complete incident review. |
+
+**Support Contact:** Raise a ticket with IT Automation and include HRIS owner review if policy scope or data classification is involved.
+
+---
+
+## References / Related documents
+
+- [Model Context Protocol MCP — Developer guide (sqlservercentral.com)](https://www.sqlservercentral.com/articles/model-context-protocol-mcp-a-developers-guide-to-long-context-llm-integration)
+- [Model Context Protocol guide (artificialintelligenceschool.com)](https://artificialintelligenceschool.com/model-context-protocol-mcp-guide/)
+- [MCP servers explained (dev.to)](https://dev.to/jamie_thompson/mcp-servers-explained-how-ai-assistants-connect-to-your-tools-598o)
+
+---
+
+## Revision history
+
+| Version | Date | Author | Description |
+| --- | --- | --- | --- |
+| v1 | 2026-03-11 | N. Castaldi | Initial draft |