Which integrations are available for this server?

Enables configuration through environment variables stored in a .env file for customizing API request parameters, rate limits, caching, and language preferences. Uses Git for version control and initial project installation through the git clone command. Offers repository access for installation via git clone from GitHub, with contribution workflows mentioned in the documentation. Provides specific integration paths for macOS, including configuration file locations for Claude Desktop integration. Provides access to Wikidata knowledge base through five specialized tools: entity search, detailed entity retrieval, custom SPARQL query execution, entity relation exploration, and property-value searches.

How do I use MCP Wikidata Server?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@MCP Wikidata Server search for Albert Einstein and get his birth date and notable works" 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.

MCP Wikidata Server

by joelgombin

Overview Schema Related Servers Score Discussions

Python

Remote

MCP Wikidata Server

Un serveur Model Context Protocol (MCP) qui fournit un accès aux données Wikidata pour les Large Language Models.

🔧 Fonctionnalités

5 outils MCP pour interagir avec Wikidata :
- search_entities : Recherche textuelle d'entités
- get_entity : Récupération détaillée d'entités par ID
- sparql_query : Exécution de requêtes SPARQL personnalisées
- get_relations : Exploration des relations d'entités
- find_by_property : Recherche par propriété-valeur
APIs supportées :
- Wikibase API (recherche et récupération d'entités)
- SPARQL Query Service (requêtes complexes)
- Support multilingue et cache intelligent

Related MCP server: Wikidata MCP Server

📋 Prérequis

Python 3.10+
uv (gestionnaire de paquets Python moderne)

📦 Installation

1. Cloner le projet

git clone https://github.com/joelgombin/mcp-wikidata.git
cd mcp-wikidata

2. Installer les dépendances

uv sync

3. Tester l'installation

uv run python test_connection.py

⚙️ Configuration avec Claude Desktop

Configuration recommandée (portable)

Ajoutez cette configuration à votre fichier Claude Desktop (~/Library/Application Support/Claude/claude_desktop_config.json sur macOS) :

{
  "mcpServers": {
    "mcp-wikidata": {
      "command": "/path/to/your/mcp-wikidata/run_mcp_wikidata.sh",
      "args": []
    }
  }
}

Important : Remplacez /path/to/your/mcp-wikidata/ par le chemin absolu vers votre dossier d'installation.

Alternative avec uv direct

Si vous préférez une configuration sans script wrapper :

{
  "mcpServers": {
    "mcp-wikidata": {
      "command": "uv",
      "args": ["run", "mcp-wikidata"],
      "cwd": "/path/to/your/mcp-wikidata",
      "env": {
        "PATH": "/usr/local/bin:/usr/bin:/bin:~/.local/bin"
      }
    }
  }
}

🧪 Tests et vérification

Test avec MCP Inspector

npx @modelcontextprotocol/inspector uv run mcp-wikidata

Tests manuels des APIs

uv run python test_manual.py

Test client MCP complet

uv run python test_mcp_client.py

🔧 Utilisation des outils

search_entities

Recherche d'entités par texte :

{
  "query": "Einstein",
  "language": "en",
  "limit": 5,
  "type": "item"
}

get_entity

Récupération d'entité par ID :

{
  "entity_id": "Q937",
  "language": "en", 
  "simplified": true
}

sparql_query

Requête SPARQL personnalisée :

{
  "query": "SELECT ?item ?itemLabel WHERE { ?item wdt:P31 wd:Q5 . SERVICE wikibase:label { bd:serviceParam wikibase:language \"en\" . } } LIMIT 10",
  "format": "json"
}

get_relations

Relations d'une entité :

{
  "entity_id": "Q937",
  "relation_type": "outgoing",
  "limit": 20
}

find_by_property

Recherche par propriété :

{
  "property": "P106",
  "value": "physicist",
  "limit": 10
}

⚙️ Configuration avancée

Variables d'environnement

Créez un fichier .env basé sur .env.example :

# User-Agent pour les requêtes API
WIKIDATA_USER_AGENT=MCP-Wikidata/0.1.0

# Limitation du taux de requêtes (par minute)
WIKIDATA_RATE_LIMIT=60

# Timeout des requêtes en secondes
WIKIDATA_TIMEOUT=30

# TTL du cache en secondes
WIKIDATA_CACHE_TTL=3600

# Nombre maximum de résultats par requête
WIKIDATA_MAX_RESULTS=50

# Langue par défaut
WIKIDATA_DEFAULT_LANGUAGE=en

Logs de debug

Pour diagnostiquer des problèmes :

uv run mcp-wikidata --log-level DEBUG

🔧 Dépannage

Erreur "server disconnected" dans Claude Desktop

Vérifiez l'installation d'uv :

which uv
# Doit retourner un chemin comme /Users/username/.local/bin/uv

Testez le script wrapper :
```
./run_mcp_wikidata.sh --help
```
Vérifiez les permissions :
```
chmod +x run_mcp_wikidata.sh
```
Redémarrez Claude Desktop après modification de la configuration

Erreur "spawned uv ENOENT"

Cette erreur indique que Claude Desktop ne trouve pas la commande uv. Le script wrapper run_mcp_wikidata.sh résout automatiquement ce problème en cherchant uv dans plusieurs emplacements courants.

Logs de diagnostic

Les logs détaillés sont disponibles dans :

Console de MCP Inspector
Fichiers de log Claude Desktop (selon votre OS)
Sortie stderr du serveur MCP

📁 Structure du projet

mcp-wikidata/
  ├ mcp_wikidata/           # Package principal
     ├ __init__.py
     ├ server.py           # Serveur MCP principal
     ├ config.py           # Configuration
     ├ tools.py            # Définitions des outils MCP
     └ wikidata_client.py  # Client API Wikidata
  ├ tests/                  # Tests
  ├ run_mcp_wikidata.sh    # Script wrapper (recommandé)
  ├ test_*.py              # Scripts de test
  ├ pyproject.toml         # Configuration du projet
  ├ .env.example           # Variables d'environnement
  └ README.md

🤝 Contribution

Les contributions sont bienvenues ! N'hésitez pas à :

Signaler des bugs
Proposer des améliorations
Ajouter de nouveaux outils MCP
Améliorer la documentation

📄 Licence

MIT License - voir le fichier LICENSE pour plus de détails.

📚 Ressources utiles

Généré avec Claude Code 🚀

Available Tools

5 tools

find_by_propertyC

Find entities by property and value

ParametersJSON Schema

Name	Required	Description	Default
`property`	Yes	Property ID (P123)
`value`	Yes	Property value to search for
`language`	No	Language code (default: en)	en
`limit`	No	Maximum number of results

TDQS

C2.7/5.0

Behavior2/5

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 states the action ('Find') but doesn't describe whether this is a read-only operation, what permissions might be needed, how results are returned (e.g., pagination, format), or any rate limits. This leaves significant gaps for a tool with 4 parameters and no output 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?

The description is a single, efficient sentence with zero waste. It's appropriately sized and front-loaded, clearly stating the core functionality without unnecessary elaboration, making it easy for an agent to parse quickly.

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?

Given the complexity of a search tool with 4 parameters, no annotations, and no output schema, the description is incomplete. It lacks details on behavioral traits, result handling, and differentiation from siblings, leaving the agent under-informed about how to effectively invoke and interpret this tool.

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 description coverage is 100%, so the schema already documents all parameters (property, value, language, limit) with descriptions and defaults. The description adds no additional meaning beyond what's in the schema, such as examples of property IDs or value formats, but doesn't need to compensate for gaps, meeting the baseline for high coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Find entities by property and value' states a clear verb ('Find') and resource ('entities'), but it's vague about what 'entities' refers to and doesn't distinguish from sibling tools like 'search_entities' or 'get_entity'. It provides a basic purpose but lacks specificity about scope or domain.

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 is provided on when to use this tool versus alternatives like 'search_entities' or 'get_entity'. The description implies a property-value search but doesn't specify use cases, prerequisites, or exclusions, leaving the agent to guess based on tool names alone.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_entityB

Get detailed information about a Wikidata entity

ParametersJSON Schema

Name	Required	Description	Default
`entity_id`	Yes	Wikidata entity ID (Q123, P456)
`language`	No	Language code (default: en)	en
`properties`	No	Specific properties to include
`simplified`	No	Return simplified format (default: false)

TDQS

B3.1/5.0

Behavior2/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 of behavioral disclosure. It states the action ('Get detailed information') but doesn't clarify aspects like whether this is a read-only operation, potential rate limits, authentication needs, or error handling. For a tool with no annotations, this leaves significant behavioral gaps.

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, clear sentence that efficiently conveys the core purpose without any unnecessary words. It's front-loaded and appropriately sized for a straightforward retrieval tool, making it easy to parse quickly.

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 the tool's moderate complexity (4 parameters, no output schema, no annotations), the description is minimally adequate. It covers the basic purpose but lacks details on usage context, behavioral traits, and output expectations, which are important for an agent to invoke it correctly without structured support.

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?

The input schema has 100% description coverage, so parameters like 'entity_id', 'language', 'properties', and 'simplified' are well-documented in the schema itself. The description adds no additional semantic context beyond implying retrieval of 'detailed information', which aligns with the schema but doesn't provide extra value like usage examples or constraints.

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 states the verb ('Get') and resource ('detailed information about a Wikidata entity'), making the purpose immediately understandable. However, it doesn't differentiate this tool from sibling tools like 'get_relations' or 'search_entities', which likely also retrieve entity information but with different scopes or methods.

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?

The description provides no guidance on when to use this tool versus alternatives. With siblings like 'find_by_property', 'get_relations', and 'search_entities', there's no indication of when this specific 'get_entity' tool is preferred, such as for retrieving core entity data by ID versus searching or querying relationships.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_relationsC

Get relations of a Wikidata entity

ParametersJSON Schema

Name	Required	Description	Default
`entity_id`	Yes	Wikidata entity ID
`relation_type`	No	Type of relations to retrieve	outgoing
`property_filter`	No	Filter by specific properties
`limit`	No	Maximum number of relations

TDQS

C2.9/5.0

Behavior2/5

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 states what the tool does but doesn't cover critical aspects like whether it's read-only, potential rate limits, error handling, or the format of returned relations. This is a significant gap for a tool with multiple parameters and no output 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?

The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, making it easy for an agent to parse quickly.

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?

Given the complexity of 4 parameters, no annotations, and no output schema, the description is incomplete. It doesn't explain what 'relations' entail in Wikidata context, the structure of returned data, or any behavioral traits, leaving the agent with insufficient information for optimal tool selection and invocation.

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?

The input schema has 100% description coverage, providing clear details for all parameters including defaults and enums. The description adds no additional parameter semantics beyond what's in the schema, so it meets the baseline score of 3 without compensating or detracting.

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 states the action ('Get relations') and target ('Wikidata entity'), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'get_entity' or 'find_by_property', which might also retrieve entity-related information, so it doesn't reach the highest score.

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 is provided on when to use this tool versus alternatives such as 'get_entity' or 'sparql_query'. The description implies usage for retrieving relations but lacks explicit context or exclusions, leaving the agent to infer based on tool names alone.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

search_entitiesB

Search for entities in Wikidata by text query

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes	Search term
`language`	No	Language code (default: en)	en
`limit`	No	Maximum number of results (default: 10, max: 50)
`type`	No	Entity type filter (item, property)

TDQS

B3.1/5.0

Behavior2/5

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. While it indicates this is a search operation, it doesn't describe what 'entities' means in Wikidata context, whether this is a read-only operation, what authentication might be required, rate limits, pagination behavior, or what the response format looks like. For a search tool with zero annotation coverage, this leaves significant behavioral gaps.

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, efficient sentence that communicates the core functionality without any wasted words. It's appropriately sized and front-loaded with the essential information. Every word earns its place in this concise formulation.

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 the tool's moderate complexity (4 parameters, no nested objects) and the absence of both annotations and output schema, the description provides a basic but incomplete picture. It states what the tool does but lacks crucial context about when to use it, behavioral characteristics, and output format. For a search tool without output schema, the description should ideally indicate what kind of results to expect.

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?

The schema description coverage is 100%, meaning all parameters are well-documented in the input schema itself. The description doesn't add any parameter-specific information beyond what's already in the schema descriptions. According to the scoring rules, when schema_description_coverage is high (>80%), the baseline is 3 even with no param info in the description, which applies here.

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 states the action ('search for entities') and target resource ('Wikidata'), which provides a specific verb+resource combination. However, it doesn't distinguish this tool from its sibling tools like 'find_by_property' or 'sparql_query', which likely offer alternative search approaches. The purpose is clear but lacks sibling 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?

The description provides no guidance on when to use this tool versus alternatives. With sibling tools like 'find_by_property', 'get_entity', 'get_relations', and 'sparql_query' available, there's no indication of when text-based search is preferred over property-based lookup, direct entity retrieval, relationship queries, or SPARQL queries. The description offers no context about appropriate use cases.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

sparql_queryC

Execute a SPARQL query against Wikidata

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes	SPARQL query
`format`	No	Response format	json
`limit`	No	Maximum number of results (default: 100, max: 1000)

TDQS

C2.9/5.0

Behavior2/5

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. While 'Execute a SPARQL query' implies a read operation, it doesn't clarify important aspects like rate limits, authentication requirements, timeout behavior, or whether this is a public endpoint. The description lacks behavioral context needed for safe and effective use.

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 extremely concise - a single sentence that directly states the tool's purpose without any wasted words. It's front-loaded with the essential information and earns its place efficiently.

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?

For a query execution tool with no annotations and no output schema, the description is insufficient. It doesn't explain what kind of results to expect, error handling, performance characteristics, or how this differs from sibling tools. The agent lacks critical context for effective tool selection and use.

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 description coverage is 100%, so the schema already documents all three parameters thoroughly. The description doesn't add any meaningful parameter semantics beyond what's in the schema - it doesn't explain SPARQL query syntax, format implications, or practical limit considerations.

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 states the action ('Execute') and target ('SPARQL query against Wikidata'), making the purpose immediately understandable. However, it doesn't differentiate this from sibling tools like 'search_entities' or 'get_entity' which might also query Wikidata data, leaving some ambiguity about when to choose this specific tool.

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?

The description provides no guidance on when to use this tool versus alternatives like 'search_entities' or 'get_entity'. There's no mention of prerequisites, appropriate use cases, or limitations that would help an agent decide between this and sibling tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

B3.4/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose with no overlap: find_by_property targets property-value pairs, get_entity retrieves entity details, get_relations focuses on entity relationships, search_entities handles text-based queries, and sparql_query allows custom SPARQL queries. The descriptions reinforce these distinct roles, making tool selection unambiguous.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern (e.g., find_by_property, get_entity, get_relations, search_entities, sparql_query), using snake_case uniformly. The verbs (find, get, search, execute) are appropriate to their actions, creating a predictable and readable naming convention throughout the set.

Tool Count5/5

With 5 tools, this server is well-scoped for interacting with Wikidata, covering essential operations like entity retrieval, searching, and querying without being overly complex. Each tool earns its place by addressing a core need in the domain, making the count appropriate for the server's purpose.

Completeness4/5

The tool surface provides strong coverage for querying and retrieving Wikidata data, including basic CRUD-like operations (e.g., get and search) and advanced querying via SPARQL. A minor gap exists in write operations (e.g., create or update entities), but agents can work around this given Wikidata's read-heavy nature, and the tools support most common workflows.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Reddit Discussion

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

wikidata-mcp-server A
io.github.cyanheads
Search and fetch Wikidata entities, execute SPARQL queries, and resolve external identifiers.
Knowledge & Memory Search Open Data
723
ACEL Observatory A
za.co.pccswart.radar
Machine-readable entity discovery with provenance, trust and verified source evidence.
E-commerce & Retail Product Management
51
Wikidata A
io.github.pipeworx-io
Wikidata MCP — wraps Wikidata API (wikidata.org/w/api.php)
Open Data Knowledge & Memory Search
352
Sugra API A
ai.sugra
Gateway between LLM agents and world data through eight tools and a bundled endpoint catalog.
Search Open Data Data Platforms
1122

Related MCP Servers

Wikidata MCP Server
RAG Systems Search Open Data
zzaebok
A
license
A
quality
F
maintenance
A server implementation for interacting with Wikidata API using the Model Context Protocol, providing tools for searching identifiers, extracting metadata, and executing SPARQL queries.
Updated 5 months ago (2026-03-27 13:38 UTC)
5
48
MIT
Wikidata MCP Server
Search Knowledge & Memory Open Data
ebaenamar
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.
Updated 9 months ago (2025-12-07 19:40 UTC)
2
mcp-dbpedia
Open Data Search Knowledge & Memory
pipeworx-io
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.
Updated 9 days ago (2026-08-26 16:59 UTC)
13
1
MIT
wikidata-mcp-server
Open Data Knowledge & Memory Search
cyanheads
A
license
Not graded
quality
A
maintenance
Enables searching and fetching Wikidata entities, executing SPARQL queries, and resolving external identifiers via the Model Context Protocol.
Updated 13 days ago (2026-08-22 21:40 UTC)
271
3
Apache 2.0

Appeared in Searches

SPARQL query language and tools

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/joelgombin/mcp-wikidata'

If you have feedback or need assistance with the MCP directory API, please join our Discord server