mcp-centreon

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation5/5
Each tool targets a distinct resource and action (list vs get, host vs service, acknowledge vs downtime, metrics discovery vs data retrieval). No two tools appear to do the same thing, and action verbs clearly differentiate between read and write operations.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern (get_, list_, acknowledge_, add_downtime_), using snake_case throughout. The pattern is predictable and makes it easy to guess the purpose of a tool from its name.
Tool Count4/5
At 17 tools, the server is slightly above the ideal 3-15 range but each tool serves a distinct purpose within the monitoring domain. The count feels justified, covering hosts, services, groups, events, acknowledgements, downtimes, metrics, and pollers, though it is a bit heavy.
Completeness4/5
The tool surface covers the core monitoring lifecycle: viewing hosts/services, acknowledging problems, scheduling downtimes, and fetching performance metrics. Missing operations like canceling a downtime or listing acknowledgements in detail are minor gaps that agents could work around, but the set is largely complete for common monitoring tasks.
Average 3.7/5 across 17 of 17 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- Last stable release on May 29, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. While 'list' implies a read-only operation, the description does not explain what 'recent' means, how pagination works, or what output format to expect. There is no mention of destructive hints or side effects, leaving significant behavioral unknowns.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that immediately states the core action and key filtering options. It contains no fluff or redundancy, making it highly efficient for an agent to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 7 optional parameters, no annotations, and no output schema, the description is under-specified. 'Recent' is vague and undefined, and there is no explanation of pagination, default time windows, or return fields. The missing context makes it hard for an agent to set correct expectations about the results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all seven parameters, so the baseline is 3. The description mentions filtering by host, state, or check type, which maps to existing schema fields, but adds no additional meaning beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List') and resource ('monitoring events and alerts in Centreon'), and mentions filtering options. However, it does not distinguish this tool from sibling tools like list_acknowledgements or list_downtimes, which also deal with monitoring events.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives. Sibling tools exist but are never referenced, and no use-case context or exclusions are provided. The description only states what the tool does, not when to choose it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It only states 'List service groups' but does not disclose pagination behavior, return format, permissions, or any other operational traits beyond the basic read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that front-loads the purpose. It contains no wasted words, though it is minimal and slightly underspecified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple nature of the tool and full schema parameter coverage, the description is minimally sufficient. However, with no output schema and no annotations, it lacks context on response format and usage nuances, making it less complete than ideal.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema descriptions cover 100% of parameters (page, limit, search), so the baseline is 3. The description adds no additional meaning about parameters, but the schema already fully documents them.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List') and resource ('service groups configured in Centreon'). It distinguishes from sibling tools by naming 'service groups' specifically, though it does not explicitly differentiate from similar listing tools like list_host_groups or list_services.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of typical use cases, pagination context, or scenarios where this tool is preferred over other list tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits itself. It mentions suppressing notifications but does not disclose that the action creates an acknowledgement record, is sticky by default, or whether it can be undone. The mutation behavior is under-communicated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that front-loads the verb and resource. Every word contributes value, and there is no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite a detailed schema, the overall context is incomplete for a mutation tool. There are no annotations, no usage guidelines, and no mention of side effects or reversibility. The description alone does not sufficiently prepare an agent to invoke this tool correctly in a broader workflow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% as all six parameters have descriptions. The tool description adds no information about parameters beyond what the schema provides, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Acknowledge') and resource ('service problem in Centreon'), clearly distinguishing it from sibling tools like acknowledge_host. It also states the key effect ('suppress notifications'), making the purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as acknowledge_host or add_downtime_service. There are no exclusions, prerequisites, or explicit context for when this is the appropriate choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for disclosing side effects and operational nuances. The only disclosed behavior is suppressing notifications; it does not mention reversibility, permissions, sticky/persistent behavior, or the acknowledgment lifecycle beyond the schema defaults.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, tightly worded sentence that immediately states the action and purpose without extraneous wording. It is appropriately concise and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 5 parameters, no annotations, and no output schema. The one-sentence description only covers the primary purpose, omitting expected return values, whether the action is reversible, and operational context such as prerequisites or consequences. This is insufficient for a mutation tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 all parameters with descriptions and defaults. The description adds no parameter-specific meaning beyond the schema, which is acceptable given full schema coverage, warranting a baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the action (acknowledge), the target resource (host problem in Centreon), and the purpose (suppress notifications). It distinguishes from siblings like acknowledge_service by explicitly mentioning 'host'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'to suppress notifications' implies a use case, but the description does not explicitly state when to use this versus related tools like acknowledge_service or add_downtime_host, nor does it mention exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the outcome (suppress notifications) but does not disclose details like whether the downtime is immediately applied, required permissions, or potential side effects. This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the primary action and purpose. There is no wasted wording, and every element contributes to understanding the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 6 parameters, no annotations, and no output schema, the description is too minimal to be complete. It does not explain return values, error handling, or usage prerequisites, leaving significant context missing for an agent to invoke it confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all six parameters already have meaningful descriptions in the schema. The tool description adds no additional parameter semantics, which is acceptable when the schema fully documents them; hence, the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Schedule a downtime') and resource ('a host in Centreon'), with the purpose of suppressing notifications during maintenance. This distinguishes it from sibling tool 'add_downtime_service' by explicitly naming 'host'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for scheduling host downtime but provides no explicit guidance on when to use this tool versus alternatives. No exclusions or when-not-to-use scenarios are mentioned, so it earns a baseline 'implied usage' score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing side effects. It mentions the effect ('suppress notifications') but does not disclose that this is a mutating operation, potential permission requirements, whether existing downtimes are replaced, or what the response/return value is. The description adds minimal behavioral context beyond the obvious scheduling action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the core purpose and resource. It contains no filler or redundant information, matching the standard of high-quality tool descriptions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 7 parameters, no annotations, and no output schema, making it moderately complex. The description is minimal and does not explain what the tool returns, how errors are handled, or how it interacts with existing downtime/acknowledgement tools. While the schema covers parameters, the overall context is incomplete for an agent to fully anticipate the tool's behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameters are already well-documented with types and descriptions (e.g., 'start_time' in ISO 8601, 'is_fixed' meaning fixed vs flexible). The description adds no additional parameter meaning or usage guidance, so the baseline of 3 is appropriate given the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action ('Schedule a downtime'), the target ('for a service in Centreon'), and the purpose ('to suppress notifications during maintenance'). It distinguishes from sibling tools by specifying 'service' rather than 'host', aligning with add_downtime_service vs add_downtime_host.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for maintenance windows where notifications need to be suppressed, but it does not explicitly state when to use this tool over alternatives like add_downtime_host or acknowledge_service. No exclusions or alternative tool names are provided, only the general context of maintenance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry behavioral context. 'Get' signals read-only, and 'full details' indicates a comprehensive return, but it doesn't disclose error behavior, required permissions, or any side effects. This is a moderate gap for a getter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence of only 14 words, front-loaded with the verb and resource. Every word adds essential meaning; no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema, the description doesn't clarify the return structure. It adequately explains the tool's core function but omits behavioral details like error handling or whether service_id is globally unique. For a simple getter with fully documented parameters, it's acceptable but not rich.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes both parameters as 'Centreon host ID' and 'Centreon service ID'; the description's 'by host ID and service ID' adds no new semantics. Schema coverage is 100%, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Get full details for a specific service by host ID and service ID,' which clearly identifies the action (get), resource (service), and selection criteria. It distinguishes from siblings like list_services (listing) and get_host (different resource).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or alternatives are given. The phrase 'specific service' implies you should use this when you have a known host_id and service_id, versus list_services for browsing. However, it doesn't name alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility. It only states that it returns aggregated counts, without disclosing behavior such as whether it is read-only, performance implications, or what 'state' categories are included. This is a significant gap for a monitoring tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-formed sentence that front-loads the verb and resource. It conveys the essential information without any wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter statistic tool with no output schema, the description is sufficiently complete: it states what the tool does and what data it returns. Minor missing details like the exact list of states are not critical for invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, which sets a baseline of 4. The description adds no parameter-related details (none exist), but it does clarify that the returned data is a breakdown by state, which gives meaningful context to the output.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource ('platform-level statistics') and the specific action ('Get'), and it states exactly what is returned (host and service counts by state). This distinguishes it from sibling tools that target individual hosts, services, or specific entities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for platform-level overviews versus per-host or per-service tools, but it does not explicitly state when to use this tool (e.g., 'use for high-level monitoring') or contrast it with alternatives. The context is clear but lacks explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits itself. 'Active and scheduled' provides useful scope by indicating that past/ended downtimes are excluded, and the tool is evidently read-only. However, it does not mention return format, pagination behavior, or any permissions needed, though these may be less critical for a list operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the verb and resource, containing no unnecessary filler. It is concise and easily scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, the schema's thorough parameter documentation, and the lack of an output schema, the description is mostly complete. It could be improved by mentioning that the result is a paginated list, but the pagination parameters in the schema imply this, so the description is adequate for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage, with descriptions for all four parameters, so the baseline is 3. The description does not add extra semantic meaning beyond the schema, such as how the 'is_active' filter relates to the 'active and scheduled' phrasing, but this is already clear from the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List'), the resource ('downtimes'), and the scope ('active and scheduled') within the Centreon platform. It distinguishes itself from sibling tools like add_downtime_host and add_downtime_service, which create downtimes, and list_acknowledgements, which lists a different resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for viewing downtimes, but it does not explicitly state when to prefer this over alternatives or provide exclusions. There is no mention of when to use list_downtimes versus list_events or list_acknowledgements, though the resource name makes the basic use case clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full burden of behavioral disclosure. 'List' implies a read-only operation, and the mention of filtering adds useful context. However, it does not disclose return format, pagination behavior, or any side effects. It is minimally adequate but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence with no redundancy. It is front-loaded with the core action and resource, followed by a concise list of filter options.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has five optional parameters and no output schema, so the description should ideally mention return behavior or pagination. The description covers purpose and filters but omits what the response looks like and how pagination works. With the schema covering parameters, this is a moderate gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and every parameter has a description. The tool description adds only a high-level summary of filters ('host, state, or service name') that maps to parameters already described in the schema. It does not add significant new meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('List') and resource ('monitored services in Centreon'), and distinguishes itself from sibling tools like get_service and list_service_groups by focusing on listing with filters. It is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool by stating its filtering capabilities (host, state, service name), giving clear context for typical listing tasks. However, it does not explicitly mention alternatives or exclusions, but the verb 'List' naturally separates it from single-service retrieval.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden. 'Get full details' indicates a read-only operation, but it doesn't specify what 'full details' includes, potential errors, or any special behavior. This is adequate but leaves gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, focused sentence that is front-loaded and free of unnecessary words. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one parameter, no output schema, no annotations). The description conveys the essential purpose and uses 'full details' to imply comprehensive return data, which is sufficient for a straight-forward get-by-ID tool, though it lacks specifics about return structure or error handling.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes host_id as 'Centreon host ID' (100% coverage). The description adds no extra meaning beyond confirming the parameter is the host ID, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and the resource ('full details for a specific host'), scoped to a single host by ID. This distinguishes it from list_hosts and other host-related tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool: when you need details for a single host and have its ID. It does not explicitly mention alternatives or exclusions, 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It states the tool lists host groups and includes member counts, which is useful. However, it does not explicitly describe safety (though it is implied to be read-only), authentication requirements, or pagination behavior beyond the parameter schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the essential information: it lists host groups and notes the inclusion of member counts. There is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given its simplicity and the comprehensive parameter schema, the description is largely complete. It clearly states the purpose and the key output detail (member counts). It does not explain return structure in detail, but that is not critical for a list operation without an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with each parameter (page, limit, search) having its own description. The tool description adds no additional parameter semantics, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'List' with the resource 'host groups' and adds context 'configured in Centreon with member counts.' This clearly distinguishes it from sibling tools like list_service_groups and list_hosts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly communicates that this tool is for retrieving host groups, providing sufficient context for when to use it. However, it does not explicitly mention alternatives or exclusion criteria compared to other list tools, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavioral traits. The verb 'List' implies a read-only operation, and the description mentions filtering and pagination, but it does not explicitly state that the operation is safe, non-mutating, or what fields are returned. It adds some context beyond the schema but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the core purpose ('List monitored hosts') and follows with concise, useful details about filtering and pagination. Every word earns its place; no unnecessary information or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a list tool with 4 parameters, full schema coverage, and no output schema, the description sufficiently conveys the primary use case and key capabilities. It could be enhanced by mentioning that results are host objects or by referencing pagination defaults, but overall it is complete enough for an agent to understand and use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers all parameters with descriptions, so the baseline is 3. The phrase 'Filter by name, state, or page through results' synthesizes the parameters (search, states, page/limit) into meaningful capabilities, adding value beyond the individual schema descriptions by clarifying their combined purpose.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action and resource: 'List monitored hosts in Centreon.' This distinguishes it from siblings like 'get_host' (singular host) and 'list_host_groups' (host groups), making the tool's specific purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by mentioning 'Filter by name, state, or page through results,' which hints at common scenarios but does not explicitly discuss when to use list_hosts versus alternatives like get_host or list_host_groups. No exclusions or prerequisites are stated, so guidance is implicit rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must itself convey behavioral traits. 'Get' implies a read-only operation, which is standard for a retrieval tool. However, it does not mention potential nuances like return format, pagination, or timezone handling. The guidance about get_service_metrics is more usage context than behavior. Overall, adequate but not rich in disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences. The first states the core action, and the second provides essential prerequisite guidance. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only tool with fully documented parameters, the description sufficiently covers the purpose and a prerequisite. It does not describe the output structure, but 'time-series performance data' gives a reasonable expectation. Given the absence of annotations and output schema, it is fairly complete, though it could be enhanced with a note about the time range parameters' defaults.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 all parameters. The description adds little beyond what's in the schema; it mentions 'specific metric' and points to get_service_metrics, but the schema already states that metric_name is 'as returned by get_service_metrics'. Therefore, no significant extra semantic value is provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('Get'), resource ('time-series performance data'), and scope ('for a specific metric of a service'). It also distinguishes itself from sibling tools by explicitly referencing get_service_metrics as the discovery step.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The second sentence gives explicit usage guidance: 'Use get_service_metrics first to discover available metric names.' This names the alternative tool and provides a clear sequential workflow, fully covering when/how to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It reveals the key behavior of returning only active acknowledgements and includes useful details about the return content (who/what/when). It does not mention pagination or rate limits, but this is a simple list operation and the 'active' filter is the main behavioral nuance.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. It communicates purpose and key details efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with optional params and no output schema, the description is adequate. It covers the essential purpose and result scope. Slight gap: it does not explicitly state that only active acknowledgements are returned and no history, but 'active' is embedded in the description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (page, limit, host_name all described). The tool description does not add extra parameter semantics beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List', the resource 'active acknowledgements', and the meaningful details 'who acknowledged what and when'. It fully distinguishes this from sibling tools like list_downtimes and list_events by specifying the unique subject matter.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies use when you need to view active acknowledgements in Centreon. It does not explicitly mention exclusions or alternatives, but the context is clear enough given the sibling names; it is more specific than just saying 'list acknowledgements'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It implies a read-only operation ('List') and mentions the data source ('platform topology'), but it does not disclose authentication requirements, return format details, or pagination behavior. For a straightforward list tool this is adequate but not fully transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states the action, target, and context without any redundancy or filler. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple no-parameter list tool, the description fully captures what the tool does and the information it provides. No output schema exists, so return-value documentation is not expected. It is complete for its complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema is empty, so the description cannot add parameter-level semantics. With 0 params, the baseline is 4, and the description correctly references no parameters without omission.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List' and clearly identifies the resource ('Centreon pollers and remote servers') and the key attribute ('connectivity status'), distinguishing it from sibling tools like get_platform_status or list_hosts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies when to use this tool (when poller/remote server connectivity info is needed) and 'from the platform topology' provides context. However, it does not explicitly name alternatives or state when not to use it, so it falls short of the highest tier.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It clearly implies a read-only operation via 'Get' and explains the discovery purpose, adding context that this is a prerequisite before data retrieval. However, it does not disclose potential side effects, permission requirements, or return format details, so it is slightly limited but adequate for a simple read tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences deliver the purpose and usage guidance without any fluff. Every word contributes meaningful information, making it efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having no output schema, the description adequately conveys the return value (a list of performance metrics) and its role in the workflow. The description is sufficiently complete for a simple discovery tool with well-documented parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully describes both parameters (host_id and service_id) with clear descriptions ('Centreon host ID' and 'Centreon service ID'), achieving 100% schema coverage. The description adds no additional parameter semantics, but the baseline of 3 is appropriate given the schema's completeness.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a list of performance metrics for a specific service, using the specific verb 'Get' and resource 'performance metrics.' It also distinguishes itself from sibling tools by positioning this as a discovery step before fetching time-series data, implying differentiation from get_metrics_data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs the user to 'Use this to discover metric names before fetching time-series data,' providing clear context on when to invoke this tool. It implicitly indicates not to use it for fetching actual data, which is a separate step, and the sibling list supports the alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![mcp-centreon MCP server](https://glama.ai/mcp/servers/fredriksknese/mcp-centreon/badges/card.svg)](https://glama.ai/mcp/servers/fredriksknese/mcp-centreon)

Score Badge

Copy to your README.md:

[![mcp-centreon MCP server](https://glama.ai/mcp/servers/fredriksknese/mcp-centreon/badges/score.svg)](https://glama.ai/mcp/servers/fredriksknese/mcp-centreon)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/fredriksknese/mcp-centreon'

If you have feedback or need assistance with the MCP directory API, please join our Discord server