Skip to main content
Glama
BilalUchiha

vibecheck

by BilalUchiha
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
TYPESAFE_API_KEYNoYour Jev API key from console.typesafe.ai. If not provided, vibecheck falls back to a built-in offline heuristic judge.

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
}

Tools

Functions exposed to the LLM to take actions

NameDescription
submit_for_reviewA

Call this when you believe a task is complete, before telling the user you are finished.

An external judge (TypeSafe AI's Jev decision model) scores the change against eight dimensions and returns a verdict. If the verdict is needs_fixes, address every item in feedback in order and call this tool again. If it is max_retries_exceeded, stop: report to the user that the change did not pass review, and list the outstanding issues.

The review is performed against git's view of the repository when project_root is a git repository, so the change set does not depend on this argument being complete.

configure_projectB

Write or update .vibecheck.json in the project root.

Use preset to select a baseline posture - lenient for prototypes and spikes, balanced (default) for everyday application code, strict for production services and libraries - then override individual dimensions as needed. Thresholds are normalised 0-1 where 1 is always good. For the graded dimensions (readability, error_handling_present, test_coverage_adequate) the raw scale has four levels, so 0.33 means 'level 1 of 3' and 0.67 means 'level 2 of 3'. Judge credentials are never stored here: the API key is read from the server's environment.

get_review_logA

Return recent reviews and verdicts for a project, so you can see why an agent looped or what was still failing at the end. Each entry records the attempt number, the verdict, every dimension score, which gates fired, and which judge produced the verdict. Reading the log never consumes a retry.

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4/5.0

Scored across 3 tools

Disambiguation5/5

Each tool has a distinct purpose: configure_project handles setup, submit_for_review performs the review, and get_review_log retrieves historical results. There is no overlap or ambiguity between them.

Naming Consistency5/5

All three tool names follow a consistent verb_noun pattern: configure_project, submit_for_review, get_review_log. This creates a predictable and clear naming convention.

Tool Count4/5

Three tools is slightly on the lower end but appropriate for the server's narrow scope of code review configuration and execution. Each tool covers a necessary step without redundancy.

Completeness4/5

The tool surface covers the core lifecycle: configuration, submission, and log retrieval. Minor gaps exist, such as no explicit way to read the current configuration or delete it, but these do not hinder the primary workflow.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Resources