MuleSoft Platform MCP Server

Use this tool to add one or more existing platform users to an Anypoint Team. Write operation (idempotent — re-adding a member is a no-op). user_ids are platform user IDs, NOT emails — resolve emails to IDs with find_user_by_email first. membership_type is 'member' (default) or 'maintainer' and applies to every user in the call. Returns a per-user outcome so a partial failure reports which ids succeeded. Use for prompts like 'add these users to the Payments team', 'make user X a maintainer of team Y'. Example: add_members_to_team(team_id=<team_id>, user_ids=[<user_id>]).

Server-side rollup that absorbs the agent→model loop. Picks the top-N agents by request volume (`fetch_monitoring_drill_down(entity_type='agents')), calls view_agent_details per agent (capped at top_n, default 10, hard cap 20), aggregates their model configurations and returns a comparison. Use this for: 'which models are used the most across agents?', 'which models are underutilized or unused?', 'which agents use which LLM?'. Args: organization_id (required), top_n (default 10), agents (optional list of agent ids — if supplied, skips the top-N discovery and just walks these). Returns: {summary, agents: [{agent_id, name, model: {...}, model_id, model_provider}], model_distribution: {model_id: count}, errors: [...]}`.

Apply the selected policy to a SINGLE target asset instance using the provided configuration data. This is the tool for a provider-NATIVE policy (a Kong plugin name or an Apigee template ID, as selected via prepare_policy_creation) — those are NOT canonical templates and can only be applied one instance at a time, so loop this tool per instance if a native policy targets several. It is also the right choice for a single MuleSoft/Anypoint instance when you need fine per-instance control (order, pointcut, disabled). ONLY for a CANONICAL (Universal) policy — one returned by 'list_universal_policies' — that must be applied to MORE THAN ONE API instance at once, or across instances spanning different providers (mulesoft/anypoint, kong, apigee, azure, aws), prefer 'apply_universal_policy' instead: it fans the canonical template out across every instance in one call and creates the native policy on each provider's control plane. Do NOT route a native plugin/template id to 'apply_universal_policy' — it only accepts canonical template names. For a non-MuleSoft external gateway (provider='kong'/'apigee'/'azure'), set provider and pass the numeric api_instance_id plus the template's Exchange coordinates via asset (group_id + asset_id + asset_version, from get_policy_template_form) — the policy is applied through the Anypoint API Manager Universal API (gateway_id is not used on this path). injection_point is optional; omit it to let APIM default it from the template. This routing is gated per organization; a closed gate returns a structured error.

Apply a Universal (canonical) policy to one or more API instances across any provider in one call — each instance gets a native policy created on its own provider's control plane. This is the REQUIRED path whenever the policy targets MORE THAN ONE API instance (e.g. 'apply CORS to these 3 APIs') or the instances span different providers (mulesoft/anypoint, kong, apigee, azure, aws): pass every instance id in one call rather than looping 'apply_policy_to_instance'. No environment id is needed or accepted (non-MuleSoft instances have none). Only for a SINGLE MuleSoft/Anypoint instance that needs finer per-instance control (order, pointcut, disabled) should you prefer 'apply_policy_to_instance' instead.

Fetch applied + automated policies for up to N instances of a given API in one call, aggregate them, and return a per-instance + cross-instance summary. Replaces the agent-driven pattern of looping `view_api_instance_policies per instance — that loop burst the rate-limited Anypoint policy endpoint into 502s (W-22750961 #34, 18 calls all failed). Sampling order: production env first, then sandbox, then design, then any remaining environments. Stops sampling on the first 5xx and reports what it captured. Use this for: 'what gaps exist in policy coverage across instances?', 'compare policy coverage between production and staging', 'which instances are missing rate limiting?', 'audit policies for this API'. Args: organization_id (active BG), asset_id (the API's asset id), max_instances (default 3, max 8). Returns: {summary, instances: [{instance_id, environment_name, policy_count, applied: [...], automated: [...]}], comparison: {policy_names_in_all, policy_names_missing_anywhere}, errors: [{instance_id, error}]}`. Example: audit_api_policies(organization_id=<bg>, asset_id=<api>).

Preview APIs matched by a control scope filter.

Convert the selected policy application payload to JSON-LD and print it in backend logs.

Verify whether a SINGLE named secret exists and return its non-sensitive metadata (name, type, expiration, last-modified) — never the secret value. USE THIS for 'does secret X exist?'. Provide secret_name alone and it reports which group(s) the secret lives in; add secret_group_name ONLY when the user explicitly names a group; or pass secret_group_id + secret_id UUIDs. A secret name may contain '/' (e.g. 'byov-test/api-key') — pass it whole as secret_name; never split it into group/secret on a slash. Use list_secret_refs to enumerate everything, or search_secrets for partial-name matches across groups.

Run `find_assets (facets mode) against each of the supplied business-group ids and return a side-by-side comparison (totalHits + byType breakdown per BG). Use this for 'compare service maturity between business units', 'which BG has the most APIs?', 'breakdown by BG'. The agent should call list_business_groups first to discover the ids; this tool fans out at most max_groups (default 3, hard cap 8) of them. Returns: {groups: [{business_group_id, total_hits, byType: {...}}], cross_group: {leader_by_total, type_distribution_diff}}`. Example: compare_business_groups(business_group_ids=['<bg1>', '<bg2>', '<bg3>']).

Create a new automated-policy governance strategy from wizard inputs.

Use this tool to create a new Anypoint business group (a sub-organization) under a parent. Write operation. Creates a CHILD of parent_organization_id (the session org by default) — the org's true root is the pre-existing master org, which this does not create. The new business group has NO resource quota (zero vCores etc.); grant quota and permissions in the Anypoint UI afterward. The owner is always the authenticated caller (not selectable). Use for prompts like 'create a business group called Payments', 'add a child org under X'. Example: create_business_group(name=Payments).

Use this tool to create an Anypoint connected app with a client_credentials grant — a machine / CI-CD credential that mints Anypoint access tokens from a client id + client secret. Write operation. For security the generated client secret is NOT returned (it would land in the transcript); the result gives the client id and a deep link to the Connected Apps page where the owner copies the secret and assigns scopes. The app is created UNSCOPED — grant business-group / environment access there (or via a follow-up tool) before it can be used. Resolves the org from the session when organization_id is omitted. Use for prompts like 'create a connected app for our CI pipeline', 'set up a machine credential to deploy from GitHub Actions'. Example: create_connected_app(name=CI/CD deploy).

Create a new control strategy from wizard inputs.

Use this tool to create a new Anypoint environment (sandbox or production) in a business group. Write operation. environment_type must be 'sandbox' or 'production'. Resolves the org from the session when organization_id is omitted. Use for prompts like 'create a sandbox environment called QA', 'add a production environment to org X'. Example: create_environment(name=QA, environment_type=sandbox).

Create and deploy a Model Proxy (LLM proxy) in Anypoint: creates the Exchange asset then deploys via API Manager. This is the chat equivalent of the two-step 'Create a Model Proxy' wizard, and the fields map 1:1 onto it.
Step 1 'Configure Gateway' — where the proxy is hosted: name (required), base_path (required), port (required, default 8081), and target_id (required). Copy target_id from the exact id field of a deployable row returned by list_model_proxy_gateway_targets. A gateway target name is never a valid target_id; when only the name is known, call that lookup, match the row by name, and pass its id. The server reads that row's authoritative name and inserts targetName into the deployment payload. description is optional. Resolve environment_id with list_omni_gateway_environments, then the gateway target with list_model_proxy_gateway_targets — do not ask the user for raw IDs, and do not source the target from list_omni_gateway_targets (different service, ids the deploy call rejects).
Step 2 'Configure Routing Strategy' — where traffic goes. Two modes, matching the wizard. routing_strategy is required: the user must explicitly choose model-based or semantic after Step 1; never omit, default, or infer this field. model-based needs one or more typed routes entries with provider + model + upstream_url + that provider's wizard extras (authFields / configFields from list_model_proxy_providers). Call list_model_proxy_providers first (omit provider) and pick provider/model from that wizard catalog (bare models[].value). semantic needs a semantic_service_config_id from list_model_proxy_semantic_routing and that row's topicMode. advanced / select: each route's prompt_topic_ids from that service's topics. basic / create: each route's prompt_topic {name, utterances} (created on the fly, same POST as the UI modal) — an empty topics list is not a blocker. Also collect the rest of that wizard step from wizardFields: fallback card (fallback_threshold default 0.5, fallback_route, fallback_model), prompt guard (deny_topic_ids_json or deny_topics_json {name, utterances}), and optional semantic cache (semantic_cache_config_id). Optional: input_format.
The Omni Gateway target is NOT an LLM provider or upstream URL — upstreams belong in routes. For every new route, first ask the user to choose Dynamic or From Vault; set credential_source to dataweave or from_vault from that explicit choice. Dynamic uses api_key_selector, or both AWS selector fields for Bedrock. From Vault requires list_model_proxy_vault_secret_groups then list_model_proxy_vault_secrets; show names, retain ids internally, and put the selected ids in the matching typed *_vault_ref field. Never construct or accept a URN. The backend constructs key_mode, selectors, and vault keys. Literal API/AWS keys are rejected. There are no tag or runtime-constraint fields; do not ask for any field not listed here.
Never construct a route from this description, provider defaults, lookup output, prior proxies, or reasonable guesses. A lookup result only supplies choices; it does not authorize choosing one. The gateway target, routing strategy, and every route's provider, model, upstream URL, credential source and source-specific fields, and optional settings must be explicitly confirmed by the user. If any required choice is missing, ask for it and do not call create_model_proxy.

Create a Model Wallet in an Anypoint organization + environment. A Model Wallet scopes a caller (required_claims) to LLM Proxies and carries token/spend budgets. The wallet is scoped to ALL proxies automatically (there is no proxy picker yet), so proxy scope is not a parameter. environment_id is OPTIONAL: omit it to auto-select the environment the create UI would use (a production environment if the org has one, else the first available; design-time environments are ignored), so you need not know the env id. Pass an explicit environment_id only to override that default. required_claims is REQUIRED and must contain at least one 'claim:value' string using a COLON separator (NOT '='), e.g. 'group:managers' or 'iss:https://login.example.com'; each claim must include a value (the upstream rejects a claim with no value). budgets is REQUIRED — a wallet with no budget is unbounded and will be rejected; provide at least one budget, each with provider, metric (spend|tokens), period (daily|weekly|monthly), and limit. model is OPTIONAL: omit it for a provider-wide ('Any model') budget that caps every model under the provider (the usual case for a token budget), or pass a bare model id (e.g. 'claude-fable-5', no provider prefix) to cap one model. A 'spend' budget is only allowed with a concrete model that has a price configured in the Models catalog (an 'Any model' spend cap isn't priceable) — for an all-models cap use metric='tokens'. Example (provider-wide token cap, env auto-selected): create_model_wallet(organization_id=<org_id>, name='Team A', required_claims=['group:managers'], budgets=[{'provider':'anthropic','metric':'tokens','period':'monthly','limit':100000}]). Add 'model':'claude-fable-5' to that budget to cap a single model instead.

Launch the managed Omni Gateway creation wizard for the active MuleSoft provider. When fully configured, creates the gateway in Anypoint Platform.

Create a new agent scanner. Internally validates connectivity before persisting the configuration. Parameters: provider (targetSystemType), platform (specific platform within a provider group, e.g. 'bedrock-agents'), schedule with unit (day/week/month) and at (0-23 UTC hour). Returns the created scanner details including scannerId on success, or a connection_failed status if credentials are invalid. Call WITHOUT name/provider to display the interactive wizard.

Use this tool to create a new Anypoint Team (the platform identity construct — NOT the Microsoft Teams messaging channel). Write operation. parent_team_id is REQUIRED: to create a top-level team, first call list_teams to find the root team (the one with no parent) and pass its team_id. team_type is 'internal' (default), 'external', 'private', 'shared', or 'legacy'. Use for prompts like 'create a team called Payments under the root team', 'add a private team X'. Example: create_team(team_name=Payments, parent_team_id=<root_team_id>).

Delete one automated-policy governance strategy by strategy ID.

Delete one governance strategy by strategy id.

Delete one Model Wallet by id in an Anypoint organization + environment. Destructive and irreversible. version is REQUIRED: read the wallet's current version with fetch_model_wallet_details and pass it — it is sent as the upstream optimistic-concurrency If-Match header, and a missing version is rejected (there is no force-delete path). environment_id is OPTIONAL: omit it to auto-select the environment the UI would use (a production environment if the org has one, else the first available; design-time environments are ignored). When acting on a wallet from fetch_model_wallets, pass that wallet's environmentId — a wallet can live in ANY environment, and auto-select resolves only one, so a delete could target the wrong environment or not find the wallet. Example (env from the fetch_model_wallets row): delete_model_wallet(organization_id=<org_id>, model_wallet_id=<id>, environment_id=<env_id>, version=<n>).

Answer 'what do I need to connect/onboard this vault?' in up to three steps. (1) No arguments: list every supported provider. (2) provider ONLY (e.g. 'azure_key_vault'): list the auth methods that provider supports so the user can choose one — use this for 'create an azure vault integration' before asking for any fields. (3) provider + auth_method: get the COMPLETE onboarding checklist — always-required inputs (name, provider, auth_method, vault_url), required/optional raw_secrets and connection_config fields, and optional inputs (description, sync_interval_minutes). Common provider phrasings are accepted (e.g. 'aws', 'aws secret manager'). Use before onboard_vault so you know exactly what to collect, and before edit_integration to see valid attributes.

Edit the configuration of an already-applied native policy on an external gateway instance (Kong / Apigee / Azure) via the Anypoint API Manager Universal API. The numeric api_instance_id identifies the instance on this path (no environment_id or gateway_id is needed). Pass provider, api_instance_id, the policy_id and the policy's Exchange coordinates (asset: group_id / asset_id / asset_version) from view_api_instance_policies, plus the new configuration_data. configuration_data REPLACES the existing configuration wholesale — send the full merged object, not a delta: read the current configurationData from view_api_instance_policies immediately before and merge your change into it, or the keys you omit are dropped. A policy whose readOnly flag is true cannot be edited. Writes are asynchronous (accepted with HTTP 202); poll list_instance_policy_operations for the terminal COMPLETED / FAILED state. This routing is gated per organization; a closed gate returns a structured error.

Modify an existing vault integration's configuration. The current optimistic-lock version is read automatically by describing the integration first (callers do NOT supply a version). Provider, auth method, name and vault URL are immutable. For managed integrations the editable attributes are description, raw_secrets and connection_config; for reference-based integrations they are description, sync_enabled and credential_refs. Supplying an attribute that is not valid for the integration type is rejected with the list of valid attributes. Edited managed credentials are validated against the auth schema and connection-tested before saving; the save is ABORTED unless the vault is reachable AND the credential grants all required permissions (list, describe, get-value). If a reachable vault is missing permissions the edit is refused and 'missingPermissions' in the response says which to grant.

Edit an existing Model Wallet by id in an Anypoint organization + environment. Partial update: pass only the fields to change — an omitted field is left as-is upstream (a rename can send just name). required_claims are flat 'claim' or 'claim:value' strings; each budget needs provider, metric (spend|tokens), period (daily|weekly|monthly), and limit. model is OPTIONAL: omit it for a provider-wide ('Any model') budget that caps every model under the provider (the usual case for a token budget), or pass a bare model id (e.g. 'claude-fable-5', no provider prefix) to cap one model. A 'spend' budget requires a concrete model that has a price configured in the Models catalog (an 'Any model' spend cap isn't priceable) — for an all-models cap use metric='tokens'. version is REQUIRED: read the wallet's current version with fetch_model_wallet_details and pass it — it is sent as the upstream optimistic-concurrency If-Match header, and a missing version is rejected so an edit can't clobber a concurrent change. environment_id is OPTIONAL: omit it to auto-select the environment the UI would use (a production environment if the org has one, else the first available; design-time environments are ignored). When acting on a wallet from fetch_model_wallets, pass that wallet's environmentId — a wallet can live in ANY environment, and auto-select resolves only one, so an edit could target the wrong environment or not find the wallet. Example (env from the fetch_model_wallets row): edit_model_wallet(organization_id=<org_id>, model_wallet_id=<id>, environment_id=<env_id>, version=<n>, name='Renamed').

Fetch one policy template's full configuration schema. Pass either `template_id (legacy) or (group_id, asset_id, asset_version)`.

Use this tool to get org-wide managed LLM usage for the Budget dashboard: totalSpend plus by-provider and by-wallet breakdowns. ALWAYS read displayUnit before quoting amounts: 'dollars' means the LLM-proxy Model Library has at least one priced model (idle priced models still show dollars, which may be $0); 'tokens' is total tokens because no catalog model has a Model Library rate — never call token totals dollars. When displayUnit is dollars, also read excludedUnpricedModelCount and excludedTokens: if count > 0 those tokens are not in the dollar total (catalog-unpriced usage) and must not be quoted as full spend. Unattributed proxy spend (no wallet id) is omitted from by-wallet only; totalSpend and byProvider include it. Answers questions like 'how much are we spending on LLMs?', 'which provider costs the most?', 'top spending wallets?'. When Budget Management is not enabled for the org, the tool returns a non-error 'not enabled' empty-state — do NOT report that as $0 spend. When the spend source is unreachable, degraded=true and the summary says unavailable — also not $0. Supports time_range values: 1h, 6h, 24h, 7d, 30d (default 7d). Pass environment_id (Anypoint environment UUID) when known so by-key labels resolve to wallet names and catalog rates can price dollars. Omit rather than inventing one; missing env leaves raw wallet ids and returns tokens (not dollars) without degraded. organization_id is accepted only as an alias or a business group the Bearer belongs to, never as the authorization decision. Example: fetch_budget_usage(organization_id=<org_id>, time_range='7d', environment_id=<env_id>). For per-agent dollar spend, use fetch_cost_instances(category='agent'). For per-instance MCP token usage, use fetch_cost_instances. For org-wide MCP token KPIs (not Budgets), use fetch_cost_overview.

Fetch a control ruleset payload by sourceRulesetKey.

Use this tool to chart a single instance over time. category selects the scope (defaults to 'mcp'). category='mcp': an MCP server instance — instance_id is the API Manager instance id; buckets carry totalTokens, tokenDelta, and avgResponseTimeMs. category='agent': a single AGENT (LLM proxy) — instance_id is the agent's id (agentId / llmProxyId from fetch_cost_instances(category='agent')); buckets carry the agent's LLM-proxy token counts and avgResponseTimeMs. The agent series is token-denominated — it carries NO per-bucket dollars (for agent dollar spend/savings totals use fetch_cost_instances(category='agent')). This is the only tool that returns an agent timeseries — fetch_cost_instances(category='agent') gives the agent table but no per-agent chart. Always pass a real instance_id from fetch_cost_instances (mcp or agent scope); never invent one. Supports time_range values: 1h, 6h, 24h, 7d, 30d. Example (mcp): fetch_cost_instance_timeseries(organization_id=<org_id>, instance_id=<instance_id>, time_range='7d'). Example (agent): fetch_cost_instance_timeseries(organization_id=<org_id>, instance_id=<agentId>, time_range='7d', category='agent'). For the org-wide overview, use fetch_cost_overview instead.

Use this tool to get per-instance usage. category selects the scope (defaults to 'mcp'). category='mcp': per-MCP-server-instance token usage with optimization coverage. Each instance includes totalTokens, tokenDelta (tokens saved), avgResponseTimeMs, toolsListTokens, toolsCallTokens, environmentId, organizationId, appliedPolicies, appliedCostPolicyIds, unappliedCostPolicyIds, and optimizationCoverage (0-1). Response also includes a policyTemplates lookup (templateId -> name, description). Use filter_unoptimized=true to find instances with unapplied cost policies. Use sort_by to change ordering (totalTokens, tokenDelta, avgResponseTimeMs, totalCalls, tokensPerCall). To optimize a specific instance, use the unappliedCostPolicyIds list with prepare_policy_creation(asset_id=<assetId>, policy_name_hint=<policy_id>). category='agent': per-agent LLM-proxy spend and savings in DOLLARS (not token estimates). Each agent includes agentId, agentName, managedType (managed if connected to an LLM proxy, else unmanaged), llmProxyId, spend (cost $), saved / potentialSavings ($), and a usage block (totalTokens, totalCalls, tokensPerCall, avgResponseTimeMs). Dollar figures depend on cost data being available for the org (response carries costDataAvailable); when false, spend/saved are zeroed placeholders, NOT real dollars — do NOT report that $0 as real spend, tell the user to Configure Costs. potentialSavings is always 0.0 (no per-agent rate source). sort_by / filter_unoptimized do not apply to the agent scope. Answers 'how much are my agents spending?', 'which agents saved the most?'. Supports time_range values: 1h, 6h, 24h, 7d, 30d. Use top_n to limit results (default 10, max 50). Example (mcp): fetch_cost_instances(organization_id=<org_id>, time_range='30d', filter_unoptimized=true). Example (agent): fetch_cost_instances(organization_id=<org_id>, time_range='30d', category='agent').

Use this tool to get a ranked list of instances that should be optimized, mirroring the 'Recommended Optimizations' card on the Cost Management page. Filters to active instances (usage in window) that have at least one unapplied cost policy, projects token savings from Exchange tool metadata using the same rate analyzers as the UI, and returns the top N by projected savings. Each recommendation includes instanceId, instanceName, serverName, assetId, environment, totalTokens, projectedTokensSaved, projectedSavingsPercent, unappliedCostPolicyIds, and perPolicyProjections (policyId, policyName, rate 0-1, tokensSaved). category='mcp' (default) ranks MCP-server instances. category='agent' scopes to agents / LLM proxies, but agent optimization needs an upstream per-proxy cost-policy/rate source that is not yet emitted (W-23371138): it returns an empty list today (no fabricated agent savings) and lights up automatically once that source lands. Do NOT invent agent recommendations. Supports time_range values: 1h, 6h, 24h, 7d, 30d. top_n defaults to 3, max 10. Answers questions like 'what should I optimize next?', 'biggest token savings opportunities?', 'where is the most waste?'. Follow up with prepare_policy_creation(asset_id=<assetId>, policy_name_hint=<policyId>) to apply a policy. Example: fetch_cost_optimization_recommendations(organization_id=<org_id>, time_range='30d', top_n=3).

Use this tool for the org-wide cost summary: MCP-server token KPIs (total tokens, saved tokens from optimization policies, total tool calls) PLUS org-wide agent dollar cards (totalManagedSpend, agentAmountSaved). The dollar cards are populated only when cost data is available for the org (costDataAvailable=true); when false they are absent — do NOT report $0 as real spend. agentPotentialSavings is always 0.0 (no per-agent rate source) and is not a spend figure. Optionally includes token usage timeseries. Supports time_range values: 1h, 6h, 24h, 7d, 30d. Use include_timeseries=true for chart data (increases response size). Example: fetch_cost_overview(organization_id=<org_id>, time_range='30d'). For a per-MCP-instance token breakdown, use fetch_cost_instances. For per-agent dollar spend/savings, use fetch_cost_instances(category='agent').

Use this tool to get detailed governance conformance data for a single service. Returns the service summary, per-ruleset details with violation/warning counts, rule-level messages, and instance-level policy conformance when available. Use this after fetch_governance_services to drill into one service, or when the user asks about a specific service's governance status. Example: fetch_governance_service_report(organization_id=<organization_id>, service_id=<service_id>). Example: fetch_governance_service_report(organization_id=<organization_id>, service_id=<service_id>, api_version=<version>, include_rule_messages=true).

Use this tool to search, filter, and count governance conformance across services. Returns lightweight rows with conformance status, concern-area breakdowns, error/warning/info counts, and violated rulesets for each matched service. Supports filtering by conformance status, concern area, ruleset, provider, service type, severity thresholds, and text query. Returns aggregate totals alongside paged results. Canonical conformance values: compliant, non-compliant, pending. Concern area IDs include: security-privacy, consumption-economic-governance, structural-conformity-lifecycle. Canonical provider values: mulesoft, kong, apigee, aws, azure. Example: fetch_governance_services(organization_id=<organization_id>, conformance_status_in=[<status>]). Example: fetch_governance_services(organization_id=<organization_id>, provider_in=[<provider>], limit=<n>). For detailed drill-down into one service, use fetch_governance_service_report instead. IMPORTANT: The totals object already contains aggregate counts for all matched services (statusTotals, concernTotals, providerTotals, messageTotals). providerTotals breaks down services per provider with compliant/non-compliant/pending counts. Do NOT paginate through all pages to count services yourself — use the totals. Synthesize your answer from the first page of results plus the totals. Only call again with different filters if the first result set doesn't match the user's question.

Get one Model Wallet by id in an Anypoint organization + environment. Returns modelWalletId, name, clientId, requiredClaims, budgets (each with model, metric, period, and limit), and version. environment_id is OPTIONAL: omit it to auto-select the environment the UI would use (a production environment if the org has one, else the first available; design-time environments are ignored). When acting on a wallet from fetch_model_wallets, pass that wallet's environmentId — a wallet can live in ANY environment, and auto-select resolves only one, so it may not find the wallet. Read-only. Example (env from the fetch_model_wallets row): fetch_model_wallet_details(organization_id=<org_id>, model_wallet_id=<id>, environment_id=<env_id>). For the full list, use fetch_model_wallets.

List the Model Wallets in an Anypoint organization, across EVERY environment in the org. A Model Wallet scopes a caller (clientId + requiredClaims) to a set of LLM Proxies and carries its token/spend budgets. This tool takes NO environment parameter — it always spans all environments and each returned wallet carries the environmentId (and environmentName) it lives in. To answer about a single environment, filter the returned wallets by their environmentId; do NOT assume the session's active environment is the only one. Each returned wallet includes modelWalletId, name, clientId, requiredClaims, budgets, version, and environmentId. Pass an optional 'search' substring to filter by name or clientId (case-insensitive), the same as the catalog page's search box; omit it to list all. Read-only. Example: fetch_model_wallets(organization_id=<org_id>). Example (name filter): fetch_model_wallets(organization_id=<org_id>, search='team a'). For one wallet's full detail, use fetch_model_wallet_details (pass the wallet's environmentId from these results).

Use this tool to rank services or instances contributing to a specific performance metric (availability, reliability, avgLatency, requestVolume, errorRate, policyViolations, taskResolution, qualityScore, latencyMs, agentMethod, failureReason). Powers the Performance view's drill-down drawer and answers questions like "which services are driving errors?", "rank instances by latency", or "which agents have the highest quality score / most resolved tasks?". The taskResolution and qualityScore metrics surface agent quality: taskResolution ranks by resolved-task volume, and qualityScore ranks by the task-count-weighted mean quality score. The latencyMs metric ranks by agent-execution latency (the mulesoft.agent.latency.ms signal, request-weighted at the service level) distinct from avgLatency's gateway p99. The agentMethod and failureReason metrics rank by total event count and each row carries a category breakdown array (agentMethodBreakdown / failureReasonBreakdown, each entry {label, count} sorted count-descending): agentMethod breaks down invocations by mulesoft.agent.method, failureReason breaks down failures by mulesoft.agent.failure.reason. Filter by entity_type (apis/agents/mcp-servers/llms), service_id (narrow to one service's instances), instance_id (single instance), environments list, or providers list. Free-text search matches service/instance/environment names. Returns MetricContributorRow[] plus pagination metadata (totalRows, offset, pageSize). Example: fetch_monitoring_drill_down(metric='errorRate', time_range='24h'). Example: fetch_monitoring_drill_down(metric='avgLatency', entity_type='apis', sort_dir='desc'). Example: fetch_monitoring_drill_down(metric='qualityScore', entity_type='agents', sort_dir='desc'). Example: fetch_monitoring_drill_down(metric='latencyMs', entity_type='agents', sort_dir='desc'). Example: fetch_monitoring_drill_down(metric='agentMethod', entity_type='agents'). Example: fetch_monitoring_drill_down(metric='failureReason', entity_type='agents').

Use this tool to get monitoring data for a single API instance: time-series charts (requests, error rate, latency, policy violations), top endpoints by traffic, and top clients by traffic. Requires organization_id, asset_id, and ideally instance_id. If instance_id is omitted, the first available instance is selected. Supports time_range values: 1h, 6h, 24h, 7d, 30d. Supports environment values: production, sandbox, unknown. Only MuleSoft-managed instances have monitoring data. Example: fetch_monitoring_instance(organization_id=<organization_id>, asset_id=<asset_id>, instance_id=<instance_id>, time_range=<time_range>, environment=<environment>). Example: fetch_monitoring_instance(organization_id=<organization_id>, asset_id=<asset_id>). For org-wide health overview, use fetch_monitoring_overview instead.

Use this tool to get an org-wide monitoring health snapshot: total requests, error rate, average latency, availability, reliability, and compact trend charts. Returns KPI summary plus time-series data for request volume, error rate, average latency, and error volume over the selected time range and environment. Supports time_range values: 1h, 6h, 24h, 7d, 30d. Supports environment values: production, sandbox, unknown. Supports provider filter: currently only 'mulesoft' returns monitoring data. Other providers (kong, apigee, aws, azure) will return empty results. Canonical provider values: mulesoft, kong, apigee, aws, azure. Example: fetch_monitoring_overview(organization_id=<organization_id>, time_range=<time_range>, environment=<environment>). Example: fetch_monitoring_overview(organization_id=<organization_id>, time_range=<time_range>, environment=<environment>, provider=<provider>). For instance-level monitoring drill-down, use fetch_monitoring_instance instead.

Return the full ruleset payload for one source_ruleset_key (rules, severities, source asset id/version, profile name). Pair with search_repository_knowledge: each match's metadata.rulesetKey is the argument to pass back here. Use when the user asks for 'full ruleset details', 'list every rule in <ruleset>', or 'what does the X ruleset check'.

Use this tool when you need aggregate counts/buckets for summaries, dashboards, or filter panels, not full service-row hydration. Prefer this tool over fetch_services when the user asks 'how many', 'breakdown by type/status/provider', or other distribution insights. Fetches facet aggregates for exactly one required business_group_id. Supports either text query (q) OR typed filtering/aggregates; when q is provided, do not send filters or aggregates. Canonical typed values are api classifiers (rest-api, http-api, graphql, soap-api, grpc-api, evented-api) plus agent and mcp, and common aliases are normalized before filtering. Canonical provider values include: mulesoft, kong, apigee, aws, azure, openai, anthropic, aws-bedrock, google-vertex, agentforce, microsoft-copilot, godaddy-ans, langsmith, mistral, meta. filters MUST be a JSON object, never a Lucene-style string. Supported filter fields: providerIn (list of canonical provider strings), statusIn, apiCategoryIn, environmentTypeIn, complianceStatusIn, tagsIn (list of exact Exchange tags, ANDed with the other filters), hasInstances (bool), hasActiveInstance (bool). Example (typed facets): fetch_service_facets(business_group_id=<business_group_id>, asset_types=[<asset_type>, ...], aggregates={'totalHits': True, 'byType': True, 'byProvider': True}). Example (query facets): fetch_service_facets(business_group_id=<business_group_id>, q=<search_query>). Returns structured payload with aggregates, total, and query context metadata. If the user then asks for specific assets, follow with fetch_services.

Use this tool when you need concrete service rows (for example asset IDs/names, detail selection, or navigation affordances). Prefer this tool over fetch_service_facets when the user asks 'which assets' or requests item-level results. Fetches lightweight services for exactly one required business_group_id. Searches the user's business group AND the MuleSoft public catalog overlay for agent / mcp / llm asset types — public providers like GoDaddy ANS, Salesforce Agentforce, LangSmith, Microsoft Copilot, OpenAI, Anthropic, AWS Bedrock surface here. API asset types (rest-api, http-api, graphql, soap-api, grpc-api, evented-api) are user-org-only by design — the public overlay carries no API rows, so APIs are not affected. Supports either text query (q) OR typed filtering/aggregates; when q is provided, do not send filters or aggregates. Canonical typed values are api classifiers (rest-api, http-api, graphql, soap-api, grpc-api, evented-api) plus agent and mcp. The tool normalizes common aliases/plurals (for example api/apis, rest, openapi, asyncapi, agents, mcp-servers) to canonical values before filtering. Returns structured payload with services, assets (alias), total, and optional aggregates. Service rows include a provider field. Canonical provider values include: mulesoft, kong, apigee, aws, azure, openai, anthropic, aws-bedrock, google-vertex, agentforce, microsoft-copilot, godaddy-ans, langsmith, mistral, meta. If you only need counts/buckets (no row hydration), use fetch_service_facets instead. filters MUST be a JSON object, never a Lucene-style string. Supported filter fields: providerIn (list of canonical provider strings), statusIn, apiCategoryIn, environmentTypeIn, complianceStatusIn, tagsIn (list of exact Exchange tags, ANDed with the other filters — use this to scope to tagged assets, e.g. finance), hasInstances (bool), hasActiveInstance (bool). Example (typed rows): fetch_services(business_group_id=<business_group_id>, asset_types=[<asset_type>, ...], size=<n>). Example (provider-filtered): fetch_services(business_group_id=<business_group_id>, asset_types=['agent'], filters={'providerIn': ['godaddy-ans']}, size=50). Example (tag-filtered): fetch_services(business_group_id=<business_group_id>, filters={'tagsIn': ['finance']}, size=50). Example (text search): fetch_services(business_group_id=<business_group_id>, q=<search_query>, size=<n>). Service rows include affordances and links for downstream navigation/actions. IMPORTANT: Do NOT paginate through all results by calling this tool multiple times with different offsets. Use the first page of results to synthesize your answer. Only call again with different filters if the first result set is clearly irrelevant to the user's question.

🔍 Discover assets in your portfolio + the public catalog.

Use this tool for any of:
✓ 'find [thing]' / 'search for [thing]' / 'discover [thing]'
✓ 'do you have [thing]?' / 'is there a [thing]?'
✓ 'show me [thing]' / 'list [thing]' / 'what [things] exist?'
✓ Data catalog discovery ('show my data assets', 'find Informatica sources')
✓ '[type] for [capability]' (e.g. 'APIs for payments', 'agents for invoices')
✓ 'similar to [thing]' / 'alternatives to [thing]'
✓ Resolving a user-supplied display name or slug to an asset id
before navigating or fetching detail.

Internally runs semantic (concept / synonym) and lexical (literal slug /
short query / id-token) discovery in parallel and merges. One call covers
literal pastes ('pet-store-api'), partial names ('Pet Store'), single
tokens ('store'), and conceptual queries ('flight booking').

SEARCH DISCIPLINE (prefer one natural-language call):
Semantic + lexical search already handles slug / hyphen / spacing variants,
so a natural phrase like 'batch processing agent' already matches — slugging
the same intent into 'batch-processing' or 'batch processing' and re-calling
rarely surfaces anything new. Aim for ~3 calls at most, with at least one
using ASSET_TYPE="" (no filter). Empty results usually mean nothing matched;
slug/spacing rewrites of the same intent seldom help — though rephrasing for
a genuinely different angle (e.g. a broader or analytical query) is fine.

Returns userOrgAssets (your portfolio) + publicOrgAssets (MuleSoft public
catalog), each ranked by relevance.

USER_QUERY parameter (always pass it):
The user's verbatim, untrimmed message. Used only to tell a single named
lookup ('the NTO Recommendations API' → collapse the card to that asset)
from a set/category ('all finance APIs', 'APIs similar to Stripe' → keep
the whole set). Never sent to the search backend; pass even when you also
trim QUERY down to the key search terms.

ASSET_TYPE parameter (optional):
Leave empty ("") to search ALL types (recommended for discovery).
Pass when the user clearly names ONE kind:
'api' / 'apis' → expands to 'rest-api', 'http-api', 'graphql', 'soap-api', 'grpc-api', 'evented-api' (EXCLUDES 'mcp', 'agent', 'llm', 'model', 'vector-database', 'gateway')
'mcp', 'agent', 'llm' for those kinds
'data' for Informatica/CDGC data assets and catalog sources

APPLIED POLICIES (INCLUDE_APPLIED_POLICIES + POLICY_NAME_FILTER):
Set INCLUDE_APPLIED_POLICIES=true to answer 'which of my APIs have / are
missing policy X?' in ONE call. Each of your portfolio results then also
carries the policies currently APPLIED to its managed instances (MuleSoft
and external Kong/Apigee/Azure). Pass POLICY_NAME_FILTER='rate-limiting'
(name or substring) to report the found/missing split directly — do NOT
loop view_api_instance_policies over every hit. For the apply flow key on
policyCoverage ('all'/'partial'/'none'/'unknown') + instancesMissingPolicy
(the instances still lacking it), NOT hasPolicy alone: hasPolicy is
any-instance, so a partially-protected API reads True and would be skipped.
Off by default; the fan-out is bounded (top matched APIs, production-first
instances) and the meta block says what was capped.

DO NOT USE FOR:
✗ Performance metrics (use fetch_monitoring_*)
✗ Cost analysis (use fetch_cost_*)
✗ Governance findings / conformance reports (use fetch_governance_*) — but
for APPLIED policies across a set of APIs, use INCLUDE_APPLIED_POLICIES
above rather than calling view_api_instance_policies per asset.
✗ Applied policies for ONE already-known instance (use view_api_instance_policies)
✗ Already-selected asset details (use asset-specific tools)
✗ Typed catalog listings (use fetch_services)
✗ Catalog facets / aggregates (use fetch_service_facets)

Single `find_assets call with synonym expansion done server-side, so the agent doesn't loop across rephrasings. Use this when the user describes a capability and the literal phrasing might not match the asset's name (e.g. 'LLMs for code generation' → also search 'code completion', 'codegen'). Args: query (required), asset_type (optional: agent / rest-api / mcp / llm), max_synonyms (default 3, cap 6). Returns the standard find_assets envelope plus a query_attempts` list showing which synonyms were tried.

Use this tool to check whether a person is already a platform user in an organization, by their exact email address. Returns only users whose email matches exactly (case-insensitive) — an idempotency check before inviting someone. Resolves the org from the session when organization_id is omitted. Use for prompts like 'is jane@acme.com already a user?', 'find the user with email X', 'does this person already have access?'. Example: find_user_by_email(email=jane@acme.com).

Get instance-rooted Context Catalog lineage. Downstream supports Agent, MCP, and API roots; upstream supports MCP and API roots. If instance_id is omitted, returns deployed instance options with their owning asset versions so the user can choose; it never selects implicitly. Empty results use stable reasonCode values: ASSET_NOT_FOUND, ASSET_VERSION_NOT_FOUND, NO_INSTANCES, or LINEAGE_NOT_FOUND. Otherwise reuse the selected option's requestArguments exactly; they contain the matching instance_id and asset_version. Treat status and connections as authoritative: CONNECTS_TO is runtime evidence and ROUTES_TO is design-time evidence. Technical ASSET nodes, IMPLEMENTATION_OF edges, and RESOLVES_TO edges are omitted.

Get full metadata for a business group by its ID.

Show hierarchy, classifications, glossary terms, and the explicit PII state for ONE data asset or catalog source, never the full catalog — use find_assets(asset_type="data") first to list/find data sources. Returns source → database → schema → table → column structure, column classifications and glossary terms, aggregate governance summaries, and PII state.

Read an existing Model Proxy's FULL current configuration — not just the route list: also routingStrategy, semanticServiceConfigId, fallbackRoute/fallbackModel/fallbackThreshold, denyTopicIds, and semanticCacheConfigId. This is the ONLY tool that returns that full snapshot, and calling it is MANDATORY, in the SAME turn, immediately BEFORE every single update_model_proxy call — even if a snapshot from an earlier turn in this conversation looks current or you already called it once this session, re-fetch anyway. update_model_proxy REPLACES the whole route list AND every semantic field wholesale, so adding or editing one route without a fresh copy of the full current set silently drops the others (and their upstream_ids / prompt_topic_ids / semantic config). Prefer asset_id from list_llms and omit environment_id — the tool walks every env. Do NOT reuse the environment_id from a prior create (list_omni_gateway_environments); that 404s GET .../upstreams when the proxy lives elsewhere. Each route comes back with its upstream_ids, which update_model_proxy needs to update a route in place instead of recreating it. Credentials are never returned; an unchanged route keeps its stored key when you resend it. Semantic proxies also return routingStrategy, semanticServiceConfigId, fallbackRoute / fallbackModel / fallbackThreshold, denyTopicIds, and semanticCacheConfigId — resend those on update so they are not cleared.