AWS Resource MCP

by herrerogusano

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

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

Latest release: v0.1.0
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.
Average 4/5 across 7 of 7 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 30 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

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.
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.
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.
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.
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.
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.
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

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

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

Card Badge

Copy to your README.md:

[![aws-resource-mcp MCP server](https://glama.ai/mcp/servers/herrerogusano/aws-resource-mcp/badges/card.svg)](https://glama.ai/mcp/servers/herrerogusano/aws-resource-mcp)

Score Badge

Copy to your README.md:

[![aws-resource-mcp MCP server](https://glama.ai/mcp/servers/herrerogusano/aws-resource-mcp/badges/score.svg)](https://glama.ai/mcp/servers/herrerogusano/aws-resource-mcp)

Latest Blog Posts

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

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/herrerogusano/aws-resource-mcp'

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