Trademark filing monitor across 40+ countries - detect filings that resemble your brand.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 3.5/5 across 5 of 5 tools scored. Lowest: 2.9/5.
Each tool has a clearly distinct purpose: alert handles trademark watch alerts, billing retrieves billing data, conflict manages conflict records, getPricingList lists pricing territories, and settings manages account settings. No overlap in functionality.
Tool names are mostly single-word nouns (alert, billing, conflict, settings), but getPricingList breaks this pattern with a camelCase verb_noun structure, creating inconsistency.
Five tools is a reasonable count for a trademark monitoring service, covering alerts, conflicts, billing, pricing, and settings. It is slightly minimal but not inadequate.
The tool set covers core user-facing operations: CRUD for alerts, listing/reading conflicts, billing info, pricing list, and settings. No obvious missing operations like creating trademarks (likely handled internally) or more detailed reporting, but the surface is adequate.
alertBInspectCRUD API for IP Defender alerts (trademark watch alerts). Create, read, update, delete, or list alerts. Each alert monitors a brand name across selected countries and reports conflicting trademark applications.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | Alert ID. Required for 'read', 'update', and 'delete' operations. Ignored for 'create' and 'list'. | |
| op | Yes | CRUD operation to perform on alerts. | |
| data | No | Alert payload. Required for 'create' and 'update' operations. Ignored for 'read', 'delete', and 'list'. |
| Name | Required | Description |
|---|---|---|
| data | No | Alert data. For 'list' it is an array of alert objects (summary form). For 'read', 'create', and 'update' it is a single alert object (complete form). For 'delete' it is a confirmation object {deleted: true}. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral transparency. It only labels the tool as 'CRUD API' without disclosing traits like authentication requirements, rate limits, whether operations are destructive, or what happens to existing alerts on update. The description adds minimal behavioral context beyond the schema's operation definitions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two sentences that front-load the core purpose and then clarify the concept. Every word is necessary; no filler or repetition. It's appropriately sized for a CRUD tool with a clear input schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (3 parameters, nested object) and the existence of an output schema (not detailed), the description provides a high-level overview but lacks operational context. For instance, it doesn't mention that country codes require getPricingList or explain the relationship between textTriggers and brandName. The description is adequate but could be more complete for an agent to confidently invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds context by explaining what an alert does (monitors brand name across countries), which aligns with the 'brandName' and 'countries' parameters. However, it doesn't deepen understanding of 'data' nested fields beyond what the schema already provides, so it meets the baseline without significant added value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it's a CRUD API for IP Defender alerts (trademark watch alerts) and defines an alert as monitoring a brand name across selected countries to report conflicting trademarks. This specific verb-resource pairing distinguishes it from sibling tools like billing, conflict, or getPricingList.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The description implies its purpose but doesn't provide when-not or exclusion criteria. For example, it doesn't mention that getPricingList should be consulted for country codes, nor does it explain scenarios where conflict tool might be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
billingAInspectRetrieve billing information for the authenticated user: current daily service rate and account status (op='rate'), the list of invoices (op='invoices'), or a single invoice with line items and buyer details (op='invoiceDetail').
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | Invoice ID. Required for 'invoiceDetail'. Ignored for 'rate' and 'invoices'. | |
| op | Yes | Operation to perform: 'rate' for current billing rate; 'invoices' for the invoice list; 'invoiceDetail' for a single invoice. |
| Name | Required | Description |
|---|---|---|
| data | Yes | Billing data. Shape depends on op: 'rate' returns a rate object; 'invoices' returns an array of invoice summaries; 'invoiceDetail' returns a single invoice object with invoiceLines and buyer. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits beyond what the schema offers, such as authentication requirements or side effects. The read-only nature is implied but not stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the main purpose and efficiently covers all operations. No superfluous text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and the detailed description of return values for each operation, the tool definition is sufficiently complete for an agent to use effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema coverage, the schema already documents parameters well. The description adds additional context by describing what each 'op' value returns, enhancing meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves billing information and enumerates three distinct operations (rate, invoices, invoiceDetail), effectively distinguishing the purpose from sibling tools like alert or settings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use each operation via the 'op' parameter, but does not explicitly exclude scenarios or mention alternative tools. The context is clear enough for an agent to decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
conflictAInspectList, read, or update IP Defender conflict records (conflicting trademark applications detected by an alert). Returns per-state counts and full conflict details including the conflicting mark's source, image, and match pairs.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | Conflict ID. Required for 'read' and 'update'. Ignored for 'list'. | |
| op | Yes | Operation to perform: 'list' returns all conflicts for the user (or for a single alert when 'alertId' is given); 'read' returns one conflict with its parent alert; 'update' changes the state of one conflict. | |
| data | No | Conflict payload. Required for 'update'. Ignored for 'list' and 'read'. | |
| alertId | No | Alert ID. When provided with op='list', only conflicts belonging to this alert are returned. Ignored for 'read' and 'update'. |
| Name | Required | Description |
|---|---|---|
| data | Yes | Conflict data. For 'list' it is an array of conflict objects. For 'read' and 'update' it is a single conflict object. |
| alert | No | Parent alert object (op='read'). Same shape as the alert summary returned by the alert tool. |
| counts | No | Per-state conflict counts (op='list'). Keys are state names; values are integers. |
| baseURL | Yes | Base URL of the IP Defender server (e.g. 'https://www.ipdefender.eu'). All relative URLs in the response (imageURL, iconURL) must be prefixed with this baseURL to form complete URLs. For example, if baseURL is 'https://www.ipdefender.eu' and imageURL is '/dist/ipdefender-base/brand?abc123', the full URL is 'https://www.ipdefender.eu/dist/ipdefender-base/brand?abc123'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses that 'update changes the state of one conflict' (a side effect) and that it returns per-state counts and full details. However, it does not mention authentication needs, rate limits, or error conditions, leaving some behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, with no wasted words. It front-loads the essential verb-resource pair ('List, read, or update IP Defender conflict records') and then describes the output. Every sentence adds value, and it is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (4 parameters, nested objects, enums, output schema), the description covers the core operations and return details. The schema provides parameter specifics, and an output schema exists. Minor omissions (e.g., not stating that 'id' is required for read/update) are addressed by the schema, so completeness is high.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, so the baseline is 3. The description does not add additional meaning beyond the schema's own descriptions for each parameter (e.g., 'op', 'id', 'data', 'alertId'). No extra semantic context is provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool's purpose: 'List, read, or update IP Defender conflict records.' It uses specific verbs (list, read, update) and a clear resource (conflict records). The tool name 'conflict' and the mention of trademark applications distinguish it from siblings like 'alert' or 'billing'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. Sibling tools exist (e.g., 'alert', 'billing'), but no comparison or context is given to help the agent decide. The description only states what the tool does, not when to prefer it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
getPricingListCInspectList all territories with pricing info for monitoring trademark in those territories. Billed daily, You only pay for active monitoring in your selected markets, with usage tracked on a daily basis for maximum flexibility. Your first statement arrives 30 days after activation, followed by quarterly billing thereafter. All monitored jurisdictions automatically include international trademarks (WIPO Madrid Protocol) at no extra cost. EU countries include trademarks registered in the European Union as a whole (European Union trade marks / EUTM) at no extra cost. Every plan includes 5 specialized AI watch agents and 11 detection layers, delivering unparalleled protection.
| Name | Required | Description | Default |
|---|---|---|---|
| _ | No | Reserved placeholder. The tool takes no arguments; send {}. |
| Name | Required | Description |
|---|---|---|
| data | Yes | Response envelope from the ipd:countries handler. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses billing frequency, timeline, and included features (AI agents, detection layers), which are behavioral traits. However, these are more marketing than operational behavior, and the core read-only nature is implied but not explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is verbose with marketing language ('maximum flexibility', 'unparalleled protection'). The first sentence is clear, but subsequent sentences add non-essential billing and feature details that distract from the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple nature (no arguments, output schema exists), the description is over-complete with unnecessary details. It adequately covers return content (territories, pricing, billing) but could be much shorter and more focused.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a placeholder parameter '_' already described as 'no arguments required'. The description adds no additional meaning beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description begins with 'List all territories with pricing info', which is a specific verb+resource. However, it does not explicitly differentiate from sibling tools like 'billing' or 'settings', which could also involve pricing or configuration.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. The description focuses on what the tool does and marketing details, but does not state context or alternatives for the AI agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
settingsBInspectGet or set the authenticated user's account settings (notification emails, billing emails, invoice address, given/family name, company details, etc.). op='get' reads requested properties; op='set' writes provided property values.
| Name | Required | Description | Default |
|---|---|---|---|
| op | Yes | Operation to perform: 'get' reads settings; 'set' writes settings. | |
| data | No | Property values to write (op='set'). Keys must be valid UserPropsEnum values. Ignored for 'get'. | |
| props | No | Property names to read (op='get'). Each must be a valid UserPropsEnum value: givenName, familyName, username, phone, billingEmails, invoiceAddress, paymentTerms, notificationEmails, notificationFrequency, notificationFrequencyFmt, status, company, companyNumber, companyVatNumber, landingPage, referrerPage. Ignored for 'set'. |
| Name | Required | Description |
|---|---|---|
| data | No | Requested settings values (op='get'). Keys are the property names requested in 'props'; values are the current values (strings, arrays, or objects depending on the property). Absent for op='set'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description must cover behavior. It mentions that 'data' is ignored for 'get' and 'props' ignored for 'set', and implies authentication. However, it does not disclose side effects, permissions, or idempotency of 'set'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core purpose. No redundant information. Efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and sibling tools, the description covers the get/set functionality adequately. However, it omits details about read-only settings and does not clarify how it relates to the 'billing' sibling.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, meaning each parameter is already documented. The description adds minimal extra value by listing example property names for 'props', but largely restates schema content.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it gets or sets user account settings, listing categories and differentiating between 'get' and 'set'. It does not explicitly distinguish from sibling tools like 'billing', but the purpose is specific and actionable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description explains when to use 'get' vs 'set' within the tool, but provides no guidance on when to use this tool over siblings such as 'billing' or 'alert'. Usage context is implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
