Skip to main content
Glama
Sidd27

infrawise

by Sidd27
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Kinesis and MSK details

get_stream_details
Read-only

Retrieve Kinesis stream and MSK cluster details to check capacity mode, shard count, encryption, and state before writing producer/consumer code or reviewing streaming architecture.

Instructions

Returns all Kinesis data streams (status, shard count, retention hours, encryption, capacity mode) and Amazon MSK clusters (state, cluster type, Kafka version, broker count). Call this when writing Kinesis producer or consumer code, checking whether a stream is PROVISIONED or ON_DEMAND before writing PutRecord calls, or reviewing streaming architecture. For Kafka topic-level producer/consumer mappings extracted from application code, use get_topic_details instead.

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

TDQS

A4.5/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 value by enumerating exactly what a caller receives (status, shard count, retention, encryption, capacity mode) even though no output schema exists, which is genuinely useful behavioral disclosure. It stops short of describing snapshot freshness or pagination in the tool description itself, though the schema parameter documents the cached-snapshot model.

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?

Three sentences, all load-bearing: returns first, usage scenarios second, sibling disambiguation third. No filler, no repetition of the title, and the routing information is front-loaded rather than buried.

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?

For a read-only lookup tool with no output schema, the description compensates by enumerating the returned fields for both stream types, and the schema fully documents the single optional parameter. Nothing an agent needs to select or invoke this tool correctly is missing.

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 coverage is 100% and the single parameter (maxAgeSeconds) carries a rich description covering freshness tolerance, dataHealth.withinRequestedAge, and the need to run `infrawise analyze` to refresh. The tool description adds nothing about this parameter, so the baseline 3 for full schema coverage is appropriate.

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 two named resources (Kinesis data streams and Amazon MSK clusters) and enumerates the concrete attributes returned for each (status, shard count, retention hours, encryption, capacity mode; state, cluster type, Kafka version, broker count). It also explicitly contrasts itself with the sibling get_topic_details, so an agent can distinguish the two streaming-related tools without opening either schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives concrete triggering scenarios ('writing Kinesis producer or consumer code', 'checking whether a stream is PROVISIONED or ON_DEMAND before writing PutRecord calls', 'reviewing streaming architecture') and names the alternative for a different case ('For Kafka topic-level producer/consumer mappings... use get_topic_details instead'). Both when-to-use and when-to-use-something-else are stated explicitly.

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