F
licenseNot graded
qualityD
maintenanceAn MCP server that enables graph database interactions with Neo4j, allowing users to access and manipulate graph data through natural language commands.
graphite-mcp
Officialby GraphiteAI
The graphite-mcp server provides access to the Graphite Financial Knowledge Graph, enabling AI agents to query and analyze information about companies, executives, supply chains, regulations, patents, and more.
search_entities: Free-text search for companies, people, patents, products, regulations, or events by name, ticker, sector, or keyword (e.g., find all semiconductor companies or search for "NVIDIA").get_entity: Retrieve full details for a specific entity using its ID (e.g.,company:NVDA,person:TIM_COOK_AAPL).get_relationships: Fetch all relationships connected to an entity, such as suppliers, competitors, partners, or dependencies.get_facts: Access factual/structured data for an entity, such as revenue figures and employee headcount.find_path: Discover the shortest connection path between two entities in the knowledge graph (up to 6 hops by default).exposure_analysis: Analyze a company's risk exposure through 1st and 2nd-degree connections, sector concentration, and supply-chain dependencies.compare_entities: Compare two entities side-by-side, revealing shared connections, direct relationships, and graph distance between them.
Allows AI agents to query the Graphite Financial Knowledge Graph for company information, supply chains, executives, regulations, and patents.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@graphite-mcpWhat is NVIDIA's exposure to TSMC?"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
graphite-mcp
MCP server for the Graphite Financial Knowledge Graph — wires the graph into Claude Code, Claude Desktop, Cursor, Codex CLI, and any other MCP-compatible client.
Your Claude / agent does the reasoning. Graphite answers the graph questions it asks for. No LLM tokens are billed by Graphite — you bring your own LLM (subscription or API key); we only serve graph data.
Install
pip install graphite-mcpOr from source:
git clone https://github.com/GraphiteAI/graphite-mcp
cd graphite-mcp
pip install -e .Related MCP server: Neo4j YASS MCP
Get a Graphite key
Free tier — 100 graph queries / month — at: https://graph.graphite-ai.net/#/portal
Sign up with your email; you get back a key like sk-….
Chat-with-the-graph in the web portal is BYOK — you bring your own Anthropic or OpenAI key (it stays in your browser). Or skip the portal and use this MCP server with your Claude / ChatGPT subscription, no API key needed on the LLM side at all.
Configure your client
Same JSON shape works for every MCP client; only the file path differs.
{
"mcpServers": {
"graphite": {
"command": "graphite-mcp",
"env": {
"CENTRAL_SERVER_URL": "https://api.graphite-ai.net",
"CUSTOMER_API_KEY": "sk-your-graphite-key"
}
}
}
}Client | Config path |
Claude Code |
|
Claude Desktop |
|
Cursor |
|
Codex CLI |
|
Restart your client after editing.
If you installed from source and don't want to put the package on PATH, replace the command line with:
"command": "python",
"args": ["-m", "graphite_mcp"],Available tools
Once configured, Claude can call these tools to answer questions about companies, supply chains, executives, regulations, and patents.
Tool | Purpose |
| Free-text search by name, ticker, sector, or description |
| Full record for one entity by ID (e.g. |
| Every edge attached to an entity (employs, supplies, depends_on, …) |
| Typed fact log for an entity (revenue, headcount, etc.) |
| Shortest path between two entities through the graph |
| 1st + 2nd-degree neighborhood, sector breakdown — supply-chain risk view |
| Shared connections + path distance + direct relationships between two |
Example prompts
After setup, just ask Claude:
"What's NVIDIA's supply-chain exposure to TSMC?"
"Find the shortest path from company:AAPL to company:ASML."
"Compare Microsoft and Google — who do they share board members with?"
"List every revenue-from edge for NVDA."
Claude will pick the right tool, call this MCP server, and ground its answer in real graph data.
How it works
your Claude graphite-mcp api.graphite-ai.net
───────────── ──────────────── ─────────────────────
"NVDA exposure?" ─→ exposure_analysis ─→ GET /graph/exposure
(this package) (returns JSON)
←─
←─ formatted answerThe MCP server is a thin stdio adapter — it doesn't store anything, doesn't see your prompts, doesn't bill you. All the value lives in the graph at api.graphite-ai.net.
Env vars
Var | Default | Notes |
|
| Override to use a different Graphite deployment |
| (empty) | Required — issued at https://graph.graphite-ai.net/#/portal |
License
MIT. Use freely, modify freely, no warranty.
Available Tools
7 toolscompare_entitiesA
Compare two entities: shared connections, direct relationships, path distance. Example: compare_entities(entity_a='company:NVDA', entity_b='company:AMD')
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| entity_a | Yes | First entity ID | |
| entity_b | Yes | Second entity ID |
TDQS
A4.1/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that the tool returns shared connections, direct relationships, and path distance. This is good but lacks details on output format, performance, or potential limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: two sentences plus an example. Every word is meaningful, and the structure is front-loaded with the key action. No unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without an output schema, the description should clarify the return value. It lists comparison aspects but does not specify the format or structure of the output. This is adequate for a mid-complexity tool but could be more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with brief descriptions. The description adds value by showing an example with a specific entity format (e.g., 'company:NVDA'), clarifying the expected parameter structure beyond the schema's generic 'First entity ID'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: comparing two entities across three specific aspects (shared connections, direct relationships, path distance). It distinguishes from siblings like 'get_relationships' and 'find_path' by focusing on a multi-faceted comparison. The example further clarifies the intent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for comparing entities but lacks explicit guidance on when to use this tool versus alternatives like 'get_relationships' or 'find_path'. No exclusionary criteria or contextual conditions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
exposure_analysisA
Analyze a company's exposure: 1st and 2nd degree connections, sector concentration, dependency risks. Example: exposure_analysis(entity_id='company:TSM')
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| entity_id | Yes | Entity ID to analyze |
TDQS
A3.7/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description must fully disclose behavior. It mentions analytical scope but fails to state that it is a read-only operation, or discuss potential performance costs, authorization needs, or what happens on invalid entity IDs. The read-only nature is implied but not explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: two sentences plus an example. Front-loaded with purpose and scope. Every sentence is informative; no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description covers the tool's purpose and key analytical dimensions. However, it omits output format, error handling, and prerequisites (e.g., entity existence). Adequate for a simple analysis but would benefit from more detail on expected results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters with basic description. The description adds value by providing an example that reveals the expected format (entity_id='company:TSM'), clarifying the colon-prefixed convention not in the schema. This goes beyond the schema and aids correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states action 'Analyze' and resource 'company's exposure' with specific aspects (1st/2nd degree connections, sector concentration, dependency risks). Distinguishes from siblings like get_entity and get_relationships which return basic data, while this provides composite analysis.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use guidance. The description implies utility for exposure analysis but does not contrast with siblings like compare_entities or find_path. Example is helpful but insufficient for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
find_pathA
Find how two companies/entities are connected through the knowledge graph. Shows the chain of relationships. Example: find_path(source='company:AAPL', target='company:TSM')
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| source | Yes | Source entity ID | |
| target | Yes | Target entity ID | |
| max_depth | No | Max hops (default 6) |
TDQS
A3.9/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description carries burden of behavioral disclosure. It mentions max_depth and that it shows a chain, but lacks details on side effects, read-only nature, or output structure. Basic transparency but incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: two sentences plus example. Front-loaded with purpose. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema; description only vaguely says 'shows the chain of relationships'. Missing details on return format, pagination, or constraints. Adequate for simple use but incomplete for complex scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers all parameters (100% coverage). Description adds value by showing example with specific entity IDs ('company:AAPL'), clarifying the ID format beyond generic 'Source entity ID'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool finds connections between two entities in the knowledge graph, mentions 'chain of relationships', and provides a concrete example. It distinguishes from siblings like get_entity or search_entities by focusing on path discovery.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description implies usage when needing to understand how two entities are related, but does not explicitly state when to use this tool over siblings or provide 'when not to use' guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_entityA
Get detailed information about a specific entity by ID. Example: get_entity(entity_id='company:NVDA')
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| entity_id | Yes | Entity ID, e.g. 'company:AAPL', 'person:TIM_COOK_AAPL' |
TDQS
A3.6/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden but only states 'Get detailed information' without specifying what details or behavioral traits. Lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence plus example, very concise and front-loaded. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Simple tool with no output schema; description is mostly complete but could specify what 'detailed information' includes for full clarity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema already has good description with examples; description adds example but minimal extra meaning. Schema coverage 100% so baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it gets detailed information about a specific entity by ID, using specific verb and resource. Distinguishes from siblings like search_entities and compare_entities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use guidance. Example implies use when you have an entity ID, but no exclusions or alternatives mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_factsA
Get known facts about an entity — revenue, employee count, etc. Example: get_facts(entity_id='company:AAPL')
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| entity_id | Yes | Entity ID |
TDQS
A4.2/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries the behavioral burden. It indicates a read operation ('Get known facts') but does not disclose performance characteristics, rate limits, or error conditions. Adequate for a simple read tool but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences totaling 12 words plus an example. Every word earns its place; no fluff. Front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description is largely complete. It explains what facts are returned (revenue, employee count, etc.) and provides an example. It could clarify the return format, but the context signals indicate low complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with one parameter (entity_id) described as 'Entity ID'. The description adds an example showing the expected format (e.g., 'company:AAPL'), which provides meaningful context beyond the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool retrieves known facts about an entity, with specific examples like revenue and employee count. Distinguishes from sibling tools such as 'get_entity' (general info) and 'search_entities' (search).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Includes an explicit example (get_facts(entity_id='company:AAPL')) that demonstrates proper usage. Does not explicitly mention when to avoid this tool or alternatives, but the example provides clear usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_relationshipsB
Get all relationships for an entity — suppliers, competitors, partners, dependencies, etc. Example: get_relationships(entity_id='company:NVDA')
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| entity_id | Yes | Entity ID |
TDQS
B3.4/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description must convey behavior. It implies a read operation but doesn't mention error handling, rate limits, or return format. The brief description lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence plus an example, no fluff. Everything is front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter tool, the description covers purpose and provides an example. Minor gap: no mention of output structure or read-only nature.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with 'Entity ID' description; the example adds format context (e.g., 'company:NVDA') but no additional semantic detail beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves all relationships for an entity, listing specific types (suppliers, competitors, etc.), and contrasts with sibling tools like get_entity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The example provides context but no exclusion criteria or when-not-to-use advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_entitiesB
Search the financial knowledge graph for companies, people, patents by name, ticker, or description. Example: search_entities(query='NVIDIA') or search_entities(query='semiconductor', sector='semiconductors')
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query (name, ticker, or keyword) | |
| entity_type | No | Filter by type | |
| sector | No | Filter by sector: semiconductors, software, pharma, etc. | |
| limit | No | Max results (default 20) |
TDQS
B3.4/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description fails to disclose search behavior (e.g., exact vs fuzzy matching), return structure, or potential side effects. The mention of 'by name, ticker, or description' largely repeats the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with clear front-loading of purpose and a succinct example, no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Missing output schema and no description of return format, pagination, or error handling. For a search tool, this leaves significant gaps in what the agent can expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema covers all 4 params with 100% description coverage. The description adds value with a concrete example showing how to combine query and sector, aiding parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it searches the financial knowledge graph for specific entity types (companies, people, patents) by name, ticker, or description, distinguishing it from sibling tools like get_entity or find_path.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like get_entity or compare_entities. Examples show usage but don't explain selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
TDQS
A4/5.0
Disambiguation5/5
Each tool serves a unique function: search, retrieve entity details, facts, relationships, path finding, comparison, and exposure analysis. No overlap in purpose.
Naming Consistency5/5
All tools use snake_case with a verb_noun pattern (e.g., search_entities, get_entity, find_path), maintaining a predictable and uniform naming convention.
Tool Count5/5
With 7 tools, the set is well-scoped for a knowledge graph exploration tool, covering search, retrieval, and analysis without excess or deficiency.
Completeness5/5
The tool surface covers all essential operations for exploring a financial knowledge graph: search, get entity details, facts, relationships, path finding, comparison, and exposure analysis. No dead ends.
Maintenance
ActivityInactive
ResponsivenessNo issues
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
Read-only MCP server for wafergraph.com's semiconductor & AI supply-chain data: 30 tools, no auth.
Token-free MCP server for structured RevoGrid Core, Pro, and Enterprise knowledge retrieval.
MCP server for querying Forkast documentation
Read-only MCP server for The Quiet Protocol's engines, benchmarks, proof, and business data.
Related MCP Servers
- AlicenseNot gradedqualityCmaintenanceProduction-ready MCP server for Neo4j graph databases, enabling natural language to Cypher query translation with enterprise security and async performance.MIT
- AlicenseNot gradedqualityDmaintenanceHosted MCP server that gives AI agents real-time access to SEC EDGAR filings search, 10-K/8-K reading, XBRL financial facts, and insider-trade (Form 4) alerts.251MIT
- FlicenseNot gradedqualityDmaintenanceMCP server that connects AI assistants to the Data Graphs knowledge graph platform, enabling natural language search, exploration, and querying of graph data.18
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/GraphiteAI/graphite-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server