awslabs.aws-documentation-mcp-server: No results found for given filters

[Luchiap]

Describe the bug

When an agent uses https://awslabs.github.io/mcp/servers/aws-pricing-mcp-server/ It calls the wrong APIs, even after giving it a context of what a correct API would look like. This was my prompt:

Use the cost analysis tools to provide accurate financial projections and optimization strategies.
For example, if you are looking at S3 storage, you first need to make sure you are using the values. 

To get them you need to perform the following CLI API example:
"aws pricing get-attribute-values --service-code AmazonS3 --attribute-name storageClass"
This will give you a value such as "General Purpose".

With that value you can then call the following CLI API example:
aws pricing get-products --service-code AmazonS3 --filters Type=EQUALS,Field=storageClass,Value="General Purpose"

This is one error: 2025-10-14 17:41:26.511 | ERROR | awslabs.aws_pricing_mcp_server.server:create_error_response:68 - No results found for given filters [[PricingFilter(field='storageClass', type='EQUALS', value='Standard')]], service: "AmazonS3", region "us-east-1"

Expected Behavior

I expect it to correctly perform the APIs

Current Behavior

Not performing the APIs correctly

Reproduction Steps

use an agent to call the MCP server as a tool.

Like so

from mcp import StdioServerParameters, stdio_client
from strands import Agent, tool
from strands.models import BedrockModel
from strands.tools.mcp import MCPClient

aws_docs_client = MCPClient(
    lambda: stdio_client(
        StdioServerParameters(
            command="uvx", args=["awslabs.aws-documentation-mcp-server@latest"]
        )
    )
)

I used the example from this workshop: https://catalog.us-east-1.prod.workshops.aws/workshops/fda82638-2464-49f9-b6af-0e72b157d1a9/en-US

Possible Solution

No response

Additional Information/Context

No response

OS

Mac

Server

other

Server Version

No response

Region experiencing the issue

us-east-1

Other information

No response

Service quota

• [x] I have reviewed the service quotas for this construct

[krokoko]

@Luchiap Hi, sorry I am not sure to understand the issue, you are referring to the documentation mcp server in the title and code snippet, but in the description you mention the pricing mcp server. Could you please confirm the issue is related to the pricing mcp server ? Thank you

[nspring00]

@Luchiap I assume you are referring to the AWS Pricing MCP Server.

Thanks for reporting this issue. I've verified the problem and can confirm the correct approach.

The error occurs because storageClass=Standard is not a valid value in the AWS Pricing API. What's commonly referred to as "S3 Standard" storage is actually called General Purpose in the pricing data.

Correct Usage

Step 1: Discover Valid Attribute Values

aws pricing get-attribute-values --service-code AmazonS3 --attribute-name storageClass

Available values: • General Purpose (S3 Standard) • Infrequent Access (S3 Standard-IA) • Archive (S3 Glacier Flexible Retrieval) • Archive Instant Retrieval (S3 Glacier Instant Retrieval) • Intelligent-Tiering • High Performance (S3 Express One Zone) • Non-Critical Data (S3 One Zone-IA) • Analytics • Tags • Vectors

Step 2: Query Pricing with Correct Value

aws pricing get-products --service-code AmazonS3 --filters Type=EQUALS,Field=storageClass,Value="General Purpose" --region us-east-1

This returns the pricing for S3 Standard storage successfully.

Verification

I've tested both queries: • ❌ storageClass=Standard → Returns no results (as reported in your error) • ✅ storageClass=General Purpose → Returns correct S3 Standard pricing

Resolution

The MCP server is working correctly - the issue is using an invalid attribute value. When working with agents, ensure they're instructed to:

1. Always discover valid attribute values first using get_pricing_attribute_values()
2. Use the exact values returned by the API (e.g., "General Purpose" not "Standard")

The workflow you described in your prompt is correct, but the agent needs to use the actual values returned from step 1 rather than assuming common names like "Standard".