MCP reference

Server

Unauthorized: the request is missing a valid Company Brain token.

The brain does not have enough content yet to build the knowledge graph. Try again once the organization has added more.

Workflow

Company Brain is the organization's permission-scoped knowledge graph: people, departments, processes, systems and tools, AI agents, strategies, data sources, policies, and the relations between them.

1. Call get_skill_pack once at the start of a session for a compact, tier-scoped operating map. It cites the same node ids as the index.
2. Call query_index to find relevant nodes.
3. Call read_concept with a node id, shown in brackets, for details and relations. Always cite the node ids your answers build on.
4. Call write_inbox to propose new knowledge: an observation, a correction, a proposal or a work output. Proposals are never written directly into the brain. A manager must approve them in the portal inbox first.

For onboarding, call get_onboarding_status first, then get_onboarding_action_catalog for exact schemas, and use propose_onboarding_action for verified structured changes. Onboarding proposals sit behind the same manager approval, and the external client never applies them itself.

Your token carries two independent limits. Its access tier decides which knowledge it may see; matches behind a higher tier are hidden and only reported as a count. Its scopes decide which tools it may call: the reading tools require brain:read, and both proposal tools require brain:propose on top of the viewer role and manager approval boundaries. A tool called without the scope it needs is refused as Forbidden and registers nothing: report the missing scope to the user instead of retrying.

Knowledge status: nodes and relations may be marked as an inferred hypothesis or an unresolved mapping. Qualify those in your answer and never present them as established facts. Each mark is a warning sign followed by the phrase "inferred hypothesis; needs confirmation" or "unresolved mapping; not a fact"; match on the phrase, not the whole line. Unmarked items are verified.

Tools

get_skill_pack

A compiled, versioned operating map of the organization for this token's tier: org overview, departments and people, processes with owners and provenance, systems, agents, data sources and open gaps. No input. It is a map, not the source. Not annotated read-only, because a changed graph may append a new derived revision to the internal registry. It never changes knowledge.

query_index

Ranked search across the visible graph. Input: query (string, at least 2 characters), types (optional array of node types), limit (optional integer, 1 to 20, default 10). Returns hits with node ids for follow up. Matches behind a higher tier are hidden and only counted. Read-only.

read_concept

Full information about one node: metadata, summary and all relations to other visible nodes. Input: id (string, a node id from query_index). Gives one refusal for an unknown id and a different one for a node above the token's tier. Read-only.

list_gaps

The weakest spots of the visible graph: unresolved clarifications, theme pairs held together by a single relation, sparsely covered areas, and evidence whose review is due. No input. Every line starts with a stable marker. Read-only.

write_inbox

Registers a proposal in the organization's inbox. Never writes to the brain. Input: kind (one of observation, correction, proposal, work_output), title (string, 3 to 120 characters), body (string, 10 to 4000 characters), relatedNodeIds (optional array of up to 10 node ids). Requires brain:propose. Returns a receipt with the inbox id, the kind and the status.

get_onboarding_status

How far the organization is through the seven onboarding steps, how ready its evidence is, and which area is required next. No input. Returns counts and step state, never the people roster or document contents. Read-only.

get_onboarding_action_catalog

Every supported onboarding proposal action with its exact JSON Schema and risk level. No input. Call it before you propose, instead of guessing field names or enum values. Read-only.

propose_onboarding_action

Submits one validated onboarding change to the approval inbox. Input: action (one of the catalog's action names), summary (string, 3 to 160 characters, shown to the approver), details (object matching the selected action's schema). Manager or admin token required, plus brain:propose. Never applies the change itself.

propose_draft_email

Creates a proposal for an email draft. Input: to (array of 1 to 10 email addresses), subject (string, 1 to 300 characters), bodyText (string, 1 to 20000 characters). Requires outreach:propose. It does not create the draft and it does not send anything: a manager must approve the proposal first, and on approval the draft is created in the approver's own mailbox for them to review, edit and send by hand. Nothing is ever sent by AiAx. The approval id is derived from the content, so a replayed call resolves to the proposal that already exists.

The machine contract

Every answer mixes two registers, and only one of them is a contract. Display text is rendered in the organization's own language, so a client that keys on anything display shaped breaks the day an organization switches language.

Stable, locale independent, safe to parse:

• Node ids in [brackets], and the wiki reference module and entity ids.
• Node type labels, always the English set: organization, person, department, project, agent, SOP / process, tool, strategy, data source, policy.
• Relation verbs, always the English set: is part of, belongs to, manages, works on, owns, uses, depends on, governs, can access, supports, champions, targets, needs clarification with.
• Access, rendered as the enum literal itself and never its label: public, department, project, manager, hr, executive, restricted.
• The two knowledge status mark phrases, "inferred hypothesis; needs confirmation" and "unresolved mapping; not a fact", each preceded by a warning sign in the emitted line; match on the phrase.
• Metadata keys, always English: Title, Coverage, Owner, Relation, Model, Approval threshold, Score, Quadrant, Estimated savings/year.
• Freshness fields (Evidence status, Verified, Review by) and every other timestamp, as ISO 8601 instants and never formatted dates.
• Gap markers, one per line, of the form [gap:<kind>] where kind is one of clarification, thin_link, sparse_theme, stale_evidence.
• Input bounds: the schemas listed under Tools, including the limit range and the enums.
• Refusal and empty state answers, verbatim, and the two distinct read_concept denials.
• Write receipts and skill pack registry lines, including the revision, the content hash and the generation timestamp.

Not a contract, and display text in the organization's language: titles, summaries, metadata values, tags, gap sentences and every section heading. Quote them, never parse them.

- [gap:stale_evidence] <sentence in the organization's language>