Skip to main content
Glama

Trooth

by io.github.trooth-eng
OverviewDiscussionsAdmin

Server Details

Trooth is an infrastructure & cybersecurity company providing Machine-Readable Trust.

If you are the author of this connector, you can claim ownership with GitHub, an HTTP challenge, or a DNS record. Claimed connector authors can inspect health checks, view analytics, and manage their listing.
Status
Healthy
Last Tested
Transport
Streamable HTTP · MCP 2025-06-18
URL
Repository
troothllc/trooth-mcp
GitHub Stars
0
Server Listing
Trooth Network

TDQS

A4.2/5.0

Scored across 4 tools

Disambiguation5/5

Each tool serves a clearly distinct function: general info, live security scan, profile lookup, and token verification. No overlapping purposes or ambiguous boundaries.

Naming Consistency4/5

All tools share the 'trooth_' prefix and snake_case, but 'trooth_public_trust_profile' is a noun phrase rather than a verb-action pattern, creating a minor inconsistency.

Tool Count5/5

With 4 tools, the surface is tightly scoped to the core use cases of querying, scanning, looking up profiles, and verifying tokens. No redundancy or excessive bloat.

Completeness4/5

The set covers the primary read and verification workflows, but lacks a listing/discovery tool for companies or profiles, which could be a minor gap for agents seeking to explore the network.

Available Tools

4 tools
trooth_askA
Read-onlyIdempotent
Inspect

Ask about Trooth itself: what the Trooth Network is, what one company record carries, why a company needs one, pricing (free), and how witnessing works. The Trooth Network is Trooth's only product. Answers come from Trooth's curated knowledge base.

ParametersJSON Schema
NameRequiredDescriptionDefault
questionYesA question about Trooth

Output Schema

ParametersJSON Schema
NameRequiredDescription
statusYesMachine-branchable outcome for this lookup.
subjectYesThe company, domain or token this answer is about.
summaryYesThe same answer as the text content, for display.
claim_urlNoPresent only when the subject has no published record and could be claimed by its owner.
provenanceYesWhere this answer came from. An honest_absence is missing data, never a judgment about the subject. A read_failed means Trooth could not read its own record at this moment and asserts nothing either way; retry rather than concluding.

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already cover readOnlyHint, idempotentHint, and destructiveHint. The description adds that answers come from a curated knowledge base, which clarifies the information source and behavior. It also notes that pricing is free, a concrete fact. No contradiction with annotations.

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?

Two concise sentences that front-load the purpose and provide essential context. No filler, and every sentence adds value.

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 description is complete enough for a simple Q&A tool. It mentions the knowledge base source and the range of topics. An output schema exists, so return format details are covered elsewhere. Minor omission: no guidance on out-of-scope questions, but this is not critical given the tool's simplicity.

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 100%, so the parameter 'question' is documented. The description goes beyond the schema by listing example topics (Trooth Network, record contents, pricing, witnessing), which helps an agent understand the expected scope of questions. This adds meaningful semantic guidance.

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's purpose: asking questions about Trooth itself, and enumerates specific topics (Trooth Network, record contents, pricing, witnessing). This distinguishes it from sibling tools that read specific data (trooth_outside_in_read, trooth_public_trust_profile, trooth_verify).

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?

The description implies when to use this tool: when the user has questions about Trooth's own features or concepts. It does not explicitly name alternatives or state exclusions, but the sibling tools clearly handle reading data rather than answering general questions, so the usage context is fairly clear.

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

trooth_outside_in_readA
Read-onlyIdempotent
Inspect

Perform a live, neutral read of a domain's public security surface right now: HTTPS/TLS reachability, common security headers (HSTS, CSP, nosniff, frame protection, referrer policy), and /.well-known/security.txt. These are observations from the public internet, not witnessed evidence and not a grade.

ParametersJSON Schema
NameRequiredDescriptionDefault
domainYesDomain to read, e.g. example.com

