Viberaven

io.github.ohad6kPublished by GitHub account ohad6kv1.7.1Updated Nov 8, 2026

Checks a Vercel + Supabase repo before deploy: RLS, grants, leaked keys, webhooks. Runs locally.

VerifiedSTDIODesktop onlyCloud & InfrastructureDeveloper ToolsSecurity & Monitoring

Overview

AI-generated overview

Local MCP server that scans a Vercel + Supabase repository for launch gaps such as missing RLS, leaked service_role keys and unverified webhooks.

What you can do
  • Run readiness, strict-gate and Vercel/Supabase audits on the repository and read the verdict written to .viberaven artifacts
  • Review and apply guarded heal recipes, get agent-ready fix prompts, and re-verify after a batch of fixes
  • Run an experimental local PGlite permissions matrix for owner, other_user and anon
  • Save, resume, check and report on versioned task contracts with frozen local verification plans
  • Look up npm package names on the public registry and return versioned Supabase provider guidance
  • Install bounded agent rules into CLAUDE.md, AGENTS.md or Cursor rules, and write plan-only cleanup output
When to use it
Useful before launching or handing off an AI-built app on Vercel and Supabase, after a Supabase migration or policy change, or when a production error points at RLS, env vars, the service role key, the database connection or a Stripe webhook. It is a repository check, not a live database test or a full security audit.
Requirements
Runs as a local stdio process via the npm package @viberaven/mcp; Node.js 20 or newer is required. No account, API key or telemetry for local checks. The optional PGlite permissions test needs PGlite installed next to the matching CLI. Live Supabase catalog reads and hosted features need a VibeRaven account and explicit human approval.
Before you install
Heal and init tools write to the repository: viberaven_heal_apply can add a migration enabling RLS with no policies, so browser reads return no rows until policies exist, and yes: true skips confirmation. Gate and status tools rewrite .viberaven artifacts. Live steps require account sign-in, quota or payment and a provider credential stored locally. A clear result is not a security audit.

Installation

In SourceWeft

  1. Open Viberaven in the dashboard and add it to a workspace.
  2. Enable the server for the chats that should use its tools.

Desktop only via STDIO. STDIO servers start a local process, so they need the SourceWeft desktop host.

Other MCP clients

Follow the launch instructions in the repository.

README

[VibeRaven]

VibeRaven

VibeRaven checks AI-built apps on Vercel + Supabase for launch gaps before you ship: tables without RLS, permissive policies such as using (true), service_role keys in client code, anon-callable security definer functions, the wrong pooler port and unverified Stripe webhooks.

Run npx -y [email protected] check in your app's folder. It reads the repository on your machine, needs no account, and names the file and line for each gap.

[Install from npm]   [Try it on viberaven.dev]   [Join the Discord]

[npm version] [npm downloads] [GitHub stars] [MIT license] [skills.sh pack] [Follow on X]

Website · What it checks · When to use it · How it compares · Local Studio · Agent skills · Releases

Quick start

Requires Node.js 20 or newer. From your app's project root:

bash
npx -y [email protected] check
  • In a terminal or CI: npx -y [email protected] check
  • For coding agents: npx -y [email protected] check
  • Windows PowerShell: use npx.cmd if npx is blocked by the execution policy.
  • In a coding agent you can also just ask: "check this with viberaven".

It reads supabase/migrations, your client and server code, package.json and .env.example. It does not connect to your Supabase project or send requests to your app. It exits 1 when it finds a blocker, so it also works as a CI step.

What it checks

FindingGap IDRelated Supabase Security Advisor lint
A public table created in a migration with row level security never enabledrls_disabledrls_disabled_in_public (guide)
A policy with using (true) that lets anyone read or write every rowrls_policy_allows_all_write, rls_policy_allows_all_readnone
The service_role key in a file that ships to the browser, or under a NEXT_PUBLIC_ nameservice_role_key_in_client_code, service_role_key_in_client_envnone
A security definer function in public that no migration closes to anonsecurity_definer_function_executableanon_security_definer_function_executable (guide)
A direct Postgres connection on port 5432 from serverless code, instead of the transaction pooler on 6543pooler_port_mismatchnone
A Stripe webhook handler that never checks the signature over the raw bodyunverified_stripe_webhooknone
Env vars that code reads but .env.example does not list, queries with no row limit, no error monitoringenv_var_drift, unbounded_query, missing_monitoringnone

Two other Security Advisor lints come up often in the same apps. VibeRaven has no rule for them yet, and the guides explain the fix:

