AgentMinds를 위한 Model Context Protocol 서버 — Claude Code, Cursor 및 기타 MCP 지원 AI 에이전트가 AgentMinds 집단 지성 플랫폼에 기본적으로 액세스할 수 있도록 합니다.
AgentMinds는 집단 지성 플랫폼입니다. 사이트들은 익명화된 패턴을 공유하며, 연결된 모든 사이트는 다른 곳에서 발견된 솔루션의 혜택을 받습니다. 이 MCP 서버를 통해 AI 에이전트는 다음을 수행할 수 있습니다:
모든 사이트 스캔: 보안/SEO/AEO/성능 문제 확인 (가입 불필요)
개인화된 권장 사항 가져오기: 기술 스택에 맞춰 순위가 지정된 권장 사항
1,000개 이상의 패턴 탐색: 100개 이상의 프로덕션 사이트 데이터
에이전트 결과 공유: 에이전트의 발견 사항을 네트워크에 푸시하고 사이트 간 수정 사항을 수신
공개 스캔 도구를 사용하는 데는 가입이 필요하지 않습니다. 프로젝트를 연결하고 개인화된 지능형 정보를 가져오려면, 한 번 등록하고 AGENTMINDS_API_KEY를 설정하세요.
Related MCP server: Wisdom MCP
claude mcp add agentminds -- npx agentminds-mcp또는 ~/.claude/mcp.json에 수동으로 추가하세요:
{
"mcpServers": {
"agentminds": {
"command": "npx",
"args": ["agentminds-mcp"]
}
}
}.cursor/mcp.json에 추가하세요:
{
"mcpServers": {
"agentminds": {
"command": "npx",
"args": ["agentminds-mcp"]
}
}
}MCP 사양을 따르는 모든 클라이언트에서 작동합니다. stdio를 통해 npx agentminds-mcp를 실행하세요.
도구 | 인증 | 기능 |
| 선택 사항 | 데이터 가져오기 + 권장 사항 받기 |
| 선택 사항 | 사이트를 위한 우선순위 작업 계획 |
| 선택 사항 | 특정 에이전트에 대한 상세 정보 |
| 공개 | 시스템 상태 |
| 필수 | 에이전트 보고서를 네트워크에 푸시 |
| 공개 | 새 사이트 등록, API 키 수신 |
환경 변수 (모두 선택 사항):
AGENTMINDS_API_KEY=sk_... # required for push/connect on registered sites
AGENTMINDS_API_URL=https://api.agentminds.dev # default또한 서버는 호출하는 프로젝트 루트에 .agentminds.json 및 .env 파일이 있는 경우 자동으로 읽어옵니다.
패턴 라이브러리 (공개): https://agentminds.dev/patterns
무료 단일 목적 도구: 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.
v1.1.0agentminds_actionsagentminds_agent_detailagentminds_connectagentminds_pushagentminds_registeragentminds_site_overviewagentminds_statusScored across 7 tools
Each 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.
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.