What can you do with this server?

This server is an MCP bridge to Verlon AI, exposing read-only tools for inspecting gates, logs, recommendations, and experiments — plus an optional write tool to switch a gate's model when enabled. * List gates (list_gates): Get a summary of every gate in the account (id, name, description, model, task type, creation date). * Get gate details (get_gate): Fetch a specific gate's full configuration by UUID, including fallback chain, spending limits, sub-gates, and orchestration. * List request logs (list_logs): View recent request logs with filters for gate, time (since), success/failure, and result limit; each entry includes timestamp, model, cost, latency, and request id. * Get recommendations (get_recommendations): Retrieve Cortex's intelligence report for a gate — observed themes, drift detection, and optimization suggestions (returns null if no traffic yet). * List experiments (list_experiments): See shadow and split tests, filterable by gate, status, or project; includes variants, goal metric, and configuration. * Switch model (switch_model, only when started with --enable-writes): Change which model a gate routes to (by gate id, or the default Claude Code connector gate if omitted).

How do I use @verlon-ai/mcp?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@@verlon-ai/mcp show my gates" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

@verlon-ai/mcp

Official

by verlon-ai

Overview Schema Source Related Servers Discussions Admin

TypeScript

Remote

@verlon-ai/mcp

npm version license

Model Context Protocol server for Verlon AI. Exposes your Verlon resources (gates, logs, recommendations, experiments) as MCP tools so coding agents — Claude Code, Cursor, Cline, any MCP-compatible client — can inspect and manage your AI infrastructure natively.

Status: 0.4.0 — listed in the MCP Registry as ai.verlon/mcp. Ships 6 read-only tools (list_gates, get_gate, list_logs, get_recommendations, list_experiments, list_models) plus one write tool, switch_model, registered only with --enable-writes. The broader write surface (create_gate, update_gate, run_chat, start_experiment) lands in a future release behind the same flag.

Install

You don't install it directly. Your MCP client (Claude Code, Cursor, etc.) spawns it as a subprocess via npx. Add the snippet below to your client's MCP config.

Claude Code

Add to ~/Library/Application Support/Claude/claude_desktop_config.json (macOS) or the equivalent on your OS:

{
  "mcpServers": {
    "verlon": {
      "command": "npx",
      "args": ["-y", "@verlon-ai/mcp"],
      "env": {
        "VERLON_API_KEY": "sk-vrln-..."
      }
    }
  }
}

Then restart Claude Code. The verlon server should appear in the tools list, and Claude can call verlon:list_gates against your account.

Cursor

Add to your Cursor MCP config (Settings → Features → MCP Servers):

{
  "mcpServers": {
    "verlon": {
      "command": "npx",
      "args": ["-y", "@verlon-ai/mcp"],
      "env": {
        "VERLON_API_KEY": "sk-vrln-..."
      }
    }
  }
}

Any other MCP-compatible client

The server speaks MCP over stdio. Spawn npx -y @verlon-ai/mcp with VERLON_API_KEY in the subprocess environment.

Related MCP server: MCP Toolkit Server

Tools

The default tool set is read-only — see Security note for the rationale. Write tools register only when the server starts with --enable-writes.

Tool	Inputs	What it returns
`list_gates`	none	Every gate in the account — id, name, description, model, taskType, taskSubtype, createdAt
`get_gate`	`gateId` (UUID)	Full gate config — model, fallback chain, task type, spending limits, sub-gates, orchestration
`list_logs`	`gate?`, `since?` (ISO 8601), `success?`, `limit?` (1-100, default 20)	Recent request logs — timestamp, gate, model, cost, latency, success/failure
`get_recommendations`	`gateId` (UUID)	Cortex intelligence report — themes, drift detection, optimization recommendations. `{ report: null }` when no run has been produced yet
`list_experiments`	`gateId?`, `status?`, `projectId?`	Experiments (shadow + split) — id, name, status, test type, variants, goal metric, configuration
`list_models`	`provider?` (`openai`, `anthropic`, `google`, `mistral`, …)	Chat models a gate can route to, with live pricing (USD per 1M tokens) and capability scores

Write tools (`--enable-writes` only)