For a before-and-after run on one migration, see the missing-RLS example.

Example output

Historical output from viberaven check 1.7.2 on a synthetic Next.js + Supabase app with one of each gap (project path shortened):

text
viberaven check · ~/my-app
🔴 No RLS policy proof in migrations  (rls_disabled)   1 public table without row level security: public.profiles (supabase/migrations/20260301000000_init.sql:1). The Data API does not enforce row restrictions for roles and operations allowed by the table's grants. Verify those grants to determine who can read or change rows.🔴 A policy lets anyone write every row  (rls_policy_allows_all_write)   Policy "orders are editable" on public.orders (supabase/migrations/20260301000000_init.sql:13) lets anyone, signed in or not, update every row, to any values: using (true).🔴 Service role key used in client code  (service_role_key_in_client_code)   app/admin/page.tsx:4: reads NEXT_PUBLIC_SUPABASE_SERVICE_ROLE_KEY. NEXT_PUBLIC_* variables are exposed to client code by Next.js, and the service role key skips RLS entirely. Move the call behind a server route or edge function and rotate the key.🟡 Security definer function callable by the Data API roles  (security_definer_function_executable)   public.grant_credits(uuid, integer) at supabase/migrations/20260301000000_init.sql:15 is security definer, so it runs with its owner's rights and RLS does not limit what it touches. No migration revokes EXECUTE from public, anon, authenticated, so anyone holding the anon key can call it at /rest/v1/rpc/grant_credits. If only the server calls it, add: revoke execute on function public.grant_credits(uuid, integer) from public, anon, authenticated; Fix: revoke execute on function public.grant_credits(uuid, integer) from public, anon, authenticated;🟡 Stripe webhook does not verify the signature  (unverified_stripe_webhook)   1 Stripe webhook handler without signature verification over the raw body: app/api/stripe/webhook/route.ts (no signature check (constructEvent), no stripe-signature header, no raw body). Anyone who finds the URL can post a fake event, for example a paid checkout.🟡 Env vars used in code but missing from .env.example  (env_var_drift)   Code reads 1 environment variable that .env.example does not document (NEXT_PUBLIC_SUPABASE_SERVICE_ROLE_KEY). Fresh clones, CI, and the production deploy can silently run without them.🟡 Database queries with no row limit  (unbounded_query)   1 file run Supabase selects or Prisma findMany with no .limit()/.range()/take bound (app\admin\page.tsx). These work with 50 test rows and melt with 50,000 production rows.⚪ No error monitoring detected  (missing_monitoring)   No Sentry/PostHog (or similar) instrumentation was found. Production errors will only surface when users complain.
Verdict: ❌ 3 blockers, 4 warnings · score 5Fix: viberaven fix · Details: ~/my-app\.viberaven\agent-tasklist.mdOptional live catalog: npx -y [email protected] live start --provider supabase --project <project-ref> --json (read-only metadata; account required; server availability not checked; user approves in the browser and approves the project read).Keep checks running with your agent: npx -y [email protected] init

Every result also lands in .viberaven/ as markdown and JSON (agent-tasklist.md, gate-result.json, context-map.json), so a coding agent and your git history can read it.

When to use it, and when not to

Use it:

  • before you launch or hand off a Vercel + Supabase app built with Lovable, Bolt, Cursor, Claude Code or Codex;
  • after a Supabase migration or a policy change;
  • when a production error points at RLS, the service_role key, env vars, the database connection or a Stripe webhook;
  • on every push or pull request, through the GitHub Action below.

It is not the right tool when:

  • You need to know what is live in the database. VibeRaven is a repository check, not a live database test. It reads migrations, so it cannot see a policy someone added in the Supabase dashboard. Use Supabase Security Advisor for the live project.
  • You need a full security audit. It does not send requests to your app, test for XSS or CSRF, or look up dependency CVEs. A clear result is not a security audit.
  • You need to know the app works. It does not run your build or click through your pages. Use Playwright or your own tests.
  • The app does not use Supabase. Most of the checks have nothing to read.

How it compares

These tools answer different questions, and most launches need more than one of them.

