Skip to main content
Glama

analyze_function

Inspect a Lambda handler before writing or reviewing to identify infrastructure issues: table access patterns, queue publishing, secret access, and trigger event shapes.

Instructions

Analyzes a single named function or Lambda handler for infrastructure issues: which tables it queries, how it queries them (scan vs query), queue publishing, secret access, and the correct event shape for each trigger (SQS, DynamoDB Streams, Kinesis, EventBridge). Call this before writing or reviewing a Lambda handler to get the exact trigger event shape and all findings scoped to this function. Per-file detail (file, accesses, missingPermissions) is returned in matches, one entry per source file defining a function with this name. Pass file to bind the answer to the one file you are editing: it matches a stored path exactly, or as a trailing fragment on a path-segment boundary, so a bare "orders.ts" resolves against the absolute path the scanner recorded. Matching is case sensitive. When file selects exactly one entry, that entry is returned alone with its accesses. When several deployed Lambdas link to the same function, candidateLambdas names them and triggers is absent rather than empty; re-call with file if the candidates come from different files. When several files match — with or without fileambiguous: true is returned and accesses is withheld from every entry; re-call with file set to the file you are editing rather than guessing between them. When file matches nothing, fileMatched: false is returned with availableFiles listing the paths that do exist, so you can retry. When no deployed Lambda could be linked to this function, unresolvedLambdas names each Lambda that was considered and why it was refused (no_match, multiple_functions, or multiple_lambdas with the colliding names), so an empty triggers can be told apart from a function that is not deployed. Returns found: false if the function name was not discovered during analysis.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
fileNoBind the result to one source file: the full stored path, or a trailing fragment on a path-segment boundary (e.g. "orders.ts" or "handlers/orders.ts"). Case sensitive.
functionYesFunction name to analyze
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. Dates show when Glama detected each change.

  1. Changed1 schema field changedv0.28.0
    • addedInput schema / properties / file
      Added value: +{
      +  "description": "Bind the result to one source file: the full stored path, or a trailing fragment on a path-segment boundary (e.g. \"orders.ts\" or \"handlers/orders.ts\"). Case sensitive.",
      +  "type": "string"
      +}
  2. 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"
      +}
  3. Addedv0.21.0
  4. Removedv0.19.7
  5. First observedv0.1.0

TDQS

A4.6/5.0
Behavior5/5

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

No annotations are provided, so the description carries the full disclosure burden — and it delivers: it documents the matches-per-source-file structure, case-sensitive path-segment matching, and every conditional outcome (ambiguous with accesses withheld, fileMatched: false with availableFiles, triggers absent rather than empty when candidateLambdas exist, unresolvedLambdas with refusal reasons, found: false). It also clarifies that calls read a cached snapshot rather than re-reading AWS, via the maxAgeSeconds schema note.

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 front-loaded with purpose and usage before the edge-case documentation, and each conditional behavior clause earns its place given the tool's matching complexity. It is long and partially repeats the file-matching mechanics already present in the schema, but that redundancy is minor against the well-organized, spec-like structure.

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?

With no output schema and no annotations, the description must explain both invocation and return semantics, and it does so thoroughly: matches entry shape, ambiguity handling, absent-vs-empty triggers, unresolvedLambdas refusal reasons, availableFiles recovery, and found: false. The one thing left to the schema (maxAgeSeconds freshness semantics) is itself well documented there, so nothing an agent needs to call the tool correctly is missing.

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 baseline is 3, but the description adds meaning beyond the schema: it frames `file` as a way to 'bind the answer to the one file you are editing' and prescribes the retry strategy for ambiguous results, and it attaches found: false semantics to `function`. This actionable interpretation guidance exceeds what the schema's mechanical descriptions provide.

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?

States a specific verb and resource ('Analyzes a single named function or Lambda handler') and enumerates the exact analysis dimensions: tables queried, scan vs query, queue publishing, secret access, and trigger event shapes. This clearly distinguishes it from the sibling get_* overview tools, which retrieve resource snapshots rather than function-scoped infrastructure analysis.

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?

'Call this before writing or reviewing a Lambda handler' is an explicit when-to-use with a clear context, and the description scopes the result ('all findings scoped to this function'). However, no alternative tools are named and no when-not-to-use conditions are stated, though the sibling tools are clearly different in purpose.

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

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/Sidd27/infrawise'

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