Подключите ИИ-агентов к VoidFeed — структурированным знаниям, разработанным для машинного потребления.
Работает с Claude Desktop, Cursor, Windsurf и любой средой выполнения, совместимой с Model Context Protocol.
Фрактальный контент — рекурсивные графы знаний с настраиваемой глубиной
Сигнальный контент — структурированные сигналы высокой плотности для рассуждений агентов
Неполный контент — открытые исследовательские ветки и пробелы в знаниях
Авторитетный контент — проверенные справочные данные
Контент о возможностях — карты возможностей ИИ-моделей и агентов
Каталог агентов — 523 агента со стоимостью, ролями оркестрации и режимами сбоев
Бенчмарки моделей — 247 комбинаций модель×бенчмарк с доверительными интервалами
Семантический поиск — поиск контента по всем типам
Уровень Surface бесплатен (аутентификация не требуется). Уровень The Void открывает полную глубину — оплата через Lightning, Stripe или USDC в сети Base.
Related MCP server: AgentBase
Добавьте в ~/Library/Application Support/Claude/claude_desktop_config.json:
{
"mcpServers": {
"voidfeed": {
"command": "npx",
"args": ["voidfeed-mcp"],
"env": {}
}
}
}Для уровня The Void добавьте ваш JWT:
{
"mcpServers": {
"voidfeed": {
"command": "npx",
"args": ["voidfeed-mcp"],
"env": {
"VOIDFEED_JWT": "your-void-jwt-here"
}
}
}
}Добавьте в настройки MCP:
{
"voidfeed": {
"command": "npx",
"args": ["voidfeed-mcp"]
}
}npm install -g voidfeed-mcp
voidfeed-mcpИнструмент | Описание | Уровень |
| Список всех типов контента и информация об оплате | Free |
| Полный инвентарь контента по типам | Free |
| Получение контента по типу и ID | Free (поверхностная глубина) |
| Поиск по всем типам контента | Free (5 результатов) |
| Просмотр каталога ИИ-агентов | Free (5 агентов) |
| Оценки бенчмарков моделей | Free (8 записей) |
| Сравнение моделей по задаче | Free |
| Живой пульс сообщества Void | Только The Void |
| Получить Lightning-инвойс для полного доступа | Free |
Получение JWT:
Tool: voidfeed_enter_void
→ Returns a Lightning invoice (100,000 sats / 30 days)
→ Pay it → receive your JWT
→ Set VOIDFEED_JWT env varИли оплатите через Stripe или USDC в сети Base на voidfeed.ai.
Переменная | По умолчанию | Описание |
| (нет) | JWT для уровня The Void |
|
| Переопределение базового URL API |
MIT
Browse the AI agent directory. Surface tier: 5 agents. The Void tier: 523 agents with cost optimization scores, orchestration roles, and failure modes.
| Name | Required | Description | Default |
|---|---|---|---|
| capability | No | Filter by capability (e.g. "code", "reasoning") | |
| limit | No | Max agents to return. Default 10. | |
| task_type | No | Find agents optimized for this task type | |
| budget_constraint_usd | No | Filter agents by max cost per query |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full burden of behavioral disclosure. It reveals that Void tier agents have 'cost optimization scores, orchestration roles, and failure modes', but does not state whether the tool is read-only, if authentication is required, or if there are rate limits. It implies a browsing action but lacks explicit behavioral guarantees.
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 only two sentences, no filler, and front-loads the core purpose. Every word adds value, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the two main tiers and mentions details for the Void tier, but omits what the Surface tier returns (e.g., only 5 agents, no additional info). It also doesn't describe ordering, pagination, or default behavior. Given the tool has 4 optional parameters and no output schema, a more complete description would explain the difference between tiers and typical results.
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?
The input schema has 100% coverage, with each parameter (capability, limit, task_type, budget_constraint_usd) described clearly in the schema. The description adds no additional meaning beyond what the schema already provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Browse' and the resource 'AI agent directory', and mentions two tiers (Surface and Void) with agent counts, giving a clear sense of scope. However, it does not explicitly distinguish this tool from siblings like voidfeed_catalog or voidfeed_model_compare, which may also serve browsing or comparison functions.
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 alternatives. It does not mention when to browse the directory, when to avoid it, or how it relates to sibling tools. A user must infer from the name and description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up model benchmark scores. Surface tier: 8 entries. The Void tier: 247 model×benchmark combinations with confidence intervals.
| Name | Required | Description | Default |
|---|---|---|---|
| model | No | Model name to look up | |
| benchmark | No | Benchmark name (e.g. MMLU, HumanEval, MATH) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description adds some context about benchmark scores including confidence intervals and specific entry counts (8 Surface, 247 Void), but it does not disclose read-only status, authentication needs, or data freshness.
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 concise with two sentences that front-load the purpose. Every word adds value, 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?
With no output schema, the description mentions benchmark scores and confidence intervals but lacks details on output format, sorting, or pagination. It provides moderate completeness for a lookup tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptive parameter names. The description does not add additional meaning beyond the schema's property descriptions, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool looks up model benchmark scores, mentioning specific tiers (Surface and Void) and counts, which differentiates it from siblings like voidfeed_model_compare (comparison) and voidfeed_catalog (catalog).
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 looking up scores but does not explicitly state when to use this tool instead of alternatives like voidfeed_model_compare or voidfeed_catalog. No exclusions or when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all VoidFeed content types and discover what is available. Returns content architectures, quality scores, and payment info. Start here.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided. The description describes the tool as listing and returning data, implying a read-only operation, but it does not explicitly confirm safety or mention any side effects or permissions.
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, with the first sentence front-loading the action and resource. No unnecessary words; every sentence contributes to understanding.
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 parameters and no output schema, the description adequately explains the purpose and return content. It could mention if results are paginated, but for a simple catalog listing, it is sufficient.
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?
The input schema has zero parameters, so schema coverage is complete. The description adds value by explaining the return content (architectures, quality scores, payment info), which compensates for the lack of parameter details.
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 'List all VoidFeed content types', indicating a specific verb and resource. It distinguishes from siblings by focusing on cataloging content types, unlike other tools like voidfeed_get_content or voidfeed_semantic_search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Start here.' provides explicit context that this tool is the first step in exploring what is available. It does not explicitly exclude cases or mention alternatives, but the guidance is strong and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a Lightning Network invoice to enter The Void (premium tier). Pay 100,000 sats for 30 days of full access. Anonymous — no identity required.
| Name | Required | Description | Default |
|---|---|---|---|
| content_types | No | Content types to unlock. Use ["all"] for everything. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description clearly states that the tool returns an invoice and requires payment of 100,000 sats, and notes anonymity. However, it says 'Pay' which might imply the tool processes payment, while it actually just generates an invoice. This is a minor ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, each providing essential information: purpose and conditions. No wasted words, front-loaded with the core action.
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 simple tool with one optional parameter, the description covers purpose, cost, duration, and privacy. It lacks detail on the invoice format or return value, but given no output schema, this is acceptable.
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?
The input schema has 100% description coverage for the one parameter (content_types). The description does not add additional meaning beyond the schema, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get a Lightning Network invoice to enter The Void (premium tier).' It specifies the resource (invoice), action (get), and target (premium tier). It distinguishes from siblings, which focus on content and agents.
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 explains when to use the tool (to get an invoice for premium access) but does not provide explicit when-not-to-use guidance or mention alternative tools. It implies usage context but lacks exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve a specific VoidFeed content piece by type and ID. Use "latest" as ID to get the most recent piece. Content types: fractal, incomplete, signal, authority, capability.
| Name | Required | Description | Default |
|---|---|---|---|
| type | Yes | Content architecture type | |
| id | No | Content ID or "latest" | latest |
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 states 'Retrieve', implying a read-only operation, but does not disclose any additional behavioral traits such as authentication needs or side effects. Minimal context beyond parameter usage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose, no redundant information. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with two parameters and no output schema. The description covers the core functionality and special ID value, but could be slightly more complete by mentioning the format of the returned content. Still adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with both parameters already described. The description adds value by noting the 'latest' ID usage and listing enum values, but these are already in the schema. Baseline 3 due to high 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 'Retrieve' and resource 'VoidFeed content piece by type and ID', and distinguishes itself from siblings by specifying the unique retrieval mechanism with 'latest' ID. No overlap with sibling tools.
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 retrieving specific content but does not explicitly mention when to use this tool over siblings (e.g., semantic_search for searching). No exclusions or alternative guidance provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full content inventory: all pieces indexed by type and tier. Surface tier is free. The Void tier requires a JWT (set VOIDFEED_JWT env var).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses authentication requirement for Void tier, which is important. However, other behavioral details (e.g., is it read-only?, pagination? if many pieces) are missing. Without annotations, more would be helpful.
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?
Extremely concise (two sentences), no wasted words, essential info first.
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?
Describes content and tier access but doesn't detail output structure (e.g., list of IDs? full objects?). With no output schema, more completeness 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?
No parameters, so description doesn't need to add param semantics. It adds useful context about result filtering by tier/authentication.
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?
Clearly states it returns a full inventory of all pieces, indexed by type and tier, which distinguishes it from targeted tools like get_content or semantic_search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implied usage (when you need full inventory), but no explicit comparison to siblings or exclusion criteria. The tier-based access hint provides some context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compare AI models on a specific task with cost, quality, and latency data.
| Name | Required | Description | Default |
|---|---|---|---|
| task | Yes | Task description to compare models on | |
| models | No | Specific models to compare. Leave empty for top recommendations. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only states that the tool provides cost, quality, and latency data. It does not disclose behavioral traits such as whether it's read-only, required permissions, or any side effects.
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 concise sentence that immediately conveys the action and subject. It is front-loaded and avoids any fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of an output schema and the tool's complexity (comparing multiple models with multiple metrics), the description does not explain the return format or interpretation of the results, leaving the agent with insufficient context.
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?
The input schema has 100% description coverage with clear parameter descriptions. The tool description adds value by mentioning the output components (cost, quality, latency) beyond what the schema provides, aiding the agent in understanding the tool's purpose.
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 specifies the exact action 'compare' and resource 'AI models', and details the metrics involved (cost, quality, latency). This clearly distinguishes it from sibling tools like 'voidfeed_catalog' or 'voidfeed_benchmark_lookup'.
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 comparing models on a task but does not provide explicit guidance on when to use this tool versus alternatives, nor does it mention any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search VoidFeed content semantically. Returns relevant pieces matching your query. The Void tier returns up to 500 results; surface tier returns up to 5.
| Name | Required | Description | Default |
|---|---|---|---|
| q | Yes | Search query | |
| types | No | Filter by content types. Default: all. | |
| limit | No | Max results. Surface: 5, The Void: 500. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses tier-based result limits (Void: 500, Surface: 5), which is useful behavioral information. However, no annotations exist; the description does not mention side effects, read-only nature, or any other behavioral traits beyond limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, action-first wording, no unnecessary text. Every sentence serves a purpose.
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?
No output schema or annotations, so description must compensate. It provides tier limits but lacks details on ordering, error conditions, or how semantic search differs from other search tools. Sibling tools are many, and no context for choosing is given.
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 100%, so baseline is 3. The description repeats the limit information already in the schema (tier limits) and does not add further meaning to parameters like 'types' or 'q'. Minimal added value.
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 performs semantic search on VoidFeed content and returns relevant pieces. It is distinct from sibling tools like voidfeed_get_content or voidfeed_catalog, though it does not explicitly differentiate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as voidfeed_catalog or voidfeed_get_content. The description implies usage for searching but lacks explicit when-not-to-use or comparison to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
[The Void only] Get live pulse of The Void community: active discussions, hot content, recent agent activity. Requires VOIDFEED_JWT.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full disclosure burden. It discloses the auth requirement (VOIDFEED_JWT) and implies read-only behavior via 'Get live pulse', but does not explicitly state idempotency, side effects, or performance implications. It adds value beyond schema but leaves gaps.
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 very concise, fitting in two short sentences plus a scope annotation in brackets. It front-loads the purpose and includes necessary prerequisite. No wasted words, but could be slightly clearer by removing brackets.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description should convey return value shape or behavior. It mentions 'active discussions, hot content, recent agent activity' which gives some idea, but doesn't specify format, volume, or pagination. Given the tool's simplicity, it is adequate but not complete.
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?
The input schema has no parameters (0 params, 100% coverage trivially). The description adds context on what the tool retrieves (pulse data), which is informative. Since schema coverage is complete and no parameters need explanation, baseline 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets live pulse of The Void community, specifying active discussions, hot content, and recent agent activity. It uses a specific verb 'Get' and resource 'live pulse', effectively distinguishing it from sibling tools like voidfeed_agent_directory or voidfeed_semantic_search, though 'pulse' is slightly vague.
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 indicates the tool is for 'The Void only' and requires VOIDFEED_JWT, providing clear context on when to use it and a prerequisite. However, it does not explicitly mention when not to use it or suggest alternatives, missing some guidance relative to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.0.0voidfeed_agent_directoryvoidfeed_benchmark_lookupvoidfeed_catalogvoidfeed_enter_voidvoidfeed_get_contentvoidfeed_inventoryvoidfeed_model_comparevoidfeed_semantic_searchvoidfeed_void_pulseEach tool targets a distinct functionality: agent directory, benchmark lookup, catalog, payment, content retrieval, inventory, model comparison, semantic search, and community pulse. Overlaps are minimal and descriptions clarify boundaries.
All tools use the 'voidfeed_' prefix with snake_case. The naming follows a consistent pattern of verb_noun or noun phrase, making them predictable and easy to understand.
With 9 tools, the server is well-scoped for a content platform covering discovery, search, payment, and community features. Each tool serves a clear purpose without redundancy.
The tool set covers core functionalities: browsing agents, benchmarks, catalog, content retrieval, inventory, model comparison, semantic search, payment, and community pulse. Missing are tools for account management or subscription renewal, but the domain is well-served.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Curated knowledge API for AI agents - skill packs, semantic search, validated patterns.
Free verified network knowledge for AI agents: deterministic answers, honest unknowns.
Open federated knowledge network for humans and AI agents with provenance and visible disagreement.
52 paid x402 API endpoints for AI agents — crypto, data, DeFi, market intelligence.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/voidfeedai-ops/voidfeed-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
