Build on your institution’s origination data

Overview

MCP Connect is a hosted Model Context Protocol server. It lets an AI assistant your institution has already approved — Claude, ChatGPT, or Microsoft Copilot — answer plain-English questions about your origination pipeline, without moving your data anywhere.

There is no SDK to install and nothing to deploy on your infrastructure. Your AI client connects directly to our server over an authenticated, audited HTTPS channel. Authorization uses standard OAuth 2.1, so any MCP-compatible client works without custom integration code.

Quickstart

To connect an approved AI client, you need an active Cotribute portal account and MCP Connect enabled for your institution.

1. Add the connector

   In your AI client’s connector or integration settings, add a custom MCP server with the URL https://mcp.cotribute.co. No API key, client ID, or secret is required — the client registers itself.

2. Authorize in your browser

   The client opens a Cotribute login. Sign in with your normal staff credentials and approve the read access request. You are returned to your AI client, connected.

3. Ask a question

   Try “What does our application pipeline look like today?” The assistant discovers the available capabilities automatically and selects among them.

Configuration file format

For clients configured by file rather than UI, the server entry is:

{
  "mcpServers": {
    "cotribute": {
      "type": "streamable-http",
      "url": "https://mcp.cotribute.co"
    }
  }
}

Authentication

MCP Connect is an OAuth 2.1 protected resource. It issues no credentials of its own and accepts no static API keys. Every request carries a bearer token issued to an individual staff member.

Discovery

Clients discover the authorization server from the protected-resource metadata document (RFC 9728). This endpoint is unauthenticated — you can inspect it now:

curl https://mcp.cotribute.co/.well-known/oauth-protected-resource

{
  "resource": "https://mcp.cotribute.co",
  "authorization_servers": ["https://auth.cotribute.co"],
  "scopes_supported": ["applications.read"],
  "bearer_methods_supported": ["header"]
}

Authorization server

Full metadata is published at https://auth.cotribute.co/.well-known/oauth-authorization-server. The endpoints your client will use:

Supported parameters

Scopes

A token without applications.read is rejected at the transport layer before any tool executes. There is no write scope in v1.0.

Endpoints

The MCP transport lives at the root of the host. Supporting endpoints sit alongside it.

Any other method on the MCP endpoint returns 405. The server does not implement server-initiated streams, so GET / serves a plain HTML overview to browsers rather than opening an event stream.

Capability discovery

Capabilities are discovered at runtime. A connected client calls tools/list and receives the current set of tools with their input schemas and descriptions — so a client never needs a hardcoded list, and new capabilities become available without a client update.

Every tool in v1.0 is annotated readOnlyHint: true and destructiveHint: false, which compliant clients surface to the user before executing a call.

What v1.0 covers

Three categories of question about your origination pipeline:

Tools accept declared, validated inputs only. An assistant cannot compose arbitrary queries against your data, and cannot reach data outside these categories.

Errors

Transport-level failures return a JSON body with an error code. Failures inside a tool call are returned through the MCP protocol as tool errors, so the assistant can explain them to the user.

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer resource_metadata=
  "https://mcp.cotribute.co/.well-known/oauth-protected-resource"

{
  "error": "invalid_token",
  "error_description": "Bearer token required"
}

A client that receives a 401 should follow the resource_metadata pointer, discover the authorization server, and re-run the authorization flow. Well-behaved MCP clients do this automatically.

Usage quotas

Each institution has a monthly usage allotment that resets at the start of the period. Tool calls are metered against it.

v1.0 does not hard-block on exhaustion — service continues, and the assistant surfaces a notice as the allotment is approached and passed, so a staff member is never cut off mid-question. Your allotment depends on your agreement; your account team can confirm it.

A client or administrator can read current consumption directly:

curl -H "Authorization: Bearer $TOKEN" \
  https://mcp.cotribute.co/usage

If MCP Connect has not been enabled for your institution, this endpoint reports that it is disabled rather than returning usage figures.

Security model

The controls below are architectural properties of the server, not configuration an administrator can weaken.

Read-only by architecture

v1.0 implements retrieval and summarization only. There is no code path by which a connected assistant can create, modify, delete, or approve anything.

No shared credentials

No static API keys or service accounts. Every session is authorized by a token issued to an individual named staff member through your existing Cotribute login. Clients authorize with PKCE, so no client secret is embedded in a desktop AI application. Revoking a staff account removes that staff member’s MCP access.

Access inherits your existing permissions

• Tenant isolation. The institution is resolved from the authenticated token, never from a request parameter — there is no input to manipulate in order to reach another institution’s data.
• Role and flow scoping. Results are filtered to the application flows the individual holds through your existing role and permission-set configuration. A member services representative and a lending manager get different answers to the same question.
• One permission model. MCP Connect reads the same permissions that govern the portal. There is no parallel entitlement system to maintain.

Applicant personal information is masked by default

v1.0 is designed for counts, distributions, and trends. Personally identifiable information is masked by default, keeping the assistant focused on governed, aggregate origination insights rather than applicant records.

Every call is audited

Every MCP Connect query is audited, with audit records retained for seven years. Your Cotribute account team can provide the supporting security documentation for your institution’s review.

Scope boundaries in v1.0

Stated explicitly, because the boundary is part of what your security team is reviewing.

• No write, approval, or decisioning actions of any kind
• PII is masked by default
• No document or image retrieval
• No access to data outside your own institution’s tenant
• No member- or applicant-facing use — MCP Connect is a staff tool

Any expansion of this boundary would ship as a new version — announced in advance, subject to your review, and adopted at your discretion. It would not arrive silently as a change to v1.0.

Versioning and change policy

Two things version independently: the capabilities inside the server, and the connection contract itself.

Support

Contact your Cotribute account team to enable MCP Connect for your institution, or to request the security documentation pack — including our SOC 2 report and subprocessor list — for your vendor review process.

For connection problems, note the timestamp and the error code returned, and include the AI client and version you are connecting from.

MCP Connect v1.0. Current as of September 2026 and subject to change in future versions.