Skip to main content
Glama

Batch-Inspect AWS Infrastructure

awsinspect_batch
Read-only

Run up to 32 AWS inspect probes in one batch call for faster multi-resource health checks with fewer database round trips.

Instructions

BATCH INSPECTION: run up to 32 AWS inspect probes in one call. ⚠️ PREREQUISITE: Same as awsinspect — deploy attempt required. Check convostatus for hasDeployAttempt=true before calling.

Use this when you need to check more than ~3 resources. The backend fetches Oracle credentials ONCE per batch and fans out probes against a single AWS config — for a 12-resource health check this is ~5–8× faster and 12× fewer Oracle round-trips than calling awsinspect 12 times.

BUDGETS:

  • Up to 32 sub-probes per call (subs array length).

  • 30s per-sub timeout; 60s total batch wall-clock.

  • Concurrency cap 8 — sub-probes run in parallel but never saturate AWS.

  • 512 KB response cap: subs past the cap keep their envelope (index/service/action/ok) but have result replaced with truncated=true.

PARTIAL FAILURE IS EXPECTED. The response is an ordered results array; each entry has {index, service, action, ok, result, error}. Inspect each result — do NOT abort on the first error. A credential fetch failure leaves cred-less probes (list-actions, list-metrics) succeeding anyway.

REQUIRES: session_id from convoopen response (format: sess_v2_...). Supported services: account, acm, alb, apigateway, apprunner, backup, bedrock, cloudfront, cloudwatchlogs, cognito, cost-explorer, dynamodb, ebs, ec2, ecs, eks, elasticache, kms, lambda, msk, opensearch, rds, route53, s3, sagemaker, secretsmanager, sqs, vpc, waf For a specific service's actions, use awsinspect (singular) with action="list-actions" — batch is not the place for discovery. Batch responses are always summarized (no detail/raw per-sub); use singular awsinspect when you need full metadata or raw API output for one resource.

EXAMPLES:

  • awsinspect_batch(session_id=..., subs=[ {"service":"ec2","action":"describe-instances"}, {"service":"rds","action":"describe-db-instances"}, {"service":"vpc","action":"describe-vpcs"}, {"service":"s3","action":"list-buckets"}])

  • awsinspect_batch(session_id=..., subs=[ {"service":"ec2","action":"get-metrics","filters":"{"hours":6}"}, {"service":"rds","action":"get-metrics","filters":"{"hours":6}"}])

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
subsYesUp to 32 sub-probes, each with {service, action, filters?, detail?, raw?}. The backend fetches credentials once per batch and fans out probes in parallel (concurrency 8, 30s per-sub timeout, 60s total wall clock). Partial failure is expected — inspect each result.ok independently.
session_idYesSession ID from convoopen — pass back EXACTLY as returned, including the ?token=... suffix (format: sess_v2_*?token=*). The suffix is part of the session credential; never strip it when summarizing. The session must have an AWS deploy attempt before inspect probes will succeed.
Behavior5/5

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

Beyond the readOnlyHint and openWorldHint, the description details budgets (sub count, timeouts, concurrency cap, response cap), partial failure behavior, credential handling, and response format. This fully informs the agent of operational constraints.

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 long but well-structured with headings (BUDGETS, PARTIAL FAILURE, etc.) and front-loaded with the core purpose. Every section adds necessary detail, though some redundancy could be trimmed.

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?

Given the tool's complexity (batch, partial failure, multiple services), the description covers prerequisites, budgets, error handling, response format, and provides multiple examples. Without an output schema, this level of detail is essential and sufficient.

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?

The schema covers all parameters (session_id, subs) with descriptions. The description adds value by providing examples, clarifying the subs structure (service, action, filters), and explaining the credential fan-out. Since schema coverage is 100%, baseline is 3, but the additional context raises it to 4.

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 clearly states it runs up to 32 AWS inspect probes in one batch call. The title 'Batch-Inspect AWS Infrastructure' reinforces the purpose. It distinguishes from sibling 'awsinspect' by emphasizing batching for efficiency.

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?

Explicitly advises using this tool when checking more than ~3 resources, and directs to awsinspect for discovery or detailed output. It also states the prerequisite (deploy attempt required) and checks convostatus for hasDeployAttempt=true.

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/luthersystems/insideout-agent-skills'

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