serpent
Provides search capabilities for the arXiv academic repository, allowing AI agents to find and retrieve scientific papers and preprints through the arXiv Atom API.
Provides web search capabilities through Baidu's search engine using HTML scraping, though noted as best-effort due to anti-bot measures.
Provides web search capabilities through Brave's official Search API, with optional authentication for increased rate limits (2000 free requests/month).
Provides privacy-focused web search capabilities through DuckDuckGo's lite endpoint using HTML scraping.
Provides eco-friendly web search capabilities through Ecosia's search engine using HTML scraping.
Provides search capabilities for GitHub repositories through the GitHub REST API, with optional token authentication for higher rate limits.
Provides search capabilities for the Internet Archive's digital library through the Advanced Search API.
Provides web search capabilities through Mojeek's search engine using HTML scraping.
Provides search capabilities for npm packages through the npm registry API.
Provides search capabilities for biomedical literature through NCBI's PubMed E-utilities API, with optional API key for higher rate limits.
Provides search capabilities for Python packages through PyPI using HTML scraping.
Provides web search capabilities through Qwant's internal JSON API, though noted as best-effort due to undocumented endpoints.
Provides search capabilities for Reddit content through the public JSON API.
Provides search capabilities for academic papers through Semantic Scholar's Graph API, with optional API key for higher rate limits.
Provides search capabilities for Stack Overflow questions and answers through the Stack Exchange API, with optional key for higher rate limits.
Provides privacy-focused web search capabilities through Startpage's search engine using HTML scraping, though noted as best-effort.
Provides search capabilities for structured data through the Wikidata API, enabling entity search and retrieval.
Provides search capabilities for Wikipedia articles through the MediaWiki Action API.
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., "@serpentsearch for recent advancements in quantum computing"
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.
serpent
An open-source metasearch backend built for MCP / AI agent workflows.
It aggregates results from multiple search engines, returns a unified schema, and exposes both a standard HTTP API and an MCP server that LLM agents can call directly.
Why this exists
Most search aggregators are designed for human-readable output: HTML pages, result cards, pagination UIs. When an LLM agent needs to search the web, it needs something different: structured JSON, stable field names, concurrent multi-source results, and predictable error handling.
serpent is designed for that use case. It is not a SearXNG clone.
Positioning
Agent-friendly metasearch backend
MCP-first search gateway for LLM workflows
Structured search API designed for AI pipelines
Supported providers
Google is not scraped directly. The reason is practical: Google's anti-bot measures make self-hosted scraping fragile. Maintaining a reliable scraper against Google's continuously evolving detection means constant breakage and high maintenance overhead. For production use cases, third-party providers are more reliable and cost-effective.
Currently supported Google providers:
Provider | Env var | Notes |
| Pay-per-use; generally cheaper for low volume | |
| 2,500 free queries, then pay-per-use |
Both are low-cost options. For casual or low-volume use, serpbase.dev tends to be cheaper per query. Either works; configure whichever you prefer, or both for fallback.
Web search
Provider | name | Method | Auth |
DuckDuckGo |
| HTML scraping (lite endpoint) | No |
Bing |
| HTML scraping | No |
Yahoo |
| HTML scraping | No |
Brave |
| Official Search API | Optional (free tier: 2000/month) |
Ecosia |
| HTML scraping | No |
Mojeek |
| HTML scraping | No |
Startpage |
| HTML scraping (best-effort) | No |
Qwant |
| Internal JSON API (best-effort) | No |
Yandex |
| HTML scraping (best-effort) | No |
Baidu |
| HTML scraping (best-effort) | No |
Providers marked best-effort use undocumented endpoints or scraping targets with strong anti-bot measures. They may stop working without warning.
Knowledge / reference
Provider | name | Method | Auth |
Wikipedia |
| MediaWiki Action API | No |
Wikidata |
| Wikidata API (entity search) | No |
Internet Archive |
| Advanced Search API | No |
Developer
Provider | name | Method | Auth |
GitHub |
| GitHub REST API | No (token raises rate limit) |
Stack Overflow |
| Stack Exchange API | No (key raises limit) |
Hacker News |
| Algolia HN API | No |
| Public JSON API | No | |
npm |
| npm registry API | No |
PyPI |
| HTML scraping | No |
crates.io |
| crates.io REST API | No |
Academic
Provider | name | Method | Auth |
arXiv |
| Atom API | No |
PubMed |
| NCBI E-utilities | No (key raises rate limit) |
Semantic Scholar |
| Graph API | No (key raises rate limit) |
CrossRef |
| REST API (145M+ DOIs) | No |
Installation
# Clone the repository
git clone https://github.com/your-org/serpent
cd serpent
# Install with pip (editable)
pip install -e ".[dev]"
# Or with uv
uv pip install -e ".[dev]"Configuration
Copy .env.example to .env and fill in your keys:
cp .env.example .env# Required for Google search (at least one)
SERPBASE_API_KEY=your_key_here
SERPER_API_KEY=your_key_here
# Optional — omit to use unauthenticated/public access
BRAVE_API_KEY= # free tier: 2000 req/month
GITHUB_TOKEN= # raises rate limit from 60 to 5000 req/hour
STACKEXCHANGE_API_KEY= # raises limit from 300 to 10,000 req/day
NCBI_API_KEY= # PubMed; raises from 3 to 10 req/sec
SEMANTIC_SCHOLAR_API_KEY= # raises from 1 to 10 req/sec
# Server
HOST=0.0.0.0
PORT=8000
# Restrict which providers are active (comma-separated, empty = all available)
ENABLED_PROVIDERS=
ALLOW_UNSTABLE_PROVIDERS=false
# Timeouts in seconds
DEFAULT_TIMEOUT=10
AGGREGATOR_TIMEOUT=15
MAX_RESULTS_PER_PROVIDER=10Running
HTTP API server
python -m serpent.main
# or
serpentServer starts at http://localhost:8000. Interactive docs at /docs.
MCP server
python -m serpent.mcp_server
# or
serpent-mcpThe MCP server communicates over stdio. Use it with any MCP-compatible client (Claude Desktop, cline, continue.dev, etc.).
Docker
Build the image:
docker build -t serpent .Run the HTTP API:
docker run --rm -p 8000:8000 --env-file .env serpentOr with Docker Compose:
docker compose up --buildThe container starts the HTTP API on http://localhost:8000.
HTTP API
POST /search
Aggregate search across all enabled providers.
curl -X POST http://localhost:8000/search \
-H "Content-Type: application/json" \
-d '{"query": "rust async runtime"}'With explicit providers and params:
curl -X POST http://localhost:8000/search \
-H "Content-Type: application/json" \
-d '{
"query": "rust async runtime",
"providers": ["duckduckgo", "wikipedia"],
"params": {"num_results": 5, "language": "en"}
}'Response:
{
"engine": "serpent",
"query": "rust async runtime",
"results": [
{
"title": "Tokio - An asynchronous Rust runtime",
"url": "https://tokio.rs",
"snippet": "Tokio is an event-driven, non-blocking I/O platform...",
"source": "tokio.rs",
"rank": 1,
"provider": "duckduckgo",
"published_date": null,
"extra": {}
}
],
"related_searches": ["tokio vs async-std", "rust futures"],
"suggestions": [],
"answer_box": null,
"timing_ms": 843.2,
"providers": [
{"name": "duckduckgo", "success": true, "result_count": 10, "latency_ms": 840.1, "error": null},
{"name": "wikipedia", "success": true, "result_count": 3, "latency_ms": 320.5, "error": null}
],
"errors": []
}POST /search/google
curl -X POST http://localhost:8000/search/google \
-H "Content-Type: application/json" \
-d '{"query": "site:github.com rust tokio"}'GET /health
curl http://localhost:8000/health
# {"status": "ok"}GET /providers
curl http://localhost:8000/providers{
"available": [
{"name": "google_serpbase", "tags": ["google", "web"]},
{"name": "duckduckgo", "tags": ["web", "privacy"]},
{"name": "wikipedia", "tags": ["web", "academic", "knowledge"]},
{"name": "github", "tags": ["code", "web"]},
{"name": "arxiv", "tags": ["academic", "web"]}
],
"count": 5
}MCP usage
Configure your MCP client to run serpent-mcp (or python -m serpent.mcp_server).
Example Claude Desktop config (~/.claude/claude_desktop_config.json):
{
"mcpServers": {
"serpent": {
"command": "serpent-mcp",
"env": {
"SERPBASE_API_KEY": "your_key",
"SERPER_API_KEY": "your_key"
}
}
}
}Available MCP tools
search_web
General web search across all enabled providers.
{
"query": "fastapi vs flask performance 2024",
"num_results": 10
}search_google
Google search via a configured third-party provider.
{
"query": "site:docs.python.org asyncio",
"provider": "google_serpbase"
}search_academic
Search arXiv and Wikipedia.
{
"query": "transformer architecture attention mechanism",
"num_results": 8
}search_github
Search GitHub repositories.
{
"query": "python mcp server implementation",
"num_results": 5
}compare_engines
Run the same query across multiple providers and return results grouped by engine.
{
"query": "vector database comparison",
"providers": ["duckduckgo", "brave"],
"num_results": 5
}Result schema reference
Every result object has these fields:
Field | Type | Description |
| string | Result title |
| string | Result URL |
| string | Text excerpt / description |
| string | Domain name |
| int | 1-based position in final merged list |
| string | Provider that returned this result |
| string | null | ISO date (YYYY-MM-DD), if available |
| object | Provider-specific data (e.g. GitHub stars, arXiv authors) |
Development
# Install dev dependencies
pip install -e ".[dev]"
# Run tests
pytest
# Run with auto-reload
uvicorn serpent.main:app --reloadRoadmap
Caching layer (in-memory / Redis) for repeated queries
Relevance re-ranking across providers
More providers: Bing (official API), Kagi, Tavily
Rate limiting per provider with backoff
Streaming responses (SSE) for long aggregations
Docker image and Compose setup
Provider health monitoring endpoint
Result scoring and confidence signals
License
MIT
Available Tools
5 toolscompare_enginesA
Run the same query against multiple providers and return results grouped by provider for side-by-side comparison.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query | |
| providers | No | Providers to compare. Empty = all enabled. | |
| num_results | No |
TDQS
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 mentions the tool runs queries and returns grouped results, but does not cover critical aspects like whether this is a read-only operation, potential rate limits, authentication needs, error handling, or what happens when providers fail. For a tool that interacts with multiple external services, this is a significant gap.
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, well-structured sentence that efficiently conveys the tool's purpose and outcome without unnecessary words. It is front-loaded and every part earns its place.
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 of querying multiple providers, no annotations, and no output schema, the description is incomplete. It lacks details on behavioral traits, error scenarios, output format, and how results are structured for comparison. This is inadequate for a tool with external dependencies and multiple parameters.
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 67% (2 out of 3 parameters have descriptions). The description adds value by explaining the purpose of comparing providers and implying the 'providers' parameter's role, but does not detail the 'query' or 'num_results' beyond what the schema provides. With moderate coverage, it compensates somewhat but not fully.
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 specific action ('Run the same query against multiple providers') and the outcome ('return results grouped by provider for side-by-side comparison'), distinguishing it from sibling tools that search specific platforms. It uses precise verbs and identifies the resource being compared.
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 implies usage for comparative analysis across providers, but does not explicitly state when to use this tool versus the sibling search tools (search_academic, search_github, etc.). It lacks guidance on alternatives or exclusions, leaving the context somewhat implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_academicB
Search academic sources (arXiv, Wikipedia). Best for research questions, paper discovery, and factual lookups.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query | |
| num_results | No |
TDQS
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 mentions the sources (arXiv, Wikipedia) but doesn't describe important behaviors like rate limits, authentication needs, result format, pagination, or whether this is a read-only operation. The description is insufficient for a tool with no annotation coverage.
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 extremely concise with just two sentences that are front-loaded and waste-free. The first sentence states the core purpose, and the second provides usage context. Every word earns its place with no redundancy.
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 no annotations, no output schema, and incomplete parameter documentation (50% schema coverage), the description is insufficiently complete. It doesn't explain what the tool returns, how results are structured, or important behavioral constraints. For a search tool with multiple sibling alternatives, more context is needed.
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 50% (only 'query' has a description). The description adds no specific parameter semantics beyond what the schema provides. It doesn't explain what constitutes a good query format, what 'num_results' controls, or any constraints. With moderate schema coverage, the baseline 3 is appropriate as the description doesn't compensate for the coverage gap.
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 'Search academic sources (arXiv, Wikipedia)' with specific resources named. It distinguishes from siblings by focusing on academic sources rather than general web, GitHub, or engine comparison. However, it doesn't explicitly contrast with each sibling tool by name.
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 provides implied usage guidance with 'Best for research questions, paper discovery, and factual lookups,' suggesting appropriate contexts. However, it doesn't explicitly state when NOT to use this tool or name specific alternatives among the sibling tools (compare_engines, search_github, search_google, search_web).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_githubC
Search GitHub repositories. Returns repo name, description, stars, language, and topics.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query | |
| num_results | No |
TDQS
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 mentions what fields are returned (repo name, description, stars, language, topics) but doesn't cover important aspects like rate limits, authentication requirements, pagination behavior, or error conditions for a search API tool.
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 appropriately brief (two sentences) and front-loaded with the core purpose. Every sentence adds value: the first states what the tool does, the second describes the return format.
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?
For a search tool with 2 parameters, no annotations, and no output schema, the description is insufficient. It doesn't cover authentication needs, rate limits, error handling, or how results are sorted/filtered. The return format is mentioned but without schema details.
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 50% (only 'query' has a description). The description doesn't add any parameter-specific information beyond what's in the schema. It doesn't explain search query syntax, result ordering, or what 'num_results' default of 10 means in practice.
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 action ('Search GitHub repositories') and the resource ('GitHub repositories'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'search_google' or 'search_web' beyond mentioning GitHub specifically.
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 provides no guidance on when to use this tool versus the sibling search tools (compare_engines, search_academic, search_google, search_web). It mentions GitHub but doesn't explain why one would choose GitHub search over other search options.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_googleA
Search Google via a configured third-party provider (serpbase or serper). Returns structured organic results, answer boxes, and related searches.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query | |
| provider | No | Which Google provider to use. Empty = first available. | |
| num_results | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the return format ('structured organic results, answer boxes, and related searches') which is valuable behavioral information. However, it doesn't mention rate limits, authentication needs, error conditions, or pagination behavior that would be helpful for a search tool.
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 perfectly concise with two sentences that each earn their place. The first sentence establishes the core functionality and constraints, while the second specifies the return format. No wasted words, front-loaded with essential 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?
For a search tool with 3 parameters, no annotations, and no output schema, the description provides adequate but incomplete context. It covers the basic purpose and return format, but lacks details about error handling, rate limits, provider differences, or what happens when no results are found. The absence of output schema means the description should ideally explain more about the return structure.
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 67% schema description coverage, the description adds meaningful context beyond the schema. While the schema documents parameters, the description clarifies that providers are 'serpbase or serper' (matching the enum) and that results include 'organic results, answer boxes, and related searches' - giving semantic meaning to the search operation that the schema alone doesn't provide.
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 specific action ('Search Google'), identifies the resource ('via a configured third-party provider'), and distinguishes from siblings by specifying it's for Google searches only, unlike 'search_academic' or 'search_github'. It provides verb+resource+scope 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?
The description implies usage context by specifying it's for Google searches via particular providers, which helps differentiate from sibling tools like 'search_academic'. However, it doesn't explicitly state when to use this versus alternatives or provide exclusion criteria, leaving some ambiguity about provider selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_webB
Search the web using all enabled providers and return aggregated, deduplicated results with a unified schema. Good for general queries.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query | |
| providers | No | Explicit provider list (optional). Empty = all enabled. | |
| num_results | No | ||
| language | No | en | |
| country | No | us |
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. It mentions 'aggregated, deduplicated results' and 'unified schema,' which adds some behavioral context, but fails to disclose critical traits such as rate limits, authentication needs, error handling, or what 'enabled providers' entails. This is a significant gap for a web search tool with no annotation coverage.
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 two sentences, front-loaded with the core functionality and followed by a usage hint. Every word earns its place, with no redundancy or waste, making it highly efficient and easy to scan.
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 of a web search tool with 5 parameters, no annotations, and no output schema, the description is incomplete. It lacks details on result format, error cases, provider specifics, and behavioral constraints, making it inadequate for safe and effective use by an AI 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 description coverage is 40%, with only the 'query' parameter having a description. The description adds no specific parameter semantics beyond what the schema provides, such as explaining 'providers' options or 'language'/'country' effects. It compensates minimally, so the baseline 3 is appropriate given the low coverage.
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 verb ('Search') and resource ('the web'), specifying it uses 'all enabled providers' and returns 'aggregated, deduplicated results with a unified schema.' It distinguishes from siblings by mentioning 'general queries,' but could be more explicit about how it differs from specific providers like search_google or search_academic.
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 implies usage for 'general queries,' which suggests when to use this tool, but does not explicitly state when not to use it or name alternatives. It lacks clear guidance on choosing between this and sibling tools like search_google or search_academic, leaving usage context somewhat vague.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
5 tool updates
v0.1.0- First observed
compare_engines - First observed
search_academic - First observed
search_github - First observed
search_google - First observed
search_web
TDQS
The tools are mostly distinct, with each targeting a specific search domain (academic, GitHub, Google, web) or a comparison function. However, 'search_web' and 'search_google' could be confused, as Google is a web search provider, but the descriptions clarify that 'search_web' aggregates multiple providers while 'search_google' is specific to Google. This minor overlap is mitigated by clear descriptions.
All tool names follow a consistent verb_noun pattern with snake_case, using 'search_' for four tools and 'compare_' for one. The naming is predictable and readable, with no deviations in style or convention, making it easy for agents to understand and use the tool set.
With 5 tools, the set is well-scoped for a search-focused server. Each tool serves a clear purpose (e.g., different search types and a comparison feature), and there are no extraneous tools. The count is appropriate, allowing coverage of key search domains without being overwhelming.
The tool set covers major search domains (academic, GitHub, Google, general web) and includes a useful comparison tool. Minor gaps exist, such as no tools for filtering or refining search results (e.g., by date or language), but agents can work around this with the provided tools. The surface is largely complete for a search-oriented server.
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
Multi-engine search for AI agents. Trust scoring, local corpus, MCP-native. Self-hostable, BYOK.
Search engine for AI agents to find MCP servers, A2A agents, and skills on their own.
Search GitHub, npm, PyPI, StackOverflow, ArXiv from one MCP — built for coding agents.
Search, vet & assemble MCP servers from your agent: verified tools, risk labels, and trust scores.
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/reurinkkeano/serpent'
If you have feedback or need assistance with the MCP directory API, please join our Discord server