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., "@CloudOps MCP show the operational snapshot for the payment-api service in production"
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.
CloudOps MCP is a read-only Model Context Protocol server that exposes normalized operational infrastructure context (logs, metrics, deployments, health) to AI agents through a small set of typed, bounded tools.
An agent investigating an incident needs operational context: what changed recently, what the error rate looks like, what the logs say. It does not need unrestricted access to cloud APIs, and it should not be the thing deciding what counts as a root cause.
CloudOps MCP sits between the two:
Cloud APIs / observability systems
|
Provider adapters
|
Normalized operational domain
|
Deterministic services
|
MCP tools
|
AI agentEach layer normalizes further and narrows what the agent can ask for. Provider adapters translate vendor APIs into a shared domain model. Services apply bounds, ordering, and aggregation deterministically, the same way for every provider. MCP tools expose that as a small, typed surface.
CloudOps MCP returns operational facts, not root-cause conclusions. A tool can say "error rate increased from 0.4% to 8% at 14:06"; it will not say "the deployment caused the outage." That judgment belongs to the agent, with the facts CloudOps MCP hands it as evidence.
Related MCP server: cloud-chat-assistant
Six tools, all read-only and bounded:
Tool | Purpose |
| List known services and which capabilities are configured for each. |
| Provider-reported health for a service. Never inferred from logs or metrics. |
| Recent deployment events, bounded by time range and count. |
| Log events, bounded by time range, count, and message length. |
| Metric series with deterministic aggregates (min/max/average/last); raw points are opt-in and bounded. |
| A composite view: recent deployments, configured snapshot metrics, recent logs, and health, in one bounded call. |
get_operational_snapshot composes the same primitive services the other five tools use,
running all four independent queries concurrently. It never talks to a provider directly, and
it never fails as a whole because one section is unavailable, each section reports its own
status.
Read-only by construction. Provider interfaces expose no mutation methods. There is no code path to a write API.
Provider-neutral service identity. A service is identified by (service, environment).
Vendor-specific identifiers (a CloudWatch log group, a Kubernetes object name) stay internal
to provider bindings and are never part of the public contract.
Canonical, extensible metrics. error_rate, latency_p99, and similar names are ours,
not the vendor's. The mapping from a canonical name to a real metric lives in configuration,
per service. The vocabulary is open, not a fixed enum.
Bounded queries. Every telemetry query has a time-range cap and a count cap. A caller can ask for less; it cannot ask for unbounded data.
Explicit data availability. Every collection reports one of SUCCESS, EMPTY,
PARTIAL, or FAILED. Missing data is never silently treated as "healthy" or "nothing
happened."
Availability separate from outcome. NOT_CONFIGURED (no provider wired up) and
EMPTY (queried successfully, zero matches) are different states and are never conflated.
Provenance without leaking internals. Individual results carry provider and source
when a provider adapter supplies them. The internal reference used to call a provider is
never copied into public output.
UTC everywhere. All timestamps are timezone-aware and normalized to UTC; naive datetimes are rejected at the model boundary.
No LLM inside the MCP server. No summarization, no classification, no inference over log content. Log messages are treated as opaque, untrusted text.
No causal reasoning. Tools report what changed and when. Interpreting why is left to the agent.
Fake mode is the default and the primary way to try CloudOps MCP. It needs no cloud account.
python -m venv .venv
source .venv/bin/activate
pip install -e ".[dev]"Run the server (stdio transport):
python -m cloudops_mcp.serverOr, if the package is installed with its console script:
cloudops-mcpThe server speaks MCP over stdio and expects a client on the other end. To try it directly from Python, using the official SDK's client:
import asyncio
from mcp import ClientSession, StdioServerParameters
from mcp.client.stdio import stdio_client
async def main():
params = StdioServerParameters(command="python", args=["-m", "cloudops_mcp.server"])
async with stdio_client(params) as (read, write):
async with ClientSession(read, write) as session:
await session.initialize()
tools = await session.list_tools()
print([t.name for t in tools.tools])
result = await session.call_tool(
"get_operational_snapshot",
{"service": "checkout-api", "environment": "production"},
)
print(result.structured_content)
asyncio.run(main())Select a scenario with CLOUDOPS_MCP_SCENARIO (default healthy):
Scenario | What it simulates |
| A service with every capability configured, nothing unusual. |
| A deployment, then an error-rate and latency shift, then timeout logs. |
| One capability failing mid-query, one not configured, the rest succeeding. |
CLOUDOPS_MCP_SCENARIO=bad_deploy python -m cloudops_mcp.serverbad_deploy seeds three correlated facts at fixed timestamps: a deployment, then a metric
shift a few minutes later, then timeout log lines shortly after that. CloudOps MCP reports
those three facts and nothing more. It does not claim the deployment caused the errors, that
inference is left entirely to the consuming agent.
pip install -e ".[aws]" # runtime only
pip install -e ".[dev,aws]" # developmentCLOUDOPS_MCP_MODE=aws CLOUDOPS_MCP_CONFIG=/path/to/cloudops.toml cloudops-mcpSee examples/aws-cloudwatch.toml for a complete example
config. It uses only placeholder values, no real account ID, ARN, or credential belongs in
that file.
Credentials come entirely from boto3's standard provider chain: AWS_PROFILE,
AWS_REGION / AWS_DEFAULT_REGION, environment credentials, or an IAM role. CloudOps MCP
never reads, stores, or logs an access key or secret.
Implemented in AWS mode:
Logs: CloudWatch Logs FilterLogEvents.
Metrics: CloudWatch GetMetricData (MetricStat queries only).
Not implemented yet: AWS-backed deployments and health. A service configured without those
sections simply reports NOT_CONFIGURED for them, the same as any other unconfigured
capability. See docs/aws.md for config schema, pagination behavior, and
limitations.
Minimum read-only policy for this integration (fictitious account and log group):
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "logs:FilterLogEvents",
"Resource": "arn:aws:logs:us-east-1:123456789012:log-group:/aws/lambda/checkout-api"
},
{
"Effect": "Allow",
"Action": "cloudwatch:GetMetricData",
"Resource": "*"
}
]
}FilterLogEvents can be scoped to the specific log group ARN. For the MetricStat queries
this integration issues, GetMetricData has no resource-level scoping in AWS's IAM
authorization model, so that statement uses Resource: "*". That is a property of the API,
not a choice made here.
Resource | Default | Hard cap |
Services listed | 50 | 200 |
Log events | 100 | 500 |
Log message length | - | 2000 chars |
Log/metric time range | 1 hour | 24 hours (logs), 7 days (metrics) |
Metric points per series | - | 500 |
Deployment events | 20 | 100 |
Snapshot metrics per service | - | 5 |
Every bounded result reports both requested_bounds and applied_bounds, so a caller can
see exactly what was clamped. Clamping a request to the hard cap is not the same thing as
PARTIAL: a clamped-but-fully-satisfied query is still SUCCESS. PARTIAL means the
extraction itself is known incomplete, for example a provider paginated and stopped before
exhausting all matches within the applied window.
Two orthogonal questions, never collapsed into one:
Is a capability configured for this service at all? (CONFIGURED / NOT_CONFIGURED)
If it was queried, what happened? (SUCCESS / EMPTY / PARTIAL / FAILED)
State | Meaning |
| No provider is wired up for this capability. No query was attempted. |
| The provider was queried, extraction was exhausted, and there were no matches. |
| The provider was queried and returned a complete result. |
| Extraction is known incomplete. Data may or may not be present, for example every page scanned so far was empty but more pages exist. |
| The provider was queried and the call itself failed (timeout, auth error, rate limit). |
A health check for a service with no health provider configured is NOT_CONFIGURED, not
EMPTY and not FAILED. A log query that legitimately found nothing in the time window is
EMPTY, not FAILED. A metrics call that hit a rate limit before returning anything usable
is FAILED with a reason, not silently empty data.
Every tool takes typed arguments and returns a typed Pydantic model. The official Python MCP
SDK derives structuredContent and the tool's output schema directly from that return type,
tool responses are real structured data, not a JSON string wrapped in a text block.
flowchart TD
subgraph Providers
Fake[Fake providers]
AWS[AWS CloudWatch providers]
end
Fake --> Services
AWS --> Services
Registry[ServiceRegistry] --> Services
subgraph Services[Deterministic services]
Catalog[catalog_service]
Health[health_service]
Deploy[deployment_service]
Logs[logs_service]
Metrics[metrics_service]
Snapshot[snapshot_service]
end
Snapshot --> Deploy
Snapshot --> Logs
Snapshot --> Metrics
Snapshot --> Health
Services --> Tools[MCP tools]
Tools --> Agent[AI agent]get_operational_snapshot composes the primitive services, it does not bypass them or talk
to providers on its own. See docs/architecture.md for the full
technical breakdown.
Deterministic fake scenarios exercise the full tool surface end to end.
Provider-layer tests use deliberately misbehaving stub providers (wrong ordering, ignored bounds) to prove the service layer defends the output itself, not just well-behaved providers.
AWS provider tests use small stub CloudWatch clients, no real AWS calls, no moto, no LocalStack.
One test drives the real MCP SDK client against an in-process server, confirming the protocol boundary itself (tool discovery, structured output) rather than only internal logic.
ruff check src tests
mypy src tests --strict
pytest -qAWS live validation has been done with typed config parsing, stubbed client tests, and the real MCP client/server boundary, not yet against a real AWS account. That requires user-selected resources and is intentionally not automated: CloudOps MCP does not discover or probe an account on its own.
No AWS-backed deployments or health provider yet.
stdio transport only, no remote MCP.
The service registry is static and configuration-backed, there is no automatic discovery of services from a cloud account.
No mutation, remediation, or write path of any kind.
Additional read-only capabilities on existing providers.
A second real provider, to pressure-test the normalization boundary against more than one vendor.
A remote transport, if a deployment scenario actually needs one.
Consumption by incident-response agents, as one example of a generic MCP client. CloudOps MCP is not coupled to any specific consumer.
No mutation methods anywhere in the provider interfaces.
No shell execution, no cloud CLI subprocess calls.
Least-privilege IAM: exactly logs:FilterLogEvents and cloudwatch:GetMetricData, nothing
requested "just in case."
Standard AWS credential chain only, no custom credential handling.
Internal provider references (log group names, CloudWatch dimensions) never appear in tool output.
Log content is treated as untrusted, opaque text: never parsed, executed, or interpreted.
Unexpected failures are sanitized at the tool boundary; only a fixed, generic message crosses it, never a raw exception string.
Every telemetry query is bounded, protecting both provider APIs and the agent's context window.
MIT, see LICENSE.
Get log events for a service, bounded by time range, count, and message length. Message content is opaque and never interpreted.
| Name | Required | Description | Default |
|---|---|---|---|
| service | Yes | ||
| max_events | No | ||
| time_range | No | ||
| environment | Yes |
| Name | Required | Description |
|---|---|---|
| capability | No | |
| collection | No | |
| availability | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It usefully discloses that message content is opaque and never interpreted and that results are bounded by count and message length (i.e., truncation behavior), but omits ordering, permissions, and, critically, what happens when time_range is null.
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 short sentences with the core operation front-loaded and zero filler; the opacity caveat follows the scope statement logically.
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?
An output schema exists, so return values need not be explained. However, the absence of annotations and of any guidance on the required service/environment values or on the null-defaulted time_range leaves meaningful gaps for an agent to resolve.
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 on the named properties is 0%, so the description must compensate. It loosely maps to time_range and max_events but gives no format or default semantics, and the two required parameters (service, environment) are undocumented in both schema and 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?
States a specific verb and resource ('Get log events for a service') and names the dimensions it is bounded by (time range, count, message length). The resource is clearly distinguishable from siblings like get_metrics and get_service_health, though it never explicitly routes the agent against them.
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?
No when-to-use guidance, no prerequisites, and no mention of alternatives such as get_metrics or get_operational_snapshot for higher-level views. The bounding clauses describe limits, not when this tool is the right choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get metric series for a service. metric_names must be canonical names from get_services' available_metrics for that service. Always includes deterministic aggregates (min/max/average/last); raw points only when include_points=True, bounded.
| Name | Required | Description | Default |
|---|---|---|---|
| service | Yes | ||
| max_points | No | ||
| time_range | No | ||
| environment | Yes | ||
| metric_names | Yes | ||
| include_points | No |
| Name | Required | Description |
|---|---|---|
| capability | No | |
| collection | No | |
| availability | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden and does disclose output-shaping behavior: deterministic aggregates (min/max/average/last) are always returned, raw points only when include_points=True, and results are bounded. It says nothing about auth requirements, defaults for time_range, or rate limits, so it is strong but not complete.
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?
Three short sentences, front-loaded with the core action and then the two key constraints; almost no filler. The trailing word 'bounded' is terse to the point of ambiguity about what bound applies.
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?
An output schema exists, so the description need not restate return fields, and it still usefully flags the conditional raw-points behavior. Given the 0% parameter coverage, it leaves time_range, service, and environment semantics undocumented, which is the main gap.
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 0% across 6 parameters, so the description must compensate and only partially does: it explains metric_names (canonical names from get_services) and include_points, and hints at max_points via 'bounded'. service, environment, and time_range semantics (inclusive start / exclusive end, default) are left entirely to the schema.
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 a specific verb and resource ('Get metric series for a service'), which naturally separates it from siblings like get_logs or get_service_health that operate on different resources. It is clear but never explicitly names a sibling or contrasting scope, so it stops short of a 5.
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?
It gives a concrete precondition: metric_names must be canonical names obtained from get_services' available_metrics, effectively telling the agent to call get_services first. It does not state when to prefer get_metrics over get_operational_snapshot or get_service_health, so no exclusions are covered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a bounded operational snapshot for a service: recent deployments, its configured snapshot metrics, recent logs, and health. Each section reports its own status independently; a failure or unconfigured capability in one section never hides the others. Reports facts only, never a root cause.
| Name | Required | Description | Default |
|---|---|---|---|
| service | Yes | ||
| time_range | No | ||
| environment | Yes |
| Name | Required | Description |
|---|---|---|
| logs | Yes | |
| health | Yes | |
| metrics | Yes | |
| service | Yes | |
| deployments | Yes | |
| environment | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden, and it does meaningful work: each section reports status independently, a failure or unconfigured capability in one section never hides others, and it reports facts only, never root cause. These are genuinely useful operational traits. It still omits what 'bounded' means concretely, permission/auth requirements, and volume limits for logs and metrics.
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?
Three sentences, front-loaded with the purpose followed by two high-value behavioral notes. No filler, and each sentence adds information about scope or behavior rather than restating the name.
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?
An output schema exists, so return-value explanation is not needed, and the description adequately covers purpose and partial-failure semantics. However, for an aggregation tool with three parameters and 0% schema coverage, the absence of parameter semantics and any guidance on choosing it over its four siblings leaves clear gaps.
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 0%, so the description must compensate, and it largely does not. 'for a service' gestures at the required service parameter, but environment, the optional time_range, and the default-null behavior are unexplained. The nested TimeRange carries its own schema description, but nothing in the tool description clarifies how parameters shape the snapshot.
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?
States a specific verb and resource (get an operational snapshot for a service) and enumerates the four content areas: deployments, metrics, logs, and health. This maps cleanly onto the four sibling tools, but the description never explicitly contrasts itself with those siblings (e.g., 'use this instead of calling get_logs/get_metrics separately'), so differentiation is implied rather than stated.
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 word 'bounded' hints at a scoped overview use case, but there is no explicit when-to-use, when-not-to-use, or mention of the sibling alternatives it aggregates. An agent cannot tell from the text whether to prefer this tool over get_recent_deployments + get_logs + get_metrics + get_service_health.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get recent deployment events for a service, bounded by time/count
| Name | Required | Description | Default |
|---|---|---|---|
| service | Yes | ||
| max_events | No | ||
| time_range | No | ||
| environment | Yes |
| Name | Required | Description |
|---|---|---|
| capability | No | |
| collection | No | |
| availability | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. 'Bounded by time/count' gestures at limiting behavior, but it never says what happens when time_range or max_events are omitted (both default to null), whether there is a server-side default window, or what the ordering/recency guarantee is. Read-only intent is only implied by the verb 'get'.
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?
A single front-loaded sentence with no filler; the scope qualifier follows the core action. It is efficient, though 'bounded by time/count' is compressed to the point of ambiguity.
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?
An output schema exists, so return-value documentation is not required, and the read-only nature of a 'get' tool is largely self-evident. Still, with zero annotations and two nullable tuning parameters, the description omits default-window behavior and the required environment parameter, leaving the agent to infer invocation semantics.
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 0%, so the description must compensate. It covers 'service' and loosely maps 'time/count' onto time_range and max_events, but the required 'environment' parameter is never mentioned and no defaults or format details are supplied (the UTC/inclusive-start semantics live only in the nested schema).
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?
States a clear verb (get) and resource (recent deployment events) plus scope (for a service, bounded by time/count), which distinguishes it from get_logs, get_metrics, and get_service_health. It does not name any sibling explicitly, so it stops short of a 5.
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 word 'recent' hints at a use case, but there is no statement of when to prefer this over get_logs, get_metrics, or get_operational_snapshot, and no exclusions or prerequisites. An agent must infer everything about tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Provider-reported health signal for a service, never inferred
| Name | Required | Description | Default |
|---|---|---|---|
| service | Yes | ||
| environment | Yes |
| Name | Required | Description |
|---|---|---|
| capability | No | |
| collection | No | |
| availability | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden, and it does disclose one meaningful trait: the signal is provider-reported and never inferred, which tells the agent this is authoritative provenance rather than a derived heuristic. It still omits freshness, auth requirements, failure/unknown states, and error semantics for a tool whose entire value is a status signal.
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?
A single clause, front-loaded with the resource and followed by the one qualifier that matters. Nothing is padded and nothing needs trimming.
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?
An output schema exists, so return values need not be described, and the tool is structurally simple with only two params. Still, with zero annotations and zero parameter coverage, the definition leaves the agent without usage context or argument semantics, so it is only minimally complete.
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?
Both parameters (service, environment) have 0% schema description coverage, and the description adds no meaning — it does not clarify identifier format, environment naming, or whether defaults exist. For a 2-param required tool at zero coverage, the description should compensate and does not.
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 names a specific resource (a service's health signal) and its provenance, so an agent can distinguish it from get_logs, get_metrics, or get_recent_deployments. However, there is no explicit verb and no named sibling to route against, so differentiation is implied rather than stated.
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?
There is no when-to-use guidance, no prerequisites, and no mention of alternatives such as get_operational_snapshot or get_metrics. The agent is left to infer that this is the health-check counterpart to the other read tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List known services and which capabilities are configured for each.
| Name | Required | Description | Default |
|---|---|---|---|
| environment | No | ||
| max_services | No |
| Name | Required | Description |
|---|---|---|
| services | No | |
| truncated | No | |
| applied_max | Yes | |
| requested_max | Yes | |
| returned_count | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It implies a read-only list but does not state authentication requirements, pagination behavior, rate limits, or error handling.
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?
A single front-loaded sentence with no filler or redundancy. It is appropriately concise for a list operation, though its brevity contributes to gaps in other dimensions.
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?
An output schema exists, so return values need not be explained. However, with zero annotations and 0% parameter description coverage, the description omits filtering behavior (environment) and result limiting (max_services), leaving the agent without enough context for correct invocation.
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 description does not mention the environment or max_services parameters at all. With 0% schema description coverage, it fails to compensate for the missing parameter documentation.
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?
States a specific verb ('List') and resource ('services') plus the returned data ('capabilities configured for each'). However, it does not differentiate from siblings such as get_operational_snapshot, so it misses the top score.
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?
No when-to-use guidance, prerequisites, or alternatives are named. Sibling tools like get_service_health or get_operational_snapshot are not referenced, leaving the agent to infer when this inventory tool is appropriate.
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.0get_logsget_metricsget_operational_snapshotget_recent_deploymentsget_service_healthget_servicesScored across 6 tools
Each tool targets a distinct observability resource or action: service inventory, deployments, health, logs, metrics, and a composite snapshot. The composite snapshot is explicitly scoped as a bounded aggregation, so it does not blur with the individual tools. No two tools appear to do the same thing.
All six tools use the same get_ verb prefix and snake_case convention, with clear noun phrases (get_services, get_recent_deployments, get_service_health, get_logs, get_metrics, get_operational_snapshot). The pattern is predictable and easy to scan.
Six tools is a well-scoped size for a read-only CloudOps observability server. Each tool covers a distinct monitoring concern without redundant or filler endpoints.
The surface covers core operational data: services, deployments, health, logs, metrics, and a combined snapshot. Minor gaps exist for adjacent operational context such as alerts/incidents or deployment detail views, but core diagnostic workflows are supported.
MCP server for AI agents to plan, verify, and deploy Cloudflare-native apps.
An MCP server that provides an API to LLMs to manage their JumpCloud resources.
The Cortex MCP server provides read-only access to real-time engineering context from the Cortex developer portal, allowing AI coding assistants to answer natural language questions about your organization's catalog (microservices, libraries, domains, teams, infrastructure), scorecards (engineering standards and best practices), initiatives (goals and deadlines), and Engineering Intelligence metrics. It includes tools for querying documentation, tracking personal entities, and accessing AI-assisted insights across the entire Cortex ecosystem.
MCP server for building and testing AI agents with multi-model experimentation and insights.
