Google Knowledge Graph MCP
This server provides access to Google's Knowledge Graph API via two MCP tools:
search_knowledge_graph: Search for entities by name or topic, with optional filters for entity types (e.g.,Person,Organization,Place,ComputerLanguage), languages (ISO 639 codes likeen,es), and result limit (1–500; default 20).lookup_knowledge_graph_entities: Look up specific entities by their Google Machine IDs (MIDs), useful for entity resolution and retrieving canonical data.
Both tools return structured JSON with entity names, types, descriptions, detailed descriptions, images, URLs, relevance scores, and MIDs.
Search for real-world entities - people, places, organisations, concepts - and get structured data back from Google's Knowledge Graph.
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., "@Google Knowledge Graph MCPSearch the knowledge graph for "Leonardo da Vinci""
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.
Google Knowledge Graph Search MCP
Model Context Protocol server that connects Claude (or any MCP client) to Google's free public Knowledge Graph API. Search for real-world entities - people, places, organisations, concepts - and get structured data back.
Quick Navigation
Why this exists | What you get | Installation | Getting your API key | Usage examples | Parameters | Entity types | Troubleshooting
What is this? An MCP server. If you don't know what that means, you probably don't need this. If you're using Claude Desktop or another MCP-compatible client and want to search Google's knowledge database, this is for you.
Why This Exists
I built this because I needed a way for Claude to verify entity information during research workflows. Google's Knowledge Graph contains structured data about millions of real-world entities - the same data that powers those knowledge panels in Google Search results.
The Knowledge Graph Search API is completely free. No billing account, no usage costs, just a Google Cloud API key. Most developers don't seem to know this exists, which is odd given how useful it is.
This MCP gives Claude (or any MCP client) access to that database.
Related MCP server: Google Search Console + GA4 MCP Server
What You Get
Two tools for searching Google's knowledge graph:
1. Search by query - search_knowledge_graph
Search for entities by name or description. Returns structured data including entity types, descriptions, Wikipedia URLs, and relevance scores.
2. Lookup by MID - lookup_knowledge_graph_entities
If you already have Machine IDs (Google's internal entity identifiers), look them up directly. Useful for entity resolution workflows.
Both return JSON with:
Entity names and types
Detailed descriptions (usually from Wikipedia)
Official images and URLs
Result scores (relevance ranking)
Machine IDs for further lookups
Installation
NPX (Easiest)
Add this to your claude_desktop_config.json:
{
"mcpServers": {
"google-knowledge-graph": {
"command": "npx",
"args": ["-y", "@houtini/google-knowledge-graph-mcp"],
"env": {
"GOOGLE_KNOWLEDGE_GRAPH_API_KEY": "your-api-key-here"
}
}
}
}Claude Code (CLI)
Claude Code uses a different registration mechanism -- it doesn't read claude_desktop_config.json. Use claude mcp add instead:
claude mcp add \
-e GOOGLE_KNOWLEDGE_GRAPH_API_KEY=your-api-key-here \
-s user \
google-knowledge-graph -- npx -y @houtini/google-knowledge-graph-mcpVerify with:
claude mcp get google-knowledge-graphYou should see Status: Connected.
Local Install
If you prefer running from source:
git clone https://github.com/houtini/google-knowledge-graph-mcp.git
cd google-knowledge-graph-mcp
npm install
npm run buildThen configure Claude Desktop:
{
"mcpServers": {
"google-knowledge-graph": {
"command": "node",
"args": ["C:\\path\\to\\google-knowledge-graph-mcp\\dist\\index.js"],
"env": {
"GOOGLE_KNOWLEDGE_GRAPH_API_KEY": "your-api-key-here"
}
}
}
}Windows users: Use double backslashes in paths: C:\\MCP\\...
Config location:
Windows:
%APPDATA%\Claude\claude_desktop_config.jsonmacOS:
~/Library/Application Support/Claude/claude_desktop_config.jsonLinux:
~/.config/Claude/claude_desktop_config.json
Getting Your API Key
Google's Knowledge Graph Search API is free - no billing account, no card, no quota to unlock.
Go to Google Cloud Console
Create a new project (or select an existing one)
Enable "Knowledge Graph Search API" in the API Library
Navigate to "Credentials" and create an API key
(Optional but recommended) Restrict the key to Knowledge Graph Search API only
That's it. No credit card, no billing setup.
Usage Examples
Once installed and Claude Desktop is restarted, you can:
Basic entity search:
Search the knowledge graph for "Marie Curie"Entity type filtering:
Search knowledge graph for "Python" with types ["ComputerLanguage"]Multiple results:
Search knowledge graph for "Paris" limit 5Lookup by MID:
Look up knowledge graph entity /m/0dl567The MCP returns structured JSON that Claude can parse. You'll get entity names, types, descriptions, URLs, and relevance scores.
What Gets Returned
Example response structure:
{
"entities": [
{
"mid": "/m/0dl567",
"name": "Taylor Swift",
"type": ["Person", "Thing"],
"description": "American singer-songwriter",
"detailedDescription": "Taylor Alison Swift is an American singer-songwriter...",
"image": "https://...",
"url": "http://en.wikipedia.org/wiki/Taylor_Swift",
"resultScore": 4258.07
}
],
"count": 1
}Parameters
search_knowledge_graph
query (required): Search term
languages (optional): Language codes array, e.g.
["en"]types (optional): Entity types to filter by, e.g.
["Person", "Organization"]limit (optional): Max results (default 20, max 500)
lookup_knowledge_graph_entities
ids (required): Array of Machine IDs (MIDs), e.g.
["/m/0dl567"]languages (optional): Language codes array
Common Entity Types
The Knowledge Graph uses schema.org types. Common ones:
Person- Individual peopleOrganization- Companies, institutionsPlace- Locations, geographical entitiesEvent- Historical or current eventsCreativeWork- Books, films, music, artProduct- Commercial productsComputerLanguage- Programming languagesSportsTeam- Sports teamsCountry- Nations and countriesCity- Cities and municipalities
You can combine types for more specific searches.
Troubleshooting
MCP not appearing in Claude:
Check your JSON syntax - one error breaks everything
Verify the path uses correct escaping (
\\on Windows)Completely restart Claude Desktop (quit, not just minimise)
Check the API key environment variable spelling
"API key required" error:
The environment variable isn't being read
Check spelling:
GOOGLE_KNOWLEDGE_GRAPH_API_KEYRestart Claude Desktop after config changes
No results returned:
Try different query terms
Remove entity type filters to broaden search
Check result limit isn't set too low
401 Unauthorized:
API key is invalid or expired
Knowledge Graph Search API isn't enabled in your Google Cloud project
Building From Source
npm install
npm run buildThe build process compiles TypeScript to CommonJS in dist/. No special configuration needed.
Technical Details
API Endpoint:
https://kgsearch.googleapis.com/v1/entities:searchResponse Format: JSON-LD with
itemListElementarrayAuthentication: API key via query parameter
Rate Limits: Free tier quotas apply (generally 100,000 queries/day)
Module Format: CommonJS (compatible with Node.js MCP hosts)
Why CommonJS?
The MCP SDK uses CommonJS patterns. I've stuck with that for compatibility. If you're building your own MCP and want ES modules, that's fine - just different choices.
Contributing
If you find issues or have improvements:
Check existing issues first
Test your changes locally
Submit a PR with clear description
I'm particularly interested in hearing about:
Entity types that need better handling
Response parsing edge cases
Real-world usage patterns
Licence
MIT - do what you want with it.
Author
Built by Richard Baxter (Houtini) as part of a collection of MCP servers for AI-assisted development and research workflows.
Other Houtini MCPs:
@houtini/gemini-mcp- Google AI chat with grounding and deep research@houtini/geo-analyzer- Content optimisation for AI search engines@houtini/brevo-mcp- Email marketing automation
Related
Model Context Protocol - Protocol specification
Google Knowledge Graph API - Official API docs
Claude Desktop - Primary MCP client
Version: 1.0.0
Status: Production ready, tested with Claude Desktop
Available Tools
2 toolslookup_knowledge_graph_entitiesA
Look up specific Knowledge Graph entities by their Machine IDs (MIDs). Use this when you already know the entity IDs from a previous search. MIDs look like /m/0dl567 or /g/11b6vwtjpg.
| Name | Required | Description | Default |
|---|---|---|---|
| ids | Yes | Entity Machine IDs (MIDs) to lookup (e.g., ["/m/0dl567"]) | |
| languages | No | Language codes for results. Default: ["en"] |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden for behavioral disclosure. It explains the MID format and that the tool looks up entities, which implies a read-only operation, but it does not mention what is returned, language handling, or any limitations. This is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences: the first states exact purpose, the second provides usage context and MID examples. Every word earns its place; no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With only two parameters and no output schema, the description is reasonably complete for usage. However, it does not explain what the lookup returns (e.g., entity details, names, descriptions) or mention the languages parameter, leaving some ambiguity for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both `ids` and `languages`. The description adds a second MID format example (/g/11b6vwtjpg) beyond the schema's single example, providing a slight enhancement, but it does not discuss the `languages` parameter. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Look up specific Knowledge Graph entities by their Machine IDs (MIDs)', which is a specific verb+resource+scope. It also distinguishes from the sibling tool by explicitly mentioning use after a previous search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description says 'Use this when you already know the entity IDs from a previous search', which gives clear context for when to use it. It implies search_knowledge_graph is for when you don't know IDs, but doesn't explicitly name the alternative or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_knowledge_graphB
Search Google Knowledge Graph for entities by name or topic. Returns structured information about real-world entities like people, places, organizations, and concepts from Google's public knowledge base.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum results to return (1-500). Default: 20 | |
| query | Yes | Search query for entities (e.g., "Taylor Swift", "Eiffel Tower", "Python programming") | |
| types | No | Filter by schema.org types (e.g., ["Person", "Organization", "Place"]) | |
| languages | No | Language codes (ISO 639, e.g., ["en", "es", "fr"]). Default: ["en"] |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states it 'Returns structured information' and refers to Google's public knowledge base, which adds some context. However, it doesn't disclose rate limits, authentication requirements, or explicitly state it's a read-only operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently states the tool's purpose and return type. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations. The description provides a high-level overview but doesn't specify result structure, pagination, or how it differs from the sibling lookup tool. For a straightforward search tool, this is functional but lacks depth.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the description is not expected to expand on parameters. It mentions 'by name or topic' which maps to the query parameter, but no additional semantic value is added beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as a search operation against Google Knowledge Graph, with specific resource (entities) and examples of what it returns. While it distinguishes from the sibling by using 'search' vs 'lookup', it doesn't explicitly explain the differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use search vs lookup_knowledge_graph_entities. The description doesn't mention alternatives or exclusion criteria, leaving the agent without decision-making context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
TDQS
The two tools have clearly distinct purposes: one searches by name/topic, the other retrieves by specific MID. There is no overlap in functionality, and an agent can easily choose the right tool based on whether it has an ID or a query.
Both tools follow a verb + 'knowledge_graph' pattern, with 'search_knowledge_graph' and 'lookup_knowledge_graph_entities'. The second includes an extra noun ('entities'), but the shared prefix and consistent style make them predictable and readable.
With only two tools, the server feels minimal but functional for its stated purpose of querying the Knowledge Graph. It falls into the borderline range where the count is thin but not unreasonable for a focused utility.
The two core operations for a knowledge graph API—search and lookup by ID—are covered. Missing features like batch lookup or relation traversal are minor gaps that can be worked around with repeated calls.
Maintenance
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
Machine-readable entity discovery with provenance, trust and verified source evidence.
Search Google straight from your AI agent. Web results, images, videos, news, products, scholarly ar
Provides tools for searching Google Workspace documentation and much more.
62 real-world tools for agents: search, scraping, social, enrichment, image, video, voice.
Related MCP Servers
- FlicenseNot gradedqualityDmaintenanceConnects LLMs to Wikidata's structured knowledge base using a hybrid architecture that optimizes for both fast entity searches and complex relational queries. It provides tools for entity and property retrieval, metadata lookups, and direct SPARQL execution to ground AI responses in verified data.2
- FlicenseNot gradedqualityNot gradedmaintenanceEnables querying Google Search Console and Google Analytics 4 data to retrieve search performance and site analytics. It provides tools for listing web properties and running detailed reports using secure Google OAuth authentication.
- AlicenseNot gradedqualityCmaintenanceEnables querying DBpedia's structured knowledge graph using SPARQL and lookup tools, allowing AI agents to access Wikipedia-derived data.131MIT
- AlicenseAqualityDmaintenanceEnables searching and retrieving content from Grokipedia, with tools for page lookup, citations, sections, and related pages.7MIT
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/houtini-ai/google-knowledge-graph-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server