CompanyGraphover MCP.

We are working toward companies whose knowledge is written once, in a structure that the people who run them and the agents working beside them can both rely on — so that what a company knows can be read, checked and acted on where it is needed, rather than reassembled out of wikis, decks, tickets and chat threads every time somebody asks.

The endpoint

Three paths, and only one of them speaks the protocol. Add https://mcp.companygraph.io/mcp to a client that takes a remote MCP server by URL.

• POST/mcpThe protocol. Streamable HTTP, one snapshot, no session.
• GET/healthWhether the server is up, and the model commit it answers from.
• GET/This page. A browser gets it; GET /mcp is a 405 on purpose.

Or run one against the same model over stdio, with no server at all:

npx --package github:companygraph/mcp-server companygraph-mcp ./model ./meta/core

What it answers

• list_typesEvery type the instance's schemas declare, with its tagline, its owner type and how many entities it holds.
• describe_schemaOne type's schema as the instance vendors it: file location, frontmatter fields, sections and their columns, purpose and writing rules. Its relations come beside it as data, both ways: the type that owns it, the types it owns, each reference it declares and each reference another schema declares to it, with how many a page may hold, the values each of its enums permits, and the joins and list kinds the schema declares.
• describe_relationsEvery reference the schemas declare between types, as data read from their tables: the type that declares it, the field or Section.Column it is declared on, the type it names, its form (ref, ref? or qualifier), whether it is a list, whether it is required and how many of it a page may hold (min and max); which type owns which; the values every field or column typed enum permits; the joins a schema declares between its tables, among them the tables whose repeated references carry distinct roles; and the kind of list each list section holds. Every term is explained in the answer. The whole vocabulary and what it constrains in one answer, for a diagram or an audit.
• list_rulesThe rules the instance is held to, from the CONVENTIONS.md its core vendors: each rule's number, its title and the part of the file it stands in. A schema cites a rule by number, such as R9, and this is where the number is read.
• describe_ruleOne rule as written, by its number.
• list_checksEvery check the checker runs over an instance, from the checker release this server was built with: what each is called, the rule it cites and that rule's title. A list and no verdict, since this server runs none of them; the answer says who does. It shows which rules a script enforces and which are left to a reader.
• list_entitiesThe id, canonical name and tagline of every entity of one type.
• get_entityOne entity by type and canonical name: its frontmatter, sections and tables, with every reference it makes and every reference made to it. A name resolves within its type; a name of an owned type, such as an experience or a phase, is unique only within its owner, and one held by two owners is refused with every id named, for fetch.
• find_evidenceEverything the model says about one skill, every edge into it grouped by the type of the page that drew it: a profile's claim, via Skills.Skill, with its level; each evidence row under that claim, via Evidence.Skill, with what it shows and the experience it came from; each experience that lists the skill; and any other page that references it. Attributes are verbatim.
• searchEntities whose name, tagline, fields, sections or table cells contain the query, case-insensitive, listed by type then name with the fields that matched. Use fetch with a result's id.
• fetchOne entity by the id search returned, with its page as written. A bare name is accepted only when exactly one type holds it.

What it reads

A snapshot of companygraph/mental-model@ff8611c, parsed at build time against the core that instance vendored, core 0.37.0 with parser v0.38.0. Every answer carries that commit, so an answer can be checked against the files it came from.