Skip to main content
Glama
houtini-ai

Google Knowledge Graph MCP

by houtini-ai

Google Knowledge Graph Search MCP

npm version MCP Registry Known Vulnerabilities License: MIT 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-mcp

Verify with:

claude mcp get google-knowledge-graph

You 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 build

Then 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.json

  • macOS: ~/Library/Application Support/Claude/claude_desktop_config.json

  • Linux: ~/.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.

  1. Go to Google Cloud Console

  2. Create a new project (or select an existing one)

  3. Enable "Knowledge Graph Search API" in the API Library

  4. Navigate to "Credentials" and create an API key

  5. (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 5

Lookup by MID:

Look up knowledge graph entity /m/0dl567

The 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 people

  • Organization - Companies, institutions

  • Place - Locations, geographical entities

  • Event - Historical or current events

  • CreativeWork - Books, films, music, art

  • Product - Commercial products

  • ComputerLanguage - Programming languages

  • SportsTeam - Sports teams

  • Country - Nations and countries

  • City - Cities and municipalities

You can combine types for more specific searches.

Troubleshooting

MCP not appearing in Claude:

  1. Check your JSON syntax - one error breaks everything

  2. Verify the path uses correct escaping (\\ on Windows)

  3. Completely restart Claude Desktop (quit, not just minimise)

  4. Check the API key environment variable spelling

"API key required" error:

  • The environment variable isn't being read

  • Check spelling: GOOGLE_KNOWLEDGE_GRAPH_API_KEY

  • Restart 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 build

The build process compiles TypeScript to CommonJS in dist/. No special configuration needed.

Technical Details

  • API Endpoint: https://kgsearch.googleapis.com/v1/entities:search

  • Response Format: JSON-LD with itemListElement array

  • Authentication: 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:

  1. Check existing issues first

  2. Test your changes locally

  3. 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


Version: 1.0.0
Status: Production ready, tested with Claude Desktop

Available Tools

2 tools
lookup_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.

ParametersJSON Schema
NameRequiredDescriptionDefault
idsYesEntity Machine IDs (MIDs) to lookup (e.g., ["/m/0dl567"])
languagesNoLanguage codes for results. Default: ["en"]

TDQS

A3.9/5.0
Behavior3/5

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.

Conciseness5/5

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.

Completeness3/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
limitNoMaximum results to return (1-500). Default: 20
queryYesSearch query for entities (e.g., "Taylor Swift", "Eiffel Tower", "Python programming")
typesNoFilter by schema.org types (e.g., ["Person", "Organization", "Place"])
languagesNoLanguage codes (ISO 639, e.g., ["en", "es", "fr"]). Default: ["en"]

TDQS

B3.3/5.0
Behavior3/5

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.

Conciseness5/5

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.

Completeness3/5

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.

Parameters3/5

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.

Purpose4/5

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.

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 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

A3.6/5.0
Disambiguation5/5

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.

Naming Consistency4/5

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.

Tool Count3/5

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.

Completeness4/5

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

ActivityMaintained
ResponsivenessSyncing

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

Related MCP Servers

  • F
    license
    Not graded
    quality
    D
    maintenance
    Connects 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
  • F
    license
    Not graded
    quality
    Not graded
    maintenance
    Enables 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.
  • A
    license
    Not graded
    quality
    C
    maintenance
    Enables querying DBpedia's structured knowledge graph using SPARQL and lookup tools, allowing AI agents to access Wikipedia-derived data.
    13
    1
    MIT
  • A
    license
    A
    quality
    D
    maintenance
    Enables searching and retrieving content from Grokipedia, with tools for page lookup, citations, sections, and related pages.
    7
    MIT

Latest Blog Posts

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