Skip to main content
Glama
Sign In
guardvibe

guardvibe

by goklab
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

secure_this

Scan code, apply only fixes that verifiably resolve vulnerabilities, roll back edits that fail or introduce issues, and return verified code plus a definition-of-done gate.

Instructions

Close the loop on vulnerabilities in code: scan, apply only the fixes that VERIFIABLY land (each candidate edit is re-scanned and rolled back if it fails to resolve the issue or introduces a new one), and return the verified code plus a definition-of-done gate. Prefer this over fix_code+verify_fix when you want a guarantee the fix landed — not just a suggestion. Returns { status: clean|secured|partial|no_autofix, fixedCode, applied[], remaining[], definitionOfDone:{passed,message}, proofTest }. Write fixedCode to disk, then require definitionOfDone.passed before claiming the task complete; anything in remaining[] needs a manual fix. When fixes were applied, proofTest is a runnable regression test (GuardVibe-as-oracle) you can drop into the project to guard against regressions. Example: secure_this({code: '...', language: 'typescript'})

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": {
      "code": "<code>",
      "language": "<language>"
    },
    "name": "secure_this"
  }
}

Input Schema

NameRequiredDescriptionDefault
codeYesThe code to scan and secure
filePathNoFile path for context-aware analysis (the file is NOT written; apply fixedCode yourself)
languageYesProgramming language of the code
frameworkNoFramework context (e.g. express, nextjs, react)

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

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

No annotations exist, so the description carries the full burden, and it does: it discloses that candidate edits are re-scanned and rolled back if they don't resolve the issue or introduce a new one, that the tool does not write files itself, and what the response contains. It also defines the status vocabulary (clean|secured|partial|no_autofix) and the meaning of remaining[] and proofTest, which are exactly the behaviors an agent could not infer.

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 core purpose and the alternative-route are front-loaded, then return shape, then required workflow, then an example — a sensible ordering. It is dense but slightly overstuffed: the return shape and the 'write fixedCode to disk' instruction overlap, and the example adds little given a 100%-covered schema.

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?

There is no output schema, so the description must describe the return payload, and it does in detail: status enum, fixedCode, applied[], remaining[], definitionOfDone, proofTest. Combined with rollback semantics and the disk-write convention, an agent has everything needed to invoke and act on 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 description coverage is 100%, so both required parameters and the two optional ones are already documented; the description adds only an example call with code and language. It does not explain how framework or filePath change analysis behavior beyond what the schema states, so this sits at the baseline appropriate when the schema does the heavy lifting.

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 opens with a specific verb chain (scan, apply verified fixes, return verified code plus a definition-of-done gate) applied to a concrete resource: vulnerabilities in code. It explicitly names the sibling combination it supersedes (fix_code+verify_fix), so an agent can distinguish it without opening any schema.

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?

It gives an explicit selection rule — 'Prefer this over fix_code+verify_fix when you want a guarantee the fix landed — not just a suggestion' — plus a post-call workflow: write fixedCode to disk, gate completion on definitionOfDone.passed, and treat remaining[] as manual work. When-to-use, when-to-prefer-an-alternative, and what to do next are all stated.

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