CloudOps MCPは、Model Context Protocolサーバーであり、運用インフラストラクチャのコンテキスト（ログ、メトリクス、デプロイメント、ヘルス）を、少数の型付けされた制限付きツールを通じてAIエージェントに公開します。
インシデントを調査するエージェントには、運用コンテキストが必要です。最近何が変わったか、エラーレートはどうか、ログには何が書かれているか。クラウドAPIへの無制限のアクセスは必要なく、根本原因を判断するものでもありません。
CloudOps MCPは、この2つの間に位置します。
Cloud APIs / observability systems
|
Provider adapters
|
Normalized operational domain
|
Deterministic services
|
MCP tools
|
AI agent各レイヤーはさらに正規化し、エージェントが要求できる範囲を狭めます。プロバイダーアダプターは、ベンダーAPIを共有ドメインモデルに変換します。サービスは、すべてのプロバイダーに対して同じ方法で、決定論的に境界、順序付け、集約を適用します。MCPツールは、それを小さな型付けされたサーフェスとして公開します。
CloudOps MCPは、運用上の事実を返し、根本原因の結論は返しません。ツールは「エラーレートが14:06に0.4%から8%に上昇しました」と言うことができますが、「デプロイメントが障害を引き起こしました」とは言いません。その判断は、CloudOps MCPが証拠として提供する事実に基づいて、エージェントに委ねられます。
Related MCP server: cloud-chat-assistant
6つのツール、すべて読み取り専用で制限付きです。
ツール | 目的 |
| 既知のサービスと、各サービスに設定されている機能を一覧表示します。 |
| プロバイダーから報告されたサービスのヘルス。ログやメトリクスから推測されることはありません。 |
| 最近のデプロイメントイベント。時間範囲と件数で制限されます。 |
| ログイベント。時間範囲、件数、メッセージ長で制限されます。 |
| 決定論的な集約値（最小/最大/平均/最新）を持つメトリクス系列。生のポイントはオプトインで制限付きです。 |
| 複合ビュー：最近のデプロイメント、設定されたスナップショットメトリクス、最近のログ、ヘルスを、1回の制限付き呼び出しで取得します。 |
get_operational_snapshotは、他の5つのツールが使用するのと同じプリミティブサービスを構成し、4つの独立したクエリをすべて同時に実行します。プロバイダーと直接通信することはなく、1つのセクションが利用不可であっても全体として失敗することはありません。各セクションは自身のステータスを報告します。
設計上、読み取り専用。 プロバイダーインターフェースは変更メソッドを公開しません。書き込みAPIへのコードパスはありません。
プロバイダーに依存しないサービスID。 サービスは(service, environment)で識別されます。ベンダー固有の識別子（CloudWatchロググループ、Kubernetesオブジェクト名など）はプロバイダーバインディング内部に留まり、公開契約の一部になることはありません。
標準的で拡張可能なメトリクス。 error_rate、latency_p99などの名前は、ベンダーのものではなく、当社のものです。標準名から実際のメトリクスへのマッピングは、サービスごとの設定に存在します。語彙はオープンであり、固定された列挙型ではありません。
制限付きクエリ。 すべてのテレメトリクエリには、時間範囲の上限と件数の上限があります。呼び出し元はより少ないデータを要求することはできますが、無制限のデータを要求することはできません。
明示的なデータ可用性。 すべてのコレクションは、SUCCESS、EMPTY、PARTIAL、またはFAILEDのいずれかを報告します。欠落データが「正常」または「何も起こらなかった」として暗黙的に扱われることはありません。
可用性と結果を分離。 NOT_CONFIGURED（プロバイダーが配線されていない）とEMPTY（クエリは成功したが、一致するものがゼロ）は異なる状態であり、混同されることはありません。
内部を漏洩させない来歴。 個々の結果は、プロバイダーアダプターが提供する場合、providerとsourceを保持します。プロバイダーを呼び出すために使用される内部参照は、公開出力にコピーされることはありません。
すべてUTC。 すべてのタイムスタンプはタイムゾーン対応でUTCに正規化されます。ナイーブな日時はモデル境界で拒否されます。
MCPサーバー内にLLMなし。 ログコンテンツの要約、分類、推論は行われません。ログメッセージは、不透明で信頼できないテキストとして扱われます。
因果推論なし。 ツールは何がいつ変わったかを報告します。理由の解釈はエージェントに委ねられます。
フェイクモードはデフォルトであり、CloudOps MCPを試すための主要な方法です。クラウドアカウントは必要ありません。
python -m venv .venv
source .venv/bin/activate
pip install -e ".[dev]"サーバーを実行します（stdioトランスポート）：
python -m cloudops_mcp.serverまたは、パッケージがコンソールスクリプトとともにインストールされている場合：
cloudops-mcpサーバーはMCP over stdioで通信し、もう一方の端にクライアントを期待します。Pythonから直接、公式SDKのクライアントを使用して試すには：
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())CLOUDOPS_MCP_SCENARIOでシナリオを選択します（デフォルトはhealthy）：
シナリオ | シミュレートされる内容 |
| すべての機能が設定されたサービスで、異常はありません。 |
| デプロイメント、その後エラーレートとレイテンシのシフト、そしてタイムアウトログ。 |
| 1つの機能がクエリ中に失敗し、1つが設定されておらず、残りは成功します。 |
CLOUDOPS_MCP_SCENARIO=bad_deploy python -m cloudops_mcp.serverbad_deployは、固定タイムスタンプで3つの相関する事実をシードします。デプロイメント、その数分後のメトリクスシフト、そしてその直後のタイムアウトログラインです。CloudOps MCPはこれら3つの事実のみを報告します。デプロイメントがエラーを引き起こしたとは主張しません。その推論は、利用するエージェントに完全に委ねられます。
pip install -e ".[aws]" # runtime only
pip install -e ".[dev,aws]" # developmentCLOUDOPS_MCP_MODE=aws CLOUDOPS_MCP_CONFIG=/path/to/cloudops.toml cloudops-mcp完全な設定例については、examples/aws-cloudwatch.tomlを参照してください。プレースホルダーのみを使用しており、実際のアカウントID、ARN、または資格情報はそのファイルに含まれていません。
資格情報はすべて、boto3の標準プロバイダーチェーン（AWS_PROFILE、AWS_REGION / AWS_DEFAULT_REGION、環境資格情報、またはIAMロール）から取得されます。CloudOps MCPは、アクセスキーやシークレットを読み取り、保存、またはログに記録することはありません。
AWSモードで実装されているもの：
ログ: CloudWatch Logs FilterLogEvents。
メトリクス: CloudWatch GetMetricData（MetricStatクエリのみ）。
まだ実装されていません：AWSバックアップのデプロイメントとヘルス。これらのセクションなしで設定されたサービスは、他の設定されていない機能と同様に、単にNOT_CONFIGUREDを報告します。設定スキーマ、ページネーション動作、制限事項については、docs/aws.mdを参照してください。
この統合のための最小読み取り専用ポリシー（架空のアカウントとロググループ）：
{
"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は、特定のロググループARNにスコープできます。この統合が発行するMetricStatクエリの場合、GetMetricDataにはAWSのIAM認可モデルにリソースレベルのスコープがないため、そのステートメントはResource: "*"を使用します。これはAPIのプロパティであり、ここでの選択ではありません。
リソース | デフォルト | ハードキャップ |
一覧表示されるサービス | 50 | 200 |
ログイベント | 100 | 500 |
ログメッセージ長 | - | 2000 chars |
ログ/メトリクス時間範囲 | 1 hour | 24 hours (logs), 7 days (metrics) |
系列あたりのメトリクスポイント | - | 500 |
デプロイメントイベント | 20 | 100 |
サービスあたりのスナップショットメトリクス | - | 5 |
すべての制限付き結果は、requested_boundsとapplied_boundsの両方を報告するため、呼び出し元は正確に何が制限されたかを確認できます。リクエストをハードキャップに制限することは、PARTIALと同じではありません。制限されたが完全に満たされたクエリは、依然としてSUCCESSです。PARTIALは、抽出自体が不完全であることがわかっていることを意味します。たとえば、プロバイダーがページネーションを行い、適用されたウィンドウ内のすべての一致を使い果たす前に停止した場合などです。
2つの直交する質問が、決して1つにまとめられることはありません。
このサービスに対して機能が設定されていますか？（CONFIGURED / NOT_CONFIGURED）
クエリが実行された場合、何が起こりましたか？（SUCCESS / EMPTY / PARTIAL / FAILED）
状態 | 意味 |
| この機能に対してプロバイダーが配線されていません。クエリは試行されませんでした。 |
| プロバイダーがクエリされ、抽出が完了しましたが、一致するものはありませんでした。 |
| プロバイダーがクエリされ、完全な結果を返しました。 |
| 抽出が不完全であることがわかっています。データが存在する場合としない場合があります。たとえば、これまでにスキャンされたすべてのページは空でしたが、さらにページが存在します。 |
| プロバイダーがクエリされ、呼び出し自体が失敗しました（タイムアウト、認証エラー、レート制限）。 |
ヘルスプロバイダーが設定されていないサービスのヘルスチェックは、NOT_CONFIGUREDであり、EMPTYでもFAILEDでもありません。時間枠内で正当に何も見つからなかったログクエリは、EMPTYであり、FAILEDではありません。使用可能なものを返す前にレート制限に達したメトリクス呼び出しは、理由とともにFAILEDであり、黙って空のデータではありません。
すべてのツールは、型付けされた引数を受け取り、型付けされたPydanticモデルを返します。公式のPython MCP SDKは、その戻り値の型から直接structuredContentとツールの出力スキーマを導出します。ツールの応答は、テキストブロックにラップされたJSON文字列ではなく、実際の構造化データです。
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はプリミティブサービスを構成します。それらをバイパスしたり、プロバイダーと直接通信したりすることはありません。完全な技術的詳細については、docs/architecture.mdを参照してください。
決定論的なフェイクシナリオは、ツールの全サーフェスをエンドツーエンドでテストします。
プロバイダーレイヤーのテストでは、意図的に誤動作するスタブプロバイダー（誤った順序付け、無視された境界）を使用して、サービスレイヤーが適切に動作するプロバイダーだけでなく、出力自体を防御することを証明します。
AWSプロバイダーテストでは、小さなスタブCloudWatchクライアントを使用します。実際のAWS呼び出し、moto、LocalStackは使用しません。
1つのテストでは、実際のMCP SDKクライアントをインプロセスサーバーに対して駆動し、内部ロジックだけでなく、プロトコル境界自体（ツール発見、構造化出力）を確認します。
ruff check src tests
mypy src tests --strict
pytest -qAWSのライブ検証は、型付き設定解析、スタブ化されたクライアントテスト、および実際のMCPクライアント/サーバー境界で行われていますが、実際のAWSアカウントに対してはまだ行われていません。これにはユーザーが選択したリソースが必要であり、意図的に自動化されていません。CloudOps MCPは、アカウントを自動的に発見またはプローブしません。
AWSバックアップのデプロイメントまたはヘルスプロバイダーはまだありません。
stdioトランスポートのみで、リモートMCPはありません。
サービスレジストリは静的で設定に基づいており、クラウドアカウントからのサービスの自動発見はありません。
変更、修復、または書き込みパスは一切ありません。
既存のプロバイダーへの追加の読み取り専用機能。
2つ目の実際のプロバイダー。複数のベンダーに対して正規化境界をテストします。
リモートトランスポート。デプロイメントシナリオで実際に必要とされる場合。
インシデント対応エージェントによる消費。これは汎用MCPクライアントの一例です。CloudOps MCPは特定のコンシューマーに結合されていません。
プロバイダーインターフェースにミューテーションメソッドは一切ありません。
シェル実行やクラウドCLIのサブプロセス呼び出しはありません。
最小特権のIAM：logs:FilterLogEvents と cloudwatch:GetMetricData のみで、「念のため」のリクエストは一切ありません。
標準のAWS認証チェーンのみ使用し、カスタム認証処理はありません。
内部プロバイダー参照（ロググループ名、CloudWatchディメンション）はツール出力に一切表示されません。
ログコンテンツは信頼できない不透明なテキストとして扱われ、解析、実行、解釈されることはありません。
予期しない障害はツール境界でサニタイズされ、固定の汎用メッセージのみが境界を越え、生の例外文字列は決して渡されません。
すべてのテレメトリクエリは範囲制限されており、プロバイダーAPIとエージェントのコンテキストウィンドウの両方を保護します。
MIT、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.
MCP server for your apps' tools and custom tools, plus hosted AI agents and approval-gated workflows
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.