Tool	Inputs	What it does
`switch_model`	`model` (id from `list_models`), `gateId?`	Switches which model a coding gate routes to. Takes effect on the next turn of any running session, no restart. With `gateId` omitted, targets the account's Claude Code connector gate. Idempotent; the change is one reversible field.

Configuration

Env var	Required	Default	Notes
`VERLON_API_KEY`	Yes	—	Your Verlon API key (`sk-vrln-...`).
`VERLON_BASE_URL`	No	`https://api.verlon.ai`	Override for self-hosted Verlon.

CLI flags

Flag	Purpose
`--enable-writes`	Register write-capable tools (`switch_model` today). Default is read-only — a misaligned agent can't accidentally destroy resources.
`--help`, `-h`	Print usage.

Security note

Read-only by default is a deliberate choice. The MCP client (Claude Code, Cursor, etc.) sees this server's tools and may invoke them autonomously when a user's request makes them seem relevant. A read-only default means even a misaligned agent can only inspect your account, not modify it. Opt in to write tools (--enable-writes) only after you understand the implications. The only write tool today is switch_model, deliberately the narrowest possible first write: one reversible field on one gate. Creating, updating, or deleting resources is not yet exposed.

Development

npm install
npm test          # vitest
npm run build     # tsc → dist/

Publishing (maintainers)

The package is dual-published: to npm as @verlon-ai/mcp (automated, with provenance), and to the MCP Registry as ai.verlon/mcp (manual). The registry validates that the npm version exists before accepting a publish, so npm always goes first.

Per-release flow

Bump versions in lockstep across three files — CI fails on drift:

File	Field
`package.json`	`version`
`server.json`	`version` AND `packages[0].version`
`src/server.ts`	`VERLON_MCP_VERSION` constant

Then:

# 1. Merge the bump to main (CI enforces the lockstep), then tag:
git tag v0.4.1 && git push origin v0.4.1
# The publish workflow runs `npm publish --provenance` automatically.

# Wait ~30s for npm CDN; verify:
npm view @verlon-ai/mcp version   # should print the new version

# 2. MCP Registry publish (manual — needs mcp-publisher + DNS-verified ai.verlon namespace)
npm run publish:mcp

One-time setup (registry publishing)

# Install the MCP Registry publisher (NOT npm — it's a prebuilt binary)
brew install mcp-publisher

# DNS-verify the verlon.ai domain (required to publish under the ai.verlon namespace)
mcp-publisher login --help   # follow the DNS verification flow it prints
# Add the TXT record on verlon.ai; verify with `dig TXT verlon.ai +short`

Verification

# All three versions match?
npm view @verlon-ai/mcp version
jq -r .packages[0].version server.json
grep VERLON_MCP_VERSION src/server.ts

# Registry listing live?
curl 'https://registry.modelcontextprotocol.io/v0/servers?search=verlon' | jq

# End-to-end smoke against the published artifact
VERLON_API_KEY=sk-vrln-... npx @modelcontextprotocol/inspector npx -y @verlon-ai/mcp

License

MIT — see LICENSE.

Available Tools

5 tools

get_gateGet Verlon GateA

Read-only

Fetch the full configuration of a specific Verlon AI gate by its UUID. Returns model, fallback chain, task type, spending limits, sub-gates, and orchestration settings as JSON. Read-only.

ParametersJSON Schema

Name	Required	Description	Default
`gateId`	Yes

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true, so the agent knows it's a safe read. The description adds the specific return fields ('model, fallback chain, task type, spending limits, sub-gates, and orchestration settings as JSON'), providing valuable context beyond annotations. No contradictions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences: first states the core action, second lists the return value. No wasted words, front-loaded with the purpose. It is appropriately sized for a simple tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (one parameter, no output schema, sibling context), the description covers purpose, return format, and read-only nature. It is complete for an AI agent to decide to use this tool, though it could mention that the gate must exist or any error scenarios.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has only gateId (string, required) with no description (0% coverage). The description adds that it is a UUID, which gives meaning beyond the bare schema. However, it could be more precise (e.g., 'UUID of the gate as returned by list_gates').

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 clearly states 'Fetch the full configuration of a specific Verlon AI gate by its UUID.' This specifies the verb (Fetch), resource (configuration of a Verlon AI gate), and scope (specific gate by UUID). It distinguishes from sibling tools like list_gates (which lists all gates without full config) and get_recommendations (different functionality).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage context: use when you need the full configuration of a specific gate, identified by its UUID. It does not explicitly provide 'when not to use' or name alternatives, but the context is clear, and siblings like list_gates are naturally differentiated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_recommendationsGet Verlon Gate RecommendationsA

