Skip to main content
Glama

get_cloudfront_overview

Retrieve a complete map of all CloudFront distributions, origins, and cache behaviors to pinpoint which distribution and rule serves a given path before changing routing, edge caching, or HTTPS policies.

Instructions

Returns all CloudFront distributions with, per distribution: id, comment, domain name, alias domains, enabled state, origins (type s3 or custom, domain name, and the resolved API Gateway name when the origin is an execute-api endpoint), and every cache behavior with its path pattern, target origin, cache policy name, viewer protocol policy, and allowed methods. Behaviors are listed in CloudFront match order — ordered behaviors first, the default behavior last. Call this to answer which distribution and behavior serves a given path and which origin it hits, before changing a path-based routing rule, or when reviewing edge caching and HTTPS enforcement across a multi-API front door.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
maxAgeSecondsNoFreshness tolerance in seconds. Advisory: the answer is returned either way, with dataHealth.withinRequestedAge reporting whether it met the tolerance. Nothing re-reads AWS on a tool call — run `infrawise analyze` to refresh. Pass a small value for point-in-time questions ("does this queue have a DLQ right now"); omit it for architecture questions where a day-old snapshot is fine.
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description discloses important behavioral traits beyond annotations: the data is a snapshot that is not re-read from AWS on each call, and behaviors are returned in CloudFront match order. It also directs the agent to `infrawise analyze` to refresh data, which is valuable operational 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 dense and front-loaded, with the main purpose first and usage guidance following. Though the first sentence is long, it packs necessary detail without fluff, earning a 4.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description thoroughly explains what each distribution's data includes, including origins and cache behaviors with ordering. The freshness semantics are covered by the parameter schema, and usage guidance is present, making this complete for a read-only overview tool.

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 tool description does not discuss the sole parameter, maxAgeSeconds, but the schema description covers it 100%, explaining the advisory nature and the dataHealth field. Per the rubric, baseline 3 is appropriate when schema coverage is high.

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 opens with a specific verb and resource ('Returns all CloudFront distributions') and enumerates the exact fields returned, making the tool's purpose unmistakable. It is clearly differentiated from sibling overview tools by its CloudFront-specific scope.

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 explicitly states when to call the tool: to determine which distribution/behavior serves a path, before changing routing rules, or when reviewing caching/HTTPS. However, it does not mention alternatives or exclusions, so it falls short of the highest bar.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Latest Blog Posts

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/Sidd27/infrawise'

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