Pillars, tiers, and tool visibility

MCP discovery is contextual. The Worker filters the canonical catalog for the requested surface, tenant policy, and authenticated principal before returning a manifest or registering tools for a request.

Subscription pillars and AI COO scope

Subscription tiers establish enabled product pillars and an AI COO scope:

Tier	Enabled product pillars	AI COO scope
Core	portal, accounting, reporting	`accounting`
Growth	portal, accounting, reporting, commerce, cx, datax	`full`
Scale	portal, accounting, reporting, commerce, cx, studio, datax	`unlimited`
Enterprise	portal, accounting, reporting, commerce, cx, studio, datax	`unlimited`
Practice	portal, accounting, reporting, cx	`accounting`

datax is a subscription pillar but is not an MCP ToolPillar. The MCP catalog’s tool pillars are accounting, commerce, cx, portal, reporting, and studio.

These gates intersect. For example, Practice includes the CX product pillar, but its accounting AI COO scope limits MCP discovery to accounting, reporting, and portal tools while acting in the practice tenant.

Ordered visibility gates

toolVisibilityDecision applies these checks:

Gate	What must be true
Surface	The tool declares the requested `public` or `internal` surface
Agent state	The tenant policy has the AI assistant enabled
Effective tier	Public discovery excludes T4; policy-blocked destructive tools are excluded
AI COO scope	The tool’s pillar is allowed by `accounting`, `full`, or `unlimited`
Pillar	The tenant policy enables the tool’s pillar
Feature	Every `requiredFeatures` key is present
GL layer	The tenant GL layer meets `minGlLayer`
Entitlement	Every `requiredEntitlements` key is present
Role	At least one `allowedRoles` value matches when roles are restricted
Permission	Every `requiredPermissions` value is present in policy permissions or principal scopes
Persona	The canonical tenant persona matches an `allowedPersonas` value when restricted

The catalog visibility policy has this normalized shape:

interface ToolVisibilityPolicy {
  requiredEntitlements: readonly string[];
  requiredFeatures: readonly string[];
  minGlLayer: 0 | 1 | 2 | 3;
  allowedRoles: readonly string[];
  requiredPermissions: readonly string[];
  allowedPersonas: readonly string[];
}

Empty arrays mean that gate adds no tool-specific restriction. Defaults are normalized when the catalog is built, so every ToolDefinition has a complete policy.

Public and internal surfaces

The public surface excludes destructive T4 tools from discovery. The internal manifest can include T4 definitions, but visibility does not imply immediate execution: curated destructive tools remain hard-blocked and other allowed T4 tools use the destructive pending-action path.

Public requests without X-Tenant-ID receive a restricted bootstrap policy for organization selection. After selecting an organization, clients must send the returned tenant header. Tenant-scoped requests fail closed if policy cannot be verified.

Discovery and execution

/mcp/manifest and MCP tools/list return only the tools visible in the current context. The set can change when the tenant, principal, role, feature set, subscription, or policy changes. Clients should rediscover tools after changing tenant context and should not cache a catalog as a universal contract.

Do not treat hidden UI controls as API authorization. Product APIs enforce their own authorization, while MCP applies the catalog gates above before tool execution.

Example

For a Growth tenant with AI COO enabled, full scope allows non-Studio pillars. A specific CX tool is still omitted unless CX is enabled and all of that tool’s feature, entitlement, GL-layer, role, permission, and persona requirements pass.

For a Scale tenant, unlimited allows all MCP pillars, including Studio. It does not bypass the remaining visibility or approval gates.