What the client can do

The read, documentation, and write tools the P4A MCP server exposes, and how token scopes gate them.

The tools the server exposes mirror what you can do in the portal, scoped to your account and gated by your token's scopes. Read tools require api:read; write tools require api:write. Documentation search needs only a valid token. See Connecting a client for how to mint a token with the right scopes.

Read tools (`api:read`)

Tool	What it does
`search_policies`	Search the policy catalog. Each result carries the policy's public `slug` (the identifier in its shareable `/p/{slug}` link). Pass `source: "mulesoft"` to search MuleSoft's out-of-the-box Omni Gateway policies instead of the community catalog. Filter by `direction: "inbound"` / `"outbound"` (enforcement leg, applies to both sources) or `assetKind` (agent/api/llm/mcp, community only).
`get_policy`	Fetch one community policy by id, including its public `slug` (the identifier in its shareable `/p/{slug}` link), `delivers_ideas` (the Policy Ideas this policy delivers, each with coverage/scope), `asset_kinds` (agent, api, llm, mcp), `a2a_protocol_versions` (when agent is a kind), `direction` (inbound/outbound), `source_ref` / `implementation_source_ref` (the default git branch/tag/commit used when deploying; `null` = the repository default branch), and `contributors` (additional registered members credited on the policy alongside the owner, each with a display name — empty when there are none or the policy isn't visible to you). A policy may deliver more than one idea.
`get_install_command`	Get the manual install/deploy commands for a policy.
`get_mulesoft_policy`	Fetch one MuleSoft out-of-the-box policy by slug, including its full documentation.
`list_deployments`	List your deployments, newest first.
`get_deployment`	Get one deployment plus its latest build progress.
`get_deployment_logs`	Get a deployment's build-log lines — the same output you see live in My Deployments — to diagnose a failed or in-flight deploy.
`list_my_connections`	List your Anypoint connections (no secrets returned).
`list_my_submissions`	List your policy submissions, optionally filtered by status. Each carries the reviewer's latest `feedback` note when the submission was sent back for improvement or rejected (null otherwise).
`get_submission_feedback_history`	Get the reviewer feedback history for one of your submissions, newest first — every round it was sent back or rejected, each with the feedback text, the reviewer's name, and when it happened.
`list_my_workspaces`	List your workspace memberships and your role in each.
`get_connection`	Get one Anypoint connection by id (no secrets returned).
`list_connection_business_groups`	List the Anypoint business groups a connection can reach — the deploy targets for `deploy_policy`.
`get_workspace`	Get one workspace, your role, and its members.
`list_ideas`	List Policy Ideas, optionally filtered by query or category. Each idea carries its public `slug` (the identifier in an approved idea's shareable `/i/{slug}` link), its derived `delivery_state` — `delivered`, `partially_delivered`, or null — and a `reviewer` (the name of the reviewer who last reviewed it, or null if not yet reviewed).
`get_idea`	Fetch one Policy Idea by id, including its public `slug` (the identifier in an approved idea's shareable `/i/{slug}` link), its derived `delivery_state` (`delivered` / `partially_delivered` / null), a `reviewer` (the name of the reviewer who last reviewed it, or null), `delivered_by_policies` — every policy delivering it, each with coverage (`full`/`partial`), scope note, and whether it completes the idea — and its reviewer `feedback_history` (each round the idea was sent back or rejected, newest-first) when you can see it. An idea may be delivered by more than one policy.
`get_public_profile`	Look up a community member's public profile by their `@`-handle or user id. Returns their name, company, and handle (always), plus their bio and social links only when they've made their profile public, along with their published policies, the policies they've been credited on as a contributor, their published rulesets (each with its description and Validation Profile name), the rulesets they've been credited on as a contributor, and approved ideas. When the member has opted into showing an avatar, it also returns their provider avatar URL and an email hash for building a Gravatar URL.
`list_testimonials`	List the approved user testimonials shown in the home-page carousel, newest first. Each carries the author's name, role, company, and quote.
`get_policy_comments`	List the discussion comments on a policy (flat, oldest-first; replies carry a parent id).
`get_idea_comments`	List the discussion comments on a Policy Idea (flat, oldest-first; replies carry a parent id).
`get_ruleset_comments`	List the discussion comments on a ruleset (flat, oldest-first; replies carry a parent id).
`get_ruleset_docs`	Read a ruleset's documentation tabs (Overview, Rules, Examples, FAQ, and any custom tabs). Readers see the Overview and every tab with content; the owner and editors also see the empty tabs.
`search_rulesets`	Search the community API Governance rulesets — design-time conformance rules for your API and agent specifications, not runtime gateway policies. Filter by `query`, `category`, or target `scope` (`rest-api`, `async-api`, `http-api`, `grpc-api`, `agent`, or `mcp`), and sort by `alpha`, `submitted`, `likes`, or `views`. Returns up to 50 per page (default 20) with a `hasMore` flag; page with `offset`. You see published rulesets plus your own that are still under review. Pass `source: "mulesoft"` to search MuleSoft's out-of-the-box rulesets instead; those results carry a `slug` and a `gav`, and only `alpha` sorting applies.
`get_ruleset`	Fetch one ruleset by id, including its Validation Profile name, rule names and counts per severity, target scopes, and source repository, plus `contributors` (registered members credited on the ruleset alongside the owner, each with a display name; empty when there are none). Reviewer feedback is included only on your own rulesets.
`get_mulesoft_ruleset`	Fetch one MuleSoft out-of-the-box ruleset by `slug`, including its GAV (`group_id/asset_id/version`) and Exchange URL, rule names and counts per severity, the Exchange home page as markdown, and the full Validation Profile YAML, so you can read the rules. The GAV can be attached directly to an Anypoint governance profile.
`validate_ruleset`	Check a ruleset you wrote (AMF Validation Profile YAML). Returns `valid`, errors with 1-based `line` where known, the profile name, rule names and counts per severity. By default a fast structural check (`authoritative: false`). With `authoritative: true`, `connectionId` and `workspaceId` it runs the Anypoint CLI validator as an audited job (rate limited per day) and waits up to about 30 seconds; if still running it returns `pending: true` and a `jobId` you pass back (with no `yaml`) to fetch the result.
`fork_mulesoft_ruleset`	Start from a MuleSoft out-of-the-box ruleset by `slug`: returns its Validation Profile YAML, a suggested `exchange.json` (new asset id, `(custom)` name, version `1.0.0`), the files to commit to your own public repository, and next steps (`validate_ruleset`, then `submit_ruleset`). P4A creates no repository.
`fork_ruleset`	The same for a community ruleset, by `id`: reads its Validation Profile YAML from the source repository at the submitted ref and returns it with a suggested `exchange.json` and files to commit. Returns `source_unavailable` with a message if the repository can't be read.
`list_governance_profiles`	List the API Governance profiles of one Anypoint business group (id, name, description) through your connection, for example to pick the `profileId` for `attach_ruleset_to_profile` or `deploy_ruleset`.
`list_my_ruleset_submissions`	List your ruleset submissions, optionally filtered by status (`submitted`, `under_review`, `needs_improvement`, `published`, `rejected`). Each carries the id of the ruleset it created once accepted for review.

Prompts

Prompt	What it does
`author_ruleset`	Guide your agent through writing a governance ruleset from a plain-English rule (optional `rule` argument): the Validation Profile dialect, severities, rule and constraint examples, common pitfalls, and the loop of `fork_mulesoft_ruleset`, `validate_ruleset`, then `submit_ruleset`. P4A hosts no model; your own agent writes the YAML.

Documentation tools

Tool	What it does
`search_docs`	Full-text search across this documentation site.
`get_doc`	Fetch one documentation page by slug.

Write tools (`api:write`)

Tool	What it does
`submit_policy`	Submit a policy for review from a public GitHub repository. Optionally set `sourceRef` (and `implementationSourceRef` for split policies) to pin the default git branch/tag/commit used when the policy is deployed — omit to use the repository's default branch. Optionally declare one or more approved Policy Ideas it delivers, each with a coverage (full/partial), and optionally specify `assetKinds` and `a2aProtocolVersions` to override the inferred classification.
`submit_idea`	Submit a Policy Idea for review.
`submit_ruleset`	Submit an API Governance ruleset for review from a public repository containing a Validation Profile. Pass `name`, `description`, and `repoUrl`; optionally `sourceRef` (branch/tag/commit), `rulesetPath`, `category` (one of `Security`, `API Design`, `Documentation`, `Compliance`, `MCP`, `A2A`, `LLM`, `Operations`, or `Other`, the default), `targetScopes` (the same values as the `scope` filter), `tags`, `videoTutorialUrl`, `examplesUrl`, `iconUrl` (omit it to use the repository's `icon.png` or `icon.svg`), and `iconDisabled` (`true` shows the default icon instead). The repository is checked first — if it has no valid Validation Profile, the result lists what's wrong and nothing is submitted.
`submit_testimonial`	Share a testimonial about P4A. You set the author name, role, and company shown on the card (free-text — they need not match your profile) plus a short quote. It's held for review and appears on the home page once approved.
`vote_idea`	Toggle your vote on a Policy Idea.
`withdraw_idea`	Recall one of your own under-review Policy Ideas back to an editable draft, so you can revise it and resubmit. Only works while the idea is still under review; votes and comments are preserved.
`post_policy_comment`	Post a comment, or a nested reply, on a policy's discussion.
`post_idea_comment`	Post a comment, or a nested reply, on a Policy Idea's discussion. A delivered idea's thread is read-only.
`post_ruleset_comment`	Post a comment, or a nested reply, on a ruleset's discussion. The ruleset must be published, or your own while it's under review.
`set_ruleset_doc_tab`	Create or update one documentation tab on a ruleset. You must own the ruleset, be an admin, or be an editor reviewer while it's under review.
`replace_ruleset_docs`	Replace a ruleset's whole set of documentation tabs in one call. The Overview tab is required, and missing predefined tabs are added back empty. Same permissions as `set_ruleset_doc_tab`.
`update_my_profile`	Update your own profile: company, `@`-handle, bio, LinkedIn and X links, whether your bio and links are public, and whether to show your external avatar. Only the fields you pass change; pass an empty value to clear an optional link.
`deploy_policy`	Deploy a policy to your Anypoint business groups. Asks you to confirm before enqueuing. Returns a deployment id per target so you can track progress with `get_deployment`. Pass an optional `version` (a semver core like `1.2.3`) to override the published Exchange asset version instead of using the one in the policy repository.
`deploy_ruleset`	Publish an approved ruleset to Exchange in your Anypoint business groups. While a ruleset is under review, its invited reviewers (including its author) can also publish it to their own organization. Asks you to confirm before enqueuing. Optional `assetId` (Exchange asset id), `version` (semver core like `1.2.3`) and `ref`. Returns a deployment id per target; track it with `get_deployment`. Pass an optional `governanceProfile` to add the published ruleset to a new or existing governance profile in the same step, including optional `notifications` (`contact`, `publisher`, `others` emails) for conformance failures.
`attach_ruleset_to_profile`	Add rulesets that are already in Exchange (a MuleSoft ruleset's GAV, or one you published) to a new (`mode: 'create'` with a `name`) or existing (`mode: 'update'` with a `profileId`) governance profile, without publishing anything. Up to 20 `group/asset/version` entries. An existing profile keeps the rulesets it already has. Optional `notifications` (`contact`, `publisher`, `others` emails) set who is emailed when an API fails conformance; on an existing profile they replace its recipients, and leaving them out keeps them. Asks you to confirm first. If it's still running after about 30 seconds you get a `jobId`; call again with just `jobId` to check. Counts toward your daily deploy limit.
`delete_deployment`	Permanently delete one of your failed deployments. Asks you to confirm first; only failed deployments can be deleted.
`delete_failed_deployments`	Permanently delete all your failed deployments, optionally just for one policy. Asks you to confirm first.
`rename_connection`	Rename an Anypoint connection.
`delete_connection`	Delete an Anypoint connection. Asks you to confirm before deleting.
`create_workspace`	Create a shared workspace (you become its owner).
`rename_workspace`	Rename a shared workspace you own.
`add_workspace_member`	Add or re-enable a member of a workspace you administer.
`update_workspace_member`	Change a member's role, or re-enable a disabled member.
`remove_workspace_member`	Remove a member from a workspace. Asks you to confirm before removing.

The destructive and outward-facing tools — deploy_policy, deploy_ruleset, attach_ruleset_to_profile, delete_connection, remove_workspace_member, delete_deployment, delete_failed_deployments — ask you to confirm before acting. If your client supports interactive confirmation (MCP elicitation), it will pop up a prompt and the action runs only if you accept. Clients that don't support it fall back to running the action under your write access — so only grant api:write to clients you trust.

Some clients (Claude Code among them) advertise interactive confirmation but can't actually show you the prompt, so the call would just stall. For those, pass confirm: true in the tool arguments to authorize the action explicitly — the client confirms with you in its own UI first, then re-runs the tool with that flag. Your api:write access plus the audit log remain the security boundary either way.

If a deploy_policy call times out, the deployment may still have been queued. Check list_deployments (or get_deployment with the id from the response) before trying again — don't blindly re-deploy. If you do re-run the same deploy within 5 minutes, it's recognized as a retry and returns the original deployment instead of starting a duplicate. When a deploy ends in failed, fetch get_deployment_logs for the same id to read the build output and see what went wrong.

References

Overview — the endpoint and transport.
Connecting a client — mint a token and configure your client.
REST API reference — the underlying endpoints these tools call, callable directly with a token.
Personal access tokens
Getting started

What the client can do