Finding Workday tool IDs with the Agent Resource Search (finder) API

What the finder API is for

The finder API is Workday's ASOR Agent Resource Search API: a GET endpoint on the Agent Gateway host that searches the tools an agent can be given and returns each one's Workday ID (WID). You search by name, filter by tool type and operation, and copy the wid of each result into an agent definition's agent_resource.id or into a custom agent skill's tool-wids.

An agent definition registers tools by WID, not by name, and the WIDs of Workday's Agent-Ready tools, Workday-delivered and custom agents, and public REST and SOAP operations are all searchable here. Workday's Developer Site also has a browsable tool explorer for the same job; the API is the one to use from a script or build process.

Who can call it

Two conditions, per Workday's documentation:

• The caller must be an Extend Professional user (the SKU Workday now calls Extend AI). For organisations on the Main Service Agreement (MSA), the feature is enabled through Innovation Services with the Enable Innovation Services Feature and AI Data Contributions for MSA Customers step. On the Universal Main Subscription Agreement (UMSA) it is available automatically. Your agreement type is shown on your organisation's profile in Workday Community.
• The token must belong to a user with the Setup: Agents domain in the Agent System of Record functional area. The quickest token is the Developer Site's: connect to the tenant and use Copy Token. Any standard tenant OAuth token for such a user also works.

Send the request to the Agent Gateway host for the tenant's region, such as us.agent.workday.com or eu.agent.workday.com. Workday notes that the tenant's own REST host rejects the Developer Site token.

The request

GET https://us.agent.workday.com/asor/agentResourceSearch/v1?searchString=time%20off&operationType=VIEW
Authorization: Bearer <access token>

The parameters Workday documents:

A result looks like this:

[
  {
    "type": "AGENT READY",
    "name": "getTimeOffEntries",
    "description": "Returns time off entries for a worker.",
    "wid": "386c0e439ecd100039e864720d570000",
    "mcpEnabled": true,
    "httpEnabled": false
  }
]

mcpEnabled and httpEnabled tell you how the tool can be called. Workday's SOAP examples come back with mcpEnabled: false and httpEnabled: true.

Where Workday's pages disagree, and what to send

Workday describes this API on three pages, and they don't match exactly. Know the differences before you script against it:

• Path. The discovery page uses /asor/agentResourceSearch/v1. The Custom Agent Action troubleshooting page uses /asor/v1/agentResourceSearch. If one form fails on your gateway, try the other.
• toolType values. The discovery page lists AGENT READY (Workday's Agent-Ready tools, the ones you register in an agent definition), AGENT (Workday-delivered agents and custom agents you build, which can be called as tools by your agent) and INT. The API concept page lists SOAP, REST and the protocol value. The troubleshooting page uses REST or SOAP for finding operations an orchestration calls.
• Underscore or space. The discovery page writes the type as AGENT READY in its table and response, and as AGENT_READY in its example query. Match what the response returns.

The practical approach is to start with only searchString, read the type values that come back for your tenant, and add filters using exactly those values.

Common searches

An Agent-Ready tool for a custom agent or external agent. Search by the business term, filter to the Agent-Ready type and the operation you need. For a write tool, check its required prompt tools too: Workday's preferred-name example needs four read-only prompt tools (hereditary suffixes, salutations, social suffixes and titles), and the names and WIDs of all of them must be in the agent definition alongside the write tool.

A Workday agent to call as a tool. Search with searchString=self service and the AGENT type to find the Self-Service Agent. Custom agents you have deployed show up the same way.

The REST and SOAP operations inside a Custom Agent Action. Filter toolType to REST or SOAP and set operationType. When several results share the same name, Workday's troubleshooting steps say to copy every wid. For WQL, don't search: Workday gives fixed IDs, 9749ba9ac47e1000073fdc1bc8a5001a for GET and 3e15b2a1676d10000c9572ea9cc264b3 for POST.

When the search returns nothing

Some operations aren't returned. Workday's example is a SOAP operation that writes data. For those, build a custom report with the Create Custom Report task:

Workday lists the Custom Report Creation, Manage: All Custom Reports and Report Tag Management domains as prerequisites for this step. The Workday ID column holds the WID to register.

Using the WID

For an external agent, each wid goes in a workdayResources entry of the skill in the agent definition:

{
  "tool_name": "getTimeOffEntries",
  "description": "Time off entries for the signed-in worker",
  "agent_resource": { "id": "386c0e439ecd100039e864720d570000" }
}

For a custom agent built in App Builder, it goes in the .agentskill file:

tool-wids:
  - name: getTimeOffEntries
    wid: 386c0e439ecd100039e864720d570000

Paste carefully. Workday warns that a space anywhere in a WID in a skill file stops the tool from registering. After changing an external agent's registration, sign in again from the agent's client: a token issued before the change doesn't include the new resources.

Search again before every build

Workday treats its Agent-Ready tools as a single, unversioned surface. Tool names, schemas, field names and descriptions change without notice when the meaning is preserved, Workday's tool explorer updates weekly on Tuesdays, and Workday's developer guidelines say not to bind an agent's prompts to specific tool names. A name you saved last month may not return today. Run the search as part of each build, compare the WIDs with what the agent definition has, and investigate any tool that no longer comes back before you deploy.