Skip to main content
Glama
Sign In

GuardLayer

by io.github.solvionholdings
OverviewDiscussionsAdmin

Scan code for security issues

scan_files
Read-only

Static security scan of a Next.js + Supabase codebase: secrets in code or public env vars (NEXT_PUBLIC_, VITE_), service role keys in client code, RLS off or open policies in supabase/migrations, unauthenticated API routes, Server Actions and Edge Functions, unsafe redirects and more. Send source files (ts, tsx, js, jsx, sql, .env*, config files) with paths relative to the project root; skip node_modules, build output and lockfiles. Up to 300 files and 4 MB per call; split bigger projects. Files are scanned in memory and discarded.

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": {
      "files": "<files>"
    },
    "name": "scan_files"
  }
}

Input Schema

NameRequiredDescriptionDefault
filesYes
ignoreNoOptional contents of a .guardlayerignore (gitignore syntax) to skip fixtures.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the description is not burdened with the safety profile. It still adds genuinely useful context beyond them: hard limits of 300 files / 4 MB per call, the instruction to split larger projects, and the privacy guarantee that files are scanned in memory and discarded.

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?

Dense but front-loaded: what it scans, then what to send, then limits and privacy. Every clause carries information an agent needs to construct a valid call; nothing is filler.

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?

There is no output schema, so the description should indicate what a scan returns, and it never describes the findings format or severity reporting. Otherwise it is complete for a two-parameter scanning tool, covering inputs, exclusions, size limits, and data handling.

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 coverage is 50% and the nested `files` item schema lacks descriptions, so the description compensates well by specifying allowed extensions, relative-path convention, and exclusions. However, it says nothing about the `ignore` parameter (gitignore-syntax file for skipping fixtures), leaving one of two parameters explained only by the 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?

States a specific verb and resource ("static security scan of a Next.js + Supabase codebase") and then enumerates the exact issue classes it detects: secrets in code or NEXT_PUBLIC_/VITE_ env vars, service role keys in client code, RLS off/open policies in supabase/migrations, unauthenticated routes, Server Actions, Edge Functions, unsafe redirects. This is far more than a restatement of the name and clearly separates it from the snapshot-oriented siblings.

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?

Gives concrete operational guidance: which file types to send, that paths must be relative to the project root, which directories to skip (node_modules, build output, lockfiles), and to split projects above the limits. It does not explicitly say when to prefer this over the snapshot tools, but the code-vs-snapshot distinction is strongly implied by the input requirements.

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

All GuardLayer toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources