MCP and Capability Integrations

Model Context Protocol (MCP) is one integration mechanism in the THINK work-delivery architecture. Customers do not need to install MCP to assign work to a Managed Team.

Capability resolution

Digital Employee or skill → Capability request → Authorized resolution → Approved provider → Resource

The architecture separates what a task needs from which provider or system supplies it. A capability may resolve through Compound Leverage-controlled MCP services, approved customer integrations, native runtime tools, or other approved APIs.

Boundary	Responsibility
CL-controlled capabilities	Approved proprietary or centrally managed services
Customer integrations	Authorized customer data, applications, repositories, and operations
Runtime-native tools and APIs	Approved execution mechanisms satisfying the required capability
Authorization	Human authorization, Digital Employee authorization, and workflow policy must all permit access

An available connector is not permission to use it. Customer credentials and authorization policies are not implicitly transferred to CL-controlled capabilities.

How a capability request is resolved

The MCP boundary specification defines this conceptual flow:

Digital Employee / skill → Capability request → Customer-specific policy and context resolution → Approved provider → Resource

Step	What is checked or resolved	Why it matters
1. Identify the requested capability	A stable capability identifier such as `github_read`	Separates the work definition from a specific connector
2. Establish the authorized context	Customer/deployment identity and applicable work scope	Prevents using the wrong customer context
3. Apply policy	Human, Digital Employee, and workflow permissions	An available tool is not automatically permitted
4. Select a provider	CL capability, customer integration, runtime-native tool, or approved API	Supports different delivery environments
5. Execute and return	Approved operation and result	Output remains subject to review and delivery controls

The specification states that human authorization ∩ Digital Employee authorization ∩ workflow policy determines permitted capability use. Provider-specific tool names belong in deployment configuration, not the reusable Digital Employee job definition.

Customer adapter: documented Capture-to-Proposal handoff

The commercial adapter source describes two entry-point operations: submit_capture_handoff_operation(request, manifests) and accept_capture_handoff_operation(request, manifests). Both accept a request and a caller-supplied manifest registry.

Validation point	Documented adapter behavior
Malformed request	Returns a typed `NOT_AUTHORIZED` decision with validation flags
Missing customer/deployment/user identity	Rejects before tenant resolution
Unknown tenant	Fails closed
Unapproved authenticated user	Rejects before forwarding
Inconsistent nested identity	Rejects mismatched customer/deployment identifiers
Underlying team handoff	Intended to be reached through the approved adapter boundary, not direct imports from a customer-facing session

These behaviors are documented in THINK-Commercial/MCP/customer-adapters/README.md and related tests. They demonstrate code-level validation, not that every live request is already routed through this interface.

Example response shape

The adapter documentation illustrates a rejection with a decision and reason. The following is an illustrative fragment, not a complete API contract:

{
  "decision": "NOT_AUTHORIZED",
  "reason": "malformed_request",
  "flags": []
}

Refer to the implementation and schema for complete fields and current behavior.

Troubleshooting and escalation

Symptom	First check	Next action
Missing data or inaccessible source	Was the source approved and connected for this assignment?	Ask the strategist to confirm permitted access
Authorization rejected	Identity, tenant, deployment, and approved-user configuration	Correct authorization through the designated owner; do not bypass the adapter
Capability unavailable	Whether an approved provider exists in the delivery environment	Use an approved alternative or revise the scope
Customer-environment integration blocked	Customer policy, credentials, network, or system permissions	Coordinate with the customer’s system owner
Result requires consequential action	Human approval requirements	Obtain explicit authorization before acting

Implementation evidence and limitations

Repository evidence	What it shows	What it does not show
`platform-spec/mcp-boundary.md`	Intended capability and provider boundaries	A live endpoint
`THINK-Commercial/MCP/customer-adapters/`	Adapter code and automated test cases	Universal enforcement across all sessions
`THINK-Commercial/Execution/deployment-architecture.md`	Deployment design and documented gaps at its review date	A completed Commercial MCP production deployment

The Commercial deployment architecture specifically states that its Commercial MCP server workflow had not yet been implemented at the time of that review. A current deployment audit is needed before claiming otherwise.

Implementation and maturity

The architecture is specified in CL-website/platform-spec/mcp-boundary.md and supported by code in THINK-internal/THINK-Commercial/MCP/customer-adapters/. The commercial deployment architecture notes that the Commercial MCP server deployment workflow was not implemented at the time of its review. Do not interpret these design references as a guarantee that every adapter or commercial endpoint is live.

Customer experience

The THINK Strategist coordinates approved integrations as part of delivery. The customer assigns work by meeting, email, or Customer Portal and receives the agreed deliverable. Work in customer environments requires separate access and execution arrangements.