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
本地 MCP 服务器，使用 Python 开发，用于以只读模式查询 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 在收到针对确切请求的临时同意之前保持锁定。
不在 AWS 上部署，也不进行持续交付。
可靠性
第 10 阶段加入了本地集成、契约、安全、性能和 MCP 协议测试。清单在每次 SDK 调用前还会应用 AWS_MCP_MAX_REQUESTS_PER_TOOL（默认 250）；当预算耗尽时，会保留结果并返回 partial_request_budget_exhausted。
持续集成在每个 pull request 中执行格式化、lint、编译、确定性 IAM 验证和本地测试。它不配置 AWS 凭据，也不执行 AWS 操作。
与 Codex 配合使用
Codex 是主要客户端。通过 stdio 使用包入口点 uv run aws-resource-mcp，在仓库外部配置任何 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 pytest生成并验证 IAM 策略
uv run aws-resource-mcp-generate-iam
uv run aws-resource-mcp-generate-iam --check生成过程是本地、确定性的，不使用凭据。项目不会在 AWS 中创建或修改角色或策略。策略区分免费操作、需要同意的读取操作以及组合最大值；IAM 权限永远不会取代应用程序的同意。
运行 AWS 清单
在实际诊断之前，检查本地配置将解析为哪个身份：
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 调用；使用 check_aws=false 时不使用网络。返回版本、传输方式、已注册的工具和适配器、区域、经济策略以及零计费操作。其状态为：
ok：服务器和配置有效；STS 在请求时已响应。degraded：服务器正常运行，但缺少凭据或 STS 不可访问。error：安全配置或内部注册表无法初始化。
身份会被匿名化：只保留主体的通用类型，以及（如果存在）一个掩码账户。不执行清单、Resource Explorer、适配器、CloudTrail 或 CloudWatch。
listar_recursos_aws
查询本地凭据可用的 AWS 清单，不修改任何资源。参数：
region：将搜索限制在某个区域；无值时使用所有可用覆盖范围。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 以及一个五分钟后过期的请求。在第二次显式调用之前，不会执行这些操作：
{
"consent_request_id": "<id devuelto por la primera llamada>",
"consent_action": "approve",
"approved_services": ["s3"]
}批准是一次性的，与原始身份和范围绑定，并限制操作、区域和请求。发现和丰富化分别授权；额外的页面需要新的请求。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 的现有索引、适配器的注册表和能力、免费的活动来源以及被阻止的操作。每次执行的检查限制为五个区域、一个 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
查询 GetFreeTierUsage 和 GetAccountPlanState，这些是 AWS 文档中记录为免费的操作。区分月度限制、预测、计划和积分。可能因权限、更新延迟、优惠耗尽或资格差异而返回部分或未知信息。不声称任何特定资源是免费的。
consultar_costes_aws
为精确的时期和过滤器准备聚合的 GetCostAndUsage 查询。第一次调用执行零个 AWS 操作，并返回一个临时请求，其中包含主视图上每次请求 0.01 USD 的已发布价格。使用 consent_action="approve" 的第二次调用最多执行一页；每个额外的页面都需要新的同意。cancel 不调用 AWS。
粒度可以是 MONTHLY 或 DAILY；end_date 是排他性的。预测、按资源的详细信息、关联账户和自定义账单视图在此阶段未实现。
AWS 清单
Boto3 是 AWS 官方的 Python SDK。清单层使用：
STS
GetCallerIdentity用于识别账户和有效身份。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.
Maintenance
ActivitySlowing
ResponsivenessNo recent community issues
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