Skip to main content
Glama
Sidd27

infrawise

by Sidd27
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

API Gateway routes

get_api_routes
Read-only

List all API Gateway routes (REST, HTTP, WebSocket) with methods, paths, and invoking Lambda functions before writing handlers or reviewing integration coverage.

Instructions

Returns all API Gateway APIs (REST, HTTP, WebSocket) with their routes, HTTP methods, paths, and the Lambda function each route invokes. Call this before writing any API handler to understand which Lambda handles a route, or when reviewing API surface area and Lambda integration coverage.

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

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.26.1
    • changedInput schema / properties / maxAgeSeconds / description
      Previous value: -"Refuse to answer from an analysis older than this many seconds. Use 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."New value: +"Freshness 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."
  2. Changed1 schema field changedv0.25.1
    • addedInput schema / properties / maxAgeSeconds
      Added value: +{
+  "description": "Refuse to answer from an analysis older than this many seconds. Use 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.",
+  "type": "number"
+}
  3. Addedv0.21.0
  4. Removedv0.19.7
  5. Addedv0.10.3

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds genuine behavioral context by disclosing that it enumerates ALL APIs across three protocol types and links each route to its Lambda, which is more than the annotations convey. The snapshot/freshness caveat lives in the parameter schema rather than the description, a minor omission.

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 sentences, front-loaded with the return content and followed by usage scenarios. No filler; every clause carries 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?

With no output schema, the description usefully explains the returned structure (routes, methods, paths, Lambda target). Annotations cover the safety profile and the sole parameter is fully documented, so an agent has enough to call it correctly. Only the freshness behavior, which is documented in the schema, is not echoed in the description.

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 100% for the single maxAgeSeconds parameter, and the schema itself richly documents its freshness-tolerance semantics. The description adds no additional parameter meaning beyond what the schema provides, so the baseline 3 applies.

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?

States a specific verb ('Returns') and resource ('all API Gateway APIs (REST, HTTP, WebSocket)'), then enumerates exactly what fields come back (routes, HTTP methods, paths, and the invoked Lambda). It is clearly distinct from siblings like get_lambda_overview or get_infra_overview because it names the API Gateway domain and its route-to-Lambda linkage.

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?

Gives two concrete when-to-use scenarios: 'before writing any API handler to understand which Lambda handles a route' and 'when reviewing API surface area and Lambda integration coverage.' This is clear context, though it doesn't name an explicit alternative tool or a when-not-to-use condition, keeping it below a 5.

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

Deploy Server

Other Tools