Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@intesta-mcp Check the trust level for acme-invoicing.com before I send payment."
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An MCP server that lets an AI agent check who it is dealing with before it acts.
Intesta is a trust registry. Every entity has a trust level on the
A0→A4 ladder (A0 claimed · A1 domain-control · A2 payment-verified · A3/A4 higher) and a
set of facts, each marked confirmed (independently verified) or auto_collected (scraped
from public sources, not verified). This server exposes the registry's public reads as
MCP tools so an agent can ask "can I trust this domain, and what is actually proven?" before
it pays a counterparty, shares data, or follows instructions from an unknown party.
Its ethos is Intesta's own: refuse, don't guess. A level is only ever what was proven; an
auto_collected fact is not a verified one. The server reports exactly what the registry says
and never upgrades either.
Tool | What it answers |
| Find an entity by name or domain; each result carries its trust level. |
| The headline: A0..A4 level, whether it's attested, |
| The entity's public facts, each flagged |
| A question answered only from that entity's registry facts, with a |
| What each of A0..A4 means. |
All tools are read-only and need no API key — public registry reads work out of the box.
An optional INTESTA_API_KEY (ik_…) is only needed for metered or private use.
Related MCP server: domain-whois-mcp
// Claude Desktop / any MCP client — mcp config
{
"mcpServers": {
"intesta": { "command": "uvx", "args": ["intesta-mcp"] }
}
}Or run directly:
uvx intesta-mcpAgent is about to send funds to
acme-invoicing.com.
check_trust("acme-invoicing.com")
→ { "level": "A0", "attested": false,
"what_is_proven": "listed only; nothing independently verified" }A0 and attested:false means the domain is unproven — the agent should pause or escalate
(pair this with Raposa Aval for a human approval step) rather than
assume the counterparty is who it claims to be.
python3 -m venv .venv && .venv/bin/pip install -e ".[test]"
.venv/bin/python -m pytest -q # contract tests, no networkMIT · a DC ESCRYPT product · https://intesta.io
Ask a question answered ONLY from a specific entity's registry facts. The answer is grounded in that entity's passport (no guessing) and carries a passport_hash and, when configured, a registry signature you can verify offline. Use for 'what does X do / what is X's refund policy' about a known domain.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | ||
| question | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does disclose meaningful traits: the answer is grounded in the entity's passport with 'no guessing' and includes a passport_hash plus an optional verifiable registry signature. However, it says nothing about auth requirements, rate limits, latency, or failure behavior on an unknown domain, so coverage is partial.
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?
Three sentences, front-loaded with the defining constraint (answers come ONLY from one entity's registry facts), followed by provenance details and usage examples. No filler, though the provenance sentence is slightly dense.
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 enumerated, yet the description still summarizes the payload (passport_hash, registry signature). Combined with the grounding guarantee and usage examples, an agent has enough to invoke it, with only parameter-level detail for 'question' left thin.
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 description coverage is 0%, so the description must compensate. It clarifies that 'domain' refers to a known entity domain and that 'question' is a natural-language question, but it adds no format constraints, syntax, or examples per parameter, leaving both fields only lightly specified.
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 states a specific verb+resource: asking a question that is answered ONLY from a specific entity's registry facts, grounded in that entity's passport. It implicitly distinguishes itself from siblings like search_registry and get_facts via the 'known domain' and 'ONLY from that entity' framing, though it never names an alternative directly.
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?
It gives concrete usage examples ('what does X do / what is X's refund policy') and scopes them to a known domain, which tells the agent when this tool applies. It stops short of explicitly stating when NOT to use it or naming search_registry/get_facts as the alternative for discovery-style queries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check what is actually proven about a domain before you trust it. Returns its trust level (A0..A4), whether it is attested, the human-readable 'what_is_proven', the proof method, and how many public facts it has. A low level or attested=false means unproven — not necessarily false, but not verified.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden, and it does useful work by disclosing meaning of results — the A0..A4 scale, the attested flag, and the key caveat that a low level or attested=false is 'unproven — not necessarily false, but not verified.' It omits auth/rate-limit/error behavior, but the semantic interpretation of the output is well covered.
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?
Four short lines, front-loaded with the core action and then the return contract. Every sentence carries information; only the parenthetical caveat could arguably be tightened, but it earns its place by preventing a false-negative misread.
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 needn't enumerate return fields, yet it helpfully summarizes them and adds interpretation. The one meaningful gap is the absence of any routing guidance relative to the sibling trust_ladder, which likely overlaps in purpose.
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 description coverage is 0% and there is one parameter, so the description would ideally state the expected format (e.g., bare domain vs URL). It only implies 'domain' implicitly through the tool's phrasing; the parameter name is self-describing but no explicit format guidance compensates for 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?
States a specific verb+resource (check the trust status of a domain) and enumerates exactly what is returned: trust level A0..A4, attested flag, what_is_proven, proof method, and public fact count. It does not, however, distinguish itself from the sibling 'trust_ladder' or explain how it differs from 'get_facts', so an agent must infer the boundary.
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?
"Before you trust it" implies a usage context (pre-trust verification), but there is no explicit when-to-use/when-not-to-use statement and no mention of the sibling alternatives like trust_ladder or get_facts. Usage is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read a domain's public facts from the registry. Each fact carries an attestation_status: 'confirmed' (independently verified) or 'auto_collected' (scraped from public sources, NOT verified). Do not treat auto_collected as proven. Also returns each fact's source so you can check it yourself.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does so for the most important trait: that some returned data is unverified ('auto_collected ... NOT verified'), plus an explicit instruction not to over-trust it and a note that provenance is returned. It omits auth requirements, rate limits, and unknown-domain behavior, which keeps it 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three compact sentences, front-loaded with the action and then the critical interpretation caveat. No filler, though the trust warning is stated twice in slightly different words.
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 spelled out, and the description still adds useful semantic context about attestation_status. For a single required parameter it is close to complete, missing only input format and failure behavior for unknown domains.
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 description coverage is 0% for the single 'domain' parameter, so the description must compensate; it conveys that the input identifies a domain whose facts are read, but gives no format or example (e.g., bare hostname vs URL). Partial compensation only.
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?
States a specific verb and resource ('Read a domain's public facts from the registry'), which is unambiguous. However, it never differentiates itself from siblings like search_registry or check_trust, so an agent must infer the boundary.
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 'use this when' guidance and no comparison to the alternatives (search_registry, check_trust, ask_entity, trust_ladder). The caveat about attestation_status tells the agent how to interpret results, not when to prefer this tool over a sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the Intesta trust registry for entities by name or domain. Returns each match with its domain, trust level (A0..A4) and public fact count. Use this to find the domain to pass to check_trust / get_facts.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are supplied, so the description carries the full behavioral burden. It discloses the result shape (domain, trust level A0..A4, public fact count) and implies a read-only lookup, but says nothing about auth requirements, rate limits, or pagination beyond the schema's silent limit param.
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?
Three short sentences with zero waste: purpose first, result summary second, routing hint last. Everything is front-loaded and each sentence earns its place.
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 explained, yet the description still summarizes them helpfully. For a simple two-parameter search the only real gap is the undocumented limit/pagination behavior.
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 description coverage is 0%, so the description must compensate. It meaningfully clarifies the query param ('by name or domain'), but the limit param, its default of 10, and any cap/behavior are left entirely undocumented in both schema and description.
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?
States a specific verb+resource ('Search the Intesta trust registry for entities') and the two lookup axes (name or domain), and it names the downstream siblings (check_trust/get_facts) so an agent can place it in the pipeline without opening a schema.
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?
Explicitly says to use this to find the domain to pass to check_trust / get_facts, which is real when-to-use guidance tied to alternatives. It stops short of stating when not to use it (e.g. when a domain is already known and the agent should call check_trust directly).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Explain the A0..A4 trust ladder: what each level means and what it proves. Call this to interpret the 'level' returned by check_trust and search_registry.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden; it makes clear this is a static interpretive reference with no side effects, implied by 'explain' and zero parameters. It does not explicitly state the operation is read-only or describe the response shape, though the output schema covers the latter.
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?
Two short sentences, front-loaded with what is explained and followed by when to call it. No filler.
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 zero-parameter explainer with an output schema, the description is complete: it conveys purpose, trigger, and that the return is an explanation of level meanings. Nothing needed to call it correctly is missing.
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 takes zero parameters, so there are no parameter semantics to document; the baseline for a no-arg tool is 4. Nothing in the description conflicts with 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?
States a specific verb+resource ('Explain the A0..A4 trust ladder') and precisely what it delivers ('what each level means and what it proves'). It also distinguishes itself from siblings by naming check_trust and search_registry.
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?
Explicitly gives the trigger condition: 'Call this to interpret the level returned by check_trust and search_registry.' An agent knows exactly when this tool is the right choice versus the sibling that produced the opaque value.
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.
v0.1.1ask_entitycheck_trustget_factssearch_registrytrust_ladderScored across 5 tools
Each tool targets a distinct step in the trust workflow: discovery via search_registry, trust assessment via check_trust, fact retrieval via get_facts, grounded Q&A via ask_entity, and interpretation via trust_ladder. Boundaries are clear, and descriptions explicitly guide when to use each tool.
Most names use a consistent verb_noun snake_case pattern (search_registry, check_trust, get_facts, ask_entity). The one outlier is trust_ladder, which is noun-based rather than verb-based, but the overall convention remains readable and predictable.
Five tools is well-scoped for a trust registry lookup server. Each tool has a clear purpose and no unnecessary redundancy, supporting a focused read-oriented workflow.
The toolset covers the core lifecycle: find entities, check trust, read facts, ask grounded questions, and explain the trust ladder. A minor gap is the lack of an explicit tool to verify returned passport signatures or hashes offline, though the descriptions suggest this can be done externally.
Trust signals for AI agents: an open agent-readiness standard and developer tool guide. Read-only.
Independent AI-agent reviews: trust checks, evidence scorecards, incident registry, recommendations.
Trust verification for AI agents: identities, domains, phishing, contacts, Trust Circle, Vault.
Trust infrastructure for AI agents: read a verifiable Trust Rating, claim an identity, earn a badge.
