Skip to main content
Glama
guardvibe

guardvibe

by goklab

secure_prompt

Analyzes a raw coding prompt before code generation and returns a structured directive with security requirements for auth, input validation, and secrets. Detects your stack and attack surfaces to prevent vulnerabilities early.

Instructions

Shift-left security at the prompt level: analyze a raw coding prompt BEFORE any code is written and return a structured enhancement directive that embeds GuardVibe security requirements (auth checks, input validation, webhook signature verification, SQL injection prevention, secrets handling) into the prompt you are about to execute. Deterministic — no LLM, no network: triage verdict NO_MOD (prompt already specific and security-aware → proceed with the ORIGINAL prompt unchanged), LIGHT_MOD (inject missing security constraints only), or HEAVY_MOD (also surface clarifying questions — never invent answers to them). Detects stack (Next.js, Supabase, Clerk, Stripe, Prisma, Express, Hono...) and attack surfaces (auth, payments, file upload, user input, SQL, secrets, redirects) from the prompt text, matches them against GuardVibe's rule set, and returns verdict + intent summary + numbered [rule-id] requirements + rewrite directive. Call this with the user's prompt before generating code; prevents vulnerabilities before code generation instead of scanning after. Example: secure_prompt({raw_prompt: 'add login to my app'})

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": {
      "raw_prompt": "<raw_prompt>"
    },
    "name": "secure_prompt"
  }
}

Input Schema

NameRequiredDescriptionDefault
contextNoKnown stack/framework context if the client has it (e.g. 'Next.js app router, Supabase, Stripe')
raw_promptYesThe user's original coding prompt, verbatim

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv3.66.0
    • removedInput schema / additionalProperties
      Removed value: -false
  2. Addedv3.21.0

TDQS

A4.6/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does so well: deterministic, no LLM, no network, plus the three verdicts and what each implies (NO_MOD proceeds unchanged, HEAVY_MOD surfaces but never invents answers). It omits any mention of latency/limits or how rules are configured, which keeps it just short of the top.

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

Conciseness4/5

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

Front-loaded with the core action, then behavior, then example — a logical order with no filler. It is a dense single paragraph, though, and the parenthetical framework/attack-surface lists add bulk that could be tightened.

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

Completeness5/5

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

No output schema exists, and the description compensates by enumerating the return shape (verdict + intent summary + numbered [rule-id] requirements + rewrite directive). Combined with the verdict semantics and detection scope, an agent has everything needed to call and interpret it.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3; the description adds value by showing a concrete example invocation and emphasizing that raw_prompt is the verbatim pre-code prompt to be analyzed, clarifying the intended input beyond the schema's 'verbatim' note.

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?

Opens with a specific verb and resource ('analyze a raw coding prompt BEFORE any code is written') and states the concrete return ('structured enhancement directive'). It explicitly distinguishes itself from the sibling scan/check tools by being pre-generation rather than post-hoc scanning.

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

Usage Guidelines5/5

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

'Call this with the user's prompt before generating code; prevents vulnerabilities before code generation instead of scanning after' names both the trigger and the alternative it replaces. The example call anchors the usage in a concrete scenario.

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