Skip to main content
Glama
Sign In
supabase-rls-check

supabase-rls-check

by Tthanh2k6
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

scan_public_env

Scans a local project directory for exposed secrets in public environment variables and client-side source files, returning only masked values to support safe RLS and public-config reviews.

Instructions

Scan a local project directory (read-only, local files only, no network) for secrets in public env variables and client source files, returning masked values only.

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": {
      "path": "<path>"
    },
    "name": "scan_public_env"
  }
}

Input Schema

NameRequiredDescriptionDefault
pathYes

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.6.1

TDQS

A4/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 declares read-only operation, local-only file access, no network calls, and masked return values. It stops short of covering failure modes such as unreadable paths or oversized directories, but the core safety profile is disclosed.

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?

One sentence, zero filler, with the strongest constraint (read-only, local, no network) and the output limitation (masked values) packed into it. Everything an agent needs is front-loaded.

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?

An output schema exists, so return-value detail is not required here, and the description still flags that values come back masked. For a one-parameter read-only scan, this is nearly complete, with only edge-case behavior left unstated.

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 0% and the single parameter is documented only as 'path: string'. The description compensates partially by establishing that the path points at a local project directory rather than a file or remote location, but it adds no syntax, format, or resolution details.

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?

The description names a specific verb (scan) and resource (local project directory) and narrows the target to secrets in public env variables and client source files. Nothing about it overlaps with analyze_sql_export, diff_results, or explain_rule, so an agent can pick it without reading another schema.

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?

The definition bounds the scope with 'local files only, no network', which implies it is for pre-commit/pre-publish secret checks on a local project. It never states explicitly when to choose this over an alternative or what to do if the path is outside a project, so usage is only inferred.

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

Deploy Server

Other Tools