Skip to main content
Glama
Sign In
SemanticDataCharter

sdcgovernance

Official
by SemanticDataCharter
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

evaluate_decision

Evaluates a DMN decision table against instance context to return a decision, matched rules, reasoning, errors, and a tamper-evident receipt for governed or ad-hoc checks.

Instructions

Evaluate a DMN decision table against instance context. Name the table by table_id (and table_version; the highest registered version when omitted) for a governed evaluation, or pass it inline as table_json for an ad-hoc one. Returns decision, matched_rules, reasoning, errors, the table's identity and content hash, and a tamper-evident Receipt whose receipt_hash covers table_id, table_version and table_hash as well as context_hash. instance_path is optional: when omitted, the decision is evaluated against extra_context alone, which is the path external context-only consumers (e.g. MTCP Evidence Packs) should use. Pass previous_hash to chain receipts; the caller is responsible for chain persistence.

Input Schema

NameRequiredDescriptionDefault
table_idNoId of a registered decision table (see register_decision_table and list_decision_tables). Give table_id or table_json, not both.
table_jsonNoJSON string defining the decision table inline, for an ad-hoc evaluation (the Receipt then carries the table's content hash but no id or version). Format: {"name": "...", "hit_policy": "FIRST|UNIQUE|COLLECT", "rules": [{"conditions": [{"field": "...", "op": "==|!=|<|<=|>|>=|in|not_in", "value": ...}], "outcome": "PERMIT|DENY|INDETERMINATE", "description": "..."}]}
instance_idNoIdentifier for the entity being evaluated, recorded in the Receipt. For SDC instances this is the DM instance_id (CUID2). For external consumers this is the entity identifier (e.g. an MTCP model_id such as 'gpt-4o').
context_hashNoSHA-256 hash of the extra_context payload, computed by the caller. Binds the Receipt cryptographically to the context that produced the decision. MTCP consumers pass the Evidence Pack hash here.
extra_contextNoJSON string with additional context key-value pairs.{}
instance_pathNoPath to the XML instance file for context extraction. Optional. Omit to evaluate against extra_context only.
previous_hashNoSHA-256 hash of the prior Receipt in the caller's chain. Pass null (default) to start a new chain. The caller is responsible for chain persistence.
table_versionNoVersion of the registered table. Omit for the highest registered version; the Receipt records the version that was used.
instance_versionNoVersion of the entity being evaluated, recorded in the Receipt.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv4.3.1

TDQS

A4.6/5.0
Behavior4/5

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

With no annotations, the description carries real weight: it discloses the return payload (decision, matched_rules, reasoning, errors, identity, content hash, Receipt) and precisely what the receipt_hash binds (table_id, table_version, table_hash, context_hash). It does not cover auth/permission requirements or error semantics for invalid tables, so it falls short of a 5.

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?

Front-loaded with purpose then routing logic, and each sentence carries distinct information; it is dense but slightly overstuffed, with return-value enumeration and chaining responsibilities packed into a single paragraph.

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?

Despite no output schema and no annotations, the description enumerates the response fields, the receipt's hash coverage, and the caller's chaining obligation, so an agent knows both how to call it and what to expect back.

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 coverage is already 100%, so the baseline is 3, but the description adds genuine semantic meaning: the version-defaulting rule, the ad-hoc-vs-governed tradeoff, and why context_hash and previous_hash exist (cryptographic binding and chaining).

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?

States a specific verb and resource ('Evaluate a DMN decision table against instance context') and immediately distinguishes the governed (table_id) path from the ad-hoc (table_json) path, separating it from siblings like register_decision_table and list_decision_tables.

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 says to give table_id or table_json (not both), explains the default version behavior, and prescribes the external context-only path via omitted instance_path with a named example (MTCP Evidence Packs). It also states when to pass previous_hash and who owns chain persistence.

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