--- title: "Coordination Loop" slug: help-coordination-loop section: In-App Help status: stable description: "In-app help · How this site, the MCP coordination server, Asana, and the other portals stay aligned" last-updated: 2026-10-07 --- # Coordination Loop In-app help · How this site, the MCP coordination server, Asana, and the other portals stay aligned > **Read this first** > > New engineers and agents working across the AAG ecosystem keep asking the same question: how do all of these portals stay aligned, what does the MCP server actually do, and where does Asana fit? This page is the answer. If you only have two minutes, read The End-to-End Loop. ## Source of Truth This site is the source of truth for ecosystem architecture. Everything that defines how the AAG ecosystem fits together lives here: - Data models (tables, columns, enums, status flows) - Event contracts (event names, payload shapes, producers, consumers) - Ownership rules and system boundaries (who owns what, which portal can write what) - Roadmap projects and their build status (see the Delivery Overview page for the live, current list) - Glossary terms used across the ecosystem - RBAC, finance/NetSuite triggers, notification model - Sidebar and page structure of the documentation itself If two portals disagree on a contract, this site wins. The other portals (Partner Portal, GLOBUS Hub, Applicant Portal) implement what is documented here. ## What MCP Is (and Isn’t) The MCP coordination server is a separate service running at mcp.allianceabroad.com. Its job is to store and broadcast the latest snapshot of ecosystem state so downstream portal agents can read current contracts before they build. MCP IS - A snapshot store of current architecture - A broadcast point that downstream portal agents poll - A coordination registry of which portals exist (IDs 1, 2, 3) - The place this site pushes updates to after every change MCP IS NOT - This app — it runs on a different host - A PR validator or CI gate - A workflow runtime, queue, or rules engine - A source of truth on its own — it mirrors what this site publishes > **MCP does not validate PRs** > > Nothing in MCP blocks a downstream portal from merging a PR that contradicts the architecture. Alignment is enforced procedurally (everyone reads MCP before building, this site syncs after every change), not by automated gates. ## The End-to-End Loop Here is the loop a single ecosystem change travels through, from idea to implemented in a downstream portal: s agent calls MCP to get the current ecosystem snapshot \u2014 contracts, ownership, glossary, statuses \u2014 so it implements against today > **Procedural, not automated** > > The loop works because every participant does their part: this site syncs after every change, and every downstream agent reads MCP before building. There is no webhook that fails a PR if you skip a step — only stale code if you do. ## Two Auth Surfaces There are two different auth headers in this flow, on two different servers. Mixing them up causes silent failures — this is the most common debugging trap. | Surface | Server | Header | Secret | | --- | --- | --- | --- | | Local proxy guard | This Express app | x-admin-key | SESSION_SECRET | | Upstream MCP tool calls | GLOBUS Hub MCP | Authorization: Bearer | MCP_API_KEY | > **Same name, different secrets** > > The header name x-admin-key is reused on this app's local proxy and on the upstream Admin REST API — but they check different secrets. Our local proxy never sees MCP_API_KEY; it forwards through the upstream client, which adds an Authorization: Bearer header on its own. If you get a 403 on a local route, it's the local guard; if you get a 401 from upstream, it's the MCP key. ## MCP Endpoints This Site Exposes This app exposes three local proxy routes that forward to the upstream MCP server. Each requires the x-admin-key header with SESSION_SECRET. > **Local Proxies vs Upstream MCP Tools** > > These three routes are just the local coordination proxy exposed by this React app. The upstream MCP server itself is a full Model Context Protocol provider that exposes 16 live tools to AI consumers (Claude, Manus, etc.), covering documentation search, project delivery status, and live Business Intelligence metrics. See the AI Connector Spec and BI Tools pages for the full surface. | Method | Route | Purpose | | --- | --- | --- | | GET | /api/mcp/ecosystem-context | Read the full current ecosystem state stored in MCP. | | POST | /api/mcp/heartbeat | Send a heartbeat with an agentContext string describing current activity. | | POST | /api/mcp/sync-status | Report a change with a notes string describing what was added/modified/removed and the impact on other portals. | ## Circuit Breaker & Resilience Connections from this app to the upstream MCP server implement a circuit breaker pattern to protect against cascading failures. This is critical operational knowledge when debugging MCP connectivity issues. - Threshold: 3 consecutive failures open the circuit. - Reset Interval: 60,000ms (60 seconds) before the circuit enters a half-open state to test recovery. - Health Status: The internal getMcpHealth() method exposes the state as closed | open | half-open, along with the failure count and last success timestamp. ## Ecosystem Portals Three portals participate in the coordination loop. Each has a numeric ID used by MCP to identify the publisher of a heartbeat or sync. | Portal ID | Name | What They Care About | | --- | --- | --- | | 1 | Partner Portal | Partner governance, RBAC, entry flows, finance display rules. | | 2 | GLOBUS Hub | Data models, event contracts, ownership rules, all capability layers. | | 3 | Nexus Docs | This site — the documentation and the publisher of every sync. | ## Common Questions > **Related** > > See the Documentation Hub for how to navigate this site, and the Portal Integration Contract for the technical contract every portal implements. > **See also: AI Connector Spec** > > For how the same MCP coordination server is being extended to act as an AI-tool connector (Claude Desktop, Cursor, Windsurf, ChatGPT, Manus), see the AI Connector — MCP Server Activation Spec . That is a handoff contract to the MCP repo, not implementation work in this site.