Connect your agents
Your coding agents can read the same knowledge your team reads in the console. With the Knowledge MCP server, an agent checks what depends on a component, which norms apply, and what the book says before it plans a change.
The Knowledge MCP server is set up with your organization during onboarding. If you'd like to try it, reach out to us.
Use Knowledge from your coding agent​
The Knowledge MCP server works with any MCP client, such as Claude Code, an IDE assistant, or a workflow. It has no data of its own: every tool reads your organization's catalog with the credential the server runs with, so the agent sees what that credential can see.
Once it's connected, ask in plain language. The agent picks the tools:
| You ask | What the agent does |
|---|---|
| "What breaks if the payments core goes down?" | Lists every consumer with who_consumes, follows the chain with blast_radius, and cites the file and line behind each relation |
| "We're upgrading the core banking system in Chile. Which apps do we have to touch?" | Finds every application that calls it and the operation each one uses |
| "If we rotate the shared Redis credential, who do we have to tell?" | Lists the components that store in that Redis and the namespaces they belong to |
| "I need to send a transactional notification to a customer. How do we do it here?" | Searches the books and the know-how with catalog_search, then reads the norms that apply |
| "Notifications stopped at 3 AM. What do I check, and what shouldn't I do?" | Reads the application's runbook, the norms of its domain, and who to ask |
| "Add rate limiting to the orders API." | Calls plan_work to get, in one call, the candidate components, their contracts, what the change can break, and the norms to respect |
Read tools​
| Tool | What it's for |
|---|---|
catalog_search | Search books, documents, facts, and know-how in natural language, in any language. The usual entry point |
list_components | List components, filtered by namespace, account, text, or kind |
get_component | A component's card: identity, criticality, relations in and out, the know-how that applies, and the index of its facts and documents |
get_facet | The full content of one fact, with its provenance and evidence |
get_doc | A full document, such as the book, the runbook, or the risks |
get_hierarchy | The tree of accounts, namespaces, and applications |
org_index | Organization-wide indexes, such as internal APIs or libraries and who consumes each one |
get_knowledge_map | The knowledge graph, with each relation's type, provenance, and sources |
who_consumes | Who calls an API, queue, library, or identity provider. Answers "who breaks if I change this?" |
blast_radius | The impact of a change, several hops deep, toward what depends on a component or what it depends on |
plan_work | A briefing for a feature or a bug: where to make the change, what to respect, and what can break |
deploy_checklist | Checks a component's effective norms against its observed facts before a deployment |
get_norms | The norms that apply to a component, from the organization down to the application. The most specific one wins |
get_instructions | The investigation instructions your curators wrote for the analysis |
list_lore, list_rules | Every norm, piece of know-how, and identity rule, with where it applies |
list_questions, list_findings | Open questions and findings, for an application or for the whole organization |
list_suggestions | Open suggestions: places where the evidence contradicts what Knowledge says |
Write tools​
Agents can also contribute. They can record a relation they discovered with its evidence (add_edge), describe something the analysis can't see, such as an external vendor (create_node, upsert_facet, upsert_doc), ask your team a question (ask_question), or answer one (answer_question). Every write is attributed to the agent.
Write tools follow the same rules as people. An agent never overwrites what a person wrote. When it disagrees, it opens a suggestion with create_suggestion. Agents can't write investigation instructions, and a refuted relation is marked as refuted, never deleted.
Point your agent at Knowledge before it starts exploring the repository. A single plan_work or catalog_search call usually replaces most of the exploration, and it brings the context the code doesn't have.
Related docs​
- Knowledge overview: what Knowledge holds and how much to trust each fact
- Explore your software: the same knowledge in the console
- Contribute knowledge: answer questions and add know-how
- MCP server: the nullplatform MCP server for platform operations, such as deployments and scopes