Summary
AnythingMCP isn't just an MCP proxy — it builds a knowledge graph of your tools so AI agents know how to chain a customer in your CRM to their orders in your ERP. Here's how the smart connector works.
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:
- Static — read straight from your tool names and parameters. A
get_customer_idtool implies a customer entity with an id field. Free, instant, no data required. - Observed — learned from real tool calls. When a
customer_idcomes out of your CRM and the same value goes into your ERP, that's a data-flow edge. Free, and it gets more confident the more you use it. - Manual — curated by a human in the UI, protected from the automated layers.
- LLM (optional) — an AI pass that spots that
CRM.personandBilling.customerare 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).
- The static layer extracts entities like Person, Deal, Order from the tool definitions automatically.
- An agent calls
crm.get_customersand acustomer_idflows out. The observed layer records it. - The agent then calls
erp.search_orders(customer_id=…)and the same value flows in. The edge Person → produces/consumes → Order via customer_id is promoted from suggested to confirmed.
From then on, your agent knows to chain CRM → ERP correctly — no extra prompting, no brittle glue code.
AI skills: rules your agent reuses
Recurring patterns become skills — reusable business rules captured from how your tools are actually used. For example, "revenue = orders in status 2, 3 or 4" can be learned once and applied every time, baked into the MCP server's instructions instead of re-explained on every request.
kg_how_to_obtain: the graph as a tool
The graph isn't just internal. AnythingMCP exposes a kg_how_to_obtain tool to your agent. At runtime the agent can ask "how do I get a customer's orders?" and get back the chaining hint — which tool to call, and which field links the two systems. The model spends fewer tokens guessing and makes fewer wrong calls.
Why it matters
- Fewer failed calls. The agent chains systems the way your data actually links, instead of trial and error.
- Less prompt engineering. The integration knowledge lives in the graph, not in a 2,000-word system prompt you maintain by hand.
- It improves as you use it. Every successful tool call sharpens the observed layer.
- Privacy-safe. Names and structure, never raw values.
Get started
The knowledge graph is built into AnythingMCP Cloud and the self-hosted edition. Connect two systems that share an identifier, run a few calls, and watch the edges light up.
Was this guide helpful?