Skip to main content
Glama

Explain how two names score

compare_names
Read-onlyIdempotent

Scores two names the same way OFAC screening does, displaying whole-name, name-part and paired-part scores to help explain why a potential match scored as it did.

Instructions

Scores two names against each other with the same method used for screening, and shows the whole-name score, the name-parts score and how each part paired. Useful to understand or explain a score.

Input Schema

NameRequiredDescriptionDefault
nameYesThe searched name.
companiesNoTreat the names as company names, ignoring legal forms such as LLC or LTD.
otherNameYesThe name to compare with, e.g. a listed name or alias.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.7/5.0
Behavior4/5

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

Annotations already declare readOnlyHint and idempotentHint, so the description needn't cover safety. It adds genuinely new behavioral context by disclosing what comes back: a whole-name score, per-part scores, and how parts were paired, which is exactly what an explanation tool needs to promise.

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?

One compact sentence that front-loads the action and then enumerates the outputs, followed by a short use note. No filler, though the two clauses could be tightened slightly.

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?

With no output schema, the description carries the return-value burden and does so by naming the three outputs. A three-parameter, read-only tool is otherwise fully covered; only the companies flag's effect on comparison is left unmentioned.

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%, so name, otherName, and the companies flag are already documented in the schema. The description adds nothing about the companies mode or the searched-name vs alias distinction, which is acceptable at full coverage but yields only baseline credit.

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?

States a specific verb and resource: scores two names against each other and reports whole-name score, name-parts score, and pairings. This is clearly a comparison/explanation tool, distinguishably different from the screening siblings, though it never names those siblings explicitly.

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?

Implies usage with 'useful to understand or explain a score' and ties the method to screening, giving the agent enough context to infer this is a diagnostic follow-up to screening. It never states when to prefer screen_name/screen_names instead or any preconditions, so the guidance stays implicit.

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