muhandis-rls-check
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
| prompts | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| rls_check_queryA | Returns a read-only SQL query that lists every table and view in the public schema of a Supabase (Postgres) project with its RLS state, grants to anon/authenticated, column names and policies. It reads no row of data. Run it in the project (SQL Editor, or a Supabase MCP execute_sql tool), then pass the single JSON result cell to rls_check_explain. |
| rls_check_explainA | Explains the output of rls_check_query table by table, worst first: which tables anyone with the public (anon) key can read or change, which any signed-in user can read across users, which are locked, which are safe. Findings are in Arabic for founders (labels also given in English) and link to Arabic lessons on muhandis.online. Works offline on the pasted result. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| rls_check | Run the read-only RLS check on this project and explain it in Arabic. Browser version: https://muhandis.online/tools/rls-check |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 2 tools
The two tools have clearly distinct roles: one generates a read-only SQL query, the other explains the resulting JSON output. The descriptions explicitly describe a sequential handoff, leaving no realistic chance of misselection.
Both names follow the same rls_check_<action> snake_case pattern, with query and explain as clear action suffixes. The convention is fully consistent across the set.
Two tools is on the thin side generally, but for this narrowly scoped two-step RLS audit workflow each tool earns its place. There is no obvious extra operation that would justify adding more tools.
The pair covers the full lifecycle: generate the diagnostic query, run it externally, then explain the pasted result. The query tool states it reads no row data and the explain tool works offline, so there are no apparent dead ends for the stated purpose.