MCP connection planning

Define the MCP boundary before connecting an AI client

An MCP connection should expose only named tools with explicit inputs, outputs, permissions, side effects, and audit behavior. Keep tenant identity and human control visible at every step.

  • Planning focus
  • Bounded access
  • Human-controlled operation
  • Defined workflow
  • Scoped by workspace
  • Named hosting model
  • Tools / permissions
  • Explicit per tool
  • Clients / hosting
  • Declared configuration
  • The diagram is protocol-boundary orientation only. It is not a product screenshot or proof of a live customer gateway.
  • Integration directory

Connection design

Define access before choosing tools

Start with the customer, tenant, hosting, identity, tool, and audit boundaries that the connection must enforce.

  • Purpose Connection purpose Name the workflow the client should support and the outcomes it must not perform autonomously.
  • Scope Customer access Define the plan, tenant, market, and release scope for the connection.
  • Scope Gateway and hosting Specify the server, hosting model, transport, and operational ownership.
  • Scope Access model Define authentication, tenant binding, roles, scopes, credential lifecycle, and supported clients.
  • Controls Tools and audit Define the read/write catalog, fields, side effects, confirmation, audit, privacy, and operating behavior.
  • Bounded tool
  • No open-ended access.
  • Generic queries, unrestricted network calls, arbitrary code, raw database access, and unbounded administrator tools stay outside the connection scope.
  • Technology remains one qualifier.
  • A technology mention or client response cannot activate a Composite Intent or satisfy Actionable Signal eligibility.
  • Scope is the safety boundary.
  • Document every answer before configuring customer access.
01

01

Planning focus

Evidence boundary

Do not use internal developer tooling as product proof

The repository contains an MCP bridge for a separate Headless PM coordination system. It has a different purpose and tool catalog and cannot support Queast customer-product claims.

01

Different system

Headless PM coordinates internal project and agent work; it is not the Queast customer platform.

02

Different tools

Its task, document, agent, and service-management tools do not establish Queast company, Workbench, Messaging, SPICED, or Signal access.

03

Different authority

Developer access and internal administration cannot be generalized into tenant-user permissions.

04

No compatibility inference

An internal client bridge does not prove supported customer clients, hosting, connection method, or commercial availability.

Required access contract

Define the boundary before defining tools

Use these requirements to design a customer-facing MCP surface with deliberate access and data controls.

Required

Identity and tenant

Define authentication, represented tenant and user, credential issuance and revocation, and impersonation controls.

Required

Closed tool catalog

Publish only named tools with declared inputs, outputs, fields, authority, side effects, and availability.

Required

Live authorization

Define the permission and approval check for each read, draft, write, or external side effect.

Required

Data and audit boundary

Specify allowed fields, evidence references, redaction, recorded call context, retention, export, and review.

Tool design

Name and bound every tool

Each tool class needs explicit fields, permissions, side effects, confirmation behavior, and access scope.

01

Retrieve context

Company, person, evidence, Workbench, SPICED, or Actionable Signal reads require a named tool and field contract.

02

Prepare output

Research summaries, SPICED preparation, and message drafts require source and authority boundaries plus human review.

03

Change Queast state

Saved items, task status, drafts, and other writes require a named action, confirmation policy, and audit contract.

04

Act outside Queast

CRM changes, notifications, email, LinkedIn, calls, and generic requests require separate connector and human-control approval.

05

Administrative access

Tenant or super-admin operations cannot be inferred from internal developer tooling or exposed without explicit approval.

Artifact authority

Keep the same authority across the client boundary

MCP access cannot make missing evidence true, activate a Composite Intent, satisfy eligibility, or raise the authority of any artifact it retrieves or formats.

  1. Source evidence

    The observation keeps its source, date, and provenance.

  2. Analysis

    Interpretation remains separate and may connect supported inputs across time.

  3. Composite Intent

    The company-level hypothesis keeps its lifecycle, conflicts, and provenance.

  4. Actionable Signal

    Only a recommendation that passed the applicable eligibility contract carries strict Signal authority.

  5. Approved tool result

    A future named tool may expose only approved fields at the artifact’s existing authority.

  6. Client response

    The client may explain or format approved context without inventing evidence or removing uncertainty.

  7. Human action

    Action remains a separate decision unless a narrowly approved write tool and confirmation policy explicitly state otherwise.

Readiness checklist

Confirm the complete MCP contract

Use this checklist to define a customer-facing connection before it is configured for a workspace.

01

Availability

Which plan, tenant, market, and release state can use MCP?

02

Hosting and transport

Where is the server hosted and which connection method is supported?

03

Clients

Which AI clients and versions are approved?

04

Authentication

Which credential, tenant binding, role, scope, expiry, rotation, and revocation rules apply?

05

Tools and fields

What is the exact read and write catalog, with fields and side effects per tool?

06

Approval

Which calls require preview, confirmation, or a separate human action?

07

Audit and privacy

What is logged, redacted, retained, exportable, and reviewable?

08

Operations

What limits, errors, timeouts, support, incident response, and SLA apply?

Next step

Inspect the evidence before you act

Review the source, date, account context, and uncertainty. Then decide whether the proposed next step deserves action.