Skip to main content
Glama

Server Details

Fuzzy entity resolution and dedupe for names, addresses, and company records — the "is this the same person/company" problem that breaks exact-match joins. Clean CRM exports, merge duplicates, reconcile vendor lists. Pay-per-call via x402 (USDC on Base): $0.008/call, no account or API key. tools/list and /openapi.json are free for discovery.

Status
Healthy
Last Tested
Transport
Streamable HTTP
URL

Glama MCP Gateway

Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.

MCP client
Glama
MCP server

Full call logging

Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.

Tool access control

Enable or disable individual tools per connector, so you decide what your agents can and cannot do.

Managed credentials

Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.

Usage analytics

See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.

100% free. Your data is private.
Tool DescriptionsA

Average 3.9/5 across 1 of 1 tools scored.

Server CoherenceA
Disambiguation5/5

Only one tool exists, so there is no possibility of confusion or overlap.

Naming Consistency5/5

A single tool named 'resolve' is inherently consistent with itself.

Tool Count3/5

A single tool for a dedicated deduplication function is borderline thin; while it serves a focused purpose, most servers have 3-15 tools.

Completeness3/5

The tool covers the core deduplication task but lacks supporting operations like configuration or manual override, leaving some gaps for a full workflow.

Available Tools

1 tool
resolveAInspect

Fuzzy-dedupe a list of records into clusters of likely-duplicate entities. Blocks by normalized token prefix, scores with Jaro-Winkler + token-set matching (exact on email/phone), unions matches above threshold, and returns a merged canonical record per cluster with a confidence score. Deterministic, no LLM calls.

ParametersJSON Schema
NameRequiredDescriptionDefault
optionsNo
recordsYes
Behavior5/5

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

With no annotations provided, the description fully discloses the algorithm steps: blocking by token prefix, scoring with Jaro-Winkler and token-set matching, exact matching on email/phone, union above threshold, and output of merged canonical records with confidence. It also clarifies determinism and absence of LLM calls, covering the behavioral aspects well.

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?

The description is a single, coherent paragraph of three sentences that efficiently conveys purpose and algorithm. It front-loads the core idea but could benefit from bullet points or clearer separation of details for enhanced readability. It is concise without being overly terse.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is moderately complex (dedup algorithm, nested params). The description explains the algorithm well but omits details about the input record format, output structure (beyond 'merged canonical record with confidence'), and potential edge cases or errors. Given no output schema, these gaps reduce completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 0% description coverage for parameters. The description does not explain the 'records' structure or the 'options.keys' and 'options.threshold' semantics, only briefly mentioning them contextually. This leaves agents to infer parameter meaning from the schema types alone, which is insufficient.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description explicitly states it is a fuzzy-deduplication tool that clusters duplicate records and returns merged canonical records with confidence scores. It details the algorithms (Jaro-Winkler, token-set matching, email/phone exact match) and behavior, leaving no ambiguity about the tool's purpose.

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?

The description implies the tool is for deduplicating records and mentions it is deterministic with no LLM calls, but it does not explicitly state when to use versus alternatives (e.g., other dedup approaches) or provide prerequisites or limitations. With no sibling tools, this level of guidance is adequate but not explicit.

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

Discussions

No comments yet. Be the first to start the discussion!

Try in Browser

Your Connectors

Sign in to create a connector for this server.

Resources