ENTIA Entity Verification

Get Entity Home Projection v1

get_entity_home_projection

Read-onlyIdempotent

PAID (requires SIGNAL plan or higher, from €29/month). Use when you need the full structured projection of an Entia Home page (identity, location, verification) for one business. Read the materializer snapshot entia.entity_home_projection.v1 for an Entia Home (claims + projection + policy). Same truth as the public ficha HTML/JSON-LD twin. Serve from R2 sibling .projection.v1.json — no ad-hoc MCP enrichment.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "country": "<country>",
      "sector": "<sector>",
      "city": "<city>",
      "slug": "<slug>"
    },
    "name": "get_entity_home_projection"
  }
}

Input Schema

Name	Required	Description
`city`	Yes	City slug (madrid, barcelona)
`slug`	Yes	Business slug (clinica-dental-ceodent)
`sector`	Yes	Industry slug (dental, legal, …)
`country`	Yes	ISO 3166-1 alpha-2 (es, gb, fr)
`include_render_context`	No	If true, keep render_context (large). Default strips it for agents.

Output Schema

Name	Required	Description
`gate`	No	PUBLISH / PARTIAL / HOLD / REGISTRY_ONLY
`_meta`	No
`claims`	No
`policy`	No
`schema`	No
`subject`	No
`projection`	No
`generated_at`	No
`corroboration`	No
`materializer_version`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedOct 14, 2026

changedInput schema / properties / city / pattern

Previous value: -"^[a-z0-9-]+$"New value: +"^[A-Za-z0-9-]+$"

changedInput schema / properties / country / pattern

Previous value: -"^[a-z]{2}$"New value: +"^[A-Za-z]{2}$"

changedInput schema / properties / sector / pattern

Previous value: -"^[a-z0-9-]+$"New value: +"^[A-Za-z0-9-]+$"

changedInput schema / properties / slug / pattern

Previous value: -"^[a-z0-9-]+$"New value: +"^[A-Za-z0-9-]+$"

Changed1 schema field changedAug 18, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "description": "entia.entity_home_projection.v1 snapshot: claims, corroboration gate and policy.",
+  "properties": {
+    "_meta": {
+      "type": "object"
+    },
+    "claims": {
+      "type": "object"
+    },
+    "corroboration": {
+      "type": "object"
+    },
+    "gate": {
+      "description": "PUBLISH / PARTIAL / HOLD / REGISTRY_ONLY",
+      "type": "string"
+    },
+    "generated_at": {
+      "type": "string"
+    },
+    "materializer_version": {
+      "type": "string"
+    },
+    "policy": {
+      "type": "object"
+    },
+    "projection": {
+      "type": "object"
+    },
+    "schema": {
+      "type": "string"
+    },
+    "subject": {
+      "type": "object"
+    }
+  },
+  "type": "object"
+}

AddedJul 20, 2026

TDQS

A3.7/5.0

Behavior4/5

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

Annotations already declare readOnly, idempotent and non-destructive, but the description adds information they cannot carry: the SIGNAL-plan paywall, the backing source (the entia.entity_home_projection.v1 materializer snapshot served from R2), and the warning against ad-hoc MCP enrichment. These are exactly the operational facts an agent needs before spending a paid call.

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?

It is front-loaded with the most costly fact, the paid plan requirement, and stays under five sentences. The middle is dense internal jargon (materializer snapshot, R2 sibling .projection.v1.json) that partly obscures rather than clarifies, but nothing is padded.

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?

An output schema exists, so return values need no explanation, and the description still covers the pricing gate, data provenance and the authoritative-source relationship to the public ficha. The one gap is the unresolved relationship with the sibling get_entia_home, which matters for a paid tool.

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%, with patterns and examples documenting each of the four required slugs, so the schema does the heavy lifting and the baseline of 3 applies. The description adds no parameter-level detail beyond implying the payload is structured, and it never explains the include_render_context trade-off itself.

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 names a specific verb and resource: read the full structured projection of one Entia Home page, covering identity, location and verification. An agent can grasp the payload content, but it never contrasts this with the close sibling get_entia_home, so the distinction has to be inferred from the name alone.

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?

'Use when you need the full structured projection ... for one business' gives a usable trigger condition, and the paid-plan preamble is a real gating note. However, no alternative is named and no exclusion is stated, even though get_entia_home and get_full_dossier sit in the same sibling set, leaving overlap unresolved.

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

All ENTIA Entity Verification tools Inspect

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.