MCP integration
Canyon speaks MCP natively. Every Canyon-native capability — design system, data sources, metrics, repos — is exposed as MCP tools. Your own MCP servers plug into the same layer, so agents can reach your systems without bespoke integration work.
Canyon-native tools
Canyon ships with a rich set of built-in MCP tools the platform uses internally, and that are available to any MCP-speaking agent (Claude Code, Cursor, Lovable, your own). Every built-in tool is deterministic and idempotent — agents can retry freely without side effects.
list_themes()Available themes with metadataget_theme(id)Full token set (primitives, semantic, components)get_design_tokens(theme_id)Compiled tokens, ready to consumelist_components()Browse the component libraryget_component(name)Self-contained bundle: source, dependencies, usagesearch_components(query)Semantic search across componentsget_pattern(type)Full pattern implementation ready to drop invalidate_design(code, theme)Design-compliance checkget_metric_catalog()Discover metrics available to this callerquery_metrics(...)Governed query, typed results, row-level filtereddescribe_source(name)Schema, freshness, lineagelist_projects()Projects the caller can seeread_file(path)Read a source file from a projectpropose_change(...)Queue a code change for review or automatic buildAggregator & tool router
Every MCP server — Canyon-native or yours — is stitched together behind a single router. The aggregator namespaces every tool (design.get_theme, metrics.query, repo.propose_change), monitors the health of each upstream, and filters which tools are exposed to which project based on its RBAC scope.
┌─────────────────────────────────────────────────────────────────────────────────────────┐ │ CANYON MCP AGGREGATOR │ │ ════════════════════════════════════════════════════════════════════════════════════════│ │ │ │ ┌───────────────────┐ ┌───────────────────┐ ┌───────────────────┐ │ │ │ Design system │ │ Data sources │ │ Metrics │ │ │ │ (Canyon-native) │ │ (your warehouse) │ │ (semantic layer) │ │ │ └─────────┬─────────┘ └─────────┬─────────┘ └─────────┬─────────┘ │ │ │ │ │ │ │ └──────────────────────┼──────────────────────┘ │ │ ▼ │ │ ┌────────────────────────┐ │ │ │ Tool Router │ │ │ │ • Namespace tools │ │ │ │ • Per-project scope │ │ │ │ • Health + audit │ │ │ └────────────────────────┘ │ │ │ │ │ ┌────────────────────────────────┼────────────────────────────────┐ │ │ ▼ ▼ ▼ │ │ ┌───────────────────┐ ┌───────────────────┐ ┌───────────────────┐ │ │ │ Source control │ │ Notifications │ │ Your MCP server │ │ │ │ (repo ops) │ │ (Slack, Teams…) │ │ (custom tools) │ │ │ └───────────────────┘ └───────────────────┘ └───────────────────┘ │ │ │ │ TRANSPORTS: stdio · SSE · HTTP │ └─────────────────────────────────────────────────────────────────────────────────────────┘
What plugs in today
These are examples of what customers have already wired up. Canyon doesn’t care where the MCP server runs — cloud, on-prem, or inside your own VPC — as long as it speaks the protocol.
Adding your own server
Canyon’s extension model is deliberately boring: you add an MCP server configuration to your organization, the aggregator discovers it, namespaces its tools, and exposes them to the projects you authorize. Secrets are encrypted at rest; health checks run in the background.
{
"name": "Warehouse metrics",
"type": "stdio" | "sse" | "http",
"config": {
"command": "…",
"args": ["…"],
"env": { "DATABASE_URL": "…" } // Encrypted at rest
},
"health_status": "healthy" | "unhealthy" | "unknown",
"last_checked_at": "timestamp"
}