intesta-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| INTESTA_API_KEY | No | Optional API key (ik_…) for metered or private use. Public registry reads work without it. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| search_registryA | 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. |
| check_trustA | 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. |
| get_factsA | 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. |
| ask_entityA | 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. |
| trust_ladderA | 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. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored 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.