MCP Overview

Connect AI agents to Allye capabilities through the Model Context Protocol.

Allye MCP is a server that implements the Model Context Protocol. It gives an MCP-compatible AI client a structured way to work with an Allye workspace: retrieve context, remember decisions, manage delivery work, write documentation, and use shared skills.

The MCP interface is organized around intent. An agent chooses the capability it needs, then selects an action within that capability. The agent does not need to know how Allye stores or serves the data behind the interface.

What MCP enables

With Allye connected, an agent can:

recover relevant decisions and session context before starting work;
save durable knowledge with semantic search and relationship tracking;
create, inspect, and advance work items;
review teams, sprints, boards, and personal TODOs;
create and navigate workspace documentation;
resolve, export, and maintain skills and their revisions;
search the workspace API catalog when it needs product context.

How the connection works

AI agent or MCP client
          │
          │ https://mcp.allye.app + OAuth
          ▼
 Hosted Allye MCP service
          │
          │ authenticated Allye workspace connection
          ▼
     Allye workspace

Allye MCP is offered exclusively as a hosted remote service. An MCP-compatible client connects to https://mcp.allye.app and completes OAuth in the browser. The MCP server is not installed or started on the user's machine, and no alternate connection mode is available.

The client manages the OAuth consent flow, session, and reconnection. Once connected, the client can use the capabilities below through the same MCP interface.

Protocol capabilities

Allye MCP supports MCP tools, prompts, and resources. The server currently exposes:

12 tools grouped by capability;
the action-based tools listed in the reference below, with allye_health_check handled separately;
the allye_health_check tool, which is a health operation and does not use an action field;
prompts for common workflows such as memory, documentation, tasks, bugs, and TODOs;
the allye://my-teams resource for reading the teams available to the authenticated user.

The exact action names are maintained in the Actions Reference.

Capabilities by intent

Intent	MCP tool	Typical use
Start or refresh context	`initialize`	Load user, workspace, team, and document context.
Work with durable knowledge	`intelligence`	Save, search, traverse, and relocate semantic memories.
Manage personal follow-ups	`productivity`	Create, search, update, and analyze TODOs.
Plan and deliver work	`work_items`	Create, find, update, assign, and advance work items.
Write and organize knowledge	`docs`	Manage pages, folders, trees, versions, and publication state.
Inspect delivery cadence	`sprints`	List sprints and inspect their work items.
Inspect workflow views	`boards`	List boards, favorites, details, and columns.
Reuse agent guidance	`skills`	Resolve, export, import, edit, and review skills.
Find product API knowledge	`api_catalog`	Search and inspect catalogued API specifications.
Work with teams	`team`	List teams, select a team, inspect the current team, and list members.
Manage personal configuration	`user_config`	Create and maintain user configuration documents.
Check availability	`allye_health_check`	Confirm that the connected service is responding.

Teams, accounts, and context

A connection identifies the Allye account or workspace available to the client. A user can belong to more than one team inside that workspace.

For a multi-team user, Allye does not silently choose a team. Use team with team_list to inspect available teams, then team_switch with a team name, prefix, or ID. A tool call can also provide team_id when that action supports an explicit override.

Team selection is separate from MCP connection setup:

the MCP connection authenticates the user and establishes the workspace context;
team_switch selects the working team for team-scoped actions;
the protocol initialize method may be repeated when a client reconnects, while an explicit team selection is preserved when it remains valid.

A typical interaction

An agent normally follows this sequence:

The MCP client performs the protocol initialize exchange automatically.
The server returns its protocol version and available capabilities, and loads initial Allye context.
The agent checks or selects a team when the user belongs to multiple teams.
The agent calls a capability tool using tools/call and an action-specific argument object.
The agent uses the result to answer the user or continue the workflow.

For example, a semantic context lookup is an MCP tool call, not a direct request to an internal service:

{
  "name": "intelligence",
  "arguments": {
    "action": "memory_search",
    "query": "decisions about authentication",
    "sector": "decisions",
    "limit": 5,
    "return_content": true
  }
}

A team selection uses the same MCP pattern:

{
  "name": "team",
  "arguments": {
    "action": "team_switch",
    "team_query": "Platform"
  }
}