> For the complete documentation index, see llms.txt.
Skip to main content

Check out Port for yourself ➜ 

Integrations vs. MCP connectors

Port gives you two ways to connect external tools: integrations and MCP connectors. They solve different problems and are designed to complement each other — in many cases, you can benefit from both connected for the same tool.

How they differ

IntegrationMCP connector
What it doesSyncs data into Port as persistent entitiesGives AI real-time access to a tool's full surface area
Data lifecycleStored in Port, kept in syncRetrieved on demand, not persisted
Data shapeTransformed to fit your semantic layer (blueprints, relations, properties)Retrieved as-is from the source
Used byPort catalog, scorecards, dashboards, workflows, AIPort AI interfaces (assistant, MCP server)
Best forModeling, governing, and acting on dataEnriching AI context with live or unmodeled data

Use an integration when:

  • You need persistent, owned data in Port — services, deployments, teams, cloud resources that agents and workflows reference repeatedly.
  • You need relations across tools — linking a PR to the service it belongs to, or a Jira ticket to its deployment. Relations require both sides to exist as entities in Port.
  • You want to trigger workflows — automations and self-service actions operate on Port entities.
  • You want scorecards and reporting — production readiness scores, DORA metrics, and dashboards run against persisted entity data.

Use an MCP connector when:

  • You want AI to access live, transient, or unstructured data — real-time content that changes too fast or lacks the shape to model: PR diffs, Slack threads, meeting notes, raw logs.
  • You want cross-tool correlation without catalog modeling — Port AI can query GitHub and Jira together, reason over code owners and open issues, and surface connections without any entities in Port.
  • You want AI to access the full depth of a tool — integrations map a curated subset of a tool's data to your schema. MCP connectors give AI access to everything the tool exposes, including data you never modeled.
  • The external tool is already the source of truth and you want to keep it that way — AI queries it directly rather than duplicating the data into Port.

Using both together

Integrations and MCP connectors are complementary layers, not alternatives. For most major tools, connecting both gives you the best of each:

Example: GitHub

  • The GitHub integration syncs pull requests, repositories, and workflows as Port entities — giving you ownership mapping, relations to services, and scorecard checks on PR quality.
  • The GitHub MCP connector gives Port AI direct access to PR diffs, inline comments, file contents, and review threads — the rich, unstructured content that the integration doesn't map into your catalog.

When a developer asks Port AI to review a pull request, it uses the structured entity data from the integration (who owns the service, what standards apply) alongside the raw diff from the MCP connector to give a grounded, context-aware answer.

tip

You can start by connecting an MCP connector to see what insights Port AI can surface directly from your source systems, with minimal configuration. Add an integration when you want Port to become the source of truth for that data: model ownership, define relations between resources, and run scorecards on top of it.