Skip to main content
Glama

plith

by ai.plith
OverviewDiscussionsAdmin

guardrail_create_policy

Create a persistent governance policy that guardrail_check evaluates on every subsequent call. Define rules using and/or/not operators over action types, resource patterns, and budget thresholds. Call this before using guardrail_check — checks require at least one active policy. Policies persist until explicitly deleted. Duplicate policy names return an error. Returns the created policy with its ID and active status.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameYesUnique policy name per org. Examples: 'no-delete-in-prod', 'budget-cap-50', 'pii-block'.
rulesYesArray of rule objects evaluated against the proposed_action in guardrail_check. Leaf operators: eq, starts_with, contains, gt, lt (compare field to value). Compound operators: and, or, not (nest sub-rules in a rules array). Example: [{operator:'eq', field:'type', value:'file_write'}] blocks all file writes. Nested example: [{operator:'and', rules:[{operator:'eq',field:'type',value:'api_call'},{operator:'contains',field:'url',value:'prod'}]}] blocks prod API calls.
priorityNoOptional. Evaluation order. Default: 0.
descriptionNoOptional human-readable summary of what this policy enforces. Returned in guardrail_check responses and guardrail_list_policies output for auditability.
action_typesNoOptional. Restrict this policy to only evaluate when proposed_action.type matches one of these values. Examples: ['file_write', 'api_call', 'db_delete']. Omit to apply the policy to all action types regardless of type field.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
policyNo
request_idNo
credits_usedNo
credits_remainingNo
fallback_behaviorNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
+  "properties": {
+    "credits_remaining": {
+      "type": "number"
+    },
+    "credits_used": {
+      "type": "number"
+    },
+    "fallback_behavior": {
+      "type": "string"
+    },
+    "policy": {
+      "properties": {
+        "action_types": {
+          "items": {
+            "type": "string"
+          },
+          "type": "array"
+        },
+        "created_at": {
+          "type": "string"
+        },
+        "description": {
+          "type": "string"
+        },
+        "enabled": {
+          "type": "boolean"
+        },
+        "id": {
+          "type": "string"
+        },
+        "name": {
+          "type": "string"
+        },
+        "priority": {
+          "type": "number"
+        },
+        "rules": {
+          "type": "array"
+        }
+      },
+      "type": "object"
+    },
+    "request_id": {
+      "type": "string"
+    }
+  },
+  "type": "object"
+}
  2. Changed3 schema fields changed
    • changedInput schema / properties / action_types / description
      Previous value: -"Optional. Restrict policy to specific action types. Examples: ['file_write', 'api_call', 'db_delete']. Omit to apply to all action types."New value: +"Optional. Restrict this policy to only evaluate when proposed_action.type matches one of these values. Examples: ['file_write', 'api_call', 'db_delete']. Omit to apply the policy to all action types regardless of type field."
    • changedInput schema / properties / description / description
      Previous value: -"Optional human-readable description of what this policy enforces."New value: +"Optional human-readable summary of what this policy enforces. Returned in guardrail_check responses and guardrail_list_policies output for auditability."
    • changedInput schema / properties / rules / description
      Previous value: -"Rule objects evaluated against proposed_action. Leaf operators: eq, starts_with, contains, gt, lt. Compound operators: and, or, not (nest rules array). Example: {operator:'and', rules:[{operator:'eq',field:'action_type',value:'file_write'},{operator:'contains',field:'path',value:'/prod/'}]}."New value: +"Array of rule objects evaluated against the proposed_action in guardrail_check. Leaf operators: eq, starts_with, contains, gt, lt (compare field to value). Compound operators: and, or, not (nest sub-rules in a rules array). Example: [{operator:'eq', field:'type', value:'file_write'}] blocks all file writes. Nested example: [{operator:'and', rules:[{operator:'eq',field:'type',value:'api_call'},{operator:'contains',field:'url',value:'prod'}]}] blocks prod API calls."
  3. Changed8 schema fields changed
    • changedInput schema / properties / action_types / description
      Previous value: -"Optional. Restrict to action types."New value: +"Optional. Restrict policy to specific action types. Examples: ['file_write', 'api_call', 'db_delete']. Omit to apply to all action types."
    • changedInput schema / properties / description / description
      Previous value: -"Optional policy description."New value: +"Optional human-readable description of what this policy enforces."
    • changedInput schema / properties / name / description
      Previous value: -"Unique policy name."New value: +"Unique policy name per org. Examples: 'no-delete-in-prod', 'budget-cap-50', 'pii-block'."
    • changedInput schema / properties / rules / description
      Previous value: -"Rule objects. Operators: eq, starts_with, contains, gt, lt, and, or, not."New value: +"Rule objects evaluated against proposed_action. Leaf operators: eq, starts_with, contains, gt, lt. Compound operators: and, or, not (nest rules array). Example: {operator:'and', rules:[{operator:'eq',field:'action_type',value:'file_write'},{operator:'contains',field:'path',value:'/prod/'}]}."
    • changedInput schema / properties / rules / items / properties / field / description
      Previous value: -"Field path on proposed_action."New value: +"Field path on proposed_action (e.g. 'action_type', 'path', 'amount')."
    • changedInput schema / properties / rules / items / properties / operator / description
      Previous value: -"Rule operator."New value: +"Rule operator: eq | starts_with | contains | gt | lt | and | or | not."
    • changedInput schema / properties / rules / items / properties / rules / description
      Previous value: -"Nested rules for compound operators."New value: +"Nested rules for compound operators (and/or/not)."
    • changedInput schema / properties / rules / items / properties / value / description
      Previous value: -"Comparison value for the rule operator. String, number, or boolean (as string)."New value: +"Comparison value for leaf operators. String, number, or boolean as string."
  4. First observed

TDQS

A4.4/5.0
Behavior4/5

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

The description goes beyond the minimal annotations by disclosing persistence ('Policies persist until explicitly deleted'), error behavior ('Duplicate policy names return an error'), and return value ('Returns the created policy with its ID and active status'). These details add significant context beyond the annotations, which only provide basic hints. However, it doesn't mention potential authorization requirements or the interaction of multiple policies, so it's not fully comprehensive.

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 uses six short, informative sentences with no redundancy. It is front-loaded with the primary purpose, followed by usage, persistence, error handling, and return value. Every sentence earns its place, and there is no padding or unnecessary detail.

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 tool has an output schema, so return value details are covered separately. The description explains prerequisite ('Call this before using guardrail_check'), persistence, error condition, and return behavior. It lacks specifics on how multiple policies are evaluated together, but given the priority parameter in the schema and the companion guardrail_check tool, this is a minor gap. Overall, the description provides enough context for correct 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?

Schema coverage is 100%, meaning all parameters have descriptions. The description adds a high-level summary of rule syntax ('Define rules using and/or/not operators over action types, resource patterns, and budget thresholds'), but the schema already provides detailed examples for each parameter. Thus the description adds marginal value beyond the schema, warranting the baseline score of 3.

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 tool 'Create a persistent governance policy' with a specific verb and resource. It explicitly explains that guardrail_check evaluates the policy on subsequent calls, distinguishing it from sibling tools like guardrail_check itself, which presumably evaluates policies. The tool's role as a policy creator is unambiguous.

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?

The description provides explicit usage guidance: 'Call this before using guardrail_check — checks require at least one active policy.' This directly tells the agent when to use this tool relative to its sibling, and the note about duplicate policy names returning an error also informs the agent to avoid name collisions. This is clear and actionable.

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

All plith toolsInspect
Try in Browser
Context Every Agent Can ShareAgents share what they learn, hand off work, and keep it when you switch models. Start with 5 GB free.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources