Skip to main content
Glama

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
VERIFICATE_TOKENNoYour Verificate API token. Without this, introspection still works but tool calls return instructions for getting a trial token.

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

CapabilityDetails
tools
{
  "listChanged": true
}
prompts
{
  "listChanged": true
}
resources
{
  "listChanged": true
}

Tools

Functions exposed to the LLM to take actions

NameDescription
validate_ai_outputA

The merge gate for AI-written CODE: returns a binary approve/reject verdict with veto power — e.g. it rejects code calling the nonexistent stripe.Inventory API, or an N+1 loop with the latency arithmetic to prove it. Deterministic reality gates (mock/placeholder veto, gaming and bypass detection, invented-API checks) run first and cannot be overridden; a frontier-model review (ISO/IEC 25010) then scores performance, scalability, reliability and tech debt. Read-only: the code is analyzed, never executed. Call it on every AI-generated diff before accepting it; use validate_plan for plans, analyze_code for an advisory report without a verdict.

validate_planA

The gate for PLANS, designs and specs — run BEFORE any code is written, the cheapest place to catch a bad design. Returns the same binary verdict shape as validate_ai_output, with findings on completeness, feasibility, performance and scalability implications, security risks and missing considerations (e.g. it rejects a plan that polls an API every 100ms per client, with the request-volume math). Read-only: nothing is executed or stored beyond the verdict. Use validate_ai_output for the code that follows.

analyze_codeA

Advisory deep-dive on existing code — scores and findings, deliberately NO pass/fail verdict, so it never blocks an agent. Surfaces performance hot paths, scalability cliffs, reliability gaps and tech debt with concrete latency/throughput arithmetic (e.g. 'O(n²) dedup: ~4s at 10k items'). Read-only: the code is analyzed, never executed. Use it to understand a validate_ai_output rejection or review inherited code; use validate_ai_output when you need an accept/reject decision.

generate_codeA

Generate code and gate it in one step: an LLM writes the implementation, then the same protection engine as validate_ai_output vets it — retrying generation when the gate rejects. If every attempt is vetoed you still receive the last attempt, clearly marked validated:false with the gate findings — rejected code is never presented as clean. Generation runs on our infrastructure; nothing executes in your environment.

Prompts

Interactive templates invoked by user choice

NameDescription
gate_my_changesRun the Verificate merge gate on code and loop until it is approved: validate, fix every finding, re-validate.
review_my_planGate an implementation plan before any code is written: validate it, address every finding, re-validate.

Resources

Contextual data attached and managed by the client

NameDescription
The 17 protection gatesWhat each deterministic gate watches for, and why a veto cannot be overridden.
Example rejection verdictA verbatim REJECTED 30.8/100 verdict from the production gateway.

TDQS

A4.7/5.0

Scored across 4 tools

Disambiguation5/5

Each tool targets a distinct artifact and action: validate_plan is for design specs, validate_ai_output is for code verification, analyze_code is advisory without a verdict, and generate_code is generation with built-in validation. Even the overlapping gate logic in validate_ai_output and generate_code is clearly differentiated by purpose, leaving no ambiguity.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern using lowercase and underscores: validate_*, analyze_code, generate_code. The verbs clearly indicate the action (validate, analyze, generate) and the objects specify the target, making the naming predictable and scannable.

Tool Count5/5

Four tools is an ideal size for this server's purpose—covering validation, analysis, and generation without unnecessary bloat. Each tool earns its place in the workflow, and the count is well within the 3-15 range for a focused server.

Completeness5/5

The server covers the full verification lifecycle: plan validation before code, code validation for AI-generated diffs, advisory analysis for existing code, and generation with built-in gating. There are no obvious missing operations or dead ends—the tools form a complete pipeline.

Maintenance

ActivityMaintained
ResponsivenessNo issues