Help Center Agents Developer Help Developer API

Use your skills in Claude Managed Agents

Availability: All plans. Requires a workspace connector URL and an Anthropic account with Managed Agents access.

HIPAA CompliantSOC2 ReadyISO 27001 Ready

Anthropic's Managed Agents run on Anthropic's infrastructure rather than in a chat window — you create an agent, hand it tools, and send it work through the API. Your Agentman skills library can be one of those tools, so a managed agent applies the same governed procedures your team uses everywhere else.

This is the headless case: no one is present to click through a workspace chooser, so the setup differs from connecting Claude in two ways worth knowing before you start.

Use your workspace's own connector URL

Managed agents should always use the workspace-pinned URL — the one ending in your workspace's name:

https://skills.agentman.ai/mcp/your-workspace

Copy it from Use in Claude in your skills library.

The reason is a guardrail, not a limitation. A pinned URL refuses a credential issued for a different workspace, so an agent configured for one client cannot quietly read another client's library, even if the wrong credential is attached. The plain /mcp URL accepts any workspace's token, which is fine when a person is choosing but not what you want running unattended.

The agent config needs both halves

Declaring the server and granting its tools are two separate steps, and an agent with only the first will start up fine and then behave as though the skills don't exist.

Declare the server in mcp_servers:

{
  "mcp_servers": [
    {
      "type": "url",
      "name": "agentman-skills-your-workspace",
      "url": "https://skills.agentman.ai/mcp/your-workspace"
    }
  ]
}

Only type: "url" is supported, and custom headers are rejected — authentication happens through the vault below, not through a header you set here.

Grant the tools in tools, pointing at that same name:

{
  "tools": [
    {
      "type": "mcp_toolset",
      "mcp_server_name": "agentman-skills-your-workspace"
    }
  ]
}

The shared name is what ties the two halves together — that's why the connector snippets name each server after its workspace. If you attach several workspaces to one agent, each needs its own pair, and the distinct names keep them apart.

Name the tools in your prompt

Granting the toolset makes the tools available; it doesn't tell the agent to reach for them. A managed agent runs unattended with no one to nudge it, so name the tools you expect it to use in the agent's prompt — otherwise it will often answer from general knowledge and never open the skill at all.

The two that matter for almost every agent:

  • open_skill — reads a skill's SKILL.md, the actual instructions to follow. Takes the skill's slug (open_skill(slug: "claims-denial-response")).
  • read_skill_file — reads an auxiliary file bundled with a skill: a template, a reference table, an example. Takes a path that begins with the slugread_skill_file(path: "claims-denial-response/templates/appeal-letter.md"). Reach for it when SKILL.md points at another file.

Note the two argument shapes differ — a bare slug for one, a slug-prefixed path for the other. Mixing them up is the most common mistake in a first prompt.

If the agent needs to find the skill rather than being told which one, add find_skills (natural-language search) or list_skills (browse by category). When your prompt already names the skill, skip both and go straight to open_skill — it's one call instead of two.

A prompt that works looks roughly like:

Use open_skill with slug claims-denial-response and follow its instructions exactly. If it references a template, load it with read_skill_file. Don't answer from memory — the skill is the source of truth.

Writing a log back

If the agent should record what it did, prefer save_skill_resource — it writes an auxiliary file to the skill (save_skill_resource(slug, file_path: "logs/2026-09-06.md", content: …)) and leaves the instructions untouched.

update_skill also exists, but it replaces the entire SKILL.md, frontmatter included. An agent appending a log line with it has to resend the whole document, and anything it omits is gone — so use it only when the agent's job really is rewriting the instructions.

One behaviour applies to both: on a published skill, a write creates a new draft rather than changing the live version. That's the safe default — an unattended agent can't quietly alter what your team is using — but it does mean the change isn't live until someone publishes it, either in Studio or with publish_skill. If you grant publish_skill, an agent can publish its own writes; leave it out and every change waits for review.

Grant only the tools the agent actually needs. An agent that reads skills and logs its work needs open_skill, read_skill_file, and save_skill_resource — not the full toolset.

Signing in: the credential vault

A managed agent has no browser, so it can't complete an OAuth consent screen. Instead the credential lives in a vault you create ahead of time and attach to the session:

  1. claudeagent_create_vault — make the vault.
  2. claudeagent_create_credential — add a credential with type: "mcp_oauth", mcp_server_url set to your pinned URL, and the access token. For unattended renewal, include a refresh block; it needs all three of refresh_token, token_endpoint, and client_id.
  3. claudeagent_create_session — pass vault_ids.
  4. claudeagent_send_user_message — send the agent its work.

One thing to watch: claudeagent_run_task does not carry a vault. Its input schema has no vault_ids, so a task started that way has no credential and cannot reach your library — use a session for skill-backed work.

What isn't available yet

Studio does not issue OAuth credentials for this configuration today. Connecting a workspace through the normal flow never exposes the access token, and the refresh block additionally needs the OAuth client's own identity. So the vault step above describes the shape Anthropic expects, not something you can currently populate from Studio alone. An affordance for generating a managed-agent credential is planned.

Worth stating plainly because it's a common mix-up: your Anthropic API key authenticates the Managed Agents management tools — creating agents, sessions, vaults. It grants no access to your skills. Reaching your library is what the vault credential is for.

If you want your skills in an automated workflow before that lands, an Agentman agent called over the Runtime API reaches the same library today.

Availability

All plans. Requires a workspace connector URL and an Anthropic account with Managed Agents access. The Agentman MCP server for Anthropic's Managed Agents API is hosted at mcp.agentman.ai/claudeagents/mcp.

Build this yourself

A free workspace, the same tools we use in production. Describe it and ship it.