Skip to main content
Glama

run_dag

Runs a declarative multi-step query DAG across resolved AWS accounts, enabling dependent steps to reference earlier outputs and gather results with one credential set per account.

Instructions

Run a small declarative multi-step query DAG against every resolved account.

Each entry in ``steps`` is
``{"id": ..., "service": ..., "operation": ..., "params": {...},
"extract": "...", "depends_on": [...]}``.

A later step's ``params`` may reference an earlier step's extracted output
anywhere a literal would go, via ``{"$ref": "<step_id>"}``. There is no
expression language and nothing is ever evaluated as code.

Every resolved account runs its own independent copy of the whole DAG, with
one credential mint per account rather than one per step. As with
``aws_query``, AWS IAM is the sole authorization boundary for every step,
and ``max_items`` raises the per-account pagination ceiling for every step.

Input Schema

NameRequiredDescriptionDefault
orgNo
orgsNo
roleNo
stepsYes
regionYes
max_itemsNo
account_idNo
account_idsNo
environmentNo
account_nameNo
max_accountsNo
account_namesNo
name_containsNo
exclude_account_idsNo
exclude_account_namesNo

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

B3.4/5.0
Behavior4/5

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

With no annotations supplied, the description carries the full burden and does well: it discloses that each resolved account runs an independent copy of the whole DAG, that credentials are minted once per account rather than per step, that IAM is the sole authorization boundary, that max_items raises the per-account pagination ceiling, and that nothing is ever evaluated as code. It omits failure semantics — what happens when one step or one account errors, and whether partial results are returned.

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?

Front-loaded with the action, then the step shape, then the reference mechanism, then execution semantics. Every sentence carries information, including the security-relevant 'nothing is ever evaluated as code' clause. Slightly longer than needed only because the steps grammar is inline rather than deferred.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need no explanation, and the execution model is well covered. But for a 15-parameter, unannotated, inherently multi-step tool, the missing pieces are significant: no error or partial-failure behavior, no guidance on the account-resolution parameters, and no indication of cost or rate limits when fanning out across many accounts.

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 0% across 15 parameters, so the description must compensate. It documents the hardest parameter, steps, in full detail (id, service, operation, params, extract, depends_on, and $ref resolution) and explains max_items, but it is silent on the ten-plus account-selection parameters — org, orgs, role, account_id(s), account_name(s), name_contains, exclude_*, environment, max_accounts — leaving only the phrase 'resolved account' to imply how accounts are targeted.

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 and resource: run a declarative multi-step query DAG across every resolved account, and the opening sentence makes the multi-step DAG nature explicit. The family resemblance to aws_query is signalled but the description never directly contrasts the two, so an agent must infer that this is the multi-step superset.

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

Usage Guidelines2/5

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

There is no explicit when-to-use guidance and no when-not-to-use. The only sibling reference to aws_query is about the IAM authorization boundary, not about choosing between a single query and a DAG, and nothing says whether this is appropriate for large fan-outs, whether it is expensive, or what to do if a step fails.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.