Skip to main content
Glama

Get Trademark By Registration

get_trademark_by_registration
Read-onlyIdempotent

Look up a US trademark by registration number. Returns status, owner, mark text, goods/services, and classification. Requires USPTO API key.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
api_keyNoUSPTO API key
registration_numberYesUSPTO registration number (e.g., "1234567")

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
statusNoCurrent status of the trademark
attorneyNoAttorney name if applicable
mark_textNoText or verbal element of the mark
owner_nameNoOwner/applicant name
filing_dateNoApplication filing date
status_dateNoDate of the current status
raw_availableNoWhether raw XML data was available
serial_numberNoUSPTO serial number
goods_servicesNoGoods and services description
registration_dateNoTrademark registration date
international_classNoInternational classification number
registration_numberNoTrademark registration number

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
      +  "properties": {
      +    "attorney": {
      +      "description": "Attorney name if applicable",
      +      "type": [
      +        "string",
      +        "null"
      +      ]
      +    },
      +    "filing_date": {
      +      "description": "Application filing date",
      +      "type": [
      +        "string",
      +        "null"
      +      ]
      +    },
      +    "goods_services": {
      +      "description": "Goods and services description",
      +      "type": [
      +        "string",
      +        "null"
      +      ]
      +    },
      +    "international_class": {
      +      "description": "International classification number",
      +      "type": [
      +        "string",
      +        "null"
      +      ]
      +    },
      +    "mark_text": {
      +      "description": "Text or verbal element of the mark",
      +      "type": [
      +        "string",
      +        "null"
      +      ]
      +    },
      +    "owner_name": {
      +      "description": "Owner/applicant name",
      +      "type": [
      +        "string",
      +        "null"
      +      ]
      +    },
      +    "raw_available": {
      +      "description": "Whether raw XML data was available",
      +      "type": "boolean"
      +    },
      +    "registration_date": {
      +      "description": "Trademark registration date",
      +      "type": [
      +        "string",
      +        "null"
      +      ]
      +    },
      +    "registration_number": {
      +      "description": "Trademark registration number",
      +      "type": [
      +        "string",
      +        "null"
      +      ]
      +    },
      +    "serial_number": {
      +      "description": "USPTO serial number",
      +      "type": [
      +        "string",
      +        "null"
      +      ]
      +    },
      +    "status": {
      +      "description": "Current status of the trademark",
      +      "type": [
      +        "string",
      +        "null"
      +      ]
      +    },
      +    "status_date": {
      +      "description": "Date of the current status",
      +      "type": [
      +        "string",
      +        "null"
      +      ]
      +    }
      +  },
      +  "type": "object"
      +}
  2. Changed1 schema field changed
    • addedInput schema / examples
      Added value: +[
      +  {
      +    "api_key": "your-trademarks-api-key",
      +    "registration_number": "1234567"
      +  },
      +  {
      +    "registration_number": "5678901"
      +  }
      +]
  3. First observed

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already indicate readOnlyHint, idempotentHint, and non-destructive nature. The description adds value by stating the API key requirement and listing the types of data returned (status, owner, etc.). It does not contradict any annotations. It could mention rate limits or data freshness, but it is still helpful.

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?

Two concise sentences: first states the main action and identifier, second lists returns and a key requirement. No unnecessary words, front-loaded with the core purpose.

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 an output schema present, detailed return values are not needed. The description covers the identifier, returns, and a prerequisite (API key). It could mention registration number format (e.g., 7 digits), but the schema example suffices. The description is complete enough for a simple lookup tool.

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

Parameters4/5

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

Schema coverage is 100% with both parameters described. The description reinforces the purpose of registration_number ('by registration number') and clarifies that api_key is required despite not being marked as required in schema. This adds marginal but useful context beyond the schema definitions.

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 clearly states the verb 'Look up', the resource 'US trademark', and the identifier 'registration number'. It also lists the return fields (status, owner, mark text, goods/services, classification). This sufficiently distinguishes it from siblings like get_trademark_by_serial and search_trademarks.

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 mentions the requirement for a USPTO API key, guiding the user on prerequisites. However, it does not explicitly state when to use this tool versus alternatives such as get_trademark_by_serial or search_trademarks, leaving the agent to infer based on the identifier type.

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.