Skip to main content
Glama

_delimit_gov_impl

Dispatch governance operations with a single call. Choose from seven actions: health, status, policy, evaluate, new_task, run, verify.

Instructions

Unified governance entry point — dispatches to one of seven actions.

When to use: as the single MCP-registered governance surface (delimit_gov) when the caller wants to pick the action by name in one call rather than choosing a specific delimit_gov_* alias. When NOT to use: from internal code paths — prefer the specific alias (delimit_gov_health, delimit_gov_evaluate, etc.) for clarity and so docstrings and license gates show up at the right call site.

Sibling contrast: each delimit_gov_ wrapper above is a thin alias over this implementation; they exist so the action's docstring lives at the right name. This is the dispatch core.

Side effects: action="health" / "status" are read-only and not gated. action="policy" / "evaluate" / "new_task" / "run" / "verify" are gated by require_premium — unlicensed callers receive a license payload and no backend call is made. Each gated action routes to a distinct backends.governance_bridge function (health, status, policy, evaluate_trigger, new_task, run_task, verify) and the result is wrapped via _with_next_steps for orchestrator hints. Errors are deterministic ({"error": ...}); inputs that cannot be coerced (e.g. malformed context for evaluate) short-circuit before the backend call.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
actionNoWhich governance operation to perform. One of "health", "status", "policy", "evaluate", "new_task", "run", "verify". Default "health". Other values return a deterministic error.health
repoNoRepository path. Default "." (cwd)..
eval_actionNoThe proposed action name to evaluate (used only when action="evaluate"). Empty string is rejected by the backend.
contextNoAdditional context (used only when action="evaluate"). Strings are auto-coerced to {"text": ...} via _coerce_dict_arg; dicts are passed through. None is allowed.
titleNoTask title (used only when action="new_task"). Required for new_task.
scopeNoTask scope (used only when action="new_task"). Required for new_task.
risk_levelNoRisk level low/medium/high/critical (used only when action="new_task"). Default "medium".medium
task_idNoTask ID (used only when action="run" or action="verify"). Required for those actions.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Behavior5/5

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

In absence of annotations, the description fully discloses side effects (read-only vs gated actions), error determinism, short-circuit behavior, and backend routing with premium licensing.

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

Conciseness4/5

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

Well-structured with clear sections, each sentence adds value, though length is justified by complexity.

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 8 parameters, 7 actions, no annotations, and presence of output schema, the description covers all aspects: action mapping, licensing, error behavior, and parameter usage conditions.

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?

Schema coverage is 100% with each parameter's usage condition already described; description adds grouping context but does not significantly enhance beyond schema.

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 that this is a unified governance entry point dispatching to seven actions, and distinguishes itself from sibling aliases by explaining they are thin wrappers.

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

Usage Guidelines5/5

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

Explicitly specifies when to use (single MCP surface, pick action by name) and when not to use (internal code paths, prefer specific alias), with clear alternatives.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/delimit-ai/delimit-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server