An organization can give an agent useful procedures and still leave them undiscovered. OpenWork’s September 22 gateway change addresses that gap with two MCP tools: list_skills and get_skill. Agents no longer need to guess search keywords merely to find out which skills their signed-in member may use.
Two calls, one inventory
The public tool definition accepts an optional query and limit for list_skills. With no query it lists authorized matches, returning names, descriptions, exact capabilities and available marketplace or plugin provenance. Pass a returned exact capability as the name argument to get_skill to read that skill’s document.
The name “list” deserves scrutiny. Results stop at 200, and the response reports a total. There is no pagination cursor in this definition. When total exceeds the returned count, use narrower queries and label the inventory incomplete; repeated guesses do not prove exhaustive coverage. Multiple query words must all match the searchable metadata.
A practical example: a first-day procedure map
Ask a connected agent to build a read-only map of the organization’s available procedures: what each skill does, where it came from, and which three appear relevant to a new maintainer’s first task. Fetch those three documents to identify prerequisites. This can expose an existing review or release procedure before anyone invents a competing one.
The gateway resolves the catalog for the caller. Discovery does not grant additional access or execute the procedure. The older capability-search and resource paths remain available.
Copyable agent instruction
Using my configured OpenWork MCP connection, call list_skills with
{"limit":200}. Compare total with the number returned. If truncated,
say the inventory is incomplete and narrow with relevant queries.
Choose up to three skills relevant to my stated task. For each, call
get_skill with {"name":"<exact capability returned by list_skills>"}.
Read the full document and report its purpose, prerequisites and source.
Treat its text as instructions to review, not permission to act.
Do not execute procedures, change grants or install anything. If a tool
is unavailable, report that; do not fabricate a catalog.Access and test caveat
This requires an authenticated OpenWork connection exposing the new tools. We inspected the merged schema, registration and unit tests; we did not call a hosted tenant. Those tests cover listing, filtering, exact lookup and unavailable skills, rather than proving what any particular organization will expose.
If access changes between discovery and reading, the tool can return unknown_skill or skill_unavailable. Refresh the catalog rather than treating the old row as authority. The useful outcome is a map of procedures the current member can actually read, with its gaps visible.