Skip to main content
Glama

GleanMark Trademark Search

Owner Landscape for a Mark

get_mark_owner_landscape
Read-onlyIdempotent

Show which owners hold marks matching a shared trademark term and summarize what else those owners have in their broader portfolios. Use this for crowded owner-landscape questions like "Which companies own a trademark for COMET?" or "Who owns trademarks for GLEAN?" Returns the matching owners ranked by footprint, with each owner's wider portfolio context.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoMaximum number of owners to return.
mark_textYesTrademark term to analyze across owners, such as COMET or GLOW.
match_modeNoHow to match the mark text: contains, exact, or starts_with.contains
nice_classesNoOptional Nice classes to narrow the landscape.
status_filterNoOptional status filter. Default is live.live

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
titleYes
ownersNo
summaryYes
headlineYes
returnedYes
mark_textYes
match_modeYes
leader_nameNo
nice_classesYes
status_filterYes
leader_detail_urlNo
total_matching_marksYes
total_matching_ownersYes
total_matching_live_marksYes
leader_matching_mark_countYes
leader_total_portfolio_mark_countYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedOutput schema / properties / owners
      Added value: +{
      +  "items": {
      +    "properties": {
      +      "live_mark_count": {
      +        "type": "integer"
      +      },
      +      "matching_mark_count": {
      +        "type": "integer"
      +      },
      +      "owner_detail_url": {
      +        "anyOf": [
      +          {
      +            "type": "string"
      +          },
      +          {
      +            "type": "null"
      +          }
      +        ]
      +      },
      +      "owner_name": {
      +        "type": "string"
      +      },
      +      "pending_mark_count": {
      +        "type": "integer"
      +      },
      +      "rank": {
      +        "type": "integer"
      +      },
      +      "registered_mark_count": {
      +        "type": "integer"
      +      },
      +      "share_percent": {
      +        "type": "number"
      +      }
      +    },
      +    "required": [
      +      "rank",
      +      "owner_name",
      +      "matching_mark_count"
      +    ],
      +    "type": "object"
      +  },
      +  "type": "array"
      +}
  2. Added

TDQS

A4/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, covering the safety profile. The description adds the behavioral detail that results are 'ranked by footprint' and include 'wider portfolio context,' which is useful. It does not disclose pagination or any rate limits, but given the annotations, the added context is sufficient. No contradictions with 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 description is two sentences long, front-loads the core action ('Show which owners hold marks...') and then provides usage guidance and an example. There is zero waste; every sentence earns its place. The structure is logical: purpose first, then when to use, then what it returns.

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?

The tool has an output schema (context signals confirm this), so the description does not need to detail the return structure. It does state the output concept ('Returns the matching owners ranked by footprint, with each owner's wider portfolio context'), which is sufficient for an agent to understand the result. With 5 parameters, 1 required, and full schema coverage, the description is complete for a read-only landscape tool.

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 all five parameters are already documented in the schema. The description adds marginal value by giving examples of mark_text ('COMET or GLOW') and mentions ranking by footprint, but it does not elaborate on individual parameter semantics beyond what the schema provides. Baseline 3 is appropriate since the schema does the heavy lifting.

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 tool's purpose: 'Show which owners hold marks matching a shared trademark term and summarize what else those owners have in their broader portfolios.' It uses specific verbs (show, summarize) and a specific resource (owners holding matching marks). This distinguishes it from siblings like get_similar_marks (which focuses on marks, not owners) and search (which is broader). The examples ('COMET', 'GLEAN') further clarify the scope.

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?

The description explicitly states when to use it: 'Use this for crowded owner-landscape questions like ...' and gives concrete examples. It does not explicitly name alternatives or state when not to use it, but the purpose is clear enough that an agent can infer it is not for single-mark analysis or similarity searches. A clear 'when not to use' clause is missing, but the provided guidance is strong.

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