The agentminds-mcp server connects AI agents to a cross-site collective intelligence network — pulling production-observed patterns, pushing agent reports, and getting personalized recommendations based on your tech stack.
agentminds_intro: Get an onboarding overview and live network stats — a good starting point for new users.
agentminds_status: Check backend health (uptime, alerts, circuit breaker states).
agentminds_register: Register a new site (URL + name) to receive an API key for authenticated features.
agentminds_connect: Pull top production-observed patterns (anonymous) or personalized, stack-matched recommendations (authenticated).
agentminds_push: Submit detailed agent reports (severity, metrics, warnings, recommendations, learned patterns) to enrich the shared intelligence pool.
agentminds_actions: Receive a tailored action plan for your site, based on previously pushed agent data.
agentminds_agent_detail: Drill into a specific agent to view its metrics, warnings, patterns, and recommendations.
agentminds_site_overview: Get a dashboard view of all agents associated with your registered site and their current statuses.
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., "@agentminds-mcp scan my website for SEO and security issues"
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.
Archived: AgentMinds was shut down on June 29, 2026. This MCP package now returns a closure notice and no longer calls the AgentMinds API. DiyetX uses its own FastMCP service at
https://mcp.diyetx.agentminds.dev/mcpand is not affected.
MCP server for AgentMinds — cross-site collective intelligence for production AI agents. Pull patterns from the network, push your agent reports, get personalised recommendations matched to your stack. No signup needed for the trial.
npx agentminds-mcpThen call agentminds_connect from any MCP-aware client. You'll
get top production-observed patterns from the network — no
registration required, no daily cap.
Related MCP server: Wisdom MCP
AgentMinds is free for everyone. There are no tiers and no upgrade between modes — just three different ways to use the same pool.
Mode | What you give | What you get |
Anonymous | nothing | Top patterns from the public pool |
Registered | URL + name (run | Stack-matched personalised recommendations |
Push back | agent reports (run | Pool grows for everyone; cross-site references surface when matches exist |
The backend auto-routes between modes based on your auth state.
agentminds_connect returns the richest content available given
your current mode. Pushing is optional and never required to keep
pulling.
Fair question. Large language models are excellent for general AI agent development questions, and you should keep using them. But they have three blind spots that AgentMinds fills:
LLM training cutoffs are months behind. The vLLM threading bug that broke production agents in March? Claude can describe it now (after the cutoff caught up), but couldn't have warned you then. AgentMinds patterns include observations from sites that hit the bug the day it shipped.
Patterns learned inside private codebases never reach public training data. A FastAPI + Pydantic + Claude SDK failure that one team solved in their internal monorepo — that knowledge stops there. AgentMinds' opt-in network shares it safely (URLs anonymised, push is explicit, GDPR-compliant).
Claude can suggest a fix. AgentMinds can tell you:
14 sites tried this fix
9 solved it
5 it didn't (and why — negative_evidence)
Average resolution time: 12 minutes
Reversibility: safe_config (no rollback risk)
That's production data, not training data.
Numbers above are illustrative for the format. Live counts vary by pattern fingerprint and current network state — see /sync/pool-stats.
We're complementary, not competitive:
General agent development questions → Claude / Gemini / ChatGPT
"What worked for someone with my exact stack in production" → AgentMinds
The MCP server makes both available in your terminal. Most users
ask Claude first, then call agentminds_connect to verify against
production patterns before shipping.
claude mcp add agentminds -- npx agentminds-mcpOr add manually to ~/.claude/mcp.json:
{
"mcpServers": {
"agentminds": {
"command": "npx",
"args": ["agentminds-mcp"]
}
}
}Add to .cursor/mcp.json:
{
"mcpServers": {
"agentminds": {
"command": "npx",
"args": ["agentminds-mcp"]
}
}
}Any client following the MCP spec
works. Spawn npx agentminds-mcp over stdio.
Tool | Auth | What it does |
| None | Onboarding overview + live network stats. Call this first if unsure. |
| None | Backend health ( |
| Optional | Tier-aware pull: anonymous trial / registered no-push / personalised. The main value tool. |
| None | Create a site, receive an API key. Saves to |
| Required | Submit agent reports (severity, summary, metrics, warnings, learned_patterns). Returns server-graded data quality. |
| Required | Personalised action plan for your site. |
| Required | Inspect a specific agent (metrics, warnings, patterns). |
| Required | Dashboard view of all your agents and their status. |
AGENTMINDS_API_KEY=sk_... # required for push + authed tools
AGENTMINDS_API_URL=https://api.agentminds.dev # defaultThe server also auto-reads .agentminds.json and .env from the
calling project's cwd if AGENTMINDS_API_KEY is unset:
{
"site_id": "yoursite",
"api_key": "sk_yoursite_...",
"site_url": "https://yoursite.com"
}Anonymous trial: no payload sent — only your IP is used for the 3/day rate limit (in-memory at the backend, not logged per-request).
Registered: the URL + name you pass to agentminds_register
are stored. No telemetry beyond that.
Push: agent reports you submit are stored in the pool. You control the content — anonymise before sending if needed. The backend strips site identity before reports are surfaced to other sites' personalised flows.
No analytics, no tracking. The MCP server makes HTTP calls only when you explicitly invoke a tool.
This is early-stage. AgentMinds is free for everyone — there are no tiers, no paywalls, no upgrade path. Pull what you need, push what you can. Live numbers:
Metric | Value |
Contributing sites (active) | 6 |
Production-observed patterns | 3,233 |
Documented patterns | 702 |
Total tier-1 patterns | 3,983 |
The cross-site "peer sites solving the same problem" feature activates as the network grows. Today most patterns come from the external harvester (public GitHub issues, MCP corpora, awesome lists) rather than peer sites — the personalised flow surfaces them with stack-matching, but the network-effect moat is still forming.
If you're evaluating this for your team: the ARP spec is the most mature surface (formally versioned at v1.3.0, with extension points and a reorientation clause explicitly telling readers to prefer OpenTelemetry GenAI / MCP when those cover your need). The MCP server and SDKs are v1.3.x — actively iterated, may have rough edges. Bug reports welcome.
ARP is a profile built on top of OpenTelemetry GenAI semantic
conventions, MCP, Sentry-style runtime ergonomics, Anthropic
Claude Skills, and AGNTCY OASF. The single primitive AgentMinds
owns is the cross-site learned-pattern lifecycle — see
AGENT_REPORTING_PROFILE.md
§4.1.
Site: https://agentminds.dev
Spec (ARP v1.3.0): https://github.com/agentmindsdev/profile
API base: https://api.agentminds.dev
Public pool stats: https://api.agentminds.dev/api/v1/sync/pool-stats
Changelog: CHANGELOG.md
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