Introduction to MCP

Model Context Protocol (MCP) lets AI assistants call tools your vendor hosts—here, tools backed by Onboard data and the same tenancy rules as the REST API. Think of it as a controlled bridge between a desktop or web AI client and your Onboard workspace.

Projects vs Map in MCP tools

Projects are the customer-facing name for delivery work in Onboard. The API’s OpenAPI tags still use Map for that area. When assistants call Browse full API with a tag argument, they must use Map to match the spec—but they should say “Project” (or “project tasks / roadmaps”) in summaries and UI copy for customers.

Why teams use it

• Operational AI — Copilots for onboarding, launch coordination, and support that pull live projects, customers, tasks, and discussions instead of static exports.
• Same guardrails as the API — Requests still depend on your API key and company permissions; MCP does not bypass Onboard access control.
• Fits modern clients — Remote MCP over HTTP/SSE works with products such as Amazon Quick, Claude Desktop, and other MCP-aware tools (see MCP desktop clients).

Hosted vs local (stdio)

• Hosted MCP — Onboard serves MCP at https://rest.onboard.io under /mcp/… paths. This is what most remote desktop clients use. Details: MCP setup.
• Local stdio — Engineering teams may run a stdio MCP server in a controlled environment. Availability depends on your deployment; email [email protected] if you need it enabled.

Where to go next

1. MCP setup — URLs, API key, and authentication
2. Security & permissions (MCP) — keys, tenancy, and review expectations
3. MCP desktop clients — pick a client and open its guide
4. Onboard REST API — how underlying HTTP APIs behave

For the high-level product overview, see MCP.