Skip to main content
Glama

Audit supplied source evidence

audit_agent_extension_supply_chain
Read-onlyIdempotent

Statically inspect up to 16 KiB across 16 supplied source files. Does not download or execute packages. Results cover only the supplied evidence, not a verified package artifact. Never send credentials or private source without permission.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "sourceFiles": "<sourceFiles>"
    },
    "name": "audit_agent_extension_supply_chain"
  }
}

Input Schema

NameRequiredDescriptionDefault
packageNameNoOptional package label for the report, such as express or @scope/package. This label does not trigger a package download or establish its identity; omitted labels use supplied-evidence.
sourceFilesYesMap 1–16 file names to their literal source text, for example {"index.js":"module.exports = 42;"}. Names are report labels, not paths to read. File names and contents together must fit within 16 KiB of UTF-8 data. Include only source you are permitted to share, with credentials removed.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • addedInput schema / properties / packageName / description
      Added value: +"Optional package label for the report, such as express or @scope/package. This label does not trigger a package download or establish its identity; omitted labels use supplied-evidence."
    • addedInput schema / properties / sourceFiles / additionalProperties / description
      Added value: +"Literal source text for the named file. It is inspected as data and never executed; the file map shares one 16 KiB UTF-8 budget."
    • addedInput schema / properties / sourceFiles / description
      Added value: +"Map 1–16 file names to their literal source text, for example {\"index.js\":\"module.exports = 42;\"}. Names are report labels, not paths to read. File names and contents together must fit within 16 KiB of UTF-8 data. Include only source you are permitted to share, with credentials removed."
  2. First observed

TDQS

A4/5.0
Behavior5/5

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

Annotations already declare this a read-only, idempotent, non-destructive, closed-world operation, so the description is free to add the context that matters: nothing is downloaded or executed, findings are scoped to the supplied evidence rather than a verified artifact, and credentials or private source should not be submitted without permission. Those are exactly the limitations an agent needs before trusting or relaying output. No contradiction with the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short sentences, each earning its place, with the operational scope front-loaded and the trust caveats after it. No filler or repetition of the schema.

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

Completeness4/5

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

Given a nested-object schema with full coverage and no output schema, the definition covers consumption limits and result trustworthiness well. The one gap is that it never characterizes the kind of findings the report contains, which matters for a security-audit tool with no declared return shape. Slight shortfall against the tool's complexity, but broadly complete.

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?

With 100% schema description coverage the schema already carries parameter meaning, so the baseline is 3. The description reinforces the shared 16 KiB / 16-file budget and the notion that files are supplied text rather than paths, but it adds no syntax or semantic detail beyond what packageName and sourceFiles already document. It neither compensates for nor undermines the schema.

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?

The description gives a specific verb and resource — statically inspect supplied source files — plus concrete scope limits (16 KiB across 16 files). It implicitly separates itself from an artifact-fetching or metadata tool by stating it does not download or execute packages, though it never names a sibling. An agent knows exactly what the tool consumes, if not precisely which catalogue entry to pick over check_npm_package_metadata.

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

Usage Guidelines3/5

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

Usage is implied rather than stated: the tool applies when you already hold source evidence in hand, and the caveat that results cover only supplied evidence hints that a verified-artifact path exists elsewhere. There is no explicit when-to-use/when-not-to-use rule and no named alternative for the case where the agent lacks local source. Adequate but leaves routing to inference.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.