SeenRelay
Server Details
Avoid redundant expensive validation. CHECK recent evidence; OBSERVE fresh independent results.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- ovladon/seenrelay
- GitHub Stars
- 0
- Server Listing
- SeenRelay
TDQS
Scored across 2 tools
check_fact and observe_fact are clearly complementary: one queries/validates a fact status while the other records a new observation. Their purposes do not overlap, so an agent should not misselect between them.
Both tools follow a consistent verb_noun snake_case pattern: check_fact and observe_fact. The naming is uniform and predictable.
Only two tools are provided, which is on the thin side for a typical server. However, the narrow fact-checking scope means both tools have clear and necessary roles, so the count is borderline but not unreasonable.
The tool pair covers the core workflow: check whether a fact is valid/known and observe a new fact after independent validation. No obvious missing operations are needed for the stated purpose of deduplicated fact caching and status checking.
Available Tools
2 toolscheck_factCheck Fact FreshnessARead-onlyIdempotentInspect
Cost preflight before repeated paid or slow source-backed validation, especially across an agent fleet. Use before paid web search, metered scraping, browser/extraction, rate-limited APIs or multi-step validation when the caller already has a known value. Returns SAME_OBSERVED, CHANGED_OBSERVED, CONTESTED, STALE or UNKNOWN. Only SAME_OBSERVED can be considered for caller-policy-gated reuse; every other status requires normal authoritative validation before OBSERVE. SeenRelay never browses or verifies externally.
| Name | Required | Description | Default |
|---|---|---|---|
| fact | Yes | Source-backed fact coordinate whose recent shared evidence should be checked. | |
| known_value | Yes | Caller-known value to compare with recent observations. Mutable observed content is excluded from fact identity. | |
| max_age_seconds | No | Maximum age, in seconds, of shared observations the caller is willing to consider. Omit to use the service default. |
Output Schema
| Name | Required | Description |
|---|---|---|
| hive | No | Current bounded Hive admission/lease state. |
| error | No | Present instead of a decision status when CHECK cannot be admitted or is controlled. |
| status | No | Decision status when CHECK succeeds. Only SAME_OBSERVED can be considered for reuse, and only under caller policy. CHANGED_OBSERVED, CONTESTED, STALE and UNKNOWN require normal authoritative validation before any OBSERVE. |
| fact_key | No | Canonical SeenRelay fact identity for this coordinate. |
| next_step | No | Explicit cold/stale-path instruction: validate the authoritative source normally, then OBSERVE the independently obtained result. |
| useful_reuse_awards | No | Qualified reuse awards attributable to this CHECK under SeenRelay telemetry rules; not a truth or independence score. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds useful behavioral detail beyond the annotations by stating 'SeenRelay never browses or verifies externally,' indicating this is a read-only cache lookup. Combined with readOnlyHint and idempotentHint, this gives a clear picture of side effects. It does not elaborate on error cases, but the core behavior is transparent.
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 compact and well-structured, using short sentences and a clear flow: purpose, usage guidance, return values, and policy implication. The list of expensive alternatives is slightly verbose, but overall it conveys the necessary information without significant padding.
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?
Given the rich schema and annotations, the description covers the core use case, return statuses, and the practical policy for when to trust the result ('Only SAME_OBSERVED can be considered for caller-policy-gated reuse'). It does not explain max_age_seconds behavior or error conditions, but those are secondary given the existing schema descriptions.
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 schema description coverage is 100%, with detailed explanations for fact, known_value, and max_age_seconds. The tool description does not add parameter-specific meaning beyond the general context of 'known value' and 'shared observations.' Since the schema already carries the explanatory weight, a baseline score is appropriate.
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 clearly states the tool's purpose: a cost preflight that checks whether a caller-known value is still fresh against shared observations, returning statuses like SAME_OBSERVED. It distinguishes this from the sibling observe_fact by focusing on reading/checking prior observations rather than recording new ones.
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?
The description gives explicit conditions for use: 'Use before paid web search, metered scraping, browser/extraction, rate-limited APIs or multi-step validation when the caller already has a known value.' It does not explicitly name the alternative observe_fact or state when not to use it, but the 'when caller already has a known value' condition provides clear guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
observe_factContribute Fact ObservationAInspect
After independently performing a source-backed validation, deposit the observed result for later CHECKs. Returns accepted=true when a new observation is stored or deduplicated=true for a recognized retry/recent duplicate. Never OBSERVE hearsay. Optional Ed25519 proof establishes key possession and continuity, not truth or real-world independence.
| Name | Required | Description | Default |
|---|---|---|---|
| fact | Yes | Source-backed fact coordinate for the independently obtained observation. | |
| value | Yes | Value independently obtained by the caller. Mutable observed content is excluded from fact identity. | |
| observed_at | No | ISO-8601 time when the caller obtained the observation. Omit to use server receipt time. | |
| observer_id | No | Optional self-asserted continuity label. It is unverified unless accompanied by observer_proof. | |
| observer_proof | No | Optional Ed25519 proof of key possession, continuity and payload integrity; not proof of truth or real-world independence. | |
| idempotency_key | No | Caller-chosen retry key for the same OBSERVE operation. Reusing it deduplicates an idempotent retry. | |
| source_validator | No | Optional source-validator metadata from the independent validation. The caller decides whether a returned hint is sufficient for source confirmation. | |
| evidence_fingerprint | No | Optional caller-supplied fingerprint of the independently obtained evidence. SeenRelay stores it as provenance metadata and does not verify it against the source. |
Output Schema
| Name | Required | Description |
|---|---|---|
| hive | No | Current bounded Hive admission/lease state. |
| error | No | Present when OBSERVE cannot be admitted or is controlled. This is not a statement about source truth. |
| reason | No | Deduplication reason when accepted=false and deduplicated=true. |
| accepted | No | True when a new independently obtained observation was stored. Omitted when OBSERVE cannot be admitted. |
| fact_key | No | Canonical SeenRelay fact identity for this coordinate. |
| deduplicated | No | True when an idempotent/recent duplicate was recognized and no new observation row was needed. |
| future_check_eligible | No | Whether the accepted or deduplicated observation is eligible to support later CHECKs under normal freshness rules. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses what the tool stores (observations, provenance metadata) and what it does not verify (source validators, evidence fingerprints, observer proof). It clearly states that Ed25519 proof establishes only key possession and continuity, not truth or independence.
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 concise, using three sentences to cover purpose, return behavior, and a critical warning. No redundant or filler information is present.
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?
The description covers output behavior (accepted/deduplicated), idempotency key usage, and the non-verification nature of optional metadata. Combined with the rich schema and sibling context, it fully equips an agent to invoke the tool correctly.
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?
Every parameter has a detailed schema description, including nested objects like fact, observer_proof, and source_validator. The tool description adds context about source-backed validation and the purpose of optional fields, fully covering parameter semantics.
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 clearly states the tool's function: depositing source-backed observations for later retrieval, with specific return semantics (accepted/deduplicated). It distinguishes it from check_fact by indicating observations are stored for later CHECKs.
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?
The description gives explicit preconditions: use only after independently performing source-backed validation, and warns against hearsay. It does not explicitly name check_fact as the retrieval alternative, but the phrase 'for later CHECKs' implies the distinction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
2 tool updates
- Changed
check_fact1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "$defs": { + "__schema0": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "number" + }, + { + "type": "boolean" + }, + { + "type": "null" + }, + { + "items": { + "$ref": "#/$defs/__schema0" + }, + "type": "array" + }, + { + "additionalProperties": { + "$ref": "#/$defs/__schema0" + }, + "propertyNames": { + "type": "string" + }, + "type": "object" + } + ] + } + }, + "$schema": "https://json-schema.org/draft/2020-12/schema", + "additionalProperties": {}, + "description": "CHECK result. Exactly one of a decision status or an error is expected; additional evidence fields may be present.", + "properties": { + "error": { + "additionalProperties": {}, + "description": "Present instead of a decision status when CHECK cannot be admitted or is controlled.", + "properties": { + "code": { + "description": "Stable machine-readable service/admission error code.", + "type": "string" + }, + "detail": { + "description": "Human-readable error detail. A tool error is not evidence that the source value is unchanged.", + "type": "string" + } + }, + "required": [ + "code", + "detail" + ], + "type": "object" + }, + "fact_key": { + "description": "Canonical SeenRelay fact identity for this coordinate.", + "type": "string" + }, + "hive": { + "$ref": "#/$defs/__schema0", + "description": "Current bounded Hive admission/lease state." + }, + "next_step": { + "const": "VALIDATE_THEN_OBSERVE", + "description": "Explicit cold/stale-path instruction: validate the authoritative source normally, then OBSERVE the independently obtained result.", + "type": "string" + }, + "status": { + "description": "Decision status when CHECK succeeds. Only SAME_OBSERVED can be considered for reuse, and only under caller policy. CHANGED_OBSERVED, CONTESTED, STALE and UNKNOWN require normal authoritative validation before any OBSERVE.", + "enum": [ + "SAME_OBSERVED", + "CHANGED_OBSERVED", + "CONTESTED", + "STALE", + "UNKNOWN" + ], + "type": "string" + }, + "useful_reuse_awards": { + "description": "Qualified reuse awards attributable to this CHECK under SeenRelay telemetry rules; not a truth or independence score.", + "maximum": 9007199254740991, + "minimum": 0, + "type": "integer" + } + }, + "type": "object" +}
- Changed
observe_fact1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "$defs": { + "__schema0": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "number" + }, + { + "type": "boolean" + }, + { + "type": "null" + }, + { + "items": { + "$ref": "#/$defs/__schema0" + }, + "type": "array" + }, + { + "additionalProperties": { + "$ref": "#/$defs/__schema0" + }, + "propertyNames": { + "type": "string" + }, + "type": "object" + } + ] + } + }, + "$schema": "https://json-schema.org/draft/2020-12/schema", + "additionalProperties": {}, + "description": "OBSERVE result. accepted=true means a new observation was stored; deduplicated=true means the retry/recent duplicate was recognized.", + "properties": { + "accepted": { + "description": "True when a new independently obtained observation was stored. Omitted when OBSERVE cannot be admitted.", + "type": "boolean" + }, + "deduplicated": { + "description": "True when an idempotent/recent duplicate was recognized and no new observation row was needed.", + "type": "boolean" + }, + "error": { + "additionalProperties": {}, + "description": "Present when OBSERVE cannot be admitted or is controlled. This is not a statement about source truth.", + "properties": { + "code": { + "description": "Stable machine-readable service/admission error code.", + "type": "string" + }, + "detail": { + "description": "Human-readable error detail. A tool error is not evidence that the source value is unchanged.", + "type": "string" + } + }, + "required": [ + "code", + "detail" + ], + "type": "object" + }, + "fact_key": { + "description": "Canonical SeenRelay fact identity for this coordinate.", + "type": "string" + }, + "future_check_eligible": { + "description": "Whether the accepted or deduplicated observation is eligible to support later CHECKs under normal freshness rules.", + "type": "boolean" + }, + "hive": { + "$ref": "#/$defs/__schema0", + "description": "Current bounded Hive admission/lease state." + }, + "reason": { + "description": "Deduplication reason when accepted=false and deduplicated=true.", + "type": "string" + } + }, + "type": "object" +}
2 tool updates
- Changed
check_fact7 fields changed- added
Input schema / properties / fact / descriptionAdded value: +"Source-backed fact coordinate whose recent shared evidence should be checked." - added
Input schema / properties / fact / properties / locator / properties / scheme / descriptionAdded value: +"Source-native locator type: RFC 6901-style JSON pointer, stable HTML element id, or stable source-native key." - added
Input schema / properties / fact / properties / locator / properties / value / descriptionAdded value: +"Source-native locator value. json_pointer values must begin with /; locator bytes are otherwise preserved." - added
Input schema / properties / fact / properties / qualifiers / descriptionAdded value: +"Identity-bearing semantic qualifiers. Include only fields needed to distinguish otherwise identical source-backed facts." - added
Input schema / properties / fact / properties / source / descriptionAdded value: +"Stable credential-free absolute HTTP(S) source URL. Tracking parameters are removed; authentication or signature query parameters are rejected." - added
Input schema / properties / known_value / descriptionAdded value: +"Caller-known value to compare with recent observations. Mutable observed content is excluded from fact identity." - added
Input schema / properties / max_age_seconds / descriptionAdded value: +"Maximum age, in seconds, of shared observations the caller is willing to consider. Omit to use the service default."
- Changed
observe_fact19 fields changed- added
Input schema / properties / evidence_fingerprint / descriptionAdded value: +"Optional caller-supplied fingerprint of the independently obtained evidence. SeenRelay stores it as provenance metadata and does not verify it against the source." - added
Input schema / properties / fact / descriptionAdded value: +"Source-backed fact coordinate for the independently obtained observation." - added
Input schema / properties / fact / properties / locator / properties / scheme / descriptionAdded value: +"Source-native locator type: RFC 6901-style JSON pointer, stable HTML element id, or stable source-native key." - added
Input schema / properties / fact / properties / locator / properties / value / descriptionAdded value: +"Source-native locator value. json_pointer values must begin with /; locator bytes are otherwise preserved." - added
Input schema / properties / fact / properties / qualifiers / descriptionAdded value: +"Identity-bearing semantic qualifiers. Include only fields needed to distinguish otherwise identical source-backed facts." - added
Input schema / properties / fact / properties / source / descriptionAdded value: +"Stable credential-free absolute HTTP(S) source URL. Tracking parameters are removed; authentication or signature query parameters are rejected." - added
Input schema / properties / idempotency_key / descriptionAdded value: +"Caller-chosen retry key for the same OBSERVE operation. Reusing it deduplicates an idempotent retry." - added
Input schema / properties / observed_at / descriptionAdded value: +"ISO-8601 time when the caller obtained the observation. Omit to use server receipt time." - added
Input schema / properties / observer_id / descriptionAdded value: +"Optional self-asserted continuity label. It is unverified unless accompanied by observer_proof." - added
Input schema / properties / observer_proof / descriptionAdded value: +"Optional Ed25519 proof of key possession, continuity and payload integrity; not proof of truth or real-world independence." - added
Input schema / properties / observer_proof / properties / nonce / descriptionAdded value: +"16..64 random bytes encoded as unpadded base64url." - added
Input schema / properties / observer_proof / properties / public_key / descriptionAdded value: +"Raw 32-byte Ed25519 public key encoded as unpadded base64url." - added
Input schema / properties / observer_proof / properties / scheme / descriptionAdded value: +"Observer proof contract version." - added
Input schema / properties / observer_proof / properties / signature / descriptionAdded value: +"Raw 64-byte Ed25519 signature encoded as unpadded base64url." - added
Input schema / properties / observer_proof / properties / timestamp / descriptionAdded value: +"ISO-8601 signing time; it must fall within the configured proof-skew window." - added
Input schema / properties / source_validator / descriptionAdded value: +"Optional source-validator metadata from the independent validation. The caller decides whether a returned hint is sufficient for source confirmation." - added
Input schema / properties / source_validator / properties / kind / descriptionAdded value: +"Type of observer-supplied source-validator metadata." - added
Input schema / properties / source_validator / properties / value / descriptionAdded value: +"Observer-supplied validator value. Stored and returned only as a hint; SeenRelay does not verify it against the source." - added
Input schema / properties / value / descriptionAdded value: +"Value independently obtained by the caller. Mutable observed content is excluded from fact identity."
2 tool updates
- First observed
check_fact - First observed
observe_fact
Related MCP Connectors
Physical-world evidence and operability checks with provenance and explicit data gaps.
Verify a source or provider before an AI agent trusts it. Evidence only; unknown stays unknown.
Verify stock signals, replay evidence, provenance, freshness, and caveats.
Verified external-state intelligence for agents with corroborated evidence and ANSWER or WAIT.
Related MCP Servers
- AlicenseBqualityCmaintenanceEnables AI agents to verify technical claims against supplied evidence, identify unsupported assumptions and contradictions, and recommend the smallest next check before acting.5MIT
- AlicenseBqualityAmaintenanceVerify a number before an agent asserts it — a Deflated Sharpe Ratio for backtest, plus eval-gap, subset-win, and judge-bias checks, with signed receipts anyone can verify offline.34MIT
- AlicenseNot gradedqualityBmaintenanceFreshness gate for AI agents: verify a belief is still true against the live world before you act.Apache 2.0
- AlicenseAqualityAmaintenanceFirst-line incident triage you can trust: ranked root-cause hypotheses where every claim cites a real evidence handle — and the agent abstains rather than guess.11MIT
Glama MCP Gateway
Add one secure layer between your agents and this server.