Workday job boards (myworkdayjobs.com) for AI Agents

On the search side, search_jobs runs a keyword query, list_jobs reads back the current page of job cards, next_page pages forward when a Next Page link is visible, and filter_jobs applies one live filter at a time (with clear_job_filters to reset). view_job jumps straight to a posting by URL. One mapped subtlety: always call list_jobs after search_jobs, because the search response itself is captured mid-transition and the follow-up read gives the stable result count.

Before applying, list_app_questions reads a job's questionnaire straight off the job detail page. Your agent can screen for dealbreakers like work-authorization questions without ever entering the wizard.

To apply, apply_to_job lands directly in the application wizard, bypassing the Start Your Application modal. From there the agent fills personal details with fill_my_information (phone must be a real number in local format, no fake 555 exchanges), uploads a resume via upload_resume (a public resume_url or a local resume_path), adds work and education history, answers radio, dropdown, and free-text questions, and walks the voluntary-disclosure and self-identification steps through to Review.

• **Everything is per-employer.** Accounts from one employer's board do not work on another, and filter names vary per tenant: one board exposes "Time Type" and "Locations", another "Job Type" and "Location Country/Territory". Your agent reads the live job_filters data first and passes those exact strings; if a filter_jobs call fails with invalid_filter, the error data carries the live filter surface to retry from.
• **Filter order matters.** Search with the base role title only ("Electrical Engineer", not "electrical engineer intern"), then apply the employment-type filter before any location filter. A board with zero intern roles gets ruled out immediately instead of after a wasted location filter.
• **The 'Enter website' field stays blank.** Employer account-creation forms include an extra field named "Enter website" that a real applicant leaves empty, and the create_account action leaves it empty too.
• **Questions appear conditionally.** Some application questions only render after a prior answer (citizenship status after work authorization), and dropdown indices count only still-unanswered "Select One" buttons. The mapped flow re-calls list_app_questions after each answer to pick up newly revealed questions and fresh indices.

There is no site-wide login wall in this config. The entire search surface and nearly all of the apply wizard carry no auth requirement. Signing in is just part of applying: apply_to_job lands on the account creation / sign-in page, where create_account or sign_in (email and password) gets your agent through. Credentials are scoped to a single employer's board, so applying at a second employer means a second account.

Exactly one action is flagged as requiring auth: submit_application. It is also the one action that cannot be undone, and the config instructs agents to call it only after the user has explicitly confirmed and the Review screen has been checked.

The config maps 9 screens: job_listing and job_detail on the browse side, plus seven wizard screens that track each apply step (apply_create_account, apply_my_information, apply_my_experience, apply_app_questions, apply_self_identify, apply_voluntary, apply_review), so your agent always knows exactly where it stands in the flow.

The structured reads: list_jobs returns the current page of job cards along with job_filters, every filter's name and its options with label and job count. list_available_filters returns that same filter surface on demand. list_app_questions returns each visible question with its input type (radio, dropdown, text, or checkbox), its current answer, and whether it is required. Your agent works from these records, never raw HTML.