Skip to main content
Glama
agentlabbusiness

intesta-mcp

README.md
# intesta-mcp

<!-- mcp-name: io.intesta/intesta-mcp -->

An MCP server that lets an AI agent **check who it is dealing with before it acts.**

[Intesta](https://intesta.io) 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.

## Tools

| Tool | What it answers |
|---|---|
| `search_registry(query, limit=10)` | Find an entity by name or domain; each result carries its trust level. |
| `check_trust(domain)` | The headline: A0..A4 level, whether it's attested, `what_is_proven`, and the proof method (e.g. `dns_txt`). |
| `get_facts(domain)` | The entity's public facts, each flagged `confirmed` vs `auto_collected`, with its source. |
| `ask_entity(domain, question)` | A question answered **only** from that entity's registry facts, with a `passport_hash` and, when configured, a registry signature you can verify offline. |
| `trust_ladder()` | 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.

## Install

```jsonc
// Claude Desktop / any MCP client — mcp config
{
  "mcpServers": {
    "intesta": { "command": "uvx", "args": ["intesta-mcp"] }
  }
}
```

Or run directly:

```bash
uvx intesta-mcp
```

## Example

> Agent 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](https://raposa.group) for a human approval step) rather than
assume the counterparty is who it claims to be.

## Development

```bash
python3 -m venv .venv && .venv/bin/pip install -e ".[test]"
.venv/bin/python -m pytest -q          # contract tests, no network
```

MIT · a DC ESCRYPT product · https://intesta.io

TDQS

A3.9/5.0

Scored across 5 tools

Disambiguation5/5

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.

Naming Consistency4/5

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.

Tool Count5/5

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.

Completeness4/5

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.

Maintenance

ActivityMaintained
ResponsivenessNo issues