Zero-trust logic judge: your AI writes a claim as a ZFL table, the ZTL core judges it.
Scored across 3 tools
The three tools have fairly distinct roles: 'judge' performs the core action, 'language' is a reference for the ZFL format, and 'examples' provides worked sample documents. There is minor overlap between 'examples' and 'language' (both are reference-style helpers), but an agent can reasonably tell them apart.
All three names are single lowercase nouns ('examples', 'judge', 'language'), which is a consistent style. It deviates from the verb_noun convention, but within the set it is predictable and readable.
Three tools is on the lean side, but the domain is narrow (judge a logic document plus supporting reference material), so the small surface is reasonable. Nothing feels gratuitous.
The set covers the core lifecycle: the action ('judge'), the format reference ('language'), and worked samples ('examples'). A dedicated validation or batch-judge tool is absent, but the stated purpose appears adequately served.
Worked examples: questions already written as ZFL documents, ready to judge.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It does not state that this is a read-only operation, whether it returns static data, or any side effects – only that the examples are 'ready to judge'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It could be slightly clearer with an explicit verb, but it is appropriately sized for a zero-parameter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no inputs and an output schema, the description adequately states what is returned ('worked examples ... ZFL documents') and its intended use ('ready to judge'). It does not explicitly relate to the sibling tools, but the core information is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so parameter semantics are inherently trivial. The baseline score of 4 applies because no additional meaning is needed beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names the resource clearly ('worked examples: questions already written as ZFL documents') and implies retrieval, though it lacks an explicit verb. It does not name sibling tools, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use guidance or alternatives are provided. The phrase 'ready to judge' hints at a workflow with the judge tool but does not state conditions for selecting this tool over others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Judge a ZFL document with ZTL, a zero-trust logic: three values, two-valued connectives.
Args:
document: The ZFL document, as an object or as JSON text:
{"rows": [{"name": ..., "means": ..., "status": ..., "ground": ...}], "claim": ...}.
Returns:
The verdict with its disposition and grade, the receipt, the
instruments that applied, the issues found, and what the core read.
Read the verdict WITH its disposition: T EARNED = established; F REFUTED = false; F OPEN or Z OPEN = NOT ESTABLISHED, it could still turn either way (do not report it as false) — `why` and `unverified` say what to check; ON CREDIT = holds only on an unverified ground. A compound claim gets T or F; a claim that is a single name gets that name's own value, Z while unverified.
The full report is returned whatever `ask` says.
| Name | Required | Description | Default |
|---|---|---|---|
| document | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden, and it does substantial work: it explains exactly how to interpret verdicts (T EARNED vs F REFUTED vs F/Z OPEN as NOT ESTABLISHED, ON CREDIT as holding on an unverified ground), warns against misreporting OPEN as false, and states the report is returned regardless of `ask`. It does not state side effects, idempotency, or whether any state is mutated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Content is front-loaded (purpose first, then Args, then Returns) and the verdict-interpretation sentences each carry real information. It is dense but not padded, though the run-on dash-heavy quoting in the middle paragraph makes the disposition rules harder to scan than they need to be.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so the description is not obliged to enumerate return values, yet it usefully summarizes what the verdict contains (disposition, grade, receipt, instruments, issues, what the core read). Given the domain's complexity, the main gap is the absence of any sibling routing or ZFL vocabulary grounding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the schema itself is only an untyped anyOf object|string, so the description must compensate — and it partially does by spelling out the document shape: rows of {name, means, status, ground} plus a claim, and noting the document may be passed as an object or JSON text. It stops short of defining what each row field means, so it is strong but not complete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb and resource — judge a ZFL document under ZTL — and characterizes the logic engine (three values, two-valued connectives). It is clear what the tool does, though it does not explicitly contrast itself with the siblings 'examples' and 'language', and a reader with no ZFL background gets only a hint of what 'judging' means.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit when-to-use or when-not-to-use statement, and no mention of the sibling tools that would tell an agent whether to reach for judge versus examples or language. Usage is implied by the argument description alone, which is the minimum-viable level.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The ZFL language: the columns of a row, the document fields, their meaning and rules.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full behavioral burden, but it discloses nothing about side effects, read-only status, permissions, or output format. It offers only a topic phrase, not a behavioral profile.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no wasted words, but its structure is a colon-led list that is not front-loaded with an action. It is concise yet lacks clear front-loading of purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need not be described, and the lack of parameters simplifies things. However, the description still fails to clarify the tool's action or usage, which is inadequate even for a simple zero-parameter tool with an ambiguous name like 'language'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there are no parameter semantics to describe. The baseline for 0 params is 4, as the schema itself is empty and requires no further explanation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names the domain (ZFL language, columns, fields, meaning, rules) but does not state what the tool actually does—no verb such as 'returns' or 'describes'. It is a vague purpose statement that leaves the agent guessing the action, and it does not distinguish itself from siblings 'examples' or 'judge'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no indication of when to use this tool versus alternatives like 'examples' or 'judge'. No prerequisites, context, or exclusions are provided, leaving the agent without guidance on selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
examplesjudgelanguageTrust gate for AI agents: multi-model adversarial consensus, signed and verifiable verdicts.
Deterministic sealed verdicts on public claims and startup ideas (0-LLM claim-safety guardian).
Jailbreak-proof AI guardrails. Automated Reasoning SMT solver, not an LLM. ZK proofs included.
Deterministic signed verification of numeric & financial claims for AI agents & spreadsheets.
Add one secure layer between your agents and this server.
