Build on the memory.

Your agent reads — and acts on — the memory.

Two endpoints, one contract. https://mcp.meetcrew.ai/v1 speaks MCP over Streamable HTTP; https://api.meetcrew.ai/v1 is the same memory over ordinary REST. They return the same records with the same field names, so the choice is about how your agent is built, not about what it can see. Authenticate either with a Microsoft Entra bearer token for a service principal you grant in the admin console — the same token works on both. The tenant is derived from the token — a client can’t reach another tenant’s memory even by guessing IDs. Each grant names one deployment (one named teammate), and reads and actions are scoped to it. If an administrator has shared another teammate’s memory with that one, on the teammate’s Sharing tab, list, search and topic reads include those records too, each carrying its own deployment_id. Shared records can be read but not changed through this grant, and getMeeting does not reach the other teammate’s meetings. A grant also carries a scope: read serves every read, and the four actions need read_write, which your admin selects when issuing the grant.

Before the first token. Your agent requests its token from your own Microsoft Entra directory, and Entra issues it only after a Global Administrator or Privileged Role Administrator there has authorized MeetCrew — once, for the whole organization. Do it from the admin console (Workspace → Authorize MeetCrew in Microsoft Entra), or have that administrator open https://login.microsoftonline.com/organizations/adminconsent?client_id=569124d5-6864-418d-91b6-8e0f668440ae&redirect_uri=https%3A%2F%2Fadmin.meetcrew.ai%2Fentra-consent signed in to your directory; they don’t need a MeetCrew account. Until then the token request fails with AADSTS500011 before it reaches MeetCrew. The same consent lets MeetCrew read users’ basic profiles, for naming meeting speakers and answering data-subject requests.

The grant and the token. A Tenant Administrator creates the grant in the admin console, naming your agent by its service principal’s Object ID — the Object ID on its Enterprise application in your directory, not the Application (client) ID and not the app registration’s own Object ID; a grant made with either never matches the agent’s token. Your agent then requests an app-only token with the client-credentials flow, from your own tenant’s endpoint https://login.microsoftonline.com/{your-tenant-id}/oauth2/v2.0/token — Entra refuses this flow at /organizations and /common — with scope api://569124d5-6864-418d-91b6-8e0f668440ae/.default. A token issued to a person is refused, even when a grant names that person.

Resources

Tools

Every id — deployment, meeting and record — is a GUID; anything else is refused. Every record — a decision, open question, action item or statement — carries attribution — a Microsoft Entra platform identity, or anonymous — plus created_at, deployment_id and origin. A topic carries neither attribution nor origin. An entra_id is the person’s Entra object ID where MeetCrew knows it and their email address otherwise, so don’t validate it as a GUID. A decision’s status is recorded, confirmed or superseded, and it lists its participants; an action item carries assignee and due_date; a decision or open question with a note carries it as note. origin is extracted when MeetCrew took the record from a meeting, and external when it was created through an Action or the MeetCrew console; an external action item may have no meeting_id. A record an Action or the console has changed also carries externally_updated_at. No voiceprints are ever used for attribution. limit is at most 1000 and defaults to 100. There is no pagination: next_cursor is always null, and was_capped is true when rows were left behind — narrow since, until or meeting_id rather than asking for more.

Actions v1

Actions are confined to workflow state on action items, decisions, and open questions. There is no delete, and no action can alter a transcript, a statement, provenance, or the audit log. Every action is authenticated, tenant- and deployment-scoped, and logged. An action returns only { "id", "applied": true } — on a create, the new record’s id — so read the record back to see its new state. An explicit null in an optional argument is the same as leaving it out, here and over REST alike: it never clears anything. To remove a due date or a note, send clear_due_date or clear_note.

REST — the same memory, ordinary HTTP v1

Base https://api.meetcrew.ai/v1. Every route is deployment-scoped, and the tenant is never in the path — it comes from the token. Responses carry the same records as the MCP tools above, field for field.

