MCP Server

Zuse Bifrost hosts a Model Context Protocol (MCP) server beside the application. Any MCP-aware client connects by signing in to Zuse Bifrost (OAuth 2.1) or with a personal access token, and works in the project record through tool calls. Today that record is the account, the project registry with the components each project is made of, the environments it runs in, the people it answers to and is built for the dictionary it is written in (the glossary and the data entities), the designs it is built from and the repositories its code lives in, the epics it will deliver, the backlog of stories, tasks, bugs and spikes under them with their acceptance criteria, the functional and non-functional requirements it must honour, the business rules the business has decided, the use cases that say how each persona reaches a goal with it, the RAID log of what may go wrong and what the project leans on, the decisions that record every choice with its options and consequences, the links that join all of these into one record read from either side, the comments that carry the conversation on each of them, the files pinned on each of them, and every version of them, teams, tokens, webhooks and the activity log; the build, test, release and maintenance families join as each module lands, so an agent reads the live catalogue rather than assuming it. The agent writes as well as reads: it creates and changes clients, projects and their settings, components, environments, stakeholders, personas, the glossary and the data entities, designs, repositories and labels; creates epics, work items of every kind, use cases and RAID items; changes every planning record and moves it where the lifecycle allows by hand; hands a brief to Heimdall's reader, starts the research sweep, and decides a suggestion or a council finding on the person's word. Deciding an approval, administering the team and minting tokens stay with people.

Every address on these pages is written as https://mcp.example.test. Your workspace's address is the one your administrator shares; the application also publishes it on its server card at /.well-known/mcp/server-card.json, under the address you sign in at.

What you getCopy Anchor Link

• 161 tools covering the account behind the token (who is acting, the team the token is scoped to, the Notifications Center), the project registry (every project the token can see, by key, status, client and health, the clients they are done for, the components each is made of and the environments each runs in, with their addresses, branch, flags and health), the people of each project (the stakeholders it answers to, with their side, role, weight and approvals, and the personas it is built for, with their goals, frustrations and devices), the dictionary of each project (the glossary terms with their definitions and the data entities with their fields), the design references of each project (links to Figma files, prototypes, contracts and diagrams, with the version that is current), the repositories of each project (where the code lives, with the default branch and the component each builds, never for a guest token), the epics of each project (what it will deliver, by reference, goal, owner, priority and status), the backlog of each project (its stories, tasks, sub-tasks, bugs, spikes and improvements with their kind, status, priority, people, estimates, labels and acceptance criteria, what is assigned to the person the token acts as, the project's own label vocabulary with how many items carry each word, a story drafted into the backlog as a draft, an item moved along its lifecycle or handed to a colleague), the requirements of each project (what the system shall do and the qualities it shall keep, each with its category, measure, source, priority, verification method and status, and a requirement drafted as a draft a person reviews), the business rules of each project (the decisions of the business in plain words, with their condition and action, exceptions, worked examples, authority, priority, dates in force and status, and a rule proposed as a draft a person reviews), the use cases of each project (how a persona reaches a goal with the system, with the actor, the other actors, the goal, the trigger, the conditions before and after, the frequency, the priority, the status and the steps of the main flow with the alternate and exception flows that leave it), the RAID log of each project (the risks scored by probability and impact with their mitigation and contingency, the assumptions, the issues and the dependencies, each with its area, owner, dates and status, never for a guest token, and a risk raised as open by the person the token acts as), the decisions of each project (every choice the project made, with the context, the options weighed, what was decided, the consequences, who decided and when, and the decision each supersedes, never for a guest token, and a decision recorded as proposed for a person to accept), the links of each artefact (every link that touches it, both ends named, read from its side, never for a guest token, and two artefacts linked with a kind, a repeat refused rather than doubled), the comments on each artefact (the conversation oldest first, the open comments only for a guest token, and a comment posted in Markdown as the person the token acts as, the people named and the followers told), the files on each artefact (their names, kinds, sizes and the endpoint that streams them, the agreed record only for a guest token) and every version a save of them wrote (who wrote it, why and what changed, readable and restorable by staff), each project's settings (sprint length, working days, timezone, estimation, workflow flags and alert routing, staff only), teams, team members, roles and groups, personal access tokens, outbound webhook endpoints and their deliveries, and the activity log of every change. Full catalog.
• 3 resources: the ability, error-code and webhook-event catalogues. Agents load these for context before calling a tool. Reference.
• No prompts are shipped yet; the surface is tools plus resources. The agent playbooks (implement a story, write its tests, triage a defect) arrive with the planning and test modules.
• Fine-grained authorization. Every tool enforces its own ability (project:view-any, webhook-endpoint:create, …), the same one its REST equivalent requires, so a leaked token cannot act beyond the abilities you granted.
• Nothing hidden. Every change a tool makes lands in the activity log with you as the actor and mcp as the surface it came through, beside the changes made in the application.

Connection detailsCopy Anchor Link

• Endpoint: https://mcp.example.test, your workspace's address
• Transport: MCP streamable HTTP
• Server card: /.well-known/mcp/server-card.json on the application's address: the endpoint, the protocol versions, where the OAuth metadata is and how many tools and resources the server publishes, for a client that discovers before it connects (details)
• Auth: OAuth 2.1, where the client sends you to Zuse Bifrost to sign in and authorize with no token to copy, or Authorization: Bearer zg_live_... carrying the abilities of the tools you intend to call
• Ability catalog: the zusegenius://enums/ability resource
• Rate limit: 120 tool calls a minute per token; unauthenticated probes capped at 5 a minute per address

Which client?Copy Anchor Link

Example promptsCopy Anchor Link

Natural-language calls any MCP client can translate into tool invocations against the Zuse Bifrost surface:

• "Who am I acting as, and which team is this token scoped to?"
• "List the projects in discovery or planning and tell me which of them has no lead developer yet."
• "What changed on project CRM in the last day, and who made each change?"
• "Which webhook endpoints have failing deliveries, and what did the endpoint answer?"
• "Replay everything that dead-lettered since Friday evening; the consumer is back up."
• "Show my unread notifications, then mark the onboarding ones read."
• "Which roles exist on my team, and what may a business analyst do?"

Each tool's reference page includes more targeted examples.

RelatedCopy Anchor Link

• Quickstart, a two-minute setup.
• Authentication, OAuth connections and personal access tokens side by side.
• Tools reference, every tool with its required ability.
• Resources reference, the three catalogue resources.
• Security, token scope, revocation and the audit trail.