Read-only

Fetch Cortex's intelligence report for a specific Verlon AI gate: themes observed in recent sessions, drift detection, and actionable optimization recommendations. Returns { report: null } when no run has been produced yet (typically a brand-new gate with no traffic). Read-only.

ParametersJSON Schema

Name	Required	Description	Default
`gateId`	Yes

TDQS

A4/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true, and the description reinforces 'Read-only'. It adds transparency about the null-report behavior and the nature of the data (themes, drift, recommendations), which goes beyond the annotation without contradicting it.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences front-load critical information: purpose with details, edge case (null report), and read-only nature. Every sentence adds value without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple read tool with one parameter and no output schema, the description covers the action, return content categories, and the null edge case. It does not detail error conditions or output structure, but the provided information is sufficient for basic usage.

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?

With 0% schema description coverage, the description compensates by indicating the gateId identifies 'a specific Verlon AI gate'. This adds meaningful context to the parameter, though it does not specify its format or source.

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 clearly states the action ('Fetch'), the resource ('Cortex's intelligence report for a specific Verlon AI gate'), and the report contents (themes, drift, recommendations). It distinguishes from sibling tools like 'get_gate' which returns basic gate info, not report data.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains the null return case for brand-new gates, which helps the agent handle that scenario. However, it does not explicitly specify when to use this tool over alternatives like 'get_gate' or 'list_experiments', leaving usage guidance implicit.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_experimentsList Verlon ExperimentsA

Read-only

List experiments (shadow + split tests) in the authenticated Verlon AI account. Optional filters: gateId (restrict to one gate), status (e.g. running, completed, draft), projectId. Returns each experiment's id, name, status, test type, variants, goal metric, and configuration as JSON. Read-only.

ParametersJSON Schema

Name	Required	Description	Default
`gateId`	No
`status`	No
`projectId`	No

TDQS

A4.3/5.0

Behavior4/5

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

Discloses read-only nature (consistent with readOnlyHint), authentication requirement, and return field details (id, name, status, etc.), adding value beyond annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences: first states core purpose, second covers filters and output. No extraneous content.

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?

Covers all necessary aspects: purpose, optional filters, return fields, read-only nature, authentication. Completeness is high for a list tool with no output schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

All three parameters (gateId, status, projectId) are explained with their filtering roles despite 0% schema coverage. Examples for status (e.g. running, completed, draft) provide clarity.

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?

Clear verb 'List' and resource 'experiments' specified. Differentiates from sibling tools like list_gates or get_gate by focusing on experiments (shadow + split tests).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Describes optional filters and their effects, providing context for usage. However, lacks explicit when-to-use vs alternatives or when-not-to-use guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_gatesList Verlon GatesA

Read-only

List all gates in the authenticated Verlon AI account. Each gate's summary (id, name, description, primary model, task type, creation date) is returned as JSON. Read-only.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already declare readOnlyHint and openWorldHint. The description adds value by specifying the return format (JSON with summary fields) and confirming read-only behavior without contradiction.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences, front-loaded with the action and purpose. No extraneous information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Although there is no output schema, the description explicitly details the returned fields. With zero parameters and clear purpose, the description is sufficiently complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

No parameters exist, so schema coverage is 100% by default. The description does not need to add parameter info; a baseline of 4 is appropriate.

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?

Description clearly states 'List all gates in the authenticated Verlon AI account' and enumerates the returned fields (id, name, description, primary model, task type, creation date), making it distinct from siblings like get_gate.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for listing all gates but does not explicitly state when not to use or mention alternatives like get_gate for a single gate. Context is clear but lacks exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_logsList Verlon Request LogsA

Read-only

List recent request logs across the authenticated account. Returns timestamp, gate, model, cost, latency, success/failure, and request id for each log row. Optional filters: gate (UUID or name), since (ISO 8601), success (true/false), limit (1-100, default 20). Read-only.

ParametersJSON Schema

Name	Required	Description	Default
`gate`	No
`limit`	No
`since`	No
`success`	No

TDQS

A4.6/5.0

Behavior4/5

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

The description labels the tool as read-only, matching the readOnlyHint annotation, and adds return field details beyond what annotations provide. No destructive behavior is implied.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences, front-loaded with the action, no redundant information.

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?

Given the low complexity, the description covers purpose, return fields, parameter details, and read-only nature without gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description explains all 4 parameters with type, constraints, and format (e.g., 'since (ISO 8601)', 'limit (1-100, default 20)'), fully compensating for 0% schema coverage.

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 clearly states it lists recent request logs for the authenticated account and mentions the fields returned, distinguishing it from sibling tools like list_gates or get_recommendations.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description defines optional filters but does not explicitly discuss when to use this tool versus alternatives or provide exclusions. However, the purpose is clear enough for selection.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

5 tool updatesv0.3.1Jul 11, 2026
- First observedget_gate
- First observedget_recommendations
- First observedlist_experiments
- First observedlist_gates
- First observedlist_logs

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.4/5.0

Scored 2026-07-11 16:30 across 5 tools

Disambiguation5/5

Each tool targets a distinct resource (gate config, recommendations, experiments, gates list, logs) with no functional overlap, making selection unambiguous.

Naming Consistency5/5

All tools follow a consistent verb_noun pattern (get_ for single items, list_ for collections), with no naming irregularities.

Tool Count5/5

5 tools cover the core read-only operations for an AI platform monitoring server without being too few or excessive.

Completeness4/5

The set covers key read operations (gate config, recommendations, experiments, gates, logs), but lacks details on individual experiments or log entries beyond listing.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Related MCP Connectors

anotherai
dev.anotherai
MCP server for building and testing AI agents with multi-model experimentation and insights.
Agent Orchestration Autonomous Agents Testing & QA Tools
2
hithereiamaliff-mcp-nextcloudOAuth
ai.smithery
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
Cloud Storage File Systems Workplace & Productivity
238
Apideck MCP A
dev.apideck.mcp
Model Context Protocol server for the Apideck Unified API. Connect any MCP-compatible agent framework to 100+ accounting systems, HRIS platforms, file storage providers, and more through one integration. More information https://www.apideck.com/mcp-server
Developer Tools
42
microservices.sh
sh.microservices
MCP server for AI agents to plan, verify, and deploy Cloudflare-native apps.
Cloud Platforms Agent Orchestration Developer Tools
21

Related MCP Servers

MCP-PIF Server
Autonomous Agents Knowledge & Memory Developer Tools
hungryrobot1
F
license
Not graded
quality
F
maintenance
This server implements the Model Context Protocol to facilitate meaningful interaction and understanding development between humans and AI through structured tools and progressive interaction patterns.
Updated a year ago (2025-10-20 14:28 UTC)
57
-
MCP Toolkit Server
Databases File Systems Developer Tools
vyshnavi-nandyala
A
license
A
quality
D
maintenance
A Model Context Protocol server providing tools for DB queries, API calls, file I/O, and text transformations, enabling AI agents like Claude to perform real-world actions.
Updated 5 months ago (2026-05-10 03:00 UTC)
10
MIT
Gravitas-Core-MCP
Coding Agents Autonomous Agents
ahmed-coding
A
license
B
quality
C
maintenance
Production-grade, autonomous Model Context Protocol (MCP) server that elevates AI models from stateless code generators into persistent, self-verifying software engineers.
Updated 8 months ago (2026-02-11 05:04 UTC)
21
1
MIT
Agent Construct
Agent Orchestration Autonomous Agents Developer Tools
maihengxing999
A
license
Not graded
quality
D
maintenance
Model Context Protocol server that standardizes tool discovery, execution, and context management for AI applications.
Updated 2 years ago (2025-03-16 16:50 UTC)
MIT

@verlon-ai/mcp

Install

Claude Code

Cursor

Any other MCP-compatible client

Tools

Write tools (--enable-writes only)

Configuration

CLI flags

Security note

Development

Publishing (maintainers)

Per-release flow

One-time setup (registry publishing)

Verification

License

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

Write tools (`--enable-writes` only)