Skip to main content
Glama

Screen a shortlist of names

check_names
Read-onlyIdempotent

Screens a shortlist of up to 15 candidate names in one call: the trademarks on file near each name, the companies registered under it, and whether its domains are registered. Ranks them fewest conflicts first: by how close the nearest mark is, then by companies registered under the name and domains taken, then by how many near marks there are. No account needed.

Optional `classes` (Nice class numbers) make marks filed only in unrelated classes
weigh less; without them, a mark in any class counts. The Swiss company register and
the .ch and .com domains are always checked; `countries` ("UK", "SG") adds those
company registers, and .sg for Singapore.

Returns, for each name, a trademark verdict on what is on file (none_found, similar,
close or identical), how many near marks were found, where they are filed and the
closest three; per country, the companies registered under the same or a similar
name (name and legal form only); and whether each domain is registered or appears
unregistered. A source that did not answer says not_checked, never that nothing is
on file, and names whose trademark screen did not finish are listed under
not_checked. none_found means none were found, not that the name is free to use, and
an unregistered domain can be taken at any time: it is a screen, not clearance, and
a filing from the last few days can be missing.

Input Schema

NameRequiredDescriptionDefault
namesYes
classesNo
countriesNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already declare read-only, idempotent, open-world, and non-destructive behavior, but the description adds important caveats: not_checked semantics, none_found not meaning clearance, recent filings possibly missing, and unregistered domains being takeable. This is substantial behavioral disclosure beyond the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose is front-loaded, and the remaining details on ranking, parameter effects, return shape, and caveats are dense but necessary for a tool with no output schema. No obvious filler is present.

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

Completeness5/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 must explain return values, and it does: per-name trademark verdicts, near-mark counts, closest marks, company results, domain status, and not_checked behavior. It is complete enough for an agent to call and interpret the tool correctly.

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

Parameters5/5

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

Schema description coverage is 0%, so the description must carry parameter meaning. It defines the names limit, the effect of classes as Nice class numbers, and countries with examples and their effect on company registers and domains, covering all three parameters.

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 opens with a specific verb and resource ('Screens a shortlist of up to 15 candidate names in one call') and enumerates the three checks: trademarks, companies, and domains. It is clear, but it does not explicitly distinguish this from sibling tools such as screen_mark.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives clear context for shortlist screening, notes that no account is needed, and explains how optional classes and countries alter coverage. However, it does not state when to prefer this tool over screen_mark or other alternatives.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.