The MCP Server That Gives AI Agents Real-Time Identity Resolution

Q: What is the Tilores MCP server endpoint?

The endpoint is https://api.tilotech.io/mcp. It uses the Model Context Protocol over streamable HTTP and accepts JSON-RPC 2.0 requests from compatible clients and agent frameworks.

Q: Which MCP tool generates a customer search query?

tilores_graphql_query_recipes returns GraphQL templates for common access patterns, including search by an anchor field, entity lookup by ID, and entity lookup by source record ID.

TL;DR: The Tilores MCP server gives AI assistants protocol-native tools for designing, checking, and operating a Tilores identity resolution workflow. It does not hold customer data: Tilores resolves and assembles records at ingestion, then an agent uses an authenticated GraphQL query to retrieve the current resolved customer context.

See how Tilores fits your agent workflow. Book a Demo or Try Tilores Studio (Free).

An AI agent can only act on the customer context it can reach. If that context sits across a CRM, billing system, support platform, warehouse, and compliance tool, copying a few fields into the prompt does not establish which records belong to the same person. It gives the model fragments and asks it to infer identity.

The safer pattern puts identity resolution outside the model. Our public Tilores MCP server gives an assistant tools for understanding the schema, generating GraphQL queries, checking search parameters, designing entity transformation pipelines, and linting rule configurations. The agent then calls the authenticated GraphQL API for the customer data plane. That separation keeps configuration help in MCP and keeps personal data inside the controlled Tilores instance.

What MCP server provides identity resolution as a tool for AI agents?

The Tilores MCP server provides the protocol-specific tool surface an AI agent needs to work with Tilores identity resolution.

The endpoint is https://api.tilotech.io/mcp. It speaks the Model Context Protocol over streamable HTTP and accepts JSON-RPC 2.0 requests. Claude Desktop, Claude Code, Cursor, ChatGPT Desktop, Codex CLI, and custom agent frameworks can connect through the same endpoint when they support that transport.

There is an important boundary. The public server is stateless, read-only, and requires no API key. It stores no customer records and should never receive personal data in a prompt or tool argument. Real customer records go to the authenticated Tilores GraphQL API, where matching and entity assembly happen at ingestion. Query time retrieves the current resolved entity.

That is what makes the MCP server useful as a discrete integration surface. The agent does not need a pasted page of product instructions or an improvised query template. It can discover named tools, inspect their input schemas, call the right tool, and use the result in a controlled workflow.

Which tools does the Tilores MCP server expose?

The MCP server exposes focused tilores_* tools rather than one broad chat interface.

The live tool catalogue includes tools for capability discovery, documentation search, concept and error explanation, rule configuration linting, field mapping, ingestion planning, search validation, identifier validation, GraphQL query recipes, entity transformation recipes, use-case design, and synthetic match simulation. The following tools are the most relevant to an agent that needs resolved customer context.

MCP tool	What the agent receives	Where it fits
`tilores_get_capabilities`	Server version, available tools, suggested workflows, and telemetry policy	First call for tool discovery
`tilores_graphql_query_recipes`	A GraphQL query plus a variables template for a known access pattern	Preparing a customer search or entity lookup
`tilores_validate_search_params`	Errors, warnings, and rule wiring reminders for a search input	Checking a search before the data-plane call
`tilores_mapping_workflow`	Suggested canonical fields, transformer chains, and source-column mappings	Preparing source data for ingestion
`tilores_ingest_workflow`	The staged ingestion playbook for authentication, wrapping, submission, verification, and error handling	Building the record ingestion path
`tilores_lint_rule_config`	Exact findings, locations, severities, and fix hints	Checking identity rules before deployment
`tilores_design_recipe`	Recommended fields and conservative rule shapes for named use cases	Starting a KYC, fraud, insurance, or customer-resolution design
`tilores_search_docs`	Ranked documentation passages with source paths and snippets	Answering a precise implementation question

The tool catalogue is broader than a query generator because real identity resolution starts before a query. Source fields must be mapped. Normalisation and matching rules must fit the data. Search rules must be registered correctly. Records must reach the instance through a reliable ingestion path. The query is the final retrieval step, not the place where identity gets assembled.

How does an agent connect from Claude Desktop or Claude Code?

An MCP-compatible client connects by registering the Tilores endpoint as an HTTP MCP server.

For a client that accepts JSON configuration, the connection can be represented like this:

{
  "mcpServers": {
    "tilores": {
      "type": "http",
      "url": "https://api.tilotech.io/mcp"
    }
  }
}

Claude Desktop reads this server definition from its MCP configuration. Claude Code can register the same endpoint through its MCP settings. A custom agent framework can use the same URL and the streamable HTTP transport, then perform the normal MCP initialise, tool discovery, and tool call sequence.

The connection is not an authentication shortcut into a Tilores instance. It only connects the assistant to the public tool catalogue. The authenticated GraphQL connection remains a separate credentialed integration owned by the application.

How does an agent call the MCP server before resolving a customer?

The agent first asks MCP for a validated GraphQL recipe, then sends the real customer search to its authenticated Tilores GraphQL endpoint.

A raw tool call can request the built-in email search recipe:

{
  "jsonrpc": "2.0",
  "id": 2,
  "method": "tools/call",
  "params": {
    "name": "tilores_graphql_query_recipes",
    "arguments": {
      "recipe": "search_by_anchor",
      "anchor": "email"
    }
  }
}

The tool returns a typed GraphQL query and a variables template. The current recipe has this shape:

query Search($email: String!) {
  search(input: {parameters: {email: $email}}) {
    entities {
      id
      score
      hitScore
      records { id }
      edges
      hits
      duplicates
    }
  }
}