PATCH rather than PUT, because none of these replaces a record: only workflow state can change. On an action item every field is optional, but at least one must be present; on an open question or a decision status is required. Each answers 200 with { "id", "applied": true }. A parameter or body field we don’t recognise is refused, not ignored — a dropped filter would return more than you asked for, and a dropped field would mean a change you believe you made didn’t happen.

Errors, limits and versioning

Over REST, a failure MeetCrew’s own handlers produce is an RFC 9457 problem document. Three answer with an empty body instead: a token that fails validation (401), the rate limit (429), and an id in the path that is not a GUID (404, because no route matches). Over MCP, once the token and the rate limit are past, a failure is a JSON-RPC error inside an HTTP 200: -32602 for invalid arguments, refused access and records that don’t exist, -32603 where REST would answer 502 or 503, -32601 for an unknown tool, resource or method, and -32600 or -32700 for a request that is not a single valid JSON-RPC object. A notification is answered 202 with no body. Match on the status or error code, never on the message text — wording can change without notice. Over MCP that means -32602 cannot tell a refusal from a missing record; if your agent must, use REST.

Calls on both endpoints are logged with the Entra identity that made them. The audit archive keeps every action as its own event and reads as a daily record of which identity read which teammate’s memory, and the two are retained differently, which matters when you are answering a question about something months old. Trust & Security has the retention periods.

Within v1 we add, we don’t remove: new fields, parameters, endpoints and enum values can appear at any time, so ignore what you don’t recognise rather than failing on it. Nothing is renamed or removed, and no status code changes meaning. A breaking change means a new prefix served alongside this one. Our policy is to give the administrator who issued your grant 90 days’ notice by email before deprecation, and at least 180 days more before v1 stops answering.

Example — search memory

// MCP tools/call
{
  "name": "searchMemory",
  "arguments": {
    "deployment_id": "8f14e45f-ceea-467a-9575-8b3d4c2f1a90",
    "query": "pricing decision",
    "types": ["decision", "open_question"],
    "since": "2026-06-01",
    "limit": 2
  }
}

// result.structuredContent
{
  "results": [
    {
      "id": "c3e7a1d4-5b29-4f80-9a6e-1d2c8b7f0e35", "type": "decision",
      "text": "Hold list pricing flat through Q3; revisit at QBR.",
      "created_at": "2026-06-30T16:20:00+00:00", "decided_at": "2026-06-30T16:20:00+00:00",
      "deployment_id": "8f14e45f-ceea-467a-9575-8b3d4c2f1a90",
      "meeting_id": "4823ab90-77c1-4e2f-9d5a-6b0e3f8c1d24",
      "origin": "extracted",
      "attribution": { "kind": "platform_identity", "display_name": "Priya Shah",
                       "entra_id": "3b9e6c21-7d4f-4a08-9e5b-c1f2a7d80e46" },
      "participants": [
        { "kind": "platform_identity", "display_name": "Priya Shah",
          "entra_id": "3b9e6c21-7d4f-4a08-9e5b-c1f2a7d80e46" },
        { "kind": "platform_identity", "display_name": "Dana Ruiz",
          "entra_id": "f4d81b07-62ac-4e95-b3d0-8a7e2c19f564" }
      ],
      "status": "recorded", "score": 8.42
    },
    {
      "id": "6a0b9e12-84d3-4c57-b1f8-03e9d5a2c764", "type": "open_question",
      "text": "Do enterprise renewals get the same flat-pricing treatment?",
      "created_at": "2026-06-30T16:24:00+00:00", "raised_at": "2026-06-30T16:24:00+00:00",
      "deployment_id": "8f14e45f-ceea-467a-9575-8b3d4c2f1a90",
      "meeting_id": "4823ab90-77c1-4e2f-9d5a-6b0e3f8c1d24",
      "origin": "extracted",
      "attribution": { "kind": "platform_identity", "display_name": "Marco Bianchi",
                       "entra_id": "a07c5d92-1e3b-4f6a-8c24-5b9d0e7f3a18" },
      "status": "open", "score": 5.17
    }
  ],
  "was_capped": false,
  "next_cursor": null
}

