The MCP Knowledge Graph: a connector that learns how your systems connect

From proxy to smart connector

Most MCP gateways do one job: they expose your APIs as tools and pass calls through. That's useful — but it leaves the hard part to the AI. When a tool returns a customer_id, the agent has no idea that the same id is the key to look up orders in a different system. It guesses, and often guesses wrong.

AnythingMCP adds a layer on top of the raw tools: a knowledge graph of your connectors. It maps the entities your systems expose and how data flows between them, then teaches your AI agent to use them together — without you hand-writing the integration logic.

That's the difference between a proxy and a smart connector.

What the knowledge graph actually is

The graph is a private, per-workspace map with two kinds of elements:

Nodes

The entities your tools work with — a customer, an order, a product.

Edges

The relationships between them — references, same identity, produces / consumes, parent / child.

It is built from four layers, cheapest first:

StaticNo data needed

Read straight from your tool names and parameters. A get_customer_id tool implies a customer entity with an id field. Free, instant.

ObservedImproves with use

Learned from real tool calls. When a customer_id comes out of your CRM and the same value goes into your ERP, that's a data-flow edge.

ManualHuman-verified

Curated by a human in the UI, protected from the automated layers.

LLMOptional

An AI pass that spots that CRM.person and Billing.customer are the same real-world entity under different names.

Identifier values are never stored in the clear — the graph keeps salted hashes, so it learns the shape of your data without holding the data itself.

A concrete example: CRM → ERP

Say you've connected a CRM (contacts and deals) and an ERP (orders and invoices). Watch the edge get promoted from suggested to confirmed as data flows.

→The static layer extracts entities like Person, Deal, Order from the tool definitions.
→An agent calls crm.get_customers and a customer_id flows out — the observed layer records it.
→It then calls erp.search_orders(customer_id=…) and the edge Person → Order is promoted to confirmed.

AI skills: rules your agent reuses

Recurring patterns become skills — reusable business rules captured from how your tools are actually used, baked into the MCP server's instructions instead of re-explained on every request.

✦

Learned skill

revenue = orders in status 2, 3 or 4

kg_how_to_obtain: the graph as a tool

The graph isn't just internal. AnythingMCP exposes a kg_how_to_obtain tool. At runtime the agent asks how to get something, and gets back the chaining hint — which tool to call, and which field links the two systems.

agent ⇄ kg_how_to_obtain
// agent asks
“how do I get a customer's orders?”
// kg_how_to_obtain returns
→ call erp.search_orders(customer_id)
→ link Person → Order via customer_id

Why it matters

Fewer failed calls

The agent chains systems the way your data actually links, instead of trial and error.

Less prompt engineering

Integration knowledge lives in the graph, not a 2,000-word system prompt you maintain by hand.

Improves as you use it

Every successful tool call sharpens the observed layer.

Privacy-safe

Names and structure, never raw values.

Ship MCP to your stack in 60 seconds.

Spin up AnythingMCP on managed Cloud or self-host it on your infrastructure. Free for 7 days, no credit card.

Start free on Cloud Self-host with Docker