Skip to main content
Glama

WEIR AI

Check likeness clearance for a name

check_identity
Read-onlyIdempotent

Start here when anyone asks whether a real person's name, image or likeness can be used — in an ad, a campaign, generated media or a contract. Checks whether that person has publicly declared how their likeness may be used on WEIR AI. Required: name (full name, at least 3 characters). Returns status blocked, protect, earn (licensable), open, or no_public_declaration, plus terms_url when a public license matches. Private licenses always return no_public_declaration, so this never reveals whether someone is a member. no_public_declaration is not permission. To browse who is licensable rather than check one named person, use search_catalog. [Public, no account needed]

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": {
      "name": "<name>"
    },
    "name": "check_identity"
  }
}

Input Schema

NameRequiredDescriptionDefault
nameYesThe person's full name.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), and the description adds substantial context on top: the full status vocabulary (blocked/protect/earn/open/no_public_declaration), the terms_url field, and the privacy guarantee that private licenses always resolve to no_public_declaration so membership is never exposed. Also notes no account is needed.

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?

Front-loaded with the trigger condition, then requirements, return values, the privacy caveat, the anti-misuse warning, and the sibling hand-off. Every sentence carries a distinct fact; nothing is filler despite the density.

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?

No output schema exists, yet the description enumerates the possible return statuses and the conditional terms_url, plus the fallback behavior for private licenses. An agent has everything needed to call it and interpret the result.

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?

Single parameter with 100% schema description coverage, so the schema already defines it. The description restates the schema constraints ('full name, at least 3 characters'), adding no real meaning beyond what minLength/description provide; baseline 3 applies.

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?

Names a specific verb (check) and resource (likeness clearance for a real person's name/image/likeness), and grounds it in concrete use cases: ads, campaigns, generated media, contracts. Distinguishable from the catalog-browsing siblings at a glance.

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

Usage Guidelines5/5

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

Explicitly says 'Start here when anyone asks whether...' and gives the exclusion rule plus the alternative: browse licensable people with search_catalog instead of checking one named person. It also pre-empts a likely misread by stating no_public_declaration is not permission.

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.

Resources