A
licenseNot graded
qualityD
maintenanceA minimal, production-ready MCP server running on AWS Lambda with Streamable HTTP transport, enabling deployment of custom tools behind API Gateway.
1
MIT
AWS Resource MCP
AWS Resource MCP
Pythonで開発されたローカルMCPサーバーで、AWSアカウントの実際のリソースを読み取り専用で参照するためのものです。
状態
フェーズ9が実装されています。当サーバーは、統一インベントリ、控えめなアクティビティ分析、明示的な診断、経済分析、そして実際の操作ログから生成された最小権限のIAMポリシーを組み合わせています。
Related MCP server: aws-mcp-server
想定範囲
stdioによるローカルMCPトランスポート。主要リージョン:
eu-west-1。AWSクエリは読み取り専用かつ最小権限のみ。
利用可能なツール:
health_check()、listar_recursos_aws()、analizar_actividad_recursos()、diagnosticar_cobertura_aws()、analizar_riesgo_costes()、revisar_free_tier()、およびconsultar_costes_aws()。Cost Explorerは、正確な1リクエストに対する一時的な同意を受けるまでブロックされます。
AWSへのデプロイやCIはありません。
信頼性
フェーズ10では、ローカルでの統合テスト、契約テスト、セキュリティテスト、パフォーマンステスト、MCPプロトコルテストを追加しています。また、インベントリは各SDK呼び出しの前にAWS_MCP_MAX_REQUESTS_PER_TOOL（デフォルト250）を適用します。予算を使い切ると、結果を保持してpartial_request_budget_exhaustedを返します。
継続的インテグレーションは、各プルリクエストでフォーマット、lint、コンパイル、IAMの決定論的検証、ローカルテストを実行します。AWS認証情報を設定したり、AWS操作を実行したりすることはありません。
Codexでの使用
Codexが主要なクライアントです。パッケージのエントリポイントuv run aws-resource-mcpをstdio経由で使用し、AWSプロファイルはリポジトリ外で設定し、「eu-west-1にどんなリソースがありますか？」などの自然言語の質問から始めてください。応答がpartial_pending_consentの場合、Codexは正確な操作を説明し、明示的な承認を待つ必要があります。永続的な同意は作成しません。Codex統合とデモを参照してください。
v0.1.0リリース
最初のバージョンはレビュー準備が整っています。読み取り専用ガード、一時的な同意、Codex統合、CIが含まれています。リリースチェックリストを参照してローカルで検証し、安全なデモを実行してください。
開発
プロジェクトはuvとPython 3.12以降で管理されています。
依存関係のインストール
uv syncサーバーの実行
uv run aws-resource-mcp診断のため、モジュールとして実行することもできます:
uv run python -m aws_resource_mcp.serverサーバーはstdioを使用します。MCPクライアントが標準入力と標準出力でメッセージを交換することを想定しています。SDKに含まれるツールを使用してMCP Inspectorで開くことができます:
uv run mcp dev src/aws_resource_mcp/server.pyテストの実行
uv run pytestIAMポリシーの生成と検証
uv run aws-resource-mcp-generate-iam
uv run aws-resource-mcp-generate-iam --check生成はローカルで決定論的に行われ、認証情報は使用しません。プロジェクトはAWSでロールやポリシーを作成・変更しません。ポリシーは、無料の操作、同意が必要な読み取り、および最大の組み合わせを分離します。IAM権限は、アプリケーションの同意に代わるものではありません。
AWSインベントリの実行
実際の診断の前に、ローカル設定がどのIDを解決するかを確認します:
aws sts get-caller-identityその後、デフォルトリージョンeu-west-1でインベントリを実行します:
uv run python -m aws_resource_mcp.aws.inventoryリージョンと共有プロファイルはオプションです:
uv run python -m aws_resource_mcp.aws.inventory --region eu-central-1 --profile exampleプロジェクトには鍵は保存されません。Boto3は標準の認証情報解決チェーンを使用します。AWS_PROFILEまたは--profileを指定した場合、リポジトリ外に既に存在するプロファイルのみが選択されます。
MCPツール
health_check
health_check(check_aws=True)は、ローカルの健全性とAWSの到達可能性を分離します。引数なしの場合、保護されたSTS呼び出しを最大1回実行します。check_aws=falseの場合、ネットワークは使用しません。バージョン、トランスポート、登録済みツールとアダプター、リージョン、経済ポリシー、および請求対象となる操作ゼロを返します。状態は次のとおりです:
ok: サーバーと設定が有効。STSは要求された場合に応答しました。degraded: サーバーは動作していますが、認証情報が不足しているか、STSにアクセスできません。error: セキュア設定または内部レジストリを初期化できません。
IDは匿名化されます。プリンシパルの一般的なタイプと、存在する場合はマスクされたアカウントのみが保持されます。インベントリ、Resource Explorer、アダプター、CloudTrail、CloudWatchは実行しません。
listar_recursos_aws
リソースを変更せずに、ローカル認証情報で利用可能なAWSインベントリを照会します。パラメータ:
region: 検索を1つのリージョンに制限します。値がない場合は、利用可能なすべてのカバレッジを使用します。services:lambda、s3、ec2、rdsなどのサービスでフィルタリングします。include_account_id: 応答からアカウントIDを省略して匿名化を容易にします。resource_types:ec2:instanceなどの動的タイプでフィルタリングします。query: テキストまたは名前で検索します。all_regions:regionが指定されていない場合、有効なリージョンを使用します。include_details:details内にサービス固有のメタデータを含めます。include_cost_indicators: 実際の支出を主張せずに、潜在的なコストシグナルを含めます。confirm_potentially_billable_operations: 権限を付与しなくなったレガシーパラメータ。include_activity_summary: 既に取得済みのフィールドのみを使用して短い要約を追加します。CloudTrailやCloudWatchは照会しません。consent_request_id、consent_action、approved_services: 一時的で限定されたリクエストを再開またはキャンセルします。timeout_seconds: 1〜120秒の設定可能な予算。
MCPクライアントから送信される引数の例:
{
"region": "eu-west-1",
"services": ["lambda", "s3"],
"include_account_id": false,
"all_regions": true
}最初の呼び出しは、許可された操作で取得されたリソースを返します。S3、SQS、またはSNSを完了するために課金対象の操作が必要な場合は、partial_pending_consent、pending_operations、および5分で期限切れになるリクエストを返します。2回目の明示的な呼び出しまで、それらの操作は実行されません:
{
"consent_request_id": "<id devuelto por la primera llamada>",
"consent_action": "approve",
"approved_services": ["s3"]
}承認は1回限りで、元のIDとスコープに紐付けられ、操作、リージョン、リクエストを制限します。検出と拡張は個別に承認されます。追加のページには新しいリクエストが必要です。consent_action: "cancel"はAWSインベントリを実行しません。
状態は、complete_for_requested_scope、partial_pending_consent、partial_timeout、partial_permission_denied、partial_unavailable、consent_cancelled、errorを区別します。空のリストは、照会された時点でサービスが空だったことのみを意味します。
resources、all_resources、resources_by_serviceは、同じ重複排除されたインベントリを表します。各リソースには、id、arn、name、service、resource_type、region、account_id、state、created_at、sources、details、cost_indicators、activityが含まれます。このツールはコストを計算せず、Free Tierを照会せず、書き込み操作を実行しません。
analizar_actividad_recursos
すべてのリソースに対して同じレジストリとモデルを使用して、既知の最後のアクティビティを分析します。services、regions、resource_idsによるフィルターに加えて、inactive_days、lookback_days、include_administrative_events、および設定可能な制限を受け入れます。CloudTrail履歴は90日に制限され、リソースごとではなくリージョンごとに照会されます。
応答は、last_functional_usage_at、last_administrative_activity_at、last_configuration_change_at、last_state_change_atを区別します。best_known_activity_atは常にシグナルのタイプも示します。アクティブな状態、Describe*クエリ、または変更日は、機能的な使用として提示されません。
リソースごとの状態は、active、inactive_candidate、unknown、not_supported、またはerrorです。非アクティブ候補は、レビュー用の単なる項目です。十分な経過時間、関連するソースの参照、矛盾する最近の証拠がないことが必要です。権限がない、ソースが不十分、または関係が曖昧な場合、偽の非アクティブ確信ではなくunknownになります。
CloudWatchは機能的なメトリクスを提供する可能性がありますが、GetMetricData、GetMetricStatistics、ListMetricsは潜在的に課金対象として登録され、ブロックされています。include_paid_sources=trueは構造化された説明を要求するだけです。同意を意味するものではなく、このフェーズではそれらの操作を決して実行しません。
diagnosticar_cobertura_aws
リソースを列挙せずに、MCPが実際に何を参照できるかを説明します。servicesとregionsのフィルターを受け入れ、権限、アクティビティ、または経済ポリシーのセクションを省略できます。
STS、有効なリージョン、既存のResource Explorerインデックス、アダプターのレジストリと機能、無料のアクティビティソース、ブロックされた操作をチェックします。チェックは実行ごとに5リージョン、CloudTrailのサンプルに制限され、CloudWatch呼び出しはありません。
カバレッジ状態は、available、partial、unavailable、not_configured、permission_denied、blocked_by_cost_policy、not_supported、not_checked、errorを区別します。ポリシーで許可されていると宣言された操作は、証明されたIAM権限としては提示されません。診断では、それをテストするためにサービスインベントリを実行しません。
例:
{
"services": ["ec2", "rds"],
"regions": ["eu-west-1"],
"include_activity_sources": true
}制限は、影響、MCPが続行できるかどうか、権限が不足しているかどうか、解決に書き込みが必要かどうか、コストが発生する可能性があるかどうかを示します。診断は、提案されたアクションを決して実行しません。
analizar_riesgo_costes
インベントリのインジケーターと、オプションで共通のアクティビティパイプラインを使用してリソースに優先順位を付けます。none_detected、low、medium、high、critical、またはunknown、説明可能なスコア、実行不可能な推奨事項を返します。シグナルは支出を確認せず、none_detectedはコストがゼロであることを意味しません。
include_free_tier=trueは、公式のFree Tierデータを追加します。include_actual_cost=trueは、Cost Explorerの同意を準備するだけです。クエリは実行しません。
revisar_free_tier
AWSが無料と文書化しているGetFreeTierUsageとGetAccountPlanStateを照会します。月次制限、予測、プラン、クレジットを分離します。権限、更新遅延、オファーの枯渇、または適格性の違いにより、部分的な情報または不明な情報を返す場合があります。特定のリソースが無料であるとは主張しません。
consultar_costes_aws
期間と正確なフィルターに対して、集計されたGetCostAndUsageクエリを準備します。最初の呼び出しはAWS操作をゼロ回実行し、メインビューに対するリクエストあたり0.01 USDの公開価格を含む一時的なリクエストを返します。consent_action="approve"を使用した2回目の呼び出しは、最大1ページを実行します。追加のページごとに新しい同意が必要です。cancelはAWSを呼び出しません。
粒度はMONTHLYまたはDAILYにできます。end_dateは排他的です。予測、リソースごとの詳細、リンクされたアカウント、カスタムビリングビューは、このフェーズでは実装されません。
AWSインベントリ
Boto3はAWSの公式Python SDKです。インベントリ層は以下を使用します:
STS
GetCallerIdentityを使用して、アカウントと実効IDを特定します。EC2
DescribeRegionsを使用して、有効なリージョンのみを検出します。Resource Explorerを使用して、既存のインデックスとビューを介して、サポートされているリソースとタイプを動的に検出します。
Lambda、S3、EC2/EBS/VPC、RDS/Aurora、DynamoDB、ECS/Fargate、API Gateway、CloudFormation、SQS、SNS、IAM、CloudFront、Route 53用の共通アダプターレジストリ。
CloudTrail
LookupEventsを使用して、過去90日間のリージョナルな無料の管理イベント履歴を取得します。
LambdaとS3は最初に実装されたサービスですが、特別なアーキテクチャパスはもう保持していません。すべてのアダプターは、同じコントラクトを使用してメタデータ、Boto3操作、スコープ、タイプ、詳細、インジケーターを宣言します。特定の詳細はdetails内にのみ存在します。
結果はARN、またはARNがない場合はタイプ、リージョン、識別子/名前で重複排除されます。アグリゲーターインデックスが優先されます。ローカルインデックスの場合、結果が結合され、カバレッジは部分的になります。Resource Explorerが利用できない場合、検出をサポートする選択されたすべてのアダプターが実行されます。
認証情報がない、またはアカウントを特定できない場合は、インベントリではグローバルエラーですが、ローカルヘルスではdegraded状態にすぎません。診断はローカルチェックを保持し、AWSに依存するチェックを安全にスキップします。
すべてのBoto3呼び出しは、まず中央ログを通過します。未登録の操作、書き込み操作、またはコスト不明の操作はブロックされます。free-onlyモードはプロセス全体を通じてアクティブのままです。S3、SQS、SNSはリクエストを計上できます。それらの列挙は保留中として表示され、正確な一時的なgrantのみが実行を許可します。ガードは一意の操作と実際のリクエストを別々にカウントします。
MCPクライアントの例: 「アカウントにどのようなリソースがありますか?」、「eu-west-1のEC2インスタンスを一覧表示」、「webという名前のリソースを検索」、「デプロイされたRDSタイプを表示」。Resource Explorerは広範なカバレッジを提供しますが、普遍的なものではありません。
ドキュメント
Available Tools
7 toolsanalizar_actividad_recursosA
Analyze last known AWS resource activity with conservative semantics.
Free service API fields and CloudTrail Event History management events are
combined through the common adapter pipeline. Functional usage,
administrative activity, configuration changes, and state signals remain
separate. Event History is regional, limited to 90 days, and does not
normally include data events such as S3 GetObject, so unknown results are
expected. CloudWatch could improve functional-usage coverage but is always
blocked in this phase: setting ``include_paid_sources`` only requests a
structured explanation and never grants consent or executes a metric call.
The operation is read-only, bounded, and may return partial results.
| Name | Required | Description | Default |
|---|---|---|---|
| regions | No | ||
| services | No | ||
| max_regions | No | ||
| resource_ids | No | ||
| inactive_days | No | ||
| lookback_days | No | ||
| max_resources | No | ||
| timeout_seconds | No | ||
| include_paid_sources | No | ||
| max_events_per_resource | No | ||
| include_administrative_events | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
A3.6/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears full responsibility for transparency. It does an excellent job: it details the data sources (free API, CloudTrail Event History), the regional and temporal scope (90-day limit), expected unknowns (data events excluded), the non-execution of paid sources, and the bounded, read-only nature. This sets correct expectations for the agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is 6 sentences long and front-loads the purpose. However, it includes technical jargon (e.g., 'common adapter pipeline') that could be simplified. While not excessively long, it is not as concise as it could be; some sentences could be merged or removed without losing essential information.
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 complexity (11 parameters, output schema exists), the description covers the core behavior, data sources, and limitations well. It mentions partial results and the non-execution of paid sources. Since an output schema exists, the description does not need to detail return values. However, it could briefly mention what the output contains (e.g., last activity timestamps per resource) to aid understanding, but this is not a major gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 11 parameters with 0% description coverage, meaning the schema provides no textual help. The description only explicitly mentions one parameter (include_paid_sources) and explains its behavior. The other 10 parameters (regions, services, max_regions, resource_ids, inactive_days, lookback_days, max_resources, timeout_seconds, max_events_per_resource, include_administrative_events) are not described. This leaves the agent without guidance on their semantics, which is inadequate.
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 tool's purpose: 'Analyze last known AWS resource activity with conservative semantics.' It identifies the resource (AWS resources) and action (analyze activity). However, it does not differentiate from sibling tools like listar_recursos_aws or diagnosticar_cobertura_aws, so it loses the highest score.
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 when to use the tool (for analyzing resource activity with free data sources) and provides context about limitations (regional, 90-day, no data events). It explains that include_paid_sources does not grant consent, giving guidance on that parameter. However, it does not explicitly state when NOT to use this tool or suggest alternatives, so the guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
analizar_riesgo_costesA
Prioritize potential AWS cost risk without treating it as actual spend.
The analysis uses the common inventory model and its cost indicators.
Optional activity is merged through the existing uniform activity tool.
Free Tier data uses the officially free API. ``include_actual_cost=True``
only prepares a separate Cost Explorer consent request; it does not grant
consent or execute a potentially billable operation. Recommendations are
informational and no AWS resource is changed.
| Name | Required | Description | Default |
|---|---|---|---|
| regions | No | ||
| services | No | ||
| period_days | No | ||
| resource_ids | No | ||
| max_resources | No | ||
| include_activity | No | ||
| include_free_tier | No | ||
| include_actual_cost | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
A3.8/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully explains critical behaviors: it does not change AWS resources, does not grant consent or execute billable operations, uses free API for free tier, and merges activity through existing tools. This provides sufficient transparency.
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 concise at 5 sentences, with the purpose front-loaded. Each sentence adds distinct value: purpose, model used, activity merging, free tier and include_actual_cost clarification, and non-destructive nature. No unnecessary repetition.
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 8 parameters and 0% schema coverage, the description should compensate by explaining key parameters and output. Only include_actual_cost is addressed. The output schema exists but is not described. The complexity is medium-high, but the description provides insufficient detail for effective tool use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description only explains the include_actual_cost parameter. The other 7 parameters (regions, services, period_days, etc.) receive no explanation, leaving the agent to infer from names and types. This is insufficient given the low coverage.
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 first sentence clearly states the tool's purpose: 'Prioritize potential AWS cost risk without treating it as actual spend.' It uses a specific verb (prioritize) and resource (cost risk), and distinguishes from sibling tools like consultar_costes_aws which deal with actual spend.
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 implicitly differentiates from siblings by emphasizing risk assessment rather than actual spend. It mentions when include_actual_cost=True is appropriate, but does not explicitly state when to use this tool versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
consultar_costes_awsA
Prepare or execute one exact, potentially billable Cost Explorer query.
The first call performs no AWS operation. It returns an expiring,
single-use request that states the exact period, filters, operation,
maximum request count, and estimated API charge. Calling again with the
request id and ``consent_action="approve"`` executes at most one
GetCostAndUsage page. A continuation page always needs a new consent.
``cancel`` performs no AWS call. Approval never authorizes another
operation, period, filter, identity, forecast, or resource-level query.
| Name | Required | Description | Default |
|---|---|---|---|
| regions | No | ||
| end_date | No | ||
| services | No | ||
| max_pages | No | ||
| start_date | No | ||
| granularity | No | MONTHLY | |
| resource_ids | No | ||
| consent_action | No | ||
| group_by_service | No | ||
| include_forecast | No | ||
| consent_request_id | No | ||
| include_resource_level | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
A3.8/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses that the first call is free, execution is billable, approval is single-use, continuation pages need new consent, and it never authorizes other operations. No contradictions.
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?
Description is efficient, explaining the two-step consent flow in three sentences. Could be more structured (e.g., bullet points) but remains clear and concise.
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?
Adequately explains the consent workflow, but leaves parameter details completely unaddressed. With 0% schema coverage and 12 parameters, more parameter context is needed for completeness. Output schema exists but does not help with parameter usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and description does not explain any of the 12 parameters (e.g., 'regions', 'start_date', 'consent_action'). It only references abstract concepts like 'period' and 'filters'. Falls short of compensating for missing schema descriptions.
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 tool prepares or executes a single Cost Explorer query, distinguishing between a preview call and an execution call. However, it does not differentiate from sibling tools like 'diagnosticar_cobertura_aws' or 'listar_recursos_aws'.
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?
Provides explicit workflow guidance: first call for preview, second call with 'consent_action=approve' to execute, and 'cancel' does nothing. Does not mention when to prefer this over alternatives or any prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
diagnosticar_cobertura_awsA
Explain which AWS coverage is reachable and why it may be partial.
This read-only diagnostic checks STS, enabled Regions, existing Resource Explorer indexes, the shared adapter registry, free activity sources, and the central cost policy. It does not inventory resources, create indexes, change IAM, enable Regions, or run CloudWatch. Adapter permissions are reported conservatively because service inventory calls are not executed. Results may be partial and never prove that an unqueried service is empty.
| Name | Required | Description | Default |
|---|---|---|---|
| regions | No | ||
| services | No | ||
| include_cost_policy | No | ||
| include_permissions | No | ||
| include_activity_sources | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
A4.3/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully carries the burden of behavioral disclosure. It explicitly states the tool is read-only, lists what it checks, and highlights limitations: adapter permissions reported conservatively, results may be partial, and never prove emptiness. This is comprehensive and transparent, leaving no hidden behaviors.
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 concise and well-structured: a one-sentence purpose follows by a bullet-like list of checks and non-actions, then caveats. Every sentence adds value without fluff. It is front-loaded with the primary purpose. Ideal for quick comprehension.
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 complexity (5 parameters, output schema exists), the description covers the diagnostic scope, limitations, and non-actions well. The output schema explains return values, so that gap is acceptable. However, it omits how parameters influence behavior, which is a notable hole for tool invocation. Overall, mostly complete but missing parameter-behavior links.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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 for parameter meanings. However, it does not describe any of the 5 parameters (regions, services, include_cost_policy, include_permissions, include_activity_sources). The general diagnostic scope indirectly relates, but no specific parameter guidance is given. This is a significant gap, resulting in a low score.
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's purpose: 'Explain which AWS coverage is reachable and why it may be partial.' It uses specific verbs (explain, checks) and lists concrete resources and checks (STS, enabled Regions, Resource Explorer indexes). This distinguishes it from siblings like listar_recursos_aws (resource listing) or analizar_riesgo_costes (cost risk analysis), providing a unique and precise purpose.
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 provides clear context on when to use the tool by stating it is a read-only diagnostic and listing what it does not do (inventory resources, create indexes, change IAM, etc.). It also includes caveats about partial results. However, it does not explicitly compare to siblings or provide when-not-to-use guidance, so it misses the highest tier.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
health_checkA
Check local server health and optionally perform one guarded STS call.
The AWS check never runs inventory, adapters, Resource Explorer, CloudTrail, CloudWatch, or any regional scan. Missing credentials degrade AWS access but do not mean the local MCP server is down.
| Name | Required | Description | Default |
|---|---|---|---|
| check_aws | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
A4/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without any annotations, the description carries full burden. It explains that missing credentials degrade AWS access but do not indicate server down, and clarifies the limited scope of the AWS check. The term 'guarded STS call' is somewhat vague but still informative.
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 short paragraphs with no wasted words. The purpose is stated in the first sentence, and additional constraints form a second paragraph. Every sentence adds value.
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 tool with one parameter and an existing output schema, the description covers the main point. It could explain what 'local server health' entails or what the output looks like, but the output schema likely provides that.
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 shows one optional boolean 'check_aws' with 0% description coverage. The description mentions 'optionally perform one guarded STS call' but does not explicitly link this to the parameter. It adds some meaning but could be more direct.
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 starts with 'Check local server health and optionally perform one guarded STS call', which provides a specific verb and resource. It clearly distinguishes from sibling tools like 'diagnosticar_cobertura_aws' by focusing on health rather than AWS-specific diagnostics.
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 lists what the AWS check does NOT do (e.g., no inventory, adapters, regional scans), giving implicit context for when not to use it. However, it does not explicitly name alternative tools for those cases, leaving the agent to infer usage boundaries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
listar_recursos_awsA
Discover AWS resources through locally available credentials, read-only.
Runs free read-only discovery first. Operations that AWS can meter as
requests are returned as pending and are not executed. To continue, call
this same tool with the short-lived ``consent_request_id``,
``consent_action="approve"``, and an explicit subset in
``approved_services``. Approval is single-use, identity- and scope-bound,
request-limited, and does not authorize enrichment or extra pagination.
``consent_action="cancel"`` performs no AWS inventory call. The legacy
``confirm_potentially_billable_operations`` flag is retained for signature
compatibility but grants no permission.
Every service uses the same adapter pipeline and normalized resource model.
Coverage can be partial because of pending consent, timeout, permissions,
unavailable APIs, or Resource Explorer configuration. An empty result is
therefore distinct from a service that was not queried. This tool never
writes resources, lists S3 objects, reads queue messages, publishes topics,
calculates actual costs, or guarantees that a metered request is free.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | ||
| region | No | ||
| services | No | ||
| all_regions | No | ||
| consent_action | No | ||
| resource_types | No | ||
| include_details | No | ||
| timeout_seconds | No | ||
| approved_services | No | ||
| consent_request_id | No | ||
| include_account_id | No | ||
| include_cost_indicators | No | ||
| include_activity_summary | No | ||
| confirm_potentially_billable_operations | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
A4.3/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses behavioral traits: read-only nature, consent action details, conditions for partial coverage, and explicit list of operations it never performs. This level of detail is exceptional for transparency.
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 front-loaded with the main purpose and structured into logical paragraphs. While every sentence contributes information, it is somewhat verbose and could be more concise. Overall, it is clear and well-organized.
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 complexity (14 parameters, consent workflow, output schema), the description covers essential aspects: how to initiate discovery, how to handle pending operations, and what limitations exist. It does not detail the output schema (provided separately) but sets realistic expectations about coverage and 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 0%, so the description must compensate. It adds value for consent-related parameters (consent_action, approved_services, consent_request_id) by explaining their role in the workflow. However, many parameters (e.g., include_cost_indicators, include_activity_summary) are not described, leaving the agent to rely on property names alone.
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's purpose: 'Discover AWS resources through locally available credentials, read-only.' It uses specific verbs and resource, and further distinguishes by detailing what it does not do (e.g., never writes resources, lists S3 objects). This provides clear differentiation from potential sibling 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 explains the two-step consent workflow for billable operations, guiding when to call the tool again. While it doesn't explicitly compare to sibling tools, the context it provides (read-only discovery, consent mechanism) helps the agent determine appropriate usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
revisar_free_tierA
Review account-plan and Free Tier usage without querying billed costs.
AWS officially documents programmatic Free Tier usage and account-plan monitoring at no cost. This read-only tool uses only GetFreeTierUsage and GetAccountPlanState. It does not call Cost Explorer, prove that a resource is free, or guarantee future eligibility. Usage can be estimated, delayed, absent after a limit is exhausted, or unavailable because of IAM.
| Name | Required | Description | Default |
|---|---|---|---|
| services | No | ||
| max_pages | No | ||
| include_forecast | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
A3.9/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses limitations: does not call Cost Explorer, usage can be estimated/delayed/absent, and IAM restrictions. This provides good behavioral context.
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 focused with a clear opening sentence and brief additional details. It could be slightly more concise but is not verbose.
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 description covers purpose and limitations but omits parameter details. An output schema exists, so return values are not needed, but the lack of parameter explanation is a gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description does not explain any of the three parameters (services, max_pages, include_forecast). The agent only has parameter names and types, lacking meaning beyond that.
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 reviews account-plan and Free Tier usage without querying billed costs, using specific AWS APIs. It distinguishes itself from sibling tools like consultar_costes_aws by explicitly avoiding Cost Explorer.
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 (free tier monitoring, not billed costs) and what it does not do (prove free, guarantee eligibility). It lacks explicit alternatives but context with sibling tools makes it clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
7 tool updates
v0.1.0- First observed
analizar_actividad_recursos - First observed
analizar_riesgo_costes - First observed
consultar_costes_aws - First observed
diagnosticar_cobertura_aws - First observed
health_check - First observed
listar_recursos_aws - First observed
revisar_free_tier
TDQS
A4/5.0
Scored across 7 tools
Disambiguation5/5
Each tool has a clearly distinct purpose: health check, coverage diagnosis, resource listing, activity analysis, cost risk, free tier, and cost queries. No two tools overlap in functionality.
Naming Consistency4/5
All names use snake_case and are descriptive, but there is an inconsistency in language: one tool is in English (health_check) while the rest are in Spanish. This is a minor deviation from a consistent pattern.
Tool Count5/5
Seven tools is a well-scoped set for a server focused on AWS resource discovery and cost analysis. Each tool covers a distinct aspect without being too few or too many.
Completeness4/5
The tool surface covers the main areas of health, coverage, resource discovery, activity, and cost (including free tier and actual cost). Minor gaps like direct resource detail queries are addressed by the generic listing tool, so overall completeness is high.
Related MCP Connectors
An MCP server that provides read access to your cloud storage providers, bank accounts and more.
Hosted MCP server for AWS cloud spend: service breakdowns, anomalies, savings and forecasts.
Hosted Amazon Seller and Vendor MCP server for Claude, ChatGPT, Cursor, Codex, Gemini, Copilot.
An MCP server that let you interact with Cycloid.io Internal Development Portal and Platform
Related MCP Servers
- AlicenseNot gradedqualityDmaintenanceAn MCP server that provides tools for creating and managing AWS resources using boto3, including EC2, S3, VPC, subnets, security groups, and RDS.MIT
- FlicenseNot gradedqualityDmaintenanceA stateless Python MCP server packaged as a custom AWS Lambda container image, exposing basic tools like hello, add, and current_time through an API Gateway HTTP API.-
- AlicenseNot gradedqualityDmaintenanceThis MCP server provides tools for inspecting AWS cloud infrastructure, including listing S3 buckets, EC2 instances, and fetching CloudWatch logs using your local AWS credentials.6 npmMIT