Skip to main content
Glama

Batch-Inspect GCP Infrastructure

gcpinspect_batch
Read-only

Run up to 32 GCP resource inspection probes in a single call. Fetches credentials once and fans out probes in parallel, reducing overhead compared to multiple individual calls.

Instructions

BATCH INSPECTION: run up to 32 GCP inspect probes in one call. ⚠️ PREREQUISITE: Same as gcpinspect — 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 GCP credentials blob — a 12-resource health check is ~5–8× faster and 12× fewer Oracle round-trips than calling gcpinspect 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.

  • 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: apigateway, bastion, billing, certificatemanager, cloudarmor, cloudbuild, cloudcdn, clouddeploy, clouddns, cloudfunctions, cloudkms, cloudlogging, cloudmonitoring, cloudrun, cloudsql, compute, firestore, gcs, gke, iam, identityplatform, loadbalancer, memorystore, pubsub, secretmanager, vertexai, vpc For a specific service's actions, use gcpinspect (singular) with action="list-actions" — batch is not the place for discovery. Batch responses are always summarized (no detail/raw per-sub); use singular gcpinspect when you need full metadata or raw API output for one resource.

EXAMPLES:

  • gcpinspect_batch(session_id=..., subs=[ {"service":"compute","action":"list-instances"}, {"service":"gke","action":"list-clusters"}, {"service":"cloudsql","action":"list-instances"}])

  • gcpinspect_batch(session_id=..., subs=[ {"service":"compute","action":"get-metrics","filters":"{"hours":6}"}, {"service":"cloudrun","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 a GCP deploy attempt before inspect probes will succeed.
Behavior5/5

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

Adds rich behavioral context beyond annotations: budgets (max 32, timeouts, concurrency, response cap with truncation), partial failure handling, credential fetch behavior, and summarized responses. Annotations already indicate read-only and open-world, which description complements.

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?

Well-organized with headers, bullet points, and examples. Slightly verbose but all content adds value. Front-loaded with main purpose. A minor trim could make it more concise.

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?

Covers prerequisites, budgets, failure modes, response structure, examples, and comparison with siblings. Despite no output schema, description explains the response format. Highly complete for a batch tool with partial failure.

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

Parameters5/5

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

Schema coverage is 100% but description adds significant value: session_id must include ?token= suffix, subs array constraints and concurrency details, and examples illustrate usage. Goes well beyond schema.

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?

Clearly states it runs up to 32 GCP inspect probes in one call, distinguishes from singular gcpinspect by specifying batch is for >3 resources, and notes singular is for discovery or full metadata.

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 says to use when checking >3 resources, not for discovery, provides prerequisite (deploy attempt required) and alternative (singular gcpinspect for full metadata).

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