Provides access to ConceptNet's semantic knowledge graph, enabling AI agents to look up concepts, search for related terms, analyze semantic relationships, and calculate concept similarity scores across multiple languages.
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., "@ConceptNet MCP Server what concepts are related to 'artificial intelligence'?"
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.
A Model Context Protocol (MCP) server that provides seamless access to the ConceptNet knowledge graph through FastMCP framework.
ConceptNet MCP provides AI assistants and applications with structured access to ConceptNet's semantic knowledge through four powerful MCP tools:
Concept Lookup: Get detailed information about specific concepts
Concept Query: Search and filter concepts with advanced criteria
Related Concepts: Find concepts connected through semantic relationships
Concept Relatedness: Calculate semantic similarity between concepts
Related MCP server: Vec Memory MCP Server
🚀 FastMCP Integration: Built on the modern FastMCP framework for optimal performance
🔍 Comprehensive Search: Advanced querying with language filtering and pagination
🌐 Multi-language Support: Access ConceptNet's multilingual knowledge base
📊 Semantic Analysis: Calculate relatedness scores between concepts
🔄 Async Operations: Full async/await support for non-blocking operations
📝 Type Safety: Complete Pydantic v2 type validation and IDE support
🧪 Production Ready: Error handling, logging, and testing
⚡ Optimized Output Formats: Choose between minimal (~96% smaller) or comprehensive responses
ConceptNet MCP Server supports two output formats for all tools to optimize performance and reduce token usage:
Size: ~96% smaller than verbose format
Optimized: Designed specifically for LLM consumption
Content: Essential data only - concepts, relationships, similarity scores
Performance: Faster processing and reduced API costs
Usage: Perfect for most AI applications and chat interfaces
Size: Full ConceptNet response data
Content: Complete metadata, statistics, analysis, and original API responses
Usage: Detailed analysis, debugging, or when full context is needed
Backward Compatibility: Maintains compatibility with existing integrations
All tools accept a verbose parameter:
{
"name": "concept_lookup",
"arguments": {
"term": "artificial intelligence",
"verbose": false // Default: minimal format
}
}{
"name": "related_concepts",
"arguments": {
"term": "machine learning",
"verbose": true // Full detailed format
}
}Examples of size difference:
Minimal: {"concept": "dog", "relationships": {"IsA": ["animal", "mammal"]}}
Verbose: Full ConceptNet response with complete metadata, statistics, timestamps, etc.
# Clone the repository
git clone https://github.com/infinitnet/conceptnet-mcp.git
cd conceptnet-mcp
# Install in development mode
pip install -e .The server supports both stdio (for desktop MCP clients) and HTTP (for web clients) transport modes:
# Start with stdio transport (default)
conceptnet-mcp
# Or explicitly specify stdio
conceptnet-mcp-stdio
# Or use Python module
python -m conceptnet_mcp.server# Start HTTP server on localhost:3001
conceptnet-mcp-http
# Or with custom host/port
python -c "from conceptnet_mcp.server import run_http_server; run_http_server('0.0.0.0', 8080)"# Development mode with debug logging
conceptnet-mcp-dev
# Production mode with optimized logging
conceptnet-mcp-prodAdd to your MCP client configuration:
{
"mcpServers": {
"conceptnet": {
"command": "python",
"args": ["-m", "conceptnet_mcp.server"]
}
}
}Add to your MCP client configuration:
{
"mcpServers": {
"conceptnet": {
"command": "python",
"args": ["-m", "conceptnet_mcp.server", "--transport", "http", "--port", "3001"]
}
}
}Or start the HTTP server manually and connect to:
http://localhost:3001// Example web client connection
const client = new MCPClient('http://localhost:3001');
await client.connect();Deploy ConceptNet MCP Server to Cloudflare's global edge network for worldwide access and automatic scaling using a FastAPI-based implementation optimized for Python Workers.
The Cloudflare Workers deployment uses a completely different architecture from the standard FastMCP server:
FastAPI Framework: Manual MCP protocol implementation using FastAPI for HTTP routing
Standard Workers Pattern: Uses fetch(request, env, ctx) handler (no Durable Objects)
Native HTTP Client: Custom CloudflareHTTPClient using Workers' native fetch() API
Manual MCP Protocol: JSON-RPC 2.0 MCP messages handled directly without FastMCP framework
🌍 Global Edge Network: Low-latency access worldwide via Cloudflare's CDN
🚀 Auto-scaling: Serverless scaling based on demand with zero cold starts
🔄 Dual Transport Support: Both SSE and Streamable HTTP endpoints for maximum compatibility
🤖 Remote MCP Access: Enable AI agents to access ConceptNet from anywhere
💰 Cost-effective: Pay only for actual usage with generous free tier
# Clone and navigate to Workers directory
git clone https://github.com/infinitnet/conceptnet-mcp.git
cd conceptnet-mcp/cloudflare-workers
# Install Wrangler CLI
npm install -g wrangler
# Authenticate and deploy
wrangler login
wrangler deployYour ConceptNet MCP Server will be available at:
# Streamable HTTP Transport (recommended for MCP clients)
https://your-worker.your-domain.workers.dev/mcp
# SSE Transport (legacy support)
https://your-worker.your-domain.workers.dev/sse
# Tools listing endpoint
https://your-worker.your-domain.workers.dev/toolsExample remote client connection (direct HTTP):
import httpx
import json
# Connect to your deployed Workers instance
async with httpx.AsyncClient() as client:
response = await client.post(
"https://your-worker.your-domain.workers.dev/mcp",
json={
"jsonrpc": "2.0",
"id": 1,
"method": "tools/call",
"params": {
"name": "concept_lookup",
"arguments": {"term": "artificial intelligence"}
}
}
)
result = response.json()
print(result["result"])For detailed deployment instructions, configuration options, and troubleshooting, see the Cloudflare Workers Documentation.
Get detailed information about a specific concept. Returns all relationships and properties.
{
"name": "concept_lookup",
"arguments": {
"term": "artificial intelligence",
"language": "en",
"limit_results": false,
"target_language": null,
"verbose": false
}
}Parameters:
term (required): The concept to look up
language (default: "en"): Language code for the concept
limit_results (default: false): Limit to first 20 results for quick queries
target_language (optional): Filter results to specific target language
verbose (default: false): Return detailed format vs minimal format
Advanced querying with sophisticated multi-parameter filtering.
{
"name": "concept_query",
"arguments": {
"start": "car",
"rel": "IsA",
"language": "en",
"limit_results": false,
"verbose": false
}
}Parameters:
start (optional): Start concept of relationships
end (optional): End concept of relationships
rel (optional): Relation type (e.g., "IsA", "PartOf")
node (optional): Concept that must be start or end of edges
other (optional): Used with 'node' parameter
sources (optional): Filter by data source
language (default: "en"): Language filter
limit_results (default: false): Limit to 20 results for quick queries
verbose (default: false): Return detailed format vs minimal format
Find concepts semantically similar to a given concept using ConceptNet's embeddings.
{
"name": "related_concepts",
"arguments": {
"term": "machine learning",
"language": "en",
"filter_language": null,
"limit": 100,
"verbose": false
}
}Parameters:
term (required): The concept to find related concepts for
language (default: "en"): Language code for input term
filter_language (optional): Filter results to this language only
limit (default: 100, max: 100): Maximum number of related concepts
verbose (default: false): Return detailed format vs minimal format
Calculate precise semantic relatedness score between two concepts.
{
"name": "concept_relatedness",
"arguments": {
"concept1": "artificial intelligence",
"concept2": "machine learning",
"language1": "en",
"language2": "en",
"verbose": false
}
}Parameters:
concept1 (required): First concept for comparison
concept2 (required): Second concept for comparison
language1 (default: "en"): Language for first concept
language2 (default: "en"): Language for second concept
verbose (default: false): Return detailed format vs minimal format
The server can be configured through environment variables:
# ConceptNet API settings
CONCEPTNET_API_BASE_URL=https://api.conceptnet.io
CONCEPTNET_API_VERSION=5.7
# Server settings
MCP_SERVER_HOST=localhost
MCP_SERVER_PORT=3000
LOG_LEVEL=INFO
# Rate limiting
CONCEPTNET_RATE_LIMIT=100
CONCEPTNET_RATE_PERIOD=60# Clone the repository
git clone https://github.com/infinitnet/conceptnet-mcp.git
cd conceptnet-mcp
# Install in development mode
pip install -e .[dev]
# Install pre-commit hooks
pre-commit installConcept: Represents a ConceptNet concept with URI, label, and language
Edge: Represents relationships between concepts with relation types
Query: Structured query parameters for concept searches
Response: Standardized response format with pagination support
ConceptNetClient: Async HTTP client for ConceptNet API
PaginationHandler: Automatic pagination for large result sets
ResponseProcessor: Data processing and normalization
Text Processing: Normalize text (underscores to spaces)
Logging: Structured logging with configurable levels
Error Handling: Comprehensive exception hierarchy
conceptnet_mcp/
├── client/ # ConceptNet API client
│ ├── conceptnet_client.py
│ ├── pagination.py
│ └── processor.py
├── models/ # Pydantic data models
│ ├── concept.py
│ ├── edge.py
│ ├── query.py
│ └── response.py
├── tools/ # MCP tool implementations
│ ├── concept_lookup.py
│ ├── concept_query.py
│ ├── related_concepts.py
│ └── concept_relatedness.py
├── utils/ # Utility modules
│ ├── exceptions.py
│ ├── logging.py
│ └── text_utils.py
└── server.py # FastMCP server entry pointFork the repository: https://github.com/infinitnet/conceptnet-mcp
Create a feature branch: git checkout -b feature-name
Make your changes and add tests
Run the test suite: python run_tests.py
Submit a pull request
Follow PEP 8 style guidelines
Add type hints for all functions
Include docstrings for public APIs
Write tests for new functionality
Update documentation as needed
This project is licensed under the GNU General Public License v3.0 - see the LICENSE file for details.
ConceptNet for providing the semantic knowledge base
FastMCP for the MCP framework
Model Context Protocol specification
📖 Documentation: Read the docs
🐛 Bug Reports: GitHub Issues
💬 Discussions: GitHub Discussions
🌐 Author's Website: https://infinitnet.io/
Built with ❤️ for the AI and semantic web community.
Look up information about a specific concept in ConceptNet.
This tool queries ConceptNet's knowledge graph to find all relationships
and properties associated with a given concept. By default, it returns
ALL results (not limited to 20) to provide complete information.
Features:
- Complete relationship discovery for any concept
- Language filtering and cross-language exploration
- Summaries and statistics
- Performance optimized with automatic pagination
- Format control: minimal (~96% smaller) vs verbose (full metadata)
Format Options:
- verbose=false (default): Returns minimal format optimized for LLM consumption
- verbose=true: Returns comprehensive format with full ConceptNet metadata
- Backward compatibility maintained with existing tools
Use this when you need to:
- Understand what ConceptNet knows about a concept
- Explore all relationships for a term
- Get semantic information
- Find related concepts and properties
| Name | Required | Description | Default |
|---|---|---|---|
| term | Yes | ||
| language | No | en | |
| limit_results | No | ||
| target_language | No | ||
| verbose | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key traits: it's a read-only lookup tool (implied by 'queries'), returns all results by default (not limited), supports language filtering and cross-language exploration, includes performance optimization with automatic pagination, and offers format control (minimal vs. verbose). However, it lacks details on rate limits, error handling, or authentication needs.
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 well-structured with clear sections (purpose, features, format options, usage guidelines) and front-loaded key information. Most sentences earn their place by adding value, though some phrasing (e.g., 'Performance optimized with automatic pagination') could be more concise. Overall, it's appropriately sized for a tool with 5 parameters and no annotations.
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?
Given the tool's moderate complexity (5 parameters, no annotations, but with an output schema), the description is largely complete. It covers purpose, usage, behavioral traits, and parameter semantics adequately. The output schema exists, so the description needn't explain return values. However, it could improve by explicitly linking parameters to features (e.g., naming 'limit_results') and addressing potential constraints like rate limits.
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 description coverage is 0%, so the description must compensate. It adds significant meaning beyond the schema: it explains the 'verbose' parameter with two format options (minimal vs. comprehensive), mentions language filtering and cross-language exploration (hinting at 'language' and 'target_language'), and implies 'limit_results' controls whether to return all results. However, it doesn't explicitly define all five parameters (e.g., 'term' is only implied).
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 the tool's purpose: 'Look up information about a specific concept in ConceptNet' and 'queries ConceptNet's knowledge graph to find all relationships and properties associated with a given concept.' It distinguishes from siblings by specifying it returns 'ALL results (not limited to 20)' and mentions 'Backward compatibility maintained with existing tools,' implying differentiation from concept_query.
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 explicitly provides usage guidance with a 'Use this when you need to:' section listing four specific scenarios (e.g., 'Understand what ConceptNet knows about a concept,' 'Explore all relationships for a term'). It implicitly distinguishes from siblings by mentioning 'complete information' and 'ALL results,' suggesting alternatives might be limited or partial.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Advanced querying of ConceptNet with sophisticated multi-parameter filtering.
This tool provides powerful filtering capabilities for exploring ConceptNet's
knowledge graph. You can combine multiple filters to find specific types of
relationships and concepts with precision.
Features:
- Multi-parameter filtering (start, end, relation, node, sources)
- Complex relationship discovery and analysis
- Comprehensive result processing and enhancement
- Query optimization and performance metrics
- Format control: minimal (~96% smaller) vs verbose (full metadata)
Format Options:
- verbose=false (default): Returns minimal format optimized for LLM consumption
- verbose=true: Returns comprehensive format with full ConceptNet metadata
- Backward compatibility maintained with existing tools
Filter Parameters:
- start: Start concept of relationships (e.g., "dog", "/c/en/dog")
- end: End concept of relationships (e.g., "animal", "/c/en/animal")
- rel: Relation type (e.g., "IsA", "/r/IsA")
- node: Concept that must be either start or end of edges
- other: Used with 'node' to find relationships between two specific concepts
- sources: Filter by data source (e.g., "wordnet", "/s/activity/omcs")
Use this when you need:
- Precise relationship filtering and discovery
- Complex queries with multiple constraints
- Analysis of specific relationship types
- Targeted exploration of concept connections
| Name | Required | Description | Default |
|---|---|---|---|
| start | No | ||
| end | No | ||
| rel | No | ||
| node | No | ||
| other | No | ||
| sources | No | ||
| language | No | en | |
| limit_results | No | ||
| verbose | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It describes format options (minimal vs verbose output), performance aspects ('query optimization and performance metrics'), and processing behavior ('comprehensive result processing and enhancement'). However, it doesn't cover important behavioral traits like rate limits, authentication requirements, error conditions, or pagination behavior for a query tool with 9 parameters.
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 well-structured with clear sections (Features, Format Options, Filter Parameters, Use Cases), but it's verbose with some redundant phrasing like 'sophisticated multi-parameter filtering' and 'powerful filtering capabilities.' The 'Features' section contains marketing language ('Query optimization and performance metrics') that doesn't add practical guidance for tool selection.
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?
Given the complexity (9 parameters, 0% schema coverage) and presence of an output schema, the description is reasonably complete. It thoroughly documents parameters and their usage, describes output format options, and provides usage scenarios. The main gap is lack of behavioral details like rate limits or error handling, but the output schema reduces the need to describe return values.
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?
With 0% schema description coverage and 9 parameters, the description provides excellent parameter semantics beyond the bare schema. It explains each filter parameter (start, end, rel, node, other, sources) with examples and clarifies their usage. It also documents the 'verbose' parameter's behavior and default values, and mentions 'language' and 'limit_results' parameters in the context section, adding significant value beyond the input 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 states the tool's purpose as 'Advanced querying of ConceptNet with sophisticated multi-parameter filtering' and 'exploring ConceptNet's knowledge graph.' It specifies the action (querying/filtering) and resource (ConceptNet knowledge graph), but doesn't explicitly differentiate from sibling tools like concept_lookup or concept_relatedness beyond mentioning 'backward compatibility.'
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 includes a 'Use this when you need' section listing specific scenarios like 'Precise relationship filtering and discovery' and 'Complex queries with multiple constraints.' This provides clear context for when to use this tool, though it doesn't explicitly mention when NOT to use it or name alternatives among the sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The tools are mostly distinct with clear primary purposes: concept_lookup for comprehensive concept information, concept_query for filtered searches, concept_relatedness for pairwise similarity scoring, and related_concepts for finding similar concepts. However, concept_lookup and concept_query have some functional overlap in exploring relationships, which could cause minor confusion about when to use each.
All four tools follow a consistent 'concept_' prefix pattern with descriptive suffixes (lookup, query, relatedness, related). The naming is perfectly uniform and predictable, making it easy for agents to understand the tool family and their individual functions.
Four tools is an excellent count for a ConceptNet server. Each tool addresses a distinct aspect of concept exploration: comprehensive lookup, filtered querying, pairwise relatedness, and similar concept discovery. This provides complete coverage without being overwhelming or insufficient.
The toolset comprehensively covers the ConceptNet domain with four well-chosen operations: retrieving full concept information, performing filtered queries, calculating pairwise relatedness, and finding semantically similar concepts. There are no obvious gaps for typical ConceptNet use cases.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
ConceptNet MCP — open multilingual word/phrase relation graph
Knowledge graph for AI agents. Query concepts, walk edges, get advisories.
Words MCP — wraps Datamuse API (free, no auth required)
Search and fetch Wikidata entities, execute SPARQL queries, and resolve external identifiers.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/infinitnet/conceptnet-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server