Common integration questions.

No. Mandaire is a standard MCP server. Add one URL to your AI client and auth runs automatically.

No package to install. No client library to import. One URL, one permission grant, everything available.

OAuth 2.1 with Dynamic Client Registration. For Claude.ai and Claude Desktop, the OAuth flow runs automatically on first connect. You are redirected to Mandaire to authorize, then returned to your AI. No token rotation to manage yourself.

For custom clients: send a DCR POST /register to receive a client_id, exchange for a bearer token, attach to every request. The full OAuth metadata is at https://mcp.mandaire.com/.well-known/oauth-authorization-server.

One permission grant covers all routine access. You do not request per-tool or per-kind permissions separately.

Mandaire is in private beta. Request MCP access with a quick note on what you are building and which renderer you are using. We prioritize integrations with active development.

Three possible causes, in order of likelihood:

1. The fact is not in the graph yet. Check absent_knowledge_caveats in the response envelope. If Mandaire has no record for that person or event, the field will say so explicitly. This is expected for people or topics the user has never mentioned.

2. A disclosure policy hold. The query passed technically but the disclosure policy filtered the result. Check disclosure_applied. If filtered: true, the data exists but the user's policy blocked it for this caller or context. Do not retry with a different framing to circumvent this. The filter is intentional.

3. Wrong from_kind. A query for a person via from_kind="email" returns emails, not a person profile. Use from_kind="person" with depth="deep" to get the full profile including communications.

When the result is empty and the cause is (1), the envelope includes a writeback_slot_id. See writeback slots.

Two options:

The partial read-kind list: person, email, message, event, photo, trip, note, file, topic, context, recall, open_commitments, catch_me_up, entity_state, inference_claim, open_writeback_slots.

Write kinds: ai_observation (INSERT), correction, task, state, inference_claim (UPDATE to confirm or reject).

Default (depth="standard") returns the profile fields most relevant to the query. Use depth="deep" when you need the full picture for a person: all aliases, relationship history, recent communications, open commitments, inferred context. One call, no follow-up calls needed.

The data owner's calls auto-upgrade to deep. External caller defaults remain standard unless specified.

Phrase your output to match it. Do not present a 0.6 result as certain. A few practical rules:

Also check expectedness: SUPPRESS means the user already knows this, SURFACE_NOVEL means lead with it, SURFACE_INTERESTING_IF_TRUE means surface it with the appropriate hedge.

Three situations:

1. The user directly tells you something new. The user says "Scott just took the CTO role at Inflection." That is a claim_source="user_direct" INSERT with confidence ≥ 0.80.

2. A query returned a writeback slot. The SELECT returned empty and included a writeback_slot_id. Disclose the gap to the user. If they fill it in conversation, write it back with the slot ID.

3. You have inferred something with high confidence. Use claim_source="ai_inference" and keep confidence at or below 0.50. Low-confidence rows enter a 30-day review window before they influence future responses.

Do not write back information you are uncertain about at high confidence. Overstating confidence is worse than understating it.

When a SELECT returns empty (count: 0 or found: false), the response envelope includes a writeback_slot_id. The slot is Mandaire saying: I do not know this yet. If the user tells you, close the loop.

Slots expire after 14 days if never closed. You can query open slots: mandaire(from_kind="open_writeback_slots").

The INSERT is rejected before it reaches storage. PII pattern detection runs on every ai_observation and rejects claims containing raw credentials, payment data, SSNs, or passwords.

You do not need to pre-filter for these patterns. Write the claim as the user stated it. Mandaire rejects before storage and returns a clear error describing what was blocked.

High-confidence rows (≥ 0.80 user-attributed) land silently and immediately influence future responses. Low-confidence rows (< 0.50) enter a 30-day review window. There is no penalty for being conservative. There is one for overstating.

Every SELECT response includes a disclosure_applied field confirming that the user's disclosure policy ran before the response was returned:

If filtered: true, some fields were withheld by the policy. The response is complete as returned. Do not attempt to re-query or re-frame the request to get the withheld data. The filter is intentional and runs upstream of your call.

You do not need to implement your own disclosure logic. Mandaire handles it before your AI sees the result.

Sensitive from_kind values require an explicit purpose= parameter. Without it, the call is rejected with a hint naming the required purpose.

Sensitive kinds include: correction_history, disclosure_policy, health data, personality profiles. Routine kinds like person, email, event, and recall do not require purpose by default.

If your query is rejected with a purpose_required error, the error message tells you what purpose value to include. The field is explicit by design: it creates an audit record of why the data was accessed.

Surface them. Do not invent answers. Two tools:

absent_knowledge_caveats in every response. These are facts Mandaire knows it does not have. "Last interaction: 3 months ago" is a fact. Tell the user.

Writeback slots when a query returns empty. Disclose the gap: "I do not have that in the graph yet." If the user provides the information, write it back. The next query finds it.

A gap surfaced honestly is more useful than a plausible answer invented from training data. Training data ages. The graph does not.