Skip to main content
Glama

NOMOS

ask_authority

Query a published authority on the NOMOS Exchange marketplace — a different system from verify_decision's own governance artifacts. Every public authority (e.g. eu-ai-act.nomos) is queryable with no key. Returns the authority's own verdict (AUTHORIZED/DENIED/ESCALATED), the exact rule and reason, and a permanent, cryptographically-bound transcript (query_id + url) — replayable evidence, not just a reply. Nothing is invented or paraphrased: the verdict is the authority's sealed rules evaluated against your inputs. The default response is a short, curated summary (verdict, matched rule, source citation when the artifact has one, transparency/completeness disclosures, transcript link) — not the full rule-by-rule evaluation trace. Set include_evaluation_trace: true to get that complete diagnostic record when you or the user actually need it.

Input Schema

NameRequiredDescriptionDefault
actionNoOptional label for what this query represents, for the caller's own transcript record (e.g. "pre-deployment check"). Purely descriptive — does not affect the verdict.
inputsYesKey/value facts to evaluate against the authority's rules (e.g. {"ai_categorises_biometric_data_for_sensitive_attributes": true}). Fields must match the authority's vocabulary — see the atlas endpoint or the artifact's catalog page.
authorityYesThe Exchange artifact's standard name — its short slug, optionally ".nomos"-suffixed (e.g. "eu-ai-act" or "eu-ai-act.nomos"), or its raw artifact ID. Browse the catalog at https://www.nomosprotocol.com/exchange.
exchange_api_keyNoExchange API key (nxk_...). Optional for free/public queries. Required only for metered access to licensed (paid) authorities beyond their free allotment.
include_evaluation_traceNoSet true to receive the full rule-by-rule evaluation trace (every rule checked, every missing field) instead of the default curated summary. Most callers never need this.

Output Schema

NameRequiredDescriptionDefault
urlNoPath to the permanent, shareable transcript for this query
verdictNoThe authority's own verdict
query_idNoPermanent transcript ID — reopen any time at the returned url
expected_fieldsNoPresent only when ESCALATED for lack of data — the fields this authority still needs
matched_rule_idNoID of the rule that determined the verdict — null when AUTHORIZED with no matching rule
response_sourceNoProvenance label — this is a sealed NOMOS verdict, not Claude's own reasoning. Preserve or restate this distinction when relaying the answer.
rules_evaluatedNoOnly present when include_evaluation_trace was true
source_referenceNoCitation for the matched rule, when the source document's structure was captured at extraction time. Names where the rule TEXT was extracted from (e.g. "Article 5"), not a legal claim about what it covers. Null if unavailable.
matched_rule_nameNoHuman-readable name/description of the matched rule — use this for display, not matched_rule_id
verdict_descriptionNoHuman-readable reason — the exact rule and its consequence
rules_evaluated_countNoTotal rules checked during evaluation — the size of the full trace, whether or not it was returned
open_higher_priority_countNo0 means every relevant fact was known when this was sealed; >0 means facts were still missing above the matched rule
open_higher_priority_rulesNoThe actual rules behind open_higher_priority_count (capped to 20) — use this to answer "which ones?" instead of guessing. Each has the rule name, what it would do if it matched, and exactly which input fields are missing.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.1/5.0
Behavior4/5

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

Annotations are sparse (readOnlyHint=false, openWorldHint=false, idempotentHint=false), and the description adds genuinely useful context the annotations cannot: no auth for public authorities, a permanent cryptographically-bound transcript (query_id + url) is produced, and the verdict comes from sealed rules rather than paraphrase. The non-read-only hint is consistent with the described permanent transcript write, so no contradiction. It does not discuss rate limits, latency, or error behavior for unknown authorities.

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 sibling differentiation, then response behavior — a sensible order with no wasted lead-in. Some phrasing is promotional rather than operative ('Nothing is invented or paraphrased', 'replayable evidence, not just a reply') and could be trimmed without losing decision-relevant information.

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?

For a nested-input, external-marketplace query tool with five parameters, the description covers auth tiers, what gets returned, and how to escalate detail. An output schema exists, so the description's return-value detail is a bonus rather than a requirement. Only error handling for malformed or unknown authority slugs is unaddressed.

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 description coverage is 100%, so every parameter is already documented, including the include_evaluation_trace default/trace tradeoff and the authority slug format. The description reinforces the default-vs-trace behavior but adds little syntax or format meaning beyond the schema. Baseline 3 applies when the schema carries the parameter burden.

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 ('Query a published authority on the NOMOS Exchange marketplace') and immediately scopes it against a named sibling ('a different system from verify_decision's own governance artifacts'). An agent can distinguish this from verify_decision, generate_governance, and detect_contradictions without opening any schema.

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

Usage Guidelines4/5

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

Gives clear routing context: this hits external published authorities, public ones need no key, licensed ones need an nxk_ key beyond a free allotment. It also tells the caller to omit include_evaluation_trace unless the diagnostic record is actually needed. It lacks an explicit 'use this when...' trigger phrase or stated exclusions for the other siblings, so it stops just short of a 5.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources