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"
}