ToolWhat it checksWhere it runsHow it fits with VibeRaven
Supabase Security AdvisorLints on the live database: RLS disabled, security definer views and functions, mutable search_path and moreSupabase dashboard, against the deployed projectAdvisor sees what is live. VibeRaven reads the migrations before they are applied, plus the client code and env files the database never sees.
OWASP ZAPDynamic scan of a running web app over HTTP: injection, XSS, headers, cookiesAgainst a deployed or local URLZAP tests the app from outside. VibeRaven reads the repo and knows Supabase grants, policies and keys.
Semgrep, Snyk, CodeQLGeneral static analysis and dependency vulnerabilities across many languagesCI or locally, on source codeBroad code rules and CVEs. VibeRaven is narrow: Supabase RLS and grants, service_role exposure, the pooler port and Stripe webhooks.
PlaywrightEnd-to-end tests you write, driving a real browserLocally or in CI, against a running appPlaywright proves the flows you test. A test that signs in as user A and tries to read user B's rows is the live check that VibeRaven's RLS findings point to.

Data: 512 public Lovable apps

We ran the check on the Supabase migrations of 512 public Lovable repos. From the write-up:

In a static read of 512 public Lovable projects on GitHub with a supabase/migrations folder (October 2026), 47.3% (242) define at least one security definer function in the public schema that a signed-out caller with the anon key can run at /rest/v1/rpc.

The post has the method, the limits and the fix. An earlier post covers RLS policies in the same 512 apps.

Fix the gaps

bash
npx -y [email protected] fix                         # list gaps with safe automatic recipesnpx -y [email protected] fix --gap <id> --dry-run    # preview one recipenpx -y [email protected] fix --gap <id>              # apply itnpx -y [email protected] audit --vercel-supabase     # RLS in migrations, pooler port, service_role keynpx -y [email protected] --strict                    # the verdict as an exit code for CI (exit 1 on not_clear; warnings exit 0)

The rls_disabled recipe adds a migration that enables RLS without policies, so browser reads return no rows until you add policies. Agree before applying it, then apply and test it through your database workflow.

In CI: the GitHub Action

Lovable and Bolt push straight to main, so a pull request check alone misses most of their changes. The VibeRaven GitHub Action runs the same check on pull requests and on pushes, in your own runner:

yaml
on:  push:    branches: [main]  pull_request:permissions:  contents: write  pull-requests: writejobs:  check:    runs-on: ubuntu-latest    steps:      - uses: actions/checkout@v5        with:          fetch-depth: 0      - uses: ohad6k/viberaven-action@v1

A pull request gets one comment with what the change added or fixed. A push to main gets a commit comment when there is a blocker. It is advice by default; with fail-on-blockers: 'true' the job fails when it finds a blocker, and your branch protection decides what that means for merging. npx -y [email protected] init --github writes a pull-request-only version of this workflow without the Action.

Install for AI agents

Give coding agents the same context before they patch the repo:

bash
npx -y [email protected] init --agents all --dry-run   # previewnpx -y [email protected] init --agents allnpx -y [email protected] doctor --agents

This installs bounded rules (<!-- VIBERAVEN:START --> ... <!-- VIBERAVEN:END -->) into:

  • AGENTS.md, CLAUDE.md, GEMINI.md
  • .cursor/rules/viberaven-core.mdc (plus scoped Supabase, deploy, and payments rules)
  • .github/copilot-instructions.md
  • .viberaven/agent-context.md, .viberaven/mission-map.md

The rules say when a pass helps (an AI-built app on Vercel + Supabase, before launch or handoff, or after a migration or policy change) and teach the loop: check, read .viberaven/, fix one gap, then check again once per batch of fixes. They are advice, not a gate: the user decides when to ship.

Agent skills

Six skills.sh skills route agents through architecture questions, version evidence, and launch proof:

SkillJob
viberavenThe router: local check/fix loop, Studio, and MCP context.
architecture-contextAsk the missing product questions before any edit.
architecture-planTurn answers plus repo evidence into a workstream plan.
what-brokeFind which version broke the app before patching.
production-contextKeep compact production memory in .viberaven/production-context.md.
go-liveLocal app to GitHub to Vercel, with live-URL proof.
bash
npx -y [email protected] add ohad6k/VibeRaven --skill viberaven

See agent-skills/ for the full pack.

This repo also works as an agent plugin: plugin.yaml, .claude-plugin/, .codex-plugin/, and gemini-extension.json expose the six skills plus /viberaven-work, /viberaven-help, /viberaven-production-context, and /viberaven-launch commands to Claude Code, Codex, and Gemini CLI.

For a smaller install, plugins/viberaven is a standalone plugin for Claude Code and Cursor: one skill that says when a pre-launch pass fits a Vercel + Supabase app, plus a version-pinned MCP server. Its manifests specify the package version; the plugin release is separate from the quick start above.

MCP

VibeRaven is listed in the MCP registry for agents that prefer tools over terminal commands:

