Servidor del Protocolo de Contexto de Modelo (MCP) para AgentMinds: proporciona a Claude Code, Cursor y otros agentes de IA compatibles con MCP acceso nativo a la plataforma de inteligencia colectiva de AgentMinds.
AgentMinds es una plataforma de inteligencia colectiva: los sitios comparten patrones anonimizados y cada sitio conectado se beneficia de las soluciones descubiertas en otros lugares. Este servidor MCP permite que su agente de IA:
Escanee cualquier sitio en busca de problemas de seguridad, SEO, AEO o rendimiento (sin registro)
Obtenga recomendaciones personalizadas clasificadas para su pila tecnológica
Explore más de 1.000 patrones de más de 100 sitios en producción
Envíe los hallazgos de su agente a la red y reciba correcciones de otros sitios
No se requiere registro para utilizar las herramientas de escaneo público. Para conectar su proyecto y obtener inteligencia personalizada, regístrese una vez y configure AGENTMINDS_API_KEY.
Related MCP server: Wisdom MCP
claude mcp add agentminds -- npx agentminds-mcpO añádalo manualmente a ~/.claude/mcp.json:
{
"mcpServers": {
"agentminds": {
"command": "npx",
"args": ["agentminds-mcp"]
}
}
}Añada a .cursor/mcp.json:
{
"mcpServers": {
"agentminds": {
"command": "npx",
"args": ["agentminds-mcp"]
}
}
}Cualquier cliente que siga la especificación MCP funciona. Ejecute npx agentminds-mcp a través de stdio.
Herramienta | Autenticación | Qué hace |
| Opcional | Obtener datos + recibir recomendaciones |
| Opcional | Plan de acción priorizado para su sitio |
| Opcional | Información detallada sobre un agente específico |
| Público | Estado del sistema |
| Requerido | Enviar el informe de su agente a la red |
| Público | Registrar un nuevo sitio, recibir clave API |
Variables de entorno (todas opcionales):
AGENTMINDS_API_KEY=sk_... # required for push/connect on registered sites
AGENTMINDS_API_URL=https://api.agentminds.dev # defaultEl servidor también lee automáticamente .agentminds.json y .env desde la raíz del proyecto que realiza la llamada si están presentes.
Sitio: https://agentminds.dev
Documentación: https://agentminds.dev/docs
Biblioteca de patrones (pública): https://agentminds.dev/patterns
Herramientas gratuitas de propósito único: https://agentminds.dev/tools
MIT.
Get action plan — ONLY works if you already pushed data. If no data was pushed, this returns nothing. DO NOT fabricate recommendations. Show only what this tool returns.
| Name | Required | Description | Default |
|---|---|---|---|
| site_id | No | Site ID (e.g. mimari_ai, gridera_io). If not provided, determined from API key. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Logically discloses that no prior push results in empty response. Warns not to fabricate. Lacks detail on expected output structure, but effective given no annotations.
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 efficiently convey purpose, condition, and usage rule. No redundant words; front-loaded with primary 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?
Adequately explains tool's dependency on prior data push. No output schema but fulfills core requirement; minor gap on output format.
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 covers 100% of parameter description. No additional semantic value from description beyond schema, meeting baseline expectation.
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 'Get action plan' as verb+resource. Implicitly distinguishes from sibling tools like agentminds_push by requiring prior data push, making its purpose unique.
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?
Explicitly tells when to use: only after data is pushed. Also warns against fabricating recommendations, providing clear guidance on proper usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed info about a specific agent — metrics, warnings, patterns, recommendations. Use when user asks about a specific agent like 'health agent ne diyor?', 'security durumu'.
| Name | Required | Description | Default |
|---|---|---|---|
| site_id | Yes | Site ID | |
| agent_name | Yes | Agent name (health, security, performance, seo, content, quality, feedback, learning, supervisor, ui, e2e, user_behavior, design, social_media) |
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 mentions the type of data returned (metrics, warnings, patterns, recommendations), which is helpful. However, it does not explicitly state that the tool is read-only or describe any potential side effects, performance considerations, or error conditions. For a get operation, the transparency is adequate but not exceptional.
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: two sentences with no filler. The first sentence states the core purpose, and the second provides usage context with examples. Every word serves a purpose, achieving high efficiency.
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 that there is no output schema, the description compensates by listing the categories of information returned (metrics, warnings, patterns, recommendations). This gives the agent a clear expectation of the output. However, it does not mention any pagination, error handling, or field-level details, which would be needed for a perfect score. Still, it is adequate for a detail-fetching 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?
The input schema has 100% description coverage, so the baseline is 3. The description adds context by listing example agent names (health, security, etc.) and implying the need for a specific query. However, it does not provide additional meaning beyond what the schema already offers (e.g., site_id is a string, agent_name has a definitive list). The value-add is marginal.
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 function: 'Get detailed info about a specific agent — metrics, warnings, patterns, recommendations.' It uses a specific verb 'get' and a clear resource 'detailed info about a specific agent,' which distinguishes it from sibling tools like agentminds_site_overview (site-level overview) and agentminds_status (general status). The addition of Turkish example queries further clarifies the intended use.
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 states when to use the tool: 'Use when user asks about a specific agent...' and provides concrete example queries. However, it does not explicitly mention when not to use it or list alternatives among the sibling tools, which would have elevated the score to 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Connect to AgentMinds Central — fully automatic.
CRITICAL RULES:
You MUST send your learned data FIRST before getting any recommendations
If this tool returns an error or "no_data", show ONLY the error message
DO NOT generate fake recommendations if the API fails or times out
DO NOT say "AgentMinds recommends..." unless you received real data from this tool
If you cannot reach the API, say "AgentMinds'a bağlanılamadı" — nothing else
If no key: register first, then push data, then get recommendations. If has key: push data → get recommendations.
Before calling this, collect DETAILED agent data from this project:
For each agent/module: what it does, its metrics, any issues found
Warnings and errors discovered
Patterns learned
Use agentminds_push to send detailed data FIRST, then connect for recommendations. The more data you send, the better recommendations you get.
| Name | Required | Description | Default |
|---|---|---|---|
| site_url | No | Site URL for registration (e.g. https://mysite.com). Only needed if auto-detection fails. | |
| brain_export_url | No | URL to pull brain data from (e.g. https://api.mysite.com/api/v1/brain/export). Optional. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description fully covers behavior: it details error responses, dependency on prior data push, and the fact that more data yields better recommendations. It does not mention destructive actions, but none are expected for a read-like connection 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 well-structured with bullet points and clear sections. It is front-loaded with the core purpose. While it contains extensive critical rules, they are organized logically. Slightly verbose but not excessively so.
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 annotations and output schema, the description provides thorough context: it explains when to use, prerequisites, error handling, and integration with sibling tools (register, push). It fully equips the agent to invoke the tool correctly.
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% for both parameters. The description adds no additional meaning beyond what is already in the schema, meeting the baseline expectation. No extra value from parameter semantics.
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 states 'Connect to AgentMinds Central — fully automatic' and outlines a clear flow of pushing data then getting recommendations. It distinguishes itself from siblings like agentminds_push by focusing on the connection step, but the purpose is slightly diluted by extensive rules.
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?
Explicitly states prerequisites ('send your learned data FIRST'), error handling ('show ONLY the error message'), and step-by-step workflow (register, push, connect). Also warns against generating fake recommendations, providing clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Push detailed agent data to AgentMinds Central. IMPORTANT: Send FULL data, not just names and scores.
Each agent report MUST include:
severity: "critical" | "warning" | "info"
summary: what the agent found (1-2 sentences)
metrics: key numbers (e.g. {total_leads: 567, bounce_rate: 3.5, open_rate: 12})
warnings: array of issues found [{severity: "warning", message: "..."}]
recommendations: array of suggested fixes [{title: "...", priority: "high"}]
memory.learned_patterns: what the agent learned [{pattern: "...", category: "...", confidence: 0.9, status: "active", impact: "high"}]
The MORE detail you send, the BETTER recommendations you get back. Empty data = empty recommendations.
Example: {agent: "lead_hunter", report: {severity: "warning", summary: "567 leads found but 0% open rate", metrics: {total_leads: 567, emails_found: 230, open_rate: 0, bounce_rate: 8.3}, warnings: [{severity: "critical", message: "0% email open rate - emails likely going to spam"}], recommendations: [{title: "Warm up email domain before bulk sending", priority: "critical"}]}, memory: {learned_patterns: [{pattern: "cold_email_spam", category: "email_deliverability", confidence: 0.9, status: "active", impact: "critical", detail: "Bulk cold emails without domain warmup go to spam"}]}}
| Name | Required | Description | Default |
|---|---|---|---|
| reports | No | Array of DETAILED agent reports. Each must have: agent, report (severity, summary, metrics, warnings, recommendations), memory (learned_patterns) | |
| brain_export_url | No | URL for Central to pull brain data from (alternative to sending reports directly) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It describes the expected input format and the consequence of not sending enough detail. It does not mention authentication or side effects, but the main behavior is well-covered.
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 longer due to the example, but the structure is logical: purpose, important note, bullet points, and a complete JSON example. It is front-loaded and every part 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?
Given the complexity of the nested arrays and no output schema, the description comprehensively explains the required input structure. It leaves no ambiguity about what data to send.
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%, and the description adds extensive detail beyond the schema: it specifies required fields, structure, and an example for the 'reports' parameter, and explains the 'brain_export_url' as an alternative.
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 ('Push detailed agent data to AgentMinds Central') and provides a specific resource. It distinguishes from sibling tools (e.g., agentminds_actions, agentminds_status) by focusing on data submission.
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 instructs to send full data and warns that empty data yields empty recommendations. It lacks an explicit when-not-to-use clause, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Register a new site with AgentMinds Central. Returns API key. Use when user says 'kayıt ol', 'register', 'yeni site ekle'.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Site URL (e.g. https://mysite.com) | |
| name | Yes | Site name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses that the tool returns an API key, which is a behavioral outcome. However, it omits details about authorization requirements, error handling, or idempotency.
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-loading the purpose and return value, followed by usage cues. Every word adds value 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?
For a simple registration tool with only two required parameters and no output schema, the description covers the core purpose and triggers. It could mention error cases or whether registration is idempotent, but is largely complete given the tool's simplicity.
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 the schema already documents both parameters. The description adds no extra meaning beyond the schema, and the baseline 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 'Register', the resource 'a new site with AgentMinds Central', and the return value 'API key'. It distinguishes from sibling tools like agentminds_connect or agentminds_status by focusing on registration.
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?
Explicitly lists trigger phrases ('kayıt ol', 'register', 'yeni site ekle') indicating when to use. Does not provide exclusions or alternatives, but the sibling list makes it clear this is the only registration tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get full overview of your site — all agents, their status, scores. Use when user asks 'site durumu', 'genel durum', 'tüm agentları göster'.
| Name | Required | Description | Default |
|---|---|---|---|
| site_id | Yes | Site ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description should disclose behavioral traits. It mentions getting a 'full overview' and lists what is returned (agents, status, scores), but does not mention if it is read-only, auth needs, or pagination.
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: first defines the tool's action, second provides usage examples. No fluff, every sentence 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?
For a simple tool with one parameter and no output schema, the description is fairly complete. It explains what it returns and when to use it, though it could mention prerequisites or errors.
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% for the single parameter 'site_id' with basic description 'Site ID'. The description adds no extra meaning beyond the schema, so baseline 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 purpose: 'Get full overview of your site — all agents, their status, scores.' It uses specific verb and resource, and the example queries help distinguish from 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 provides explicit usage guidance with example queries like 'site durumu', but lacks explicit when-not-to-use or alternative tool references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check AgentMinds Central system health — is the server up, any alerts, circuit breakers. Use when user asks 'sistem durumu', 'AgentMinds çalışıyor mu?'.
| 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 burden. It implies a read-only health check without detailing side effects or output format, but the behavior is inherently transparent (non-destructive, no parameters). Could be improved by noting response structure or rate 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?
The description is a single, front-loaded sentence with no redundant words. It efficiently conveys purpose and usage examples.
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 zero-parameter, no-output-schema health check tool, the description covers essential context: what it checks and when to use. It is complete enough for an agent to invoke correctly, though adding expected response format would improve completeness.
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?
There are zero parameters and schema coverage is 100%. The description does not need to add parameter information beyond the schema; baseline is 4.
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 uses specific verbs and resources: 'Check AgentMinds Central system health' with concrete checks like 'server up, any alerts, circuit breakers'. It clearly distinguishes from siblings which handle specific actions like agent details or connections.
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 states when to use this tool: 'when user asks 'sistem durumu', 'AgentMinds çalışıyor mu?''. It provides clear context for invocation, though it does not explicitly exclude other scenarios, which is acceptable given the narrow purpose.
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.1.0agentminds_actionsagentminds_agent_detailagentminds_connectagentminds_pushagentminds_registeragentminds_site_overviewagentminds_statusEach tool has a clearly distinct purpose: registration, data pushing, overviews, agent details, actions, connection, and status. No overlap or ambiguity.
All tools follow a consistent 'agentminds_' prefix with lower_snake_case naming pattern, making them predictable and easy to distinguish.
Seven tools is well-scoped for the AgentMinds domain; each tool serves a necessary function without redundancy or excess.
The tool surface covers the full lifecycle: registration, data pushing, individual and overview queries, recommendations, and system health. No obvious gaps.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Hosted MCP server for live public-data APIs and Skills for AI agents.
MCP server for building and testing AI agents with multi-model experimentation and insights.
SEO MCP server: crawl your site, find AI-visibility gaps, and ship the fix from your coding agent.
MCP server for AI agents to plan, verify, and deploy Cloudflare-native apps.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/agentmindsdev/mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server