Click on "Deploy 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., "@crowdsec-mcp show recent decisions from CrowdSec"
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.
A read-only MCP server for CrowdSec, exposing decisions and alerts.
name | endpoint | required secret |
|
| bouncer key |
|
| bouncer key |
|
| machine login |
|
| machine login |
Related MCP server: LimaCharlie MCP
We need two credential types:
Decisions need only a bouncer API key (cscli bouncers add <name>), which is
inherently read-only. This alone is enough for list_decisions / decisions_stream.
Alerts are only reachable with machine credentials (cscli machines add),
exchanged for a short-lived JWT. That credential is technically read-write on LAPI, so
this server only ever issues GET requests (plus the login POST). The alert tools stay
disabled unless machine credentials are configured.
name | default | use |
|
| LAPI base URL |
| — | bouncer API key (enables decision tools) |
| — | machine id (enables alert tools) |
| — | machine password |
|
| set |
| Name | Required | Description | Default |
|---|---|---|---|
| scopes | No | ||
| origins | No | ||
| startup | No | ||
| scenarios_containing | No | ||
| scenarios_not_containing | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| alert_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| ip | No | ||
| limit | No | ||
| range | No | ||
| scope | No | ||
| since | No | ||
| until | No | ||
| value | No | ||
| origin | No | ||
| scenario | No | ||
| decision_type | No | ||
| has_active_decision | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| ip | No | ||
| type | No | ||
| range | No | ||
| scope | No | ||
| value | No | ||
| origins | No | ||
| scenarios_containing | No | ||
| scenarios_not_containing | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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.
v0.1.0decisions_streamget_alertlist_alertslist_decisionsScored across 4 tools
The four tools target two distinct resources (decisions and alerts) with clear action prefixes (list, get, stream). The main ambiguity is between list_decisions and decisions_stream, both dealing with decisions, but one implies a static list and the other a real-time stream. Overall, the purposes are distinguishable.
Three tools follow the verb_noun pattern (list_decisions, list_alerts, get_alert), but decisions_stream breaks this pattern with a noun_noun structure. The underscores are consistent, but the mix of verb-leading and noun-leading names is a minor inconsistency.
With 4 tools, the set is within the typical well-scoped range (3-15). The count feels minimal but appropriate for a read-only client focused on listing and streaming decisions and alerts. It could be slightly more comprehensive, but it is not excessive.
The domain is CrowdSec decisions and alerts, and the set covers listing and streaming decisions, plus listing and fetching alerts. Notable gaps include a get_decision operation and any mutation endpoints (create/update/delete). These are common expectations in such a domain, so the surface is incomplete but not severely so.
An MCP server that provides an API to LLMs to manage their JumpCloud resources.
MCP server for mandates, delegation, policy-gated execution, credential grants, and audit.
Read-only MCP server for The Quiet Protocol's engines, benchmarks, proof, and business data.
An MCP server that let you interact with Cycloid.io Internal Development Portal and Platform
