> ## Documentation Index > Fetch the complete documentation index at: https://docs.vibely.sh/docs/llms.txt > Use this file to discover all available pages before exploring further. # MCP / Chat connectors > Give the Vibely agent build-time context from 46+ third-party services — Figma, Linear, Sentry, Neon, and more. # MCP / Chat connectors MCP (**Model Context Protocol**) connectors give the Vibely agent **build-time context** — they let it read your Linear issues, browse your Figma file, look at your Sentry errors, query a Neon database, and so on, *while it's building*. They do **not** ship code into your project. If you want the deployed app to call a service at runtime, you want an [App connector](/docs/connectors/overview) instead. The two surfaces are independent — connecting Linear as an MCP / Chat connector doesn't give the deployed app Linear access, and vice versa. ## How to connect one Open the **Connectors** drawer in any project, switch to the **Chat / MCP** tab, pick a service, and click **Connect**. * **Default-URL services** — Vibely already knows the MCP endpoint. You just authenticate (OAuth or API key, depending on the provider) and you're done. * **Custom MCP server** — pick **Custom**, paste your own MCP endpoint URL, and optionally add a bearer token. Vibely probes the server, lists its tools, and exposes them to the agent. Vibely auto-tests the connection by handshaking with the MCP endpoint and lists the tools each server exposes. Connection state is one of: * 🟢 **Connected** — handshake succeeded, tools listed. * ⚪ **Disconnected** — never tested, or tested with no response. * 🔴 **Error** — handshake failed; expand to see the error message. * 🟡 **Testing** — request in flight. ## Categories MCP / Chat connectors fall into six categories. The category shapes where the agent will reach for them automatically. | Category | What it's for | Examples | | ---------------- | ---------------------------------------------------- | ------------------------------------------------------------------------------------ | | **Dev** | Code, issues, repos, deploys | GitHub, Linear, Sentry | | **Knowledge** | Documents, designs, wikis the agent reads as context | Notion, Figma, Atlassian (Confluence + Jira), Miro, Canva, Webflow | | **Productivity** | Tasks, calendars, comms, billing | Slack, Google Calendar, Asana, Monday, Intercom, Square, HeyGen, Polar, Granola, n8n | | **Data** | Warehouses, notebooks, OLTP | Hex, Neon, PostHog, Amplitude | | **Monitoring** | Errors, metrics, uptime | Sentry, PostHog | | **Generic** | Bring-your-own MCP server | Custom (paste your own endpoint) | ## Catalog The full set the agent can read from. Where the same name also appears as an [App connector](/docs/connectors/catalog), the two surfaces are connected separately. ### Dev * **GitHub** — repo metadata, issues, PRs, commits. *Also App.* * **Linear** — issues, projects, cycles, comments. *Also App.* * **Sentry** — error groups, recent events, releases. *Also App.* ### Knowledge * **Notion** — pages, databases, comments. *Also App.* * **Atlassian** — Confluence pages + Jira issues from the same workspace handshake. * **Figma** — file metadata, page list, frame contents, design tokens. * **Miro** — boards, frames, widgets. *Also App.* * **Canva** — design assets, brand kits. * **Webflow** — site metadata, collections, CMS items. * **Sanity** — datasets, documents. *Also App.* * **Contentful** — spaces, entries. *Also App.* ### Productivity * **Slack** — channels, recent messages, thread history. *Also App.* * **Google Calendar** — events, attendees, availability. *Also App.* * **HubSpot** — contacts, companies, deals. *Also App.* * **Asana** — tasks, projects, assignees. *Also App.* * **Monday** — boards, items, columns. * **Intercom** — inbox conversations, customer profiles. * **Square** — locations, catalog, orders. * **HeyGen** — avatars, video projects. * **Polar** — products, subscriptions, customers. * **Granola** — meeting notes and summaries. * **n8n** — workflows, executions. * **Resend** — domains, audiences. *Also App.* * **Stripe** — products, customers, subscriptions (read-only by default). *Also App.* * **Shopify** — products, orders, customers. *Also App.* ### Data * **Hex** — notebooks, analyses, run results. *Also App.* * **Neon** — branches, databases, queries. * **PostHog** — events, insights, feature flags. *Also App.* * **Amplitude** — events, user properties, charts. *Also App.* ### Monitoring * **Sentry** — error groups, releases, performance. *Also App.* * **PostHog** — sessions, error tracking. *Also App.* ### Generic * **Custom** — paste your own MCP server URL (and optional bearer token). Vibely probes the endpoint, lists its tools, and surfaces them to the agent. ## Custom MCP servers Run your own MCP server (team-internal component library, a vendor's MCP we don't ship with, your design system) and point Vibely at it. What you provide: * **Name** — display label only. * **MCP Endpoint URL** — the server's HTTP base. * **API Key** (optional) — sent as `Authorization: Bearer ` when probing and calling. The endpoint must speak the standard MCP handshake. Once connected, every tool the server lists becomes callable by the agent alongside Vibely's built-in tools. ## App connector vs MCP / Chat connector with the same name When a service appears in both catalogs, the two are **independent connections** and serve different roles. | | App connector | MCP / Chat connector | | ----------------------- | --------------------------------------------------------------------------- | --------------------------------------------------------------------------- | | **Who calls the tools** | Your deployed app at runtime | Vibely's build agent at build time | | **Scaffolds files?** | Yes — typed clients land in your repo | No — the agent just calls the MCP tools | | **Auth** | OAuth via Vibely, Edge Function with vault-stored key, or direct-client key | OAuth via the MCP server, or API key in the Chat panel | | **Use it for** | "When a user signs up, post their email to `#new-signups`" | "Read the active Linear cycle so the scaffold matches the existing tickets" | You can connect just one surface or both — they don't interfere. If the agent needs build-time context *and* the deployed app needs runtime access, connect each side separately. ## Where MCP credentials live * **OAuth tokens** for default-URL MCP services live in Vibely's managed OAuth vault, scoped per workspace. * **API keys** for default-URL MCP services are stored encrypted at rest, scoped per workspace. * **Custom MCP server URLs + bearer tokens** are stored encrypted per workspace. Revoking a connection in the Connectors drawer immediately invalidates it for every project in the workspace. See [Auth & secrets → MCP auth](/docs/connectors/auth#mcp-auth) for the full contract. ## Limits * **MCP / Chat connectors are build-time only.** Nothing about them ships with your deployed app. For runtime access to the same data, add the matching App connector. * **Tool surface depends on the upstream MCP server.** Vibely doesn't fan out or polyfill missing capabilities; if the Linear MCP server exposes `list_issues` but not `create_issue`, the agent can read but not write. * **Custom MCP servers must implement standard MCP.** Bespoke RPC interfaces won't be discovered.