Skip to main content
Glama
Sign In
guardvibe

guardvibe

by goklab
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

get_security_docs

Look up security best practices and remediation guidance for a given topic, framework, or vulnerability type, returning actionable code examples for secure coding and hardening.

Instructions

Get security best practices and remediation guidance for a specific topic, framework, or vulnerability type. Covers OWASP Top 10, framework-specific hardening (Next.js, Supabase, Stripe), and secure coding patterns. Returns actionable guidance with code examples.

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": {
      "topic": "<topic>"
    },
    "name": "get_security_docs"
  }
}

Input Schema

NameRequiredDescriptionDefault
topicYesSecurity topic to look up (e.g. "express authentication", "sql injection prevention", "nextjs csrf", "react xss", "owasp top 10")

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv3.66.0
    • removedInput schema / additionalProperties
      Removed value: -false
  2. Addedv3.35.1
  3. Removedv3.30.0
  4. First observedv0.1.0

TDQS

A3.8/5.0
Behavior3/5

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

No annotations exist, so the description carries the full burden. It does disclose the return shape ('Returns actionable guidance with code examples'), which is valuable, but it never clarifies that this is a static knowledge-base lookup rather than an inspection of the caller's repository — a materially ambiguous point given fifteen scan_* siblings that do operate on code.

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?

Three short sentences, generously front-loaded with the purpose and coverage scope before the return-value note. No filler and no redundancy with the schema.

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?

For a single-parameter reference lookup with no output schema and no annotations, this covers the what, the topical breadth, and the response format. The one real gap is whether the answer considers the caller's actual codebase or is purely generic reference material.

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% and the single 'topic' parameter already carries a strong enumerated example list, so the schema does the heavy lifting. The description broadens the framing to 'topic, framework, or vulnerability type,' which adds a little taxonomic guidance but no syntax, casing, or granularity advice beyond the examples.

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?

States a specific verb ('Get') and resource ('security best practices and remediation guidance'), then enumerates the exact scope: OWASP Top 10, framework-specific hardening for Next.js/Supabase/Stripe, and secure coding patterns. Against a sibling set dominated by scan_*/check_*/audit_* tools, this reads unmistakably as a static reference lookup rather than a scanner.

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 description implies the usage context ('for a specific topic, framework, or vulnerability type') but never states when to prefer it over near-neighbors like explain_remediation or remediation_plan, which plausibly overlap on remediation guidance. An agent can infer this is the lookup step, but no explicit routing rule or exclusion is given.

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