Example — close an action item

// MCP tools/call
{
  "name": "updateActionItem",
  "arguments": {
    "deployment_id": "8f14e45f-ceea-467a-9575-8b3d4c2f1a90",
    "action_item_id": "e5d2f871-0c4a-4b96-8d13-9f7a2c6b4e08",
    "status": "done"
  }
}

// result.structuredContent — the change applied; read the item back to see its new state
{ "id": "e5d2f871-0c4a-4b96-8d13-9f7a2c6b4e08", "applied": true }

Example — the same two calls over REST

Same token, same records. Only the envelope differs.

# search
curl -H "Authorization: Bearer $TOKEN" \
  "https://api.meetcrew.ai/v1/deployments/8f14e45f-ceea-467a-9575-8b3d4c2f1a90/search?q=pricing+decision&types=decision,open_question&since=2026-06-01&limit=2"

# close an action item
curl -X PATCH -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" -d '{"status":"done"}' \
  "https://api.meetcrew.ai/v1/deployments/8f14e45f-ceea-467a-9575-8b3d4c2f1a90/action-items/e5d2f871-0c4a-4b96-8d13-9f7a2c6b4e08"

// the search answers 200 with the same body as the MCP result above, field for field
// the PATCH answers 200 with
{ "id": "e5d2f871-0c4a-4b96-8d13-9f7a2c6b4e08", "applied": true }

First 15 minutes.

Zero to a teammate answering in a test meeting, and your agent reading that meeting’s memory over MCP.

1. Sign in to the admin console as a MeetCrew Tenant Administrator. There is no region to choose: every tenant is hosted today in Microsoft Azure’s US East region.
2. Create a deployment — name the teammate (say, “Jim”), set its wake word, and pick a character and voice. The meeting platform comes from the meeting link when you launch the teammate. This provisions memory scoped to Jim’s deployment, identified by a GUID such as 8f14e45f-ceea-467a-9575-8b3d4c2f1a90.
3. Choose Custom webhook as the backend, and enter its endpoint and webhook signing secret. The secret is write-only: afterwards the console shows at most its last four characters.
4. Stub the backend: return { "content": "Hi, I'm Jim." } and confirm it answers inside the budget on metadata.timeout_ms.
5. Admit the teammate into a test meeting. Confirm the disclosure banner shows Jim as AI.
6. Say “Jim, are you there?” and hear the stubbed reply. The backend contract now works end to end.
7. Switch the backend to your real agent — Copilot Studio, Microsoft Foundry, an OpenAI-compatible endpoint, or your own webhook — with that backend’s credential. A webhook composes its reply from system + messages.
8. Authorize MeetCrew in your Microsoft Entra directory: Workspace → Authorize MeetCrew in Microsoft Entra. It takes a Global Administrator or Privileged Role Administrator, once per organization, and the card gives you a link to send one. Skip it and your agent’s token request fails with AADSTS500011.
9. Grant your agent MCP access — a Tenant Administrator creates a service-principal grant in the console, using the Object ID of your agent’s Enterprise application. Choose read and write if your agent will use the actions; read-only is the default, and the four actions are refused under it.
10. Request an app-only token from your own tenant’s token endpoint with scope api://569124d5-6864-418d-91b6-8e0f668440ae/.default, and connect your MCP client to https://mcp.meetcrew.ai/v1 with it. List meetcrew://deployments and confirm Jim’s deployment_id appears.
11. Call listDecisions with that deployment_id, then getMeeting with a meeting_id from one of the decisions. Your agent is now reading cross-meeting memory. Ship from here.