Skip to main content
Glama
Sidd27

infrawise

by Sidd27
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Table and collection schemas

get_table_schema
Read-only

Retrieve column types, keys, foreign keys, indexes, and DynamoDB/MongoDB schema details for named tables or collections before writing queries.

Instructions

Returns schemas for named tables or collections: column types/nullability, keys, foreign keys, indexes, DynamoDB keys/billing mode, and MongoDB estimated counts. Relational indexes include ordered columns, method, partial and valid flags; these describe possible access paths, not observed query plans. Short names match qualified names case-insensitively. Call after get_infra_overview before writing queries; request only needed tables. Do NOT use for inventory; use get_infra_overview. Row data is never included. Read source health before treating found:false as absence. DynamoDB provisioned tables may include an advisory costSignal.

Input Schema

NameRequiredDescriptionDefault
tablesYesTable or collection names to fetch schemas for
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
    • addedInput schema / properties / maxAgeSeconds
      Added value: +{
+  "description": "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.",
+  "type": "number"
+}
  2. Addedv0.15.0

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only declare readOnlyHint and openWorldHint, but the description goes much further: row data is never returned, index metadata describes possible access paths rather than observed query plans, found:false must be read against source health, and DynamoDB may carry an advisory costSignal. These are non-obvious behavioral traits an agent could not infer from structured fields.

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?

Content is front-loaded: what is returned comes first, then usage ordering, exclusions, and caveats. It is dense but nearly every clause carries operational information; the index 'possible access paths, not observed query plans' clarification and the costSignal note are the most compressed items and border on terse.

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 schema-inspection tool with no output schema, the description covers return content, scoping limits, name resolution, absence semantics, and staleness handling. An agent has everything needed to invoke it correctly and interpret the result.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the schema already documents both parameters, giving a baseline of 3. The description adds real value on top by stating that short names match qualified names case-insensitively and by reinforcing scoping to only the needed tables, though it does not explain the maxAgeSeconds advisory behavior that the schema covers.

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 opening sentence names a specific verb (Returns) and resource (schemas) and enumerates the exact content returned: column types/nullability, keys, foreign keys, indexes, DynamoDB keys/billing mode, and MongoDB estimated counts. It also explicitly separates itself from the inventory sibling, so an agent can distinguish the two without opening a 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 explicit ordering ('Call after get_infra_overview before writing queries'), an efficiency constraint ('request only needed tables'), and a hard exclusion with the alternative named ('Do NOT use for inventory; use get_infra_overview'). It also flags a caveat on interpretation ('Read source health before treating found:false as absence').

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