Skip to content

MCP & AI Assistants

SchemAlign MCP lets supported AI assistants work with SchemAlign through the permissions of the signed-in SchemAlign user.

Depending on the user's current access and the organization's MCP policy, an assistant can inspect governed SchemAlign metadata, review pipeline execution details, and help build and test Extend connectors. SchemAlign does not give the assistant broader access than the user already has.

Pipeline creation, editing, and execution remain unavailable through MCP.

How access works

MCP access is governed by several layers:

SchemAlign deployment connected to MCP
        +
user signs in through OAuth
        +
current organization membership and RBAC
        +
OAuth scopes granted to the AI client
        +
organization MCP policy
        =
effective MCP access

SchemAlign rechecks these controls whenever protected data or an Extend action is requested. Removing organization access or disabling a capability takes effect without granting the assistant an independent administrator identity.

AI client identity

SchemAlign identifies an AI client as verified only when its OAuth product identity can be trusted. The authorization page shows the verified provider when that trust can be established.

If the client cannot be verified, SchemAlign labels it Unverified MCP client and displays the claimed name and connection details for review. A client-provided name is informational and is not treated as proof of identity.

Review the client identity, requested access, and redirect destination before approving any connection.

What MCP can read

The current toolset provides governed access to:

Capability Description
Identity and organizations Shows the authenticated SchemAlign context and organizations currently available to the user.
Projects and pipelines Lists authorized projects, pipeline metadata, sanitized definitions, and graph structure.
Run history Lists pipeline runs and reads one authorized run's status and timing.
Exact logs Reads stored log events exactly when separate sensitive-diagnostic access and organization policy permit it.
Artifact metadata Lists durable run outputs without returning their contents or storage locations.
Artifact contents Reads supported text artifact contents when the organization's separate sensitive-content policy permits it.
Runtime values Reads persisted runtime-value observations when separately permitted.
Extend catalog and quality Reads connector versions, source files, validation state, test state, dependency environments, adoption, and governed runtimes.
Native runtime discovery Lists institution-managed native bundles, compatibility results, and available SchemaDocks without returning archive contents or private storage paths.

Pipeline definitions and standard metadata are allowlisted before they are returned. Credential secret material is not exposed through those tools.

Governed Extend actions

When the user, OAuth authorization, and organization policy all permit the action, MCP can help complete the nondestructive Extend lifecycle:

  1. Create or revise a draft connector version using optimistic file hashes.
  2. Declare pinned Python dependencies, requested capabilities, and logical native requirements.
  3. Validate the version and prepare its governed dependency environment.
  4. Test eligible versions through the dedicated connector runner.
  5. Publish an immutable connector version.
  6. Create an institution-managed native bundle record and upload an explicitly licensed archive after the user supplies the required attestation.
  7. Check native compatibility, install a published connector, approve declared capabilities, and bind an exact ready bundle digest.
  8. Test the installed connector with its organization approvals, native bindings, account reference, and optional SchemaDock route.

Raw passwords, tokens, private keys, and similar secret values are rejected from MCP connector-test input. Tests that require credentials use stored SchemAlign account references.

Native connector testing

A version-level test cannot resolve organization-scoped native bundle bindings. Publish and install the connector, approve an exact ready bundle digest, and use the installed-connector test path instead.

Sensitive diagnostic data

Exact logs, artifact contents, and runtime values are independently controlled sensitive reads. They require the applicable OAuth access and an organization policy that explicitly enables the capability.

Exact log events are not shortened or sanitized by MCP. They may contain stack traces, downstream response bodies, authentication headers, tokens, identifiers, or other values written by a pipeline. Enable these capabilities only when that access is appropriate for the organization and user.

What MCP cannot do

The current MCP integration does not:

  • create, edit, or execute pipelines
  • retry, cancel, or delete pipeline runs
  • change organization membership or RBAC
  • create or modify accounts and credential secrets
  • return native bundle archives or private storage paths
  • retire or delete native bundles through MCP
  • remove native bindings through MCP
  • disable, uninstall, or delete installed connectors through MCP
  • modify published connector versions
  • bypass current SchemAlign authorization or organization policy
  • expose organizations that are not currently available to the signed-in user

Draft connector files and draft versions can be deleted as part of the governed authoring workflow. Published resources and organization installations retain the stronger administrative boundaries above.

SchemAlign remains authoritative

The AI assistant does not become a separate SchemAlign administrator. Every protected read, authoring action, installation action, and test is evaluated against current SchemAlign access.

Typical setup

A normal customer setup has two parts:

  1. A SchemAlign administrator connects the deployment to SchemAlign MCP and configures organization capabilities.
  2. An individual user connects a supported AI client, signs in to SchemAlign, reviews the requested access, and completes OAuth authorization.

The assistant can then use only the capabilities currently available to that user and organization. New MCP permissions may require the user to reconnect and approve the expanded OAuth request.

Next steps