Skip to main content
Glama
Sidd27

infrawise

by Sidd27
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

SNS and Kafka topic details

get_topic_details
Read-only

Fetches SNS topics with subscription count, encryption status, and filter policies to ensure publishers include required attributes, preventing silent message drops before writing SNS code.

Instructions

Returns all SNS topics with subscription count, encryption status, and filter policies. Filter policies list the message attributes each subscription requires — publishers must include these attributes or messages are silently dropped. Call this before writing any SNS publish code or when reviewing event fan-out patterns.

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. First observedv0.1.0

TDQS

A4/5.0
Behavior4/5

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

Annotations already cover the safety profile (readOnlyHint=true, openWorldHint=false), so the bar is lower, and the description adds genuinely non-obvious behavior: filter policies determine required message attributes and violating publishers get messages 'silently dropped.' That is real operational consequence beyond the structured fields. It does not discuss data freshness, though the maxAgeSeconds schema entry covers that.

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, zero filler, with the return contents front-loaded and the call-to-action last. Every sentence carries distinct 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 enumerates what comes back (subscription counts, encryption status, filter policies) and flags the silent-drop consequence. The one gap is the Kafka scope implied by the title but absent from 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% and maxAgeSeconds is documented in exhaustive detail (advisory semantics, dataHealth.withinRequestedAge, when to pass small vs. omit). The description adds nothing about parameters, so the baseline 3 applies.

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?

States a specific verb (Returns) and resource (SNS topics) and enumerates what is included: subscription count, encryption status, and filter policies. It implicitly separates itself from siblings like get_queue_details and get_eventbridge_details by resource, but never names them, and the title's promise of 'Kafka topic details' is not reflected in the description text.

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 explicit triggers: 'Call this before writing any SNS publish code or when reviewing event fan-out patterns.' That is actionable context for the agent. It stops short of a 5 because it names no alternative tool or when-not-to-call condition.

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