--- title: MCP Servers description: MCP servers enabling AI assistants to manage resources and query observability data --- import Tabs from "@theme/Tabs"; import TabItem from "@theme/TabItem"; import CodeBlock from "@theme/CodeBlock"; import { versions } from "../_constants.mdx"; # MCP Servers OpenChoreo provides Model Context Protocol (MCP) servers that enable AI assistants to interact with your OpenChoreo platform. ## Overview OpenChoreo provides two MCP servers: 1. **Control Plane MCP Server** - Provides tools for managing OpenChoreo resources (namespaces, projects, components, builds, deployments, infrastructure) 2. **Observability Plane MCP Server** - Provides tools for accessing observability data (logs, metrics, traces, alerts, incidents, and FinOps cost insights) Each MCP server is independently accessible and requires separate configuration. ### Using Both MCP Servers Together :::tip Recommended Configuration For the best experience, configure **both** the Control Plane and Observability Plane MCP servers together. Observability tools accept resource names (namespace, project, component, environment) as parameters — use the Control Plane MCP server to list and discover these names, then pass them directly to Observability tools. **Example workflow:** 1. Use Control Plane MCP (`list_namespaces`, `list_projects`, `list_components`, `list_environments`) to discover resource names 2. Use those names with Observability Plane MCP tools (`query_component_logs`, `query_traces`, `query_http_metrics`, `query_alerts`) to fetch observability data ::: ## Available Tools ### Control Plane MCP Server The Control Plane MCP server is organized into seven toolsets. :::info Tools in multiple toolsets Some read-only tools (marked with †) appear in both the default developer toolsets and the PE toolset. This allows platform engineers to use the PE toolset alongside Namespace and Project toolsets without needing to enable all developer toolsets. :::
Namespace Toolset - `list_namespaces` — List all namespaces (top-level containers for organizing projects, components, and resources) - `create_namespace` — Create a new namespace - `list_secret_references` ‡ — List all secret references (credentials and sensitive configuration) for a namespace - `get_secret_reference` ‡ — Get a single secret reference's full spec (template, data sources, refresh interval, target plane). For sync status, query `get_resource_events` against the rendered ExternalSecret on the data plane ‡ Also registered on the PE toolset. Authoring secret references (`create_`, `update_`, `delete_secret_reference`) is PE-only — see the PE toolset below.
Project Toolset - `list_projects` — List all projects in a namespace (logical groupings of related components sharing deployment pipelines) - `create_project` — Create a new project in a namespace - `update_project` — Partially update a project (`display_name`, `description`, `deployment_pipeline`); only provided fields change - `delete_project` — Delete a project; cascades via finalizer to remove all components, workloads, releases, and bindings owned by the project
Component Toolset **Component Management** - `create_component` — Create a new component in a project - `list_components` — List all components in a project (deployable units with independent build and deployment lifecycles) - `get_component` — Get detailed component info including configuration, deployment status, and builds - `patch_component` — Partially update a component's configuration (display_name, description, autoDeploy, parameters, traits, workflow); pass an empty array for traits to clear all traits - `delete_component` — Delete a component; cascades via finalizer to its workloads, releases, and release bindings - `get_component_schema` — Get the JSON schema for a component's configuration options **Workload Management** - `list_workloads` — List workloads for a component (names, images, endpoint names) - `get_workload` — Get detailed workload info; returns the full Spec (round-trip-safe with `update_workload`) - `create_workload` — Create a new workload for a component (runtime spec: containers, resources, env vars). Set `release_line` to create the workload of one of the component's [release lines](../developer-guide/deploying-applications/release-lines.md) - `update_workload` — Update an existing workload's specification (container config, env vars, port mappings, resource limits) - `delete_workload` — Delete a workload; for reversible removal of just the deployment, use `update_release_binding` with `release_state: Undeploy` - `get_workload_schema` — Get the JSON schema for the workload specification **Release Lines** These tools work on the [release lines](../developer-guide/deploying-applications/release-lines.md) of a component. They need the `releaseline:view`, `releaseline:create`, `releaseline:update` and `releaseline:delete` permissions. - `list_release_lines` — List the lines of a component, `main` first, with each line's latest release and the environments it runs in - `get_release_line` — Get a release line, including the overrides it applies on top of the component and its status per environment - `create_release_line` — Create a release line, optionally overriding the component's parameters, traits, workflow parameters and auto deploy - `patch_release_line` — Partially update a release line's overrides. Omitted fields stay unchanged, and `reset` removes an override so the line inherits it from the component again - `delete_release_line` — Delete a release line. It is undeployed from every environment, and its releases and workload are removed **Platform Standards — Read-Only** These tools are namespace-scoped by default; pass `scope: "cluster"` to operate on the platform-wide cluster-scoped resource. - `list_component_types` † — List available component types in a namespace (WebApplication, Service, ScheduledTask, etc.) - `get_component_type` † — Get the full definition of a component type including its complete spec - `get_component_type_schema` † — Get the parameter schema for a component type - `list_traits` † — List available traits in a namespace (autoscaling, ingress, service mesh, etc.) - `get_trait` † — Get the full definition of a trait including its complete spec - `get_trait_schema` † — Get the parameter schema for a trait
Resource Toolset The Resource toolset mirrors the Component toolset for managed infrastructure: developers create Resources that reference platform-engineer-published ResourceTypes, and workloads consume the declared outputs via `dependencies.resources[]`. ResourceType writes, ResourceRelease management, and ResourceReleaseBinding CRUD live in the PE and Deployment toolsets respectively. **Resource Management** - `list_resources` — List all Resources in a project (managed-infrastructure dependencies like databases, queues, caches, object stores) - `get_resource` — Get a Resource's full spec including parameters, referenced (Cluster)ResourceType, latest cut release, and conditions - `create_resource` — Create a new Resource referencing a ResourceType or ClusterResourceType; the controller cuts the first ResourceRelease automatically - `update_resource` — Update a Resource's parameters (full replacement). `spec.owner` and `spec.type` are immutable - `delete_resource` — Delete a Resource; the two-phase finalizer blocks until all ResourceReleaseBindings are removed, then GCs owned ResourceReleases **Platform Standards — Read-Only, Namespace-Scoped** - `list_resource_types` † — List available ResourceTypes in a namespace (Postgres, Valkey, NATS, S3 buckets, Crossplane claims, etc.). Pass `scope: "cluster"` for ClusterResourceTypes - `get_resource_type` † — Get the full definition of a ResourceType including parameter schema, environmentConfigs schema, outputs, and rendered resources. Pass `scope: "cluster"` for a ClusterResourceType - `get_resource_type_schema` † — Get the parameter schema for a ResourceType. Pass `scope: "cluster"` for a ClusterResourceType
Deployment Toolset **Components** - `create_release_binding` — Create a new release binding to deploy a component to a specific environment. Set `release_line` to deploy one of the component's release lines - `list_release_bindings` — List release bindings associating releases with environments for a component - `get_release_binding` — Get detailed info for a specific release binding including state, overrides, and endpoints - `update_release_binding` — Update a release binding's configuration (release, release_state, overrides, traits, workload settings); set `release_state: Active` to deploy or `Undeploy` to remove from the data plane while keeping the binding - `delete_release_binding` — Delete a release binding entirely; for reversible removal that keeps the binding, use `update_release_binding` with `release_state: Undeploy` instead - `delete_component_release` — Delete a component release (immutable; useful for pruning old releases) **Resources** - `create_resource_release_binding` — Create a new ResourceReleaseBinding to deploy a Resource to a specific environment - `list_resource_release_bindings` — List ResourceReleaseBindings in a namespace; optionally filter by project, resource, or environment - `get_resource_release_binding` — Get detailed info for a ResourceReleaseBinding including the pinned ResourceRelease, retention policy, environment overrides, and resolved outputs - `update_resource_release_binding` — Update a ResourceReleaseBinding's configuration (`resource_release`, `retain_policy`, `resource_type_environment_configs`); promotion is performed by setting `resource_release` to a new ResourceRelease name - `delete_resource_release_binding` — Delete a ResourceReleaseBinding; if effective `retainPolicy` is `Retain`, the finalizer holds and the data-plane state persists until the policy is flipped to `Delete` - `delete_resource_release` — Delete a ResourceRelease snapshot (immutable; useful for pruning old releases) **Pipelines & Environments** - `list_deployment_pipelines` — List all deployment pipelines defining environment promotion order in a namespace - `get_deployment_pipeline` — Get detailed deployment pipeline info including stages, promotion order, and environments - `list_environments` † — List all environments (deployment targets like dev, staging, production) in a namespace
Build Toolset - `trigger_workflow_run` — Trigger a workflow run for a component using the component's configured workflow and parameters. Set `release_line` to build one of the component's release lines with its workflow parameters - `create_workflow_run` — Create a new workflow run by specifying a workflow name and optional parameters - `list_workflow_runs` — List workflow run executions in a namespace; optionally filter by project and component - `get_workflow_run` — Get detailed info for a workflow run including status, tasks, and timestamps - `get_workflow_run_status` — Get the live status of a workflow run (phase, task progress) - `get_workflow_run_logs` — Stream live logs for a workflow run (live-only — does not return archived logs for completed runs); optional `task` filter - `get_workflow_run_events` — Get Kubernetes events for a workflow run (scheduling, pod-startup failures); optional `task` filter - `list_workflows` † — List all workflow templates in a namespace (CI/CD pipelines executed on the workflow plane). Pass `scope: "cluster"` for ClusterWorkflows - `get_workflow` † — Get the full definition of a workflow including its complete spec. Pass `scope: "cluster"` for a ClusterWorkflow - `get_workflow_schema` † — Get the parameter schema for a workflow template. Pass `scope: "cluster"` for a ClusterWorkflow
Platform Engineering (PE) Toolset :::note The PE toolset is enabled by default. These tools are intended for platform administrators who manage infrastructure, environments, platform standards, and deployment pipelines. If you need to disable the PE toolset, see [Configuring MCP Toolsets](#configuring-mcp-toolsets). ::: **Environment Management** - `list_environments` † — List all environments in a namespace - `create_environment` — Create a new environment in a namespace - `update_environment` — Update an existing environment (display name, description, production flag) - `delete_environment` — Delete an environment from a namespace **Deployment Pipeline Management** - `create_deployment_pipeline` — Create a new deployment pipeline defining environment promotion order - `update_deployment_pipeline` — Update promotion paths and approval requirements - `delete_deployment_pipeline` — Delete a deployment pipeline from a namespace **Component Releases** - `list_component_releases` — List all releases (immutable snapshots at a specific build) for a component - `create_component_release` — Create a new release from the latest build of a component. Set `release_line` to release one of the component's release lines - `get_component_release` — Get detailed release info including build information, image tags, and deployment status - `get_component_release_schema` — Get the JSON schema for a component release's configuration options **Resource Releases** - `list_resource_releases` — List all ResourceReleases (immutable snapshots of `Resource.spec` + `(Cluster)ResourceType.spec`) for a Resource - `create_resource_release` — Manually cut a ResourceRelease from the current Resource and ResourceType state. Typically not needed in steady state—the Resource controller cuts releases automatically on hash change - `get_resource_release` — Get the full snapshot including the frozen (Cluster)ResourceType spec and the Resource parameters captured at release time **Infrastructure — Planes** These tools are namespace-scoped by default; pass `scope: "cluster"` to operate on the cluster-scoped plane. - `list_dataplanes` — List all data planes (clusters where workloads execute) in a namespace - `get_dataplane` — Get detailed data plane info including cluster details, capacity, and health - `list_workflowplanes` — List all workflow planes (dedicated build infrastructure) in a namespace - `get_workflowplane` — Get detailed workflow plane info including cluster details and health status - `list_observability_planes` — List all observability planes providing monitoring, logging, and tracing in a namespace - `get_observability_plane` — Get detailed observability plane info including observer URL and health status **Platform Standards — Read** These tools are namespace-scoped by default; pass `scope: "cluster"` to operate on the platform-wide cluster-scoped resource. - `list_component_types` † — List available component types in a namespace - `get_component_type` — Get the full definition of a component type including its complete spec - `get_component_type_schema` † — Get the parameter schema for a component type - `list_traits` † — List available traits in a namespace - `get_trait` — Get the full definition of a trait including its complete spec - `get_trait_schema` † — Get the parameter schema for a trait - `list_resource_types` † — List available ResourceTypes in a namespace. Pass `scope: "cluster"` for ClusterResourceTypes - `get_resource_type` † — Get the full definition of a ResourceType including outputs and resource manifests. Pass `scope: "cluster"` for a ClusterResourceType - `get_resource_type_schema` † — Get the parameter schema for a ResourceType. Pass `scope: "cluster"` for a ClusterResourceType - `list_workflows` † — List all workflow templates in a namespace - `get_workflow` — Get the full definition of a workflow including its complete spec - `get_workflow_schema` † — Get the parameter schema for a workflow template **Platform Standards — Creation Schemas** - `get_component_type_creation_schema` — Get the spec schema for creating a component type. Pass `scope: "cluster"` for a ClusterComponentType - `get_trait_creation_schema` — Get the spec schema for creating a trait. Pass `scope: "cluster"` for a ClusterTrait - `get_resource_type_creation_schema` — Get the spec schema for creating a ResourceType. Pass `scope: "cluster"` for a ClusterResourceType - `get_workflow_creation_schema` — Get the spec schema for creating a workflow. Pass `scope: "cluster"` for a ClusterWorkflow **Platform Standards — Write** These tools are namespace-scoped by default; pass `scope: "cluster"` to operate on the platform-wide cluster-scoped resource. - `create_component_type` — Create a new component type in a namespace - `update_component_type` — Update an existing component type (full replacement) - `delete_component_type` — Delete a component type from a namespace - `create_trait` — Create a new trait in a namespace - `update_trait` — Update an existing trait (full replacement) - `delete_trait` — Delete a trait from a namespace - `create_resource_type` — Create a new ResourceType. Pass `scope: "cluster"` to create a ClusterResourceType - `update_resource_type` — Update an existing ResourceType (full replacement). Pass `scope: "cluster"` for a ClusterResourceType - `delete_resource_type` — Delete a ResourceType. Pass `scope: "cluster"` to delete a ClusterResourceType - `create_workflow` — Create a new workflow in a namespace - `update_workflow` — Update an existing workflow (full replacement) - `delete_workflow` — Delete a workflow from a namespace **Authorization — Roles** - `list_authz_roles` — List authz roles in a namespace - `get_authz_role` — Get the full definition of an authz role - `get_authz_role_creation_schema` — Get the spec schema for creating an authz role - `create_authz_role` — Create a new authz role - `update_authz_role` — Update an existing authz role (full replacement) - `delete_authz_role` — Delete an authz role **Authorization — Role Bindings** - `list_authz_role_bindings` — List authz role bindings in a namespace - `get_authz_role_binding` — Get the full definition of an authz role binding - `get_authz_role_binding_creation_schema` — Get the spec schema for creating an authz role binding - `create_authz_role_binding` — Create a new authz role binding - `update_authz_role_binding` — Update an existing authz role binding (full replacement) - `delete_authz_role_binding` — Delete an authz role binding **Secret References** - `list_secret_references` ‡ — List all secret references (credentials and sensitive configuration) for a namespace - `get_secret_reference` ‡ — Get a single secret reference's full spec (template, data sources, refresh interval, target plane). For sync status, query `get_resource_events` against the rendered ExternalSecret on the data plane - `create_secret_reference` — Create a new secret reference; spec must include `template` (Kubernetes Secret type) and `data[]` (mapping of secret keys to external store references) - `update_secret_reference` — Update an existing secret reference; annotations are merged, spec is replaced wholesale when provided - `delete_secret_reference` — Delete a secret reference (the underlying Kubernetes Secret is removed by the controller) ‡ Also registered on the Namespace toolset so developers can list and inspect secret references without enabling PE. **Diagnostics** - `get_resource_tree` — Get the rendered resource tree for a release binding - `get_resource_events` — Get Kubernetes events for a specific resource in a deployment (scheduling, startup issues) - `get_resource_logs` — Get container logs from a specific pod in a deployment (application errors, runtime issues) - `evaluate_authz` — Evaluate one or more authz requests and return allow/deny plus the matching binding chain on a deny - `list_authz_actions` — List the catalog of authz action names and the lowest applicable scope for each
### Observability Plane MCP Server The Observability Plane MCP server provides tools covering logs, traces, metrics, alerts, incidents, audit logs, platform logs and FinOps cost insights: - `query_component_logs` — Query runtime application logs for components (services, APIs, workers, scheduled tasks); filter by project, component, environment, time range, log levels, and search phrases - `query_workflow_logs` — Query CI/CD workflow run logs capturing build, test, and deployment pipeline execution details; filter by workflow run name and task name - `query_http_metrics` — Query HTTP request and latency metrics; returns time-series data for request counts (total, successful, unsuccessful) and latency percentiles (p50, p90, p99) - `query_resource_metrics` — Query CPU and memory resource usage metrics; returns time-series data for usage, requests, and limits — useful for capacity planning and detecting memory leaks - `query_traces` — Query distributed traces; returns a list of traces with summary information including trace ID, span count, root span details, and duration - `query_trace_spans` — Query all spans within a specific distributed trace by trace ID; returns span details with timing, parent span, and service information - `get_span_details` — Get full details for a specific span including attributes, resource attributes, parent span ID, and timing details - `query_alerts` — Query fired alerts in OpenChoreo; supports filtering by project, component, environment, and time range — useful for investigating recent alerts and their details - `query_incidents` — Query incidents in OpenChoreo; supports filtering by project, component, environment, and time range — useful for tracking incident lifecycle and response status; all incidents have an accompanying alert but not the other way around - `query_costs` — Query per-component infrastructure costs (CPU cost, memory cost, and resource efficiency) for a namespace within an environment and time range; covers every component by default, or scope to a project or a single component; supports a `granularity` parameter to split each component into time buckets, useful for cost attribution and spotting inefficient workloads - `query_recommendations` — Query right-sizing recommendations comparing current CPU/memory requests and limits against recommended values derived from observed usage, with associated costs, for a namespace within an environment and time range; covers every component by default, or scope to a project or a single component. Useful for reducing over-provisioning - `query_dora_metrics` — Query DORA delivery performance metrics — deployment frequency, lead time for changes, change failure rate and mean time to recovery — for a namespace within a time range, optionally scoped to a project, component or environment; returns each metric's value, its Elite/High/Medium/Low classification and its trend against the previous window of equal length, plus a time-bucketed series at daily, weekly or monthly granularity. Requires the `deliveryinsights:view` permission. See [Delivery Insights](../platform-engineer-guide/delivery-insights.mdx) - `query_dora_deployments` — List the individual rollouts behind the DORA metrics, each with its project, component, environment, commit, outcome and lead time; takes the same scope and window as `query_dora_metrics`, with `limit` and `sort_order` for reading the most recent first. Useful for showing the work behind a number — which deployments failed, what shipped in a window, which rollout took longest. Requires the `deliveryinsights:view` permission. See [Delivery Insights](../platform-engineer-guide/delivery-insights.mdx) - `query_audit_logs` — Query the audit trail: who did what, to which resource, and whether it was allowed; filter by actor (ID, type, issuer, session, entitlements), resource (type, namespace, environment, project, component, name), action, category, result, surface, operation ID, request ID and a search phrase, within a window of at most 366 days; optionally returns a timeline of record counts. Requires the cluster-scoped `auditlogs:view` permission. See [Audit Logging](../platform-engineer-guide/audit-logging.mdx) - `query_platform_logs` — Query platform logs: everything one observability plane collects, addressed by raw Kubernetes coordinates, including OpenChoreo's own components, the third-party infrastructure deployed alongside them and user workloads; filter by cluster, Kubernetes namespace, pod, container, pod label selector (e.g. `openchoreo.dev/plane=controlplane`), log levels and a search phrase within a time range; optionally returns a breakdown of which clusters, namespaces, pods or containers produced the matches. Requires the cluster-scoped `platformlogs:view` permission. See [Platform Logs](../platform-engineer-guide/platform-logs.mdx) For a component with [release lines](../developer-guide/deploying-applications/release-lines.md), the component-scoped tools take a `release_line` argument that restricts the result to one line. `query_component_logs`, `query_component_events`, `query_http_metrics`, `query_resource_metrics`, `query_traces` and `query_trace_spans` need `component` and `environment` with it. `query_alerts`, `query_incidents`, `query_dora_metrics`, `query_dora_deployments`, `query_costs` and `query_recommendations` need only `component`. `main` selects the component's main line. Without `release_line`, a query covers the component's main line, and `all_release_lines` covers every line of the component. ## Configuring MCP Toolsets The Control Plane MCP server exposes seven toolsets: `namespace`, `project`, `component`, `resource`, `deployment`, `build`, and `pe`. All seven are enabled by default. You can control which toolsets are active by passing a JSON array to `openchoreoApi.config.mcp.toolsets` via `helm upgrade`. **Syntax:** {`helm upgrade openchoreo-control-plane ${versions.helmSource}/openchoreo-control-plane \\ --version ${versions.helmChart} \\ --namespace openchoreo-control-plane \\ --reuse-values \\ --set-json 'openchoreoApi.config.mcp.toolsets=["","",...]'`} ### Common Configurations **Developer toolsets:** {`helm upgrade openchoreo-control-plane ${versions.helmSource}/openchoreo-control-plane \\ --version ${versions.helmChart} \\ --namespace openchoreo-control-plane \\ --reuse-values \\ --set-json 'openchoreoApi.config.mcp.toolsets=["namespace","project","component","resource","deployment","build"]'`} **Platform Engineer toolset:** {`helm upgrade openchoreo-control-plane ${versions.helmSource}/openchoreo-control-plane \\ --version ${versions.helmChart} \\ --namespace openchoreo-control-plane \\ --reuse-values \\ --set-json 'openchoreoApi.config.mcp.toolsets=["namespace","project","pe"]'`} :::tip The `namespace` and `project` toolsets are useful companions for the PE toolset — they let platform engineers discover resources without enabling all developer toolsets. ::: ## Per-Session Tool Filtering By default, the Control Plane MCP server filters `tools/list` and `tools/call` results by the authenticated user's permissions. Tools the user lacks permission for are hidden, and unauthorized calls are rejected. MCP clients can additionally narrow what a session sees or opt out of authorization-based filtering by passing optional query parameters when establishing the session. | Query Parameter | Required | Default | Description | | --------------- | -------- | ----------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------- | | `toolsets` | `false` | All configured toolsets | Comma-separated list of toolsets to expose via `tools/list` for the session (e.g. `namespace,component,pe`). Unknown toolset names are silently ignored. | | `filterByAuthz` | `false` | `true` | When `true`, hides tools the user cannot call and rejects unauthorized invocations. Set to `false` to disable MCP-layer authorization filtering. | **Example:** ``` http://api.openchoreo.localhost:8080/mcp?toolsets=namespace,component,pe&filterByAuthz=false ``` :::note These query parameters are HTTP-only and read once when the session is established. The `toolsets` parameter only filters `tools/list` results; it does not gate `tools/call`. The control plane API enforces authorization independently of `filterByAuthz`, so disabling MCP-layer filtering does not grant additional access. It just exposes tools the user cannot successfully invoke. ::: :::note Authorization of scope-collapsed tools A scope-collapsed tool (one that accepts a `scope` argument) requires a distinct permission per scope — one for `scope: "namespace"` and one for `scope: "cluster"`. It appears in `tools/list` as long as the user holds the permission for **at least one** scope; a `tools/call` invocation is then authorized against the permission for the scope actually requested. So a user with only namespace-level permissions still sees the tool, but a call with `scope: "cluster"` is rejected unless they also hold the cluster-level permission. ::: ## Finding MCP Server URLs MCP server URLs follow a simple pattern based on the respective service's hostname: - **Control Plane MCP Server**: `/mcp` - **Observability Plane MCP Server**: `/mcp` ### Example: Local k3d Setup If you followed the [local setup](../getting-started/try-it-out/on-k3d-locally.mdx) guide, your MCP server URLs will be: **Single Cluster Installation:** - **Control Plane MCP Server**: `http://api.openchoreo.localhost:8080/mcp` - **Observability Plane MCP Server**: `http://observer.openchoreo.localhost:11080/mcp` **Multi-Cluster Installation:** - **Control Plane MCP Server**: `http://api.openchoreo.localhost:8080/mcp` - **Observability Plane MCP Server**: `http://observer.observability.openchoreo.localhost:11087/mcp` :::note The k3d local setup examples show different ports and hostnames: - Control plane services use port 8080 - Observability plane uses port 11080 (single cluster) or 11087 (multi-cluster) - Multi-cluster deployments use distinct subdomain patterns for namespace isolation ::: ## Default OAuth Applications OpenChoreo ships with pre-created OAuth applications in the default ThunderID identity provider for quick-start configuration: | Application | Client ID | Grant Type | Use Case | | -------------------------- | -------------------- | ------------------------- | ------------------------------------------------------------------------------------- | | **Browser-Based (Public)** | `user_mcp_client` | Authorization Code + PKCE | Interactive use with AI agents that support browser-based OAuth (Claude Code, Cursor) | | **Service (Confidential)** | `service_mcp_client` | Client Credentials | Programmatic access, any AI agent via bearer token | These default applications eliminate the need to manually create OAuth apps for common setups. ## Next Steps To configure your AI assistant to connect to OpenChoreo MCP servers, follow the [AI Configuration Guide](../ai/mcp-servers.mdx) to set up authentication and connect your AI agent.