How to test Workday MCP tools: tool lists, security, write tools and non-deterministic agents

Test the tool, the security and the agent separately

Testing Workday MCP tools means proving three different things: that the right user sees the right tools, that each tool call does in Workday what the agent thinks it did, and that the agent picks and fills the tools reliably enough across repeated runs. Workday's own guidance makes the third unavoidable: it says agent results will vary across runs, clients, prompts and models, so one successful chat proves very little.

Keep the layers apart. When a scenario fails, you want to know whether the tool was missing, the call was refused, the data was wrong, or the model chose badly. Each needs a different fix.

Use a client that shows the raw protocol

Workday's troubleshooting page for Custom Agent Actions recommends an MCP client that shows the raw tool list and results, and the same applies to Agent-Ready tools. A chat interface that summarises the result hides the error text you need. Bruno, Postman or a plain curl against the endpoint all work:

curl --request POST \
  --url "https://us.agent.workday.com/<tenant>/mcp" \
  --header "Content-Type: application/json" \
  --header "Authorization: Bearer <ASU token>" \
  --data '{"jsonrpc":"2.0","id":1,"method":"tools/list"}'

The token is an ASU token for a real user, obtained through the agent's OAuth flow; connecting an outside agent to Workday's MCP server covers getting one. Because the agent acts in delegate mode, every result you see is bounded by that user's own Workday security.

Layer 1: who sees which tools

Get a token for at least two test users: one in a security group listed in the skill's Available To, one outside it. Run tools/list for each.

• The user inside should see every tool registered in the agent's enabled skills.
• The user outside shouldn't see the skill's tools. Workday's troubleshooting page describes this filter for Custom Agent Actions: a tool appears only when its skill is enabled and the user is in Available To, and nothing is returned to say why when it isn't.

Two traps when the list looks wrong. First, a token issued before you changed the registration doesn't carry the new resources, per the same page; sign in again after every registration change. Second, some MCP clients rewrite characters in tool names (Workday's example is / becoming _). Compare against the client's own list, not the names in your agent definition.

Each test user has to complete the OAuth sign-in and Allow step as themselves, so keep dedicated test accounts in a non-Production tenant with known security group memberships. The multi-persona testing guide covers choosing personas that cover each group.

Layer 2: each tool call, read back in Workday

Call each tool directly with tools/call, filling arguments from the inputSchema that tools/list returned:

{
  "jsonrpc": "2.0",
  "id": 2,
  "method": "tools/call",
  "params": {
    "name": "<tool name from tools/list>",
    "arguments": { "...": "fields from the tool's inputSchema" }
  }
}

For read tools (Basic, in the MCP Explorer's terms), compare the result with the same data viewed in Workday by the same user. If the tool returns less than an administrator would see, check the test user's own access first: in delegate mode that is the expected result, and worth confirming deliberately.

For write tools (Advanced), the call's response isn't the proof. Open the worker, event or business process in Workday afterwards and confirm the change is there, with the values sent, and that any business process it started is in the state you expected. Run write tests in a non-Production tenant.

Prompt tools

Some write tools need prompt values: the IDs a Workday prompt would offer a person. Workday supplies read-only Prompt tools for these and says you must register them alongside the write tool. Its preferred-name sample pairs create_worker_preferred_name_change with tools that list name salutations, titles and suffixes. Test that the agent calls the prompt tool first and passes a returned value, rather than inventing one. If a write fails on a prompt field, check first that the prompt tool is registered and that the agent called it.

Layer 3: security on each tool, not just the skill

Available To controls who can use a skill. It doesn't grant access to what the tools touch. Workday's configuration page says the groups must also have permission on the domain or business process policies securing each tool, and Workday evaluates both at runtime.

Open the agent in the Agent Management Hub, go to the Skills tab and click View Security. The View Security for Agent Skill report lists each tool with its securing policies. Rows marked Review Required or Config Required are policies that don't include the groups in Available To. A test user who is in Available To but fails on one tool is the symptom; that report is where the cause shows.

Then test the negative case on purpose: a user who can use the skill but has no access to one worker's data should get no data for that worker. Delegate security means the agent can never exceed the user, and that's the property worth proving before go-live. ASOR agent security explains how the agent's and the user's permissions combine.

Layer 4: the agent, run many times

Workday's change policy separates its side from yours: the tools execute deterministically, but the agent's reasoning doesn't, and variance comes from the model, the agent's instructions, the client software around the model, and the prompt. That shapes the test design:

• Write scenarios as goals, not scripts. "Change this worker's preferred first name to Sam and confirm it" can be judged by reading Workday afterwards. A script that expects particular tool names will break, because Workday's policy says names, schemas and descriptions change without notice, and prohibits binding prompts to tool names.
• Repeat each scenario. One pass tells you it can work; several passes tell you how often it does. Run them on each model and client you'll actually ship with.
• Judge on the Workday outcome. Count a run as passed only if the record in Workday matches the goal, whatever the agent says it did.

kiweely can do the read-back step: it signs in to the tenant as you, opens the record the agent was meant to change in the browser, and reports what Workday shows.

Re-test on Workday's schedule, not just yours

The MCP Explorer updates weekly on Tuesdays, and you can export a CSV change log of tool additions, removals and changes from it. A routine that fits that cadence (our recommendation, not a Workday rule): export the log after each Tuesday update, match it against the tools your agents register, and rerun the scenarios that use any changed tool. Workday counts only removal without replacement, unresolvable validations and access-revoking security changes as breaking, so renamed tools and rewritten descriptions arrive as non-breaking changes and still deserve a test run.

When the agent is a Workday custom agent

If you're testing a custom agent built on Workday's platform rather than an outside one, Workday records Agent Traces for Extend AI (formerly Extend Professional) customers. Open the app, select the Agent Traces tab, and click View Trace Details on a run. The AviatoTurboChatCIS node shows what the model was given (including the tool definitions) and what it returned, including the tool calls as JSON. Workday keeps traces for 30 days and lists the latest 100. If a tool is missing from that node's inputs, Workday's advice is to check the ASOR configuration and redeploy.

For Custom Agent Actions, the result tells you which layer failed. Workday documents these messages:

A successful result carries the run ID in _meta as X-Orchestrate-Id; find that run under Orchestration Activity to see each step. A status of Completed only means the orchestration finished, not that the action succeeded.

Load testing

Workday's limits for Agent-Ready MCP tool calls are 2,000 concurrent requests, with a refresh rate and burst limit of 500 requests each. Tool calls are a metered unit (Base or Advanced, per Workday's Tool Call Catalog), monitored in the Platform Consumption Console, so run load tests in a non-Production tenant, where for most offers usage doesn't draw down Flex Credits.