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, KPIs, and discussions instead of static exports.
• Intent-first tools — Workflow actions such as “summarize onboarding status” and “find blocked tasks” before falling back to raw API calls.
• 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).

See MCP for features, day-to-day use cases, and rollout guidance.

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.

Next

MCP setup — URLs, API key, and authentication.

For the full curriculum, see MCP.