Skip to main content
Glama
delimit-ai

delimit

Official
by delimit-ai
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

Delimit Gov Evaluate

delimit_gov_evaluate

Check whether a proposed action triggers governance gating before you execute it. Returns a clear verdict for uncertain operations like deploys, external PRs, schema changes, or ruleset edits.

Instructions

Evaluate whether a proposed action triggers governance gating (Pro).

When to use: BEFORE performing any action whose policy class is uncertain — deploy, external PR submission, schema change, npm publish, force-push, force-update of a floating tag, account switch, ruleset edit. This is the canonical pre-action check the orchestrator and CI hooks call; the response is the gate verdict. When NOT to use: to read the policy rules themselves (use delimit_gov_policy), to materialize a tracked task from a "gating required" verdict (delimit_gov_new_task), or to check engine health (delimit_gov_health). Also: do not call after starting the action — the verdict is decision-time and a retroactive call has no gating effect.

Sibling contrast: delimit_gov_policy returns the rules; this evaluates a candidate action against them. delimit_external_pr_check handles the specialised external-PR duplicate path; this is the general action evaluator. delimit_gov_new_task is what you call AFTER this returns "gating required" to mint a tracked task.

Side effects: read-only on policy storage and gated by require_premium — unlicensed callers receive a license payload and no evaluation runs. On a licensed call, invokes backends.governance_bridge.evaluate_trigger which loads the active policy and returns a verdict; no task is created, no ledger write, no evidence file. Inputs are coerced before the backend call: a string context is wrapped as {"text": ...} via _coerce_dict_arg; a malformed context short-circuits with an error response.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
repoNoFilesystem path to the repository. Default "." (cwd)..
actionNoProposed action name to evaluate (e.g. "external_pr", "deploy"). Empty string returns an error.
contextNoOptional dict with action-specific context (e.g. target repo, author). Strings are auto-coerced to {"text": ...} via _coerce_dict_arg.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv4.7.9
    • addedInput schema / properties / action / description
      Added value: +"Proposed action name to evaluate (e.g. \"external_pr\", \"deploy\"). Empty string returns an error."
    • addedInput schema / properties / context / description
      Added value: +"Optional dict with action-specific context (e.g. target repo, author). Strings are auto-coerced to {\"text\": ...} via _coerce_dict_arg."
    • addedInput schema / properties / repo / description
      Added value: +"Filesystem path to the repository. Default \".\" (cwd)."
  2. Changed3 schema fields changedv4.5.5
    • addedInput schema / properties / action / default
      Added value: +""
    • changedInput schema / properties / context / anyOf
      Previous value: -[
-  {
-    "additionalProperties": true,
-    "type": "object"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "type": "string"
+  },
+  {
+    "additionalProperties": true,
+    "type": "object"
+  },
+  {
+    "type": "null"
+  }
+]
    • removedInput schema / required
      Removed value: -[
-  "action"
-]
  3. First observedv0.1.0

TDQS

A4/5.0
Behavior1/5

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

Annotation Contradiction: the description claims 'read-only on policy storage' and says no task, ledger write, or evidence file is created, while the annotations set readOnlyHint to false. This directly conflicts with the structured read-only signal and makes the safety profile ambiguous despite otherwise rich behavioral disclosure.

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 long but tightly organized with clear sections: purpose, when to use, when not to use, sibling contrast, and side effects. Every sentence carries routing or behavioral information, and the core purpose is front-loaded before the alternatives.

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?

The description covers timing, alternatives, licensing, side effects, and input coercion, and an output schema exists so return-value documentation is not required. However, the readOnlyHint false contradiction leaves unresolved ambiguity about whether the tool mutates state, preventing a perfect completeness score.

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?

Schema description coverage is 100%, so the baseline is 3. The description adds useful behavior beyond the schema by specifying that a string context is coerced to {'text': ...} via _coerce_dict_arg and that a malformed context short-circuits with an error response.

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 opening sentence states the exact verb and resource: 'Evaluate whether a proposed action triggers governance gating.' The sibling-contrast section explicitly distinguishes it from delimit_gov_policy, delimit_external_pr_check, and delimit_gov_new_task, so an agent can reliably tell this tool apart from its closest alternatives.

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?

Provides an explicit 'When to use' list with concrete scenarios, a 'When NOT to use' list naming the correct alternatives, and a critical timing constraint: the verdict is decision-time and a retroactive call has no gating effect. This is unambiguous routing guidance.

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

Deploy Server

Other Tools