Skip to main content
Glama

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
PERSONA_CONSTITUTION_PATHNoAbsolute path to an alternative CONSTITUTION.md. Defaults to <repo>/data/CONSTITUTION.md.<repo>/data/CONSTITUTION.md

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
{}

Tools

Functions exposed to the LLM to take actions

NameDescription
get_constitutionA

Retrieve the Agentic Engineering Persona constitution (v3.0.0) that governs all programming and software development work: SWEBOK v4.0, NASA Power of 10, Zero Framework Tolerance. Call with no arguments for the table of contents plus the Supreme Law; pass section for a specific part or 'full' for the whole document.

get_knowledge_areaA

Retrieve one of the 18 SWEBOK v4.0 Knowledge Areas (KA-01 Requirements through KA-18 Engineering Foundations) including its LLM operational discipline. Pass ka as a number 1-18 or a name (e.g. 'Software Security'). Omit ka to list all 18.

get_power_of_10A

Retrieve NASA/JPL Power of 10 rules (Holzmann 2006) with the persona's code-level, architecture-level, and organisational-level applications. Pass rule (1-10) for one rule, or omit for all ten.

get_verification_gatesA

Retrieve the five pre-emission verification gates (G1 Executability, G2 Completeness, G3 Correctness, G4 Dependency Honesty, G5 Problem Fit) and the prohibited-marker checklist. Run these gates before delivering any code output.

scan_code_for_violationsA

Statically scan code for Zero-Framework-Tolerance violations: TODO/FIXME markers, stub bodies (pass, ellipsis, NotImplementedError, unimplemented macros, panic stubs), empty function and catch bodies across Python, JavaScript, TypeScript, Java, Go and Rust, scaffold deception phrases ('rest of the implementation', 'omitted for brevity'), and iteration-deferral phrases ('left as an exercise', 'you can extend this'). Backed by the CodebaseCSI forensic detector plus Constitution prose rules; Python input additionally gets AST analysis so abstract stubs (Protocol/ABC/@abstractmethod) and markers inside string literals are not falsely flagged. Returns a JSON verdict (PASS/REVIEW/FAIL) with line-numbered findings. Use before delivering generated code. A PASS is necessary but not sufficient - still run gates G1-G5.

review_patchA

Review a unified diff (git diff / gh pr diff output) against the Zero-Framework-Tolerance rules. Every changed code file is scanned with the full engine union (CodebaseCSI, constitution prose rules, Python AST, tree-sitter xast) and findings are attributed to the lines the change introduces; pre-existing debt in touched files is counted separately and never fails the gate. Supply files (path -> full new-version content) for full-fidelity AST analysis; without it, added lines are scanned as fragments. Returns JSON: verdict (FAIL/REVIEW/PASS), per-file findings with new-file line numbers, totals, and the engines that ran. Deterministic and offline: fetch the diff yourself (e.g. gh pr diff) and post reviews yourself. A PASS gates nothing but markers - gates G1-G5 remain the reviewer's responsibility.

verify_dependenciesA

Verify that every external dependency introduced by code or a diff actually exists on its public registry - the mechanical half of gate G4 (Dependency Honesty). LLMs hallucinate package names and attackers register them (slopsquatting), so a missing registry entry is both an incompleteness defect and a supply-chain risk. Extracts imports (Python via AST incl. importlib/import literals; JS/TS via import/require specifiers), classifies stdlib/Node built-ins/first-party-in-diff/excluded locally, then checks the rest against PyPI (PEP 503) and the npm registry. NETWORK NOTICE: this is the only tool here that touches the network - package names and nothing else are sent over HTTPS, bounded (50 packages/call, 10s timeout, 3 attempts). Verdicts: FAIL = something does not exist (hallucinated/misspelled); REVIEW = unverifiable (offline/registry errors - never silently passed); PASS = everything resolves. Existence only: version pinning and integrity stay with the reviewer.

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A4/5.0

Scored across 7 tools

Disambiguation4/5

The three verification tools (verify_dependencies, scan_code_for_violations, review_patch) target clearly different inputs — package manifests, standalone code, and a diff — and the retrieval tools map to distinct documents. There is mild overlap since get_constitution can return everything that get_knowledge_area, get_power_of_10, and get_verification_gates offer separately, and review_patch subsumes scan_code_for_violations for changed lines, but the descriptions make the boundaries workable.

Naming Consistency4/5

Names are readable and use consistent snake_case. Four retrieval tools form a clean get_* family, but the three action tools switch to verify_/scan_/review_ prefixes, which is a mild convention split though still sensible verb_noun naming.

Tool Count5/5

Seven tools is well-scoped for a governance persona: four document retrievers plus three verification actions. Each tool clearly earns its place with no filler.

Completeness4/5

The surface covers the constitution's content areas (SWEBOK KAs, Power of 10, gates) and the mechanical verification half of gate G4 plus Zero-Framework-Tolerance scanning for both files and diffs. Gates G1, G2, G3, and G5 have no tool support and are explicitly deferred to the reviewer, a minor but acknowledged gap.

Maintenance

ActivitySlowing
ResponsivenessNo issues