run_verification

SERVERMeridian SOURCE@meridianmcp/mcp

High RISK CLASS

Category Execute

Parameters 20 required

Recommended Rate-limitedsee the rule below

Registry record Grade D, identity unverified Pull the record →

This record as markdown: /tools/io-github-ajc3xc-meridian/run-verification.md

WHAT IT DOES

What run_verification does on Meridian

AI agents invoke run_verification to trigger actions in Meridian. What it does depends on the arguments the agent supplies, and its effects often reach beyond the immediate call: builds kicked off, notifications sent, workflows started.

Parameter	Type	Required	Description
`project_id`	string	—	Meridian project id — whose stored test_cmd to run.
`project_name`	string	—	Project name — an alternative to project_id; resolved to the id internally. project_id wins if both are given.

Parameters from the server's own tool schema.

RISK

Why run_verification is rated High

run_verification triggers real processes with real consequences. An agent gone sideways doesn't fire it once. It starts dozens of builds, sends mass notifications, or burns through compute before anyone looks up.

Attacks that exploit this kind of access

RECOMMENDED RULE

The rule that runs run_verification safely

PolicyLayer is an MCP gateway: it sits between your AI agents and Meridian, and checks every tool call against a rule you set before the call runs. Nothing changes on the server itself. For run_verification, this is the rule to start with:

run_verification Rate-limited

run_verification stays usable, but rate-capped: a runaway agent can't fire it dozens of times a minute. Everything else on the server is denied unless you say otherwise.

View as policy code

policy.json

{
  "version": "1",
  "default": "deny",
  "tools": {
    "run_verification": {
      "limits": [
        {
          "counter": "run_verification_rate",
          "window": "minute",
          "max": 10,
          "scope": "grant"
        }
      ]
    }
  }
}

RATE-LIMIT THIS TOOL → Instant setup, no code required.

The button opens the PolicyLayer dashboard: create your workspace, connect Meridian, apply this rule, and every run_verification call is checked against it from then on.

FAQ

Questions about run_verification

What does the run_verification tool do? +

[SUPPORT] 0e973e52 — run the project's stored test_cmd on YOUR local machine via the tunnel and return a REAL, structured result — not self-reported. Fields: {exit_code, passed, failed, stdout_tail, stderr_tail, status, timed_out}. Returns {status: 'not_configured'} (never an error) when no test_cmd is set; call set_executor_config(test_cmd='pixi run test') first. Requires an active meridian --tunnel; the hosted server has no access to your machine (same architectural class as ingest_document / search_code_semantic / search_outputs — decision 0dedff91). Per-project: only runs when test_cmd is configured for that project. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets. It is categorised as a Execute tool in the Meridian MCP Server, which means it can trigger actions or run processes. Use rate limits and argument validation.

What parameters does run_verification accept? +

run_verification accepts 2 parameters: project_id, project_name. The full parameter table on this page comes from the server's own tool schema.

How do I enforce a policy on run_verification? +

Register the Meridian MCP server in PolicyLayer and add a rule for run_verification: allow, deny, rate-limit, or require approval. Point your MCP client at the PolicyLayer proxy URL and the rule is enforced on every call, before it reaches Meridian. Nothing to install.

What risk level is run_verification? +

run_verification is a Execute tool with high risk. Execute tools should be rate-limited and have argument validation enabled.

Can I rate-limit run_verification? +

Yes. Add a rate_limit block to the run_verification rule in your PolicyLayer policy. For example, setting max: 10 and window: 60 limits the tool to 10 calls per minute. Rate limits are tracked per agent session and reset automatically.

How do I block run_verification completely? +

Set action: deny in the PolicyLayer policy for run_verification. The AI agent will receive a policy violation error and cannot call the tool. You can also include a reason field to explain why the tool is blocked.

What MCP server provides run_verification? +

run_verification is provided by the Meridian MCP server (@meridianmcp/mcp). PolicyLayer sits as a proxy in front of this server to enforce policies before tool calls reach the server.

KEEP EXPLORING

More on Meridian, and thousands of servers like it.

This server

All 235 Meridian tools → High-risk tools on this server →

Across the catalogue

run on 0sec →shortcuts_run on Apple Apps MCP →run_emba_scan on EMBA-MCP → All high-risk MCP tools → The MCP Attack Database →

Guides

Govern code and CI agents →Agent sandbox →Least privilege for MCP →