The agent can also call tilores_validate_search_params with field names and placeholder values. That tool checks the input shape and warns when a single-anchor search depends on search and index rules being wired correctly. Again, the value supplied to the public MCP server should be fabricated. The real email address belongs only in the variables sent to the authenticated GraphQL API.

What happens when the agent resolves a customer in real time?

Real-time customer resolution is a short data-plane sequence built on work already completed at ingestion.

Step	System action	Identity state
1. Ingest	A source service submits a new or changed record through GraphQL	Tilores applies deterministic rules, fuzzy matching, and probabilistic scoring
2. Assemble	Tilores links the record to an entity, creates a new entity, or updates the entity graph	The current resolved context is maintained
3. Prepare	The agent uses MCP tools to obtain or check the correct GraphQL access pattern	No customer data needs to enter MCP
4. Query	The agent sends authenticated GraphQL variables to its Tilores instance	The query retrieves current resolved context
5. Act	The application applies permissions and passes only the allowed fields to the model	The agent answers or takes the next approved action

The search result can include entity IDs, records, graph edges, duplicate information, rule hits, an entity score, and a search hit score. The fields available on each record depend on the configured schema. The consuming application should request only what the agent needs and enforce the same access controls it would apply to any other customer-data query.

This architecture is the concrete version of an identity resolution tool for AI agents. It is also the safe way to feed resolved data into an agent RAG pipeline: resolve first, retrieve current context second, and let the model reason over an authorised slice of that context.

Why not let the model match customer records itself?

An LLM is a poor sole production matcher because it does not own stable entity IDs, calibrated link rules, correction history, or an auditable entity graph.

A prompt can compare two records. It cannot, by itself, maintain identity state across every new record, merge, split, deletion, and rule change. It also makes the query path carry work that belongs at ingestion. That creates inconsistent answers because the model can see a different subset of records on each call.

Tilores combines deterministic rules, fuzzy matching, and probabilistic scoring during ingestion. The agent then retrieves the resulting entity context. The model still has a useful role: it can decide which tool to call, explain evidence to an authorised user, summarise the returned context, or route an ambiguous case to review. It does not need to become the identity engine.

This same separation underpins IdentityRAG. Retrieval becomes identity-aware because the entity layer already knows which records belong together before the model asks a question.

How should an agent framework handle security and personal data?

An agent framework should treat the MCP endpoint as a public knowledge and configuration service, not as a customer-data destination.

Keep personal data, access tokens, instance URLs, and customer-specific secrets out of MCP prompts and arguments. Use synthetic field names and sample values when asking for mappings, recipes, or validation. Store GraphQL credentials in the application secret store. Send the real variables directly from the application to the authenticated Tilores instance.

The application should also enforce four controls:

Restrict which GraphQL operations the agent can invoke.
Limit returned fields to the agent’s approved task.
Log the tool choice, query template, variables policy, and downstream action without exposing unnecessary personal data.
Require review when the search returns multiple plausible entities or evidence below the workflow’s chosen threshold.

Tilores sits beside the MDM, CDP, KYC and AML platform, warehouse, and operational applications. Those systems keep their governance and workflow roles. The entity layer supplies resolved context to them and to the agent.

When should a team use MCP instead of a direct GraphQL integration?

Use MCP when an AI assistant needs discoverable product tools; use GraphQL when the application needs to submit or query real customer data.

Most production systems need both. MCP reduces guesswork for assistants that design schemas, generate queries, inspect errors, or validate rule configurations. GraphQL remains the explicit data interface for ingestion and current-context retrieval. A conventional service that already knows its fixed query can call GraphQL without MCP. An adaptive coding or operations agent benefits from the MCP tool catalogue because it can inspect the supported workflow before acting.

The test is simple. If the task asks, “How should I form this Tilores query?”, MCP is the right surface. If the task asks, “Which current customer matches these authorised identifiers?”, the application should execute the approved GraphQL query against its own Tilores instance.

FAQ

What MCP server provides identity resolution for AI agents?

The Tilores MCP server provides AI assistants with tools for designing, validating, and operating a Tilores identity resolution workflow. The public MCP endpoint does not store or query customer data. The agent uses an authenticated Tilores GraphQL connection for real customer searches.

What is the Tilores MCP server endpoint?

The endpoint is https://api.tilotech.io/mcp. It uses the Model Context Protocol over streamable HTTP and accepts JSON-RPC 2.0 requests from compatible clients and agent frameworks.

Does the MCP server need an API key?

No. The public MCP server is stateless, read-only, and does not require an API key. That is why customer data and personal information must never be sent to it.

Can the MCP server resolve a real customer by itself?

No. It supplies tools and artifacts that help the agent prepare the workflow. Real records are resolved and assembled in a Tilores instance at ingestion, and the current entity context is retrieved through the authenticated GraphQL API.

Which MCP tool generates a customer search query?

tilores_graphql_query_recipes returns GraphQL templates for common access patterns, including search by an anchor field, entity lookup by ID, and entity lookup by source record ID.

Can Claude Desktop and Claude Code use the same server?

Yes. Both can register the same Tilores MCP endpoint through their MCP configuration. Other clients can use it when they support the streamable HTTP transport.

Does an AI agent resolve identity at query time?

No. Tilores resolves and assembles entities at ingestion. At query time, the agent retrieves the current resolved context that the entity layer already maintains.

Does Tilores replace an MDM, CDP, KYC platform, or warehouse?

No. Tilores sits beside those systems as a dedicated entity resolution layer. It can feed current resolved context into their workflows and into AI agents without taking over their governance, analytics, case management, or system-of-record roles.