Skip to main content
Glama
goklab

guardvibe

secure_prompt

Analyze a coding prompt for security gaps before code generation. Returns a structured directive with required security constraints based on detected stack and attack surfaces.

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'})

Input Schema

TableJSON 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
Behavior5/5

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

With no annotations, the description fully details behavioral traits: deterministic, no LLM, no network, triage verdicts, detection of stack and attack surfaces, matching against GuardVibe rule set, and output contents. It also clarifies that it never invents answers.

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?

The description is front-loaded with purpose and structured with specific details. It is moderately concise; each sentence adds value, though it could be slightly shorter.

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?

Despite no output schema, the description thoroughly explains the return structure (verdict, intent, numbered requirements, rewrite directive) and behavior. It is complete for an agent to understand invocation and expected results.

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 100%, so baseline is 3. The description adds context (e.g., 'verbatim' for raw_prompt, 'if the client has it' for context) and an example, but this does not significantly extend beyond the schema descriptions.

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 clearly states the tool's action (analyze a raw coding prompt), the resource (prompt), and the outcome (structured enhancement directive). It distinguishes itself from sibling tools by focusing on pre-code generation security, with specific verdicts NO_MOD, LIGHT_MOD, HEAVY_MOD.

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?

The description explicitly instructs to 'Call this with the user's prompt before generating code' and contrasts with post-generation scanning. It provides an example but lacks explicit statements about when not to use it, though the context of sibling tools implies alternatives.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/goklab/guardvibe'

If you have feedback or need assistance with the MCP directory API, please join our Discord server