Skip to content

Access readiness

Almost every failure people hit with this tool is an access problem, and the fixes are all different. A missing Connected App, an expired token, an environment in another business group, and a scope you were never granted all produce "it does not work" — but only one of them is fixed by logging in again.

These are the six states, named the same way the mule-skills workflows name them, so a human reading this page and an agent following that gate describe the same situation with the same words.

The states

State What you see Fix
Ready whoami returns an identity, and the environment you want appears in list_environments Nothing. Proceed
Not configured Anypoint Connect is not configured (profile: "…"), with the config init command echoed Run anc config init, or export ANYPOINT_CLIENT_ID and ANYPOINT_CLIENT_SECRET. There is nothing to log in to yet
Not authenticated Not authenticated. Run: anc auth login, or a token that expired with no refresh token, or a refresh that failed anc auth login, then anc auth status
Environment not visible Environment "X" not found. Available: … The name is misspelled, or you are authenticated against a different organization or business group. Check anc config show and the available list before assuming a permission problem
Not permitted A 403, or an operation refused despite valid authentication The Connected App lacks that scope, or the subscription lacks the feature. Grant the scope in Access Management, or use get_entitlements to check whether the org has MQ or Object Store at all
Transient failure Timeout, rate limit, or a 5xx Retry once with a narrower window. Requests are rate-limited client-side, but the platform can still throttle

Confirming state before you work

Two cheap read-only calls establish everything, and they are the same ones the agent workflows use:

anc auth status
anc apps list --env Sandbox

From an MCP client, the equivalents are whoami and list_environments. whoami confirms authentication and returns the organization context other calls need; list_environments confirms the target environment is actually visible to that identity.

Never use a data call as the readiness check. An empty log result cannot distinguish "no errors in the window" from "not authenticated", and a permission error on one narrow query says nothing about the rest of the environment.

Not configured versus not authenticated

These are the two most often confused, and the error text distinguishes them deliberately:

  • Not configured means no Client ID and Secret are resolvable for the active profile. The tool has no idea who you are and no way to ask. Nothing to refresh.
  • Not authenticated means credentials exist but there is no usable token. A browser login fixes it.

Telling someone to log in when they never created a Connected App wastes the exchange, which is why the messages differ.

Entitlements are not permissions

get_entitlements reports what the organization's subscription includes — vCores, Anypoint MQ, Object Store, API quotas. A capability the subscription does not include cannot be granted by a scope. Check entitlements before concluding that a queue or Object Store tool is broken; a 403 on an unprovisioned service is the platform being correct.

For agents

If you are driving this server from an agent, gate on readiness before the first call rather than reacting to a mid-workflow failure. The mule-skills readiness reference defines that gate, including what to offer a user when access is missing and how to label evidence they supply by hand instead.

Two rules worth repeating here:

  • Never run config init, auth login, auth logout, or a profile switch without explicit approval. They change machine-local state. Print the command instead.
  • Never report the organization name, organization identifier, user name, email, or profile identifier. Say "the authorized environment" and name the environment only as the user named it.