json
{ "viberaven": { "command": "npx", "args": ["-y", "@viberaven/[email protected]"] } }

Key tools: viberaven_check_readiness (runs the local check), viberaven_heal_apply, viberaven_verify, viberaven_audit, viberaven_gate_result, and viberaven_validate_npm_package (run it before adding npm dependencies).

Provider context for AI SDK agents

Building an agent that answers provider errors? The AI SDK provider-context example adds search_guides and recent_provider_changes from the hosted MCP endpoint. It returns published guidance and dated sources, without installing the VibeRaven CLI or Studio. Its documented tests run locally with a scripted model; live retrieval is optional. It does not inspect your repository or verify a fix.

The local Studio

npx -y [email protected] with no command opens the Studio: a local page where your own coding agent (Claude Code, Codex or Gemini CLI) makes a change in your folder, and you see the steps, your checks, the running app and the diff, with Undo one click away.

[The VibeRaven Studio: the app's providers on the board, one-click starting actions, and the change box with Claude Code]

Your first app change

The same workflow, fully local, with no account:

  1. Open your project. Run npx -y [email protected] in its folder. The Studio opens in your browser.
  2. Connect your agent. Open Agents, select your installed CLI, run Test connection, then choose Use this agent.
  3. Show your app. Choose Show my app to start its development server.
  4. Ask for a small change. Pick Ask to get a plan without edits, or Edit to let the agent change files, then select Make the change.
  5. Check the result. Try the running app, read the check results and open Review for the diff. Missing tests are reported as unchecked; a page that loads does not prove every feature works.

On Windows PowerShell, use npx.cmd if execution policy blocks npx.

The Studio also runs on viberaven.dev: sign in with Google, bring your repo, and connect your computer once. Your agent still works on your computer. The site includes 2 free changes, then Pro at $20 a month for 300 changes a month. Both need a coding agent you are signed in to; its own account and limits apply.

What the Studio gives you
Your agent, your machineClaude Code, Codex or Gemini CLI make the edit in your folder, with a connection test and Ask or Edit access.
Proof next to the changeThe real steps, your project's checks, the running app and the diff, in one place.
Review and UndoRead every changed file. Undo restores attributed Claude Code edits; anything else stays for you to review.
Your app's servicesVercel, Supabase, Stripe, auth, monitoring and analytics on one map, each marked found in the code, chosen, or missing. Repo evidence is never shown as a live provider check.
Versions and releasesCompare release points and see what changed since an earlier version (local Studio).

Checks and accounts

  • Local Studio and repository checks. These run on your machine without a VibeRaven account. The CLI has no telemetry.
  • Changes from viberaven.dev. Sign in with Google. Free includes 2 changes per account; Pro includes 300 a month. Your coding agent's account and usage are separate. The site stores requests, progress, check results, file paths and redacted, size-limited diffs so you can review them.
  • Hosted full checks. Optional: 2 on Free, 50 a month on Pro, separate from changes.
  • Markdown on disk. All context lives in .viberaven/ as plain files that your agent and your git history can read.
  • Evidence over vibes. Findings point at repo evidence. Provider dashboard state is never claimed from repo edits alone.
  • Changes under your control. Review the plan and access mode before the agent edits your project. Cleanup is plan-only. A clear repository check is not a security audit or proof that the deployed app works.

Contributing

Contributions are welcome, and most of them need no private source access:

Resources

License

MIT. Current public release: [email protected].

Built by Ohad Krispin (github.com/ohad6k).

If VibeRaven helps you ship, star the repo so other AI app builders can find it. Use Watch → Custom → Releases for release notifications.

VibeRaven public repo is the agent discovery and installation surface. Product source code and service internals live in a private repository.

Source: README.md at commit b83b4ee

Tools

26

viberaven_check_readiness

Useful before an AI-built app on Vercel and Supabase launches or is handed off. Runs the local `viberaven check` (no login, no API key, no telemetry), which reads the repository for launch gaps (missing RLS in migrations, leaked secrets, unbounded queries, unsigned webhooks) and writes a prioritized task list to .viberaven/agent-tasklist.md plus a verdict to .viberaven/gate-result.json. This is advice, not a gate: the user decides when to ship. It reads repo files and does not query the live database.

Parameterscwd

viberaven_rls_test

After reviewing a Supabase migration or ownership policy, optionally execute already reviewed local permissions scenarios for owner, other_user and anon. Returns Pass, Fail or Unknown per cell with the original scoped evidence. This is an experimental PGlite imitation, not live Supabase proof. The optional PGlite dependency must already be installed next to the matching CLI used by this local MCP host; missing setup returns the CLI setup guidance as a tool error. No SQL, credentials, provider calls or dependency installation are accepted.

Parameterscwdmatrixrequiredmigrations

viberaven_verify

Re-run the local VibeRaven check after you apply fixes. Call this once per batch of fixes (not after every edit) to update .viberaven/gate-result.json and confirm whether the gate moved toward clear.

Parameterscwd

viberaven_audit

Run local Vercel + Supabase production checks: table RLS presence, policy quality, view/function boundaries, service-role boundaries, and Vercel pooler usage. Call this when the project uses Supabase or Vercel and you need a focused infra audit beyond the general readiness check. Pass json: true for machine-readable output.

Parameterscwdjson

viberaven_init_rules

Install bounded VibeRaven agent-instruction rules into native AI instruction files (CLAUDE.md / AGENTS.md / .cursor/rules), so coding agents know when a VibeRaven pass applies. Use dryRun: true to preview first.

ParameterscwdagentsdryRun

viberaven_clean_plan

Write a non-destructive cleanup plan for generated .viberaven artifacts and logs. Call this when the .viberaven directory has grown stale. Does not delete anything; it only produces a reviewable plan.

Parameterscwd

viberaven_strict_gate

Run `viberaven --strict --json` and return the verdict from .viberaven/gate-result.json (gate.status is clear, warning or not_clear). Useful before a deploy or CI run when the user wants the verdict as JSON. The user decides whether to ship.

Parameterscwd

viberaven_gate_result

Run a fresh local scan (`viberaven --json`) and return the verdict it writes to .viberaven/gate-result.json (gate.status is clear, warning or not_clear). It rewrites the .viberaven artifacts; it does not read an older result without scanning.

Parameterscwd

viberaven_context_map

Refresh and return .viberaven/context-map.json, a compact summary of the last scan for the next agent step. Use this to load minimal context before acting on a gap.

Parameterscwd

viberaven_actions

Read the current chat-native action surface from .viberaven/actions.json. Use this to list stable, referenceable action IDs the user can verify or refer to by name.

Parameterscwd

viberaven_verify_action

Verify or explain the lifecycle state of a stable VibeRaven action ID (format VR-A<number>). Use this when the user references a specific action and you need its current state.

ParameterscwdactionIdrequired

viberaven_heal_plan

Write a non-destructive heal plan (.viberaven/heal-plan.md) for a specific gap or target file, to review before viberaven_heal_apply. The plan names the target and the verify command. For rls_disabled it also shows the new migration it would write and its SQL, or why it will not write one; other gaps get no patch preview. Does not modify source files.

Parameterscwdgapyestarget

viberaven_heal_prompt

Return an agent-ready prompt that fixes a specific gap. Use this when you want a coding agent to apply the fix itself rather than using the guarded recipe.

Parameterscwdgapyestarget

viberaven_heal_apply

Apply a guarded repo-code heal recipe for a supported gap. Only call this after viberaven_heal_plan. Pass yes: true to skip confirmation. The rls_disabled recipe writes a migration that enables row level security with no policies, so browser reads of those tables return no rows until policies exist: call it only after the user agrees. Its task leaves out yes: true; pass yes: true only once the user agrees. Returns the applied change summary, with any warnings.

Parameterscwdgapyestarget

viberaven_validate_npm_package

Look up npm package names on the public registry (registry.npmjs.org). Returns not_found when the registry has no such package or cannot be reached, suspicious when the registry answers with an error other than 404, and suspicious when the package was first published less than 14 days ago and its name is within 2 character edits of a popular package (a typosquat signal), or when it has an empty description, no listed maintainers and 3 or fewer published versions. Anything else is ok, which only means none of these signals fired; it is not a security review of the package. Useful when an agent is about to add a dependency the project has not used before.

ParameterspackageNamepackageNames

viberaven_work_start

Save a versioned Task contract and run a free local check without login, network, edits or payment. Prefer contract; request alone saves a draft with unknown acceptance. No credentials or shell command fields. Review the returned contract before approving resume. Resume shares its short request and redacted results with the account; the full definition stays local. Provider and non-local contracts are planning only.

Parametersclirequiredcwdaccessrequiredrequestcontract

viberaven_work_resume

Resume the SAME saved task through account sign-in, quota or payment. Set approvedContract=true only after explicit human approval of its exact acceptance, must-not-break conditions and declared scope. A draft can be upgraded with contract before any job exists; its request must stay identical. Never authorize sign-in or payment for the person. Execution state is separate from independent verification observations; agent success is not condition proof. Scope declarations are not an enforced sandbox.

ParameterscwdtaskIdrequiredcontractapprovedContract

viberaven_work_status

Read the saved Task contract, execution state and independent verification receipts locally without account, network, edits or payment. Current worktree changes invalidate checked proof; missing observations stay not_checked. Checked conditions separately report passed/failed outcomes. Historical agent results do not verify conditions.

ParameterscwdtaskIdrequired

viberaven_work_prepare

Before implementing a local Node feature, freeze reviewed expected behavior and actual dirty/untracked baseline. Supports module comparisons, sequential HTTP requests to an isolated local server factory, and frozen Node preservation tests. No login or network; no commands or imported proof. MCP plans are limited to 4800 UTF-8 bytes; larger plans use the CLI JSON file (65536 bytes). No browser, database or live provider proof. Changed plans require a new task.

ParameterscwdtaskIdrequiredverificationrequired

viberaven_work_verify

Run or resume the SAME frozen plan using the locally available pinned Docker image only. Set approvedVerification=true only after human review/approval. Network is disabled and no dependencies are installed. No login or billing. Missing conditions, dependencies or Docker remain not_checked; completed receipts are reused for the identical candidate. Coding-agent success is not proof.

ParameterscwdtaskIdrequiredapprovedVerificationrequired

viberaven_work_report

Export a bounded local draft proof report with Markdown from current integrity-checked verification receipts. Read-only: no login, network, Docker, agent or GitHub execution. Failed and unknown evidence remain explicit; agent success is not proof. Not authoritative CI or a completed live PR pilot. Review redacted text before sharing; redaction is not a complete secret scanner.

ParameterscwdtaskIdrequired

provider_playbook

Get a provider playbook

Plan setup and integration before implementing a feature that touches a provider. Returns versioned setup guidance, gotchas, dated changes, integration seams, existing repo checks and planned live checks with official sources. Available packs: supabase. Limits: guidance only; does not connect to providers, read your project, run checks or verify that a feature works.

Parametersproviderrequired

viberaven_live_start

Local candidate feature: save a scoped metadata-verification request without provider reads or payment. Supabase catalog reads require a VibeRaven account and explicit human consent on resume. Vercel is deliberately blocked before network access. Local repository checks stay free without an account. Never pass credentials as tool arguments.

ParameterscwdteamIdschemasproviderrequiredprojectRefrequired

viberaven_live_resume

Local candidate feature: resume the SAME saved live step through account connection, allowance and metadata verification. Set approvedRead=true only after the person explicitly approves the named Supabase project/schema catalog read. Show any returned action URL and wait for the person; never approve sign-in or payment for them. Credentials stay local and are never tool arguments. Vercel stays blocked; local checks stay free.

ParameterscwdstepIdrequiredapprovedRead

viberaven_live_status

Local candidate feature: read the saved live-step receipt without provider reads, payment or another live-step charge. Evidence is historical and scoped, not proof of application security. Local checks stay free.

ParameterscwdstepIdrequired

viberaven_live_disconnect

Local candidate feature: disconnect the saved live step and remove its locally retained provider credential and evidence. Does not alter provider settings or unrelated MCP credentials. Unfinished account reservations expire. Local checks stay free.

ParameterscwdstepIdrequired

Version history

10
  1. v1.7.1LatestOct 30, 2026
  2. v1.6.12Oct 29, 2026
  3. v1.6.7Oct 9, 2026
  4. v1.6.6Oct 7, 2026
  5. v1.6.5Oct 6, 2026
  6. v1.6.4Oct 5, 2026
  7. v1.5.3Sep 30, 2026
  8. v1.5.2Sep 28, 2026
  9. v1.5.1Sep 27, 2026
  10. v1.0.7Sep 16, 2026

Score

80% of the applicable checks met

How complete this listing is, computed from the registry entry, the endpoint and public sources. Not a rating of the server and not a statement that it is safe or working today: reachability is a dated check, and no installs or reviews go into the score.

  • Reached in the last 30 days25 pts
  • Auth declared10 pts

    Declare the credential headers in the registry entry, or keep the endpoint answering the probe so its auth can be classified.

  • Tools listedRequired15 pts
  • DescriptionRequired15 pts
  • Logo10 pts
  • Documentation15 pts
  • License10 pts

    Declare a license in the repository or the registry entry.