Output Schema

ParametersJSON Schema
NameRequiredDescription
statusYesMachine-branchable outcome for this lookup.
subjectYesThe company, domain or token this answer is about.
summaryYesThe same answer as the text content, for display.
claim_urlNoPresent only when the subject has no published record and could be claimed by its owner.
provenanceYesWhere this answer came from. An honest_absence is missing data, never a judgment about the subject. A read_failed means Trooth could not read its own record at this moment and asserts nothing either way; retry rather than concluding.

TDQS

A3.9/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=true. The description adds valuable behavioral context beyond that: it explains that results are live observations from the public internet and explicitly frames them as neutral and not witnessed evidence or a grade. This covers semantics without contradiction and gives agents an accurate mental model of the tool's behavior.

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?

Two sentences that front-load the core action and then add a clarifying qualifier about interpretation. The enumeration of headers and components is verbose but necessary for precision. The definition is efficient without being wordy.

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?

Given the single required parameter, rich annotations, and presence of an output schema, the description covers what the agent needs to call the tool correctly. It explains the scope, live nature, and boundary from evidence or grading. A slightly more explicit pointer to sibling tools or when not to use it would elevate completeness, but the current content is adequate for the tool's simplicity.

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%: the schema fully documents 'domain' with an example. The description adds no extra meaning about the parameter beyond restating 'domain' and embedding it in the purpose. With full schema coverage, the baseline of 3 is correct—the description doesn't need to compensate.

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 uses a specific verb ('Perform a live, neutral read') and clearly identifies the resource (a domain's public security surface) with concrete details (HTTPS/TLS reachability, security headers, security.txt). It even distinguishes itself from witnessed evidence and grades, making it recognizably different from siblings like trooth_verify or trooth_public_trust_profile.

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

Usage Guidelines3/5

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

The description implies usage for immediate security observations but does not explicitly state when to use this tool versus alternatives. Sibling tools are known from context but not mentioned; the only comparative hint is 'not witnessed evidence and not a grade', which is more of an exclusion than a positive routing. A clear when-not-to-use or alternative pointer is missing.

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

trooth_public_trust_profileA
Read-onlyIdempotent
Inspect

Look up a company's published, witnessed Trust Profile on Trooth by domain or slug. Returns the witnessed standing, pillar summary, and evidence-chain stats for companies that publish an OS profile, or the witnessed Network standing (signed scan result) for companies listed in the public directory. Unknown companies return an honest not-found.

ParametersJSON Schema
NameRequiredDescriptionDefault
companyYesCompany domain (e.g. acme.com) or Trooth slug

Output Schema

ParametersJSON Schema
NameRequiredDescription
statusYesMachine-branchable outcome for this lookup.
subjectYesThe company, domain or token this answer is about.
summaryYesThe same answer as the text content, for display.
claim_urlNoPresent only when the subject has no published record and could be claimed by its owner.
provenanceYesWhere this answer came from. An honest_absence is missing data, never a judgment about the subject. A read_failed means Trooth could not read its own record at this moment and asserts nothing either way; retry rather than concluding.

TDQS

A4/5.0
Behavior4/5

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

Annotations already establish read-only, idempotent, non-destructive behavior, so the description's job is to add context. It does this well by disclosing two distinct output cases—Trust Profile for OS-profile companies and Network standing for directory-listed companies—and by noting that unknown companies return 'an honest not-found.' Minor jargon like 'OS profile' is not expanded, preventing a higher score.

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 is three tight sentences with no filler. It front-loads the action and input, then summarizes output variants and the not-found case, with every sentence contributing useful 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 one-parameter, read-only tool with an output schema and strong annotations, the description is nearly complete: it covers input format, output variants, and edge-case behavior. The only real gap is the undefined 'OS profile' term, which could confuse an agent about the first return category.

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 the schema already documents the single 'company' parameter as a domain or Trooth slug. The description repeats this format but adds no new details, such as slug syntax or accepted normalization behavior. This matches the baseline for high schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource: 'Look up a company's published, witnessed Trust Profile on Trooth by domain or slug.' It clearly identifies the input and what the tool returns, but it does not explicitly differentiate this lookup from sibling tools like trooth_outside_in_read or trooth_verify, 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.

Usage Guidelines4/5

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

The description gives clear context for when to use this tool: when you need a company's Trust Profile or Network standing by domain or slug. It does not explicitly mention alternatives or exclusions, but the intended use is unambiguous and no misleading guidance is present.

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

trooth_verifyA
Read-onlyIdempotent
Inspect

Verify a Trooth Trust Ledger Token (a signed, portable trust receipt in tlt2 / tlt form, or its JTI). Re-runs both signatures independently and returns whether the token is valid, expired, revoked, or tampered - plus honest provenance: Trooth's outer signature attests only the witnessing event and the byte-for-byte payload at issuance, never the truthfulness of the declared claims. Unknown tokens return an honest not-found.

ParametersJSON Schema
NameRequiredDescriptionDefault
tokenYesA Trust Ledger Token (tlt2. or tlt. form) or its JTI

Output Schema

ParametersJSON Schema
NameRequiredDescription
statusYesMachine-branchable outcome for this lookup.
subjectYesThe company, domain or token this answer is about.
summaryYesThe same answer as the text content, for display.
claim_urlNoPresent only when the subject has no published record and could be claimed by its owner.
provenanceYesWhere this answer came from. An honest_absence is missing data, never a judgment about the subject. A read_failed means Trooth could not read its own record at this moment and asserts nothing either way; retry rather than concluding.

TDQS

A4.5/5.0
Behavior4/5

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

Annotations are strong (readOnly, openWorld, idempotent, non-destructive), but the description adds meaningful behavioral context: it states that verification involves re-running both signatures and returning specific statuses (valid, expired, revoked, tampered, not-found). It also honestly discloses that the outer signature does not attest to the truthfulness of claims, which is a crucial limitation an agent must know to avoid misinterpretation.

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 is a single, information-dense paragraph that front-loads the core purpose and follows with the key behavioral notes. Every sentence adds value: formats, verification behavior, status outcomes, provenance honesty, and not-found handling. No redundancy or filler.

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?

The tool is well-served by its rich annotations and clear description. The output schema exists, so return values are documented elsewhere. The description covers input formats, behavioral outcomes (valid/expired/revoked/tampered/not-found), and an important caveat about provenance. For a single-parameter tool, this is complete.

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?

Although the schema description provides full coverage ('A Trust Ledger Token (tlt2. or tlt. form) or its JTI'), the description adds value by clarifying that the token can be in two formats or a JTI, and elaborates on the verification process, which goes beyond the schema. Since coverage is 100% and the additional explanation reinforces parameter meaning, a 4 is appropriate.

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 states a specific verb ('verify') and resource ('Trooth Trust Ledger Token'), and clearly distinguishes it from siblings by focusing on token verification rather than asking (trooth_ask), reading (trooth_outside_in_read), or profile access (trooth_public_trust_profile). It also enumerates the token formats (tlt2/tlt or JTI), making the tool's exact scope unambiguous.

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?

The description implies usage: it is for verifying token validity and provenance, and it handles unknown tokens by returning a not-found response. It does not explicitly compare with sibling tools or state when not to use it, but the narrow scope and the mention of returning 'not-found' for unknown tokens gives the agent enough context to decide.

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.

  1. 4 tool updates
    • Changedtrooth_ask3 fields changed
      • changedOutput schema / properties / provenance / description
        Previous value: -"Where this answer came from. An honest_absence is missing data, never a judgment about the subject."New value: +"Where this answer came from. An honest_absence is missing data, never a judgment about the subject. A read_failed means Trooth could not read its own record at this moment and asserts nothing either way; retry rather than concluding."
      • changedOutput schema / properties / provenance / enum
        Previous value: -[
-  "witnessed_signed",
-  "signed_scan",
-  "live_observation",
-  "honest_absence",
-  "withheld_by_owner",
-  "knowledge_base",
-  "input_error"
-]New value: +[
+  "witnessed_signed",
+  "signed_scan",
+  "live_observation",
+  "honest_absence",
+  "withheld_by_owner",
+  "knowledge_base",
+  "input_error",
+  "self_declared",
+  "read_failed"
+]
      • changedOutput schema / properties / status / enum
        Previous value: -[
-  "published",
-  "listed",
-  "unclaimed",
-  "private",
-  "observed",
-  "valid",
-  "invalid",
-  "expired",
-  "revoked",
-  "answered",
-  "out_of_scope",
-  "bad_input"
-]New value: +[
+  "published",
+  "listed",
+  "unclaimed",
+  "private",
+  "observed",
+  "valid",
+  "invalid",
+  "expired",
+  "revoked",
+  "answered",
+  "out_of_scope",
+  "bad_input",
+  "unavailable"
+]
    • Changedtrooth_outside_in_read3 fields changed
      • changedOutput schema / properties / provenance / description
        Previous value: -"Where this answer came from. An honest_absence is missing data, never a judgment about the subject."New value: +"Where this answer came from. An honest_absence is missing data, never a judgment about the subject. A read_failed means Trooth could not read its own record at this moment and asserts nothing either way; retry rather than concluding."
      • changedOutput schema / properties / provenance / enum
        Previous value: -[
-  "witnessed_signed",
-  "signed_scan",
-  "live_observation",
-  "honest_absence",
-  "withheld_by_owner",
-  "knowledge_base",
-  "input_error"
-]New value: +[
+  "witnessed_signed",
+  "signed_scan",
+  "live_observation",
+  "honest_absence",
+  "withheld_by_owner",
+  "knowledge_base",
+  "input_error",
+  "self_declared",
+  "read_failed"
+]
      • changedOutput schema / properties / status / enum
        Previous value: -[
-  "published",
-  "listed",
-  "unclaimed",
-  "private",
-  "observed",
-  "valid",
-  "invalid",
-  "expired",
-  "revoked",
-  "answered",
-  "out_of_scope",
-  "bad_input"
-]New value: +[
+  "published",
+  "listed",
+  "unclaimed",
+  "private",
+  "observed",
+  "valid",
+  "invalid",
+  "expired",
+  "revoked",
+  "answered",
+  "out_of_scope",
+  "bad_input",
+  "unavailable"
+]
    • Changedtrooth_public_trust_profile3 fields changed
      • changedOutput schema / properties / provenance / description
        Previous value: -"Where this answer came from. An honest_absence is missing data, never a judgment about the subject."New value: +"Where this answer came from. An honest_absence is missing data, never a judgment about the subject. A read_failed means Trooth could not read its own record at this moment and asserts nothing either way; retry rather than concluding."
      • changedOutput schema / properties / provenance / enum
        Previous value: -[
-  "witnessed_signed",
-  "signed_scan",
-  "live_observation",
-  "honest_absence",
-  "withheld_by_owner",
-  "knowledge_base",
-  "input_error"
-]New value: +[
+  "witnessed_signed",
+  "signed_scan",
+  "live_observation",
+  "honest_absence",
+  "withheld_by_owner",
+  "knowledge_base",
+  "input_error",
+  "self_declared",
+  "read_failed"
+]
      • changedOutput schema / properties / status / enum
        Previous value: -[
-  "published",
-  "listed",
-  "unclaimed",
-  "private",
-  "observed",
-  "valid",
-  "invalid",
-  "expired",
-  "revoked",
-  "answered",
-  "out_of_scope",
-  "bad_input"
-]New value: +[
+  "published",
+  "listed",
+  "unclaimed",
+  "private",
+  "observed",
+  "valid",
+  "invalid",
+  "expired",
+  "revoked",
+  "answered",
+  "out_of_scope",
+  "bad_input",
+  "unavailable"
+]
    • Changedtrooth_verify3 fields changed
      • changedOutput schema / properties / provenance / description
        Previous value: -"Where this answer came from. An honest_absence is missing data, never a judgment about the subject."New value: +"Where this answer came from. An honest_absence is missing data, never a judgment about the subject. A read_failed means Trooth could not read its own record at this moment and asserts nothing either way; retry rather than concluding."
      • changedOutput schema / properties / provenance / enum
        Previous value: -[
-  "witnessed_signed",
-  "signed_scan",
-  "live_observation",
-  "honest_absence",
-  "withheld_by_owner",
-  "knowledge_base",
-  "input_error"
-]New value: +[
+  "witnessed_signed",
+  "signed_scan",
+  "live_observation",
+  "honest_absence",
+  "withheld_by_owner",
+  "knowledge_base",
+  "input_error",
+  "self_declared",
+  "read_failed"
+]
      • changedOutput schema / properties / status / enum
        Previous value: -[
-  "published",
-  "listed",
-  "unclaimed",
-  "private",
-  "observed",
-  "valid",
-  "invalid",
-  "expired",
-  "revoked",
-  "answered",
-  "out_of_scope",
-  "bad_input"
-]New value: +[
+  "published",
+  "listed",
+  "unclaimed",
+  "private",
+  "observed",
+  "valid",
+  "invalid",
+  "expired",
+  "revoked",
+  "answered",
+  "out_of_scope",
+  "bad_input",
+  "unavailable"
+]
  2. 1 tool update
    • Changedtrooth_verify1 field changed
      • changedInput schema / properties / token / description
        Previous value: -"A Trust Ledger Token (tlt2.… / tlt.…) or its JTI"New value: +"A Trust Ledger Token (tlt2. or tlt. form) or its JTI"
  3. 4 tool updates
    • Changedtrooth_ask1 field changed
      • changedOutput schema / (root)
        Previous value: -nullNew value: +{
+  "properties": {
+    "claim_url": {
+      "description": "Present only when the subject has no published record and could be claimed by its owner.",
+      "type": "string"
+    },
+    "provenance": {
+      "description": "Where this answer came from. An honest_absence is missing data, never a judgment about the subject.",
+      "enum": [
+        "witnessed_signed",
+        "signed_scan",
+        "live_observation",
+        "honest_absence",
+        "withheld_by_owner",
+        "knowledge_base",
+        "input_error"
+      ],
+      "type": "string"
+    },
+    "status": {
+      "description": "Machine-branchable outcome for this lookup.",
+      "enum": [
+        "published",
+        "listed",
+        "unclaimed",
+        "private",
+        "observed",
+        "valid",
+        "invalid",
+        "expired",
+        "revoked",
+        "answered",
+        "out_of_scope",
+        "bad_input"
+      ],
+      "type": "string"
+    },
+    "subject": {
+      "description": "The company, domain or token this answer is about.",
+      "type": "string"
+    },
+    "summary": {
+      "description": "The same answer as the text content, for display.",
+      "type": "string"
+    }
+  },
+  "required": [
+    "status",
+    "provenance",
+    "subject",
+    "summary"
+  ],
+  "type": "object"
+}
    • Changedtrooth_outside_in_read1 field changed
      • changedOutput schema / (root)
        Previous value: -nullNew value: +{
+  "properties": {
+    "claim_url": {
+      "description": "Present only when the subject has no published record and could be claimed by its owner.",
+      "type": "string"
+    },
+    "provenance": {
+      "description": "Where this answer came from. An honest_absence is missing data, never a judgment about the subject.",
+      "enum": [
+        "witnessed_signed",
+        "signed_scan",
+        "live_observation",
+        "honest_absence",
+        "withheld_by_owner",
+        "knowledge_base",
+        "input_error"
+      ],
+      "type": "string"
+    },
+    "status": {
+      "description": "Machine-branchable outcome for this lookup.",
+      "enum": [
+        "published",
+        "listed",
+        "unclaimed",
+        "private",
+        "observed",
+        "valid",
+        "invalid",
+        "expired",
+        "revoked",
+        "answered",
+        "out_of_scope",
+        "bad_input"
+      ],
+      "type": "string"
+    },
+    "subject": {
+      "description": "The company, domain or token this answer is about.",
+      "type": "string"
+    },
+    "summary": {
+      "description": "The same answer as the text content, for display.",
+      "type": "string"
+    }
+  },
+  "required": [
+    "status",
+    "provenance",
+    "subject",
+    "summary"
+  ],
+  "type": "object"
+}
    • Changedtrooth_public_trust_profile1 field changed
      • changedOutput schema / (root)
        Previous value: -nullNew value: +{
+  "properties": {
+    "claim_url": {
+      "description": "Present only when the subject has no published record and could be claimed by its owner.",
+      "type": "string"
+    },
+    "provenance": {
+      "description": "Where this answer came from. An honest_absence is missing data, never a judgment about the subject.",
+      "enum": [
+        "witnessed_signed",
+        "signed_scan",
+        "live_observation",
+        "honest_absence",
+        "withheld_by_owner",
+        "knowledge_base",
+        "input_error"
+      ],
+      "type": "string"
+    },
+    "status": {
+      "description": "Machine-branchable outcome for this lookup.",
+      "enum": [
+        "published",
+        "listed",
+        "unclaimed",
+        "private",
+        "observed",
+        "valid",
+        "invalid",
+        "expired",
+        "revoked",
+        "answered",
+        "out_of_scope",
+        "bad_input"
+      ],
+      "type": "string"
+    },
+    "subject": {
+      "description": "The company, domain or token this answer is about.",
+      "type": "string"
+    },
+    "summary": {
+      "description": "The same answer as the text content, for display.",
+      "type": "string"
+    }
+  },
+  "required": [
+    "status",
+    "provenance",
+    "subject",
+    "summary"
+  ],
+  "type": "object"
+}
    • Changedtrooth_verify1 field changed
      • changedOutput schema / (root)
        Previous value: -nullNew value: +{
+  "properties": {
+    "claim_url": {
+      "description": "Present only when the subject has no published record and could be claimed by its owner.",
+      "type": "string"
+    },
+    "provenance": {
+      "description": "Where this answer came from. An honest_absence is missing data, never a judgment about the subject.",
+      "enum": [
+        "witnessed_signed",
+        "signed_scan",
+        "live_observation",
+        "honest_absence",
+        "withheld_by_owner",
+        "knowledge_base",
+        "input_error"
+      ],
+      "type": "string"
+    },
+    "status": {
+      "description": "Machine-branchable outcome for this lookup.",
+      "enum": [
+        "published",
+        "listed",
+        "unclaimed",
+        "private",
+        "observed",
+        "valid",
+        "invalid",
+        "expired",
+        "revoked",
+        "answered",
+        "out_of_scope",
+        "bad_input"
+      ],
+      "type": "string"
+    },
+    "subject": {
+      "description": "The company, domain or token this answer is about.",
+      "type": "string"
+    },
+    "summary": {
+      "description": "The same answer as the text content, for display.",
+      "type": "string"
+    }
+  },
+  "required": [
+    "status",
+    "provenance",
+    "subject",
+    "summary"
+  ],
+  "type": "object"
+}
  4. 4 tool updates
    • First observedtrooth_ask
    • First observedtrooth_outside_in_read
    • First observedtrooth_public_trust_profile
    • First observedtrooth_verify

Related MCP Connectors

Related MCP Servers

Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources