Kelp
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
} |
| resources | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| scan_pathA | Runs Kelp's static engine over a filesystem path. Detects hardcoded secrets (Stripe, AWS, GitHub, OpenAI, Anthropic, Supabase service_role, private keys, and more), Supabase edge functions that skip JWT verification, and recons Supabase edge-fn deployables. Fast, offline, deterministic. Returns findings sorted by severity. |
| scan_snippetA | Runs the static engine on one in-memory string as if it were a file. Use this after generating code, before showing it to the user or committing it. Cheaper than scan_path when only a diff is at stake. |
| list_rulesA | Returns the catalog of rules Kelp can fire on. Use this to introspect coverage before scanning, or to answer 'does Kelp check X?' without running a scan. |
| explain_findingA | Given a ruleId (and optionally the finding's path + preview), returns the reasoning ('why this matters') and a concrete remediation you can turn into a code change or an instruction to the user. |
| explain_ruleA | Given a ruleId, returns the rule's title, class, severity, why-it-matters, and remediation pattern. Use before or after a scan to understand a rule without an active finding. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| review-repo | Ask the assistant to run Kelp over a project and summarize the critical and high findings with concrete remediation. |
| harden-file | Ask the assistant to scan one file, then rewrite it in place to remove any critical or high finding. |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| rules-catalog | Every detection rule Kelp knows about, as JSON. |
| stripe-secret-live | A live Stripe secret key can charge cards, refund customers, and read your live payment data. Once it is public on GitHub it is compromised, even after removal, because the git object is still fetchable. |
| stripe-secret-test | Test-mode keys cannot charge real cards but still expose your test data and give attackers a working handle into your Stripe account structure. |
| stripe-webhook-secret | A leaked whsec_ lets anyone forge signed webhook payloads and bypass the receiving service's authenticity check, which means arbitrary state changes can be triggered by an attacker. |
| aws-access-key-id | Even alone, an AWS access key id narrows the search space. Combined with the very common paired secret key leak, this becomes a full account takeover vector. |
| github-token | A leaked GitHub token can read private repos, push code, and open PRs as the token owner. On a CI account, that is a supply-chain compromise. |
| github-pat-fine | Fine-grained PATs are still bearer tokens. Their narrower scope reduces blast radius but does not remove it, especially if the token has repo write. |
| anthropic-key | An Anthropic API key can spend the account's balance and read message history. Costs can escalate to hundreds of dollars in hours if abused. |
| openai-project-key | sk-proj-... project keys have organization-wide blast radius on the OpenAI side and can be used to spend the balance. |
| openai-key | A leaked OpenAI key can spend account balance and access model usage history. |
| google-api-key | Google / Firebase API keys are usually origin-restricted on the client, but an unrestricted key or one used server-side can incur billing and expose services. |
| slack-token | Slack tokens can read messages, post as bots, and depending on scope, invite users or exfiltrate DM history. |
| private-key-block | A PEM-formatted private key in the repo means whichever service uses that keypair is now impersonable by any reader of the repo. |
| supabase-service-role | The service_role key bypasses RLS and gives read plus write to every table in the project. If it ships to the browser or leaks to GitHub, the database is fully compromised. |
| jwt-exposed | A JWT in source code is either a session token that should never be committed, or a signing artifact whose secret is likely near. |
| high-entropy-string | The value looks like a credential by shape and entropy but does not match a known provider pattern. Likely still a secret, treat as suspicious until proven otherwise. |
| supabase-config-verify-jwt-false | verify_jwt = false in supabase/config.toml disables the built-in JWT verification for that function, meaning it accepts any unauthenticated caller. Usually a mistake, sometimes a public-by-design function that then must gate on a shared secret in the handler. |
TDQS
Scored across 5 tools
Each tool has a distinct core purpose: scanning paths vs snippets, listing rules, and explaining rules vs findings. The pairings scan_path/scan_snippet and explain_rule/explain_finding have some surface similarity, but descriptions clarify their boundaries.
All tool names follow a consistent verb_noun pattern in snake_case: scan_path, scan_snippet, list_rules, explain_rule, explain_finding. The naming is predictable and makes the toolset easy to navigate.
Five tools is well-scoped for a security scanning server: two scan entry points, one rule catalog query, and two explanation helpers. Each tool serves a clear, non-redundant role in the workflow.
The toolset covers the full lifecycle expected of a static analysis scanner: discover rules, scan a path or snippet, retrieve rule details, and explain findings with remediation. There are no obvious missing operations for the stated domain.