IP Defender Trademark Monitoring MCP
Server Details
Trademark filing monitor across 40+ countries - detect filings that resemble your brand.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
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.
Tool Definition Quality
Average 3.8/5 across 6 of 6 tools scored.
Each tool targets a distinct aspect of the service: alerts create monitoring rules, conflicts show results, billing handles finances, pricing lists costs, settings manages user preferences, and echo is a debug utility. No two tools have overlapping responsibilities.
Five tools use a single lowercase noun (alert, billing, conflict, echo, settings), while one tool uses camelCase with a verb prefix (getPricingList). This inconsistency in naming convention reduces coherence.
With 6 tools, the server covers the essential operations for trademark monitoring: alert management, conflict viewing, billing, pricing, settings, and debugging. The number is well-scoped and not excessive.
The tool set provides CRUD for alerts, read/update for conflicts, billing info, settings, and pricing. Minor gaps exist: no tool to configure AI watch agents or manage notifications beyond email settings, but core workflows are covered.
Available Tools
6 toolsalertAInspect
CRUD 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'. |
Output Schema
| 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}. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. It states high-level CRUD behavior and that alerts monitor brand names and report conflicts, but lacks details on idempotency, rate limits, authentication requirements, or error handling.
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, front-loading the key purpose (CRUD API) and then elaborating on the alert function. Every sentence is useful and there is no redundancy.
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 (CRUD with nested objects, enum parameter, and output schema), the description provides a solid high-level understanding. It covers the core concept and operations, but could mention the required sub-fields in 'data' for create/update.
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%, so baseline is 3. The description adds context about the purpose of alerts (monitoring brand names) but does not significantly augment the parameter descriptions already present in 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 identifies the tool as a CRUD API for IP Defender alerts (trademark watch alerts), and explains the purpose of each alert (monitor brand names across countries and report conflicts). This distinguishes it from sibling tools like 'echo' and '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?
The description implies usage context by stating it is a CRUD API for alerts, and the sibling tools are unrelated. However, it does not explicitly specify when to use this tool versus alternatives or provide exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
billingAInspect
Retrieve 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. |
Output Schema
| 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. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations so description carries burden. Mentions 'authenticated user' (implied auth requirement), but does not discuss side effects, rate limits, or error behavior. Adequate but not thorough.
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?
Single sentence front-loaded with main action. Lists operations concisely, though slightly dense. Could use clearer structure for each op.
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?
Provides enough detail for the three query operations. With output schema present, return format is implied. No pagination info for invoices, but acceptable for a simple 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 coverage is 100%, so description adds little beyond schema descriptions. Baseline 3, description mostly paraphrases 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?
Clearly states it retrieves billing information for the authenticated user, lists three specific operations (rate, invoices, invoiceDetail), and uses precise verbs and resources.
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 vs sibling tools (alert, conflict, etc.). Only describes internal operations, not broader context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
conflictBInspect
List, 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'. |
Output Schema
| 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'. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose all behavioral traits. It mentions list/read/update operations but does not explain side effects of updates (e.g., state changes) or any destructive potential. Minimal transparency beyond operation types.
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 one concise sentence that front-loads the core purpose and includes output details. It could be restructured for clarity (e.g., separate operations), but remains 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, output schema), the description covers basic functionality and output but lacks details on update behavior, prerequisites, or error conditions. Adequate but not comprehensive.
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%, so the baseline is 3. The description adds no additional meaning to parameters beyond what the schema provides. It does not explain relationships between parameters or usage patterns.
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 performs list, read, or update operations on conflict records, specifying the resource (IP Defender conflict records) and distinct actions. It differentiates from sibling tools like 'alert' by focusing on conflict records rather than alerts.
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 implies the tool is for managing conflict records but does not explicitly state when to use it versus alternatives. It lacks guidance on when not to use or specific context for each operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
echoAInspect
MCP debug tool: echoes the message argument back to the client. Useful as a smoke test for the MCP gateway. Use only for MCP debugging. Do not use under normal circumstances.
| Name | Required | Description | Default |
|---|---|---|---|
| message | Yes | Message text to echo back. |
Output Schema
| Name | Required | Description |
|---|---|---|
| echo | Yes | The same string the client sent. |
| receivedAt | Yes | ISO 8601 timestamp on the server. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description fully discloses behavior: it echoes input, is a debug tool, and has no side effects. No contradictions.
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?
Three concise sentences, front-loaded with purpose, then usage. No extraneous information. Every sentence adds value.
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?
For a low-complexity tool with full schema and output schema present, the description covers purpose, usage, and parameter. No gaps remain.
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 schema describes the parameter 'message' as 'Message text to echo back.' The description confirms it echoes that message. With 100% schema coverage, the description adds context (debug) but the parameter meaning is already clear from 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?
Clearly states it is an MCP debug tool that echoes the message argument back. The description effectively distinguishes from sibling tools by specifying its debug-only purpose and contrast with normal-use tools like billing 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?
Explicitly says 'Use only for MCP debugging. Do not use under normal circumstances.' This gives clear when-to-use (smoke test) and when-not-to-use guidance, plus implies alternatives (other tools).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
getPricingListAInspect
List 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 {}. |
Output Schema
| Name | Required | Description |
|---|---|---|
| data | Yes | Response envelope from the ipd:countries handler. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It describes the tool as listing data (a read operation) without mentioning side effects, authentication needs, or rate limits. The billing details are tangentially related but do not disclose core behavioral traits beyond being a data retrieval tool.
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 front-loaded with the core purpose, but includes several sentences about billing and features that are tangential to tool invocation. While not excessively long, the extra details reduce conciseness and could be relocated. It is adequate but not optimally concise.
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 low complexity (no required parameters, presence of an output schema), the description provides sufficient context by explaining the domain (trademark monitoring pricing) and additional features. It covers the essential information an agent needs to understand the tool's purpose and expected output.
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% coverage with a single null placeholder parameter, so the description does not need to add param details. The description provides context about the output (pricing info for trademark monitoring) but does not enhance parameter understanding since there are no meaningful parameters.
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 begins with 'List all territories with pricing info for monitoring trademark in those territories', clearly stating the verb 'list' and the resource 'territories with pricing info'. This directly addresses the tool's purpose and distinguishes it from unrelated siblings 'alert' and 'echo'.
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 implies usage for retrieving pricing data for trademark monitoring, but does not explicitly state when to use this tool versus alternatives or provide prerequisites or exclusions. Since there are no direct siblings, the context is clear but lacks explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
settingsAInspect
Get 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'. |
Output Schema
| 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'. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It notes the tool operates on the authenticated user's settings but lacks details on permissions, side effects, rate limits, or error conditions. The basic read/write behavior is implied but not elaborated.
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 with no wasted words. It front-loads the core purpose and operation, making it efficient for an agent to parse.
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, the description does not need to detail return values. However, it could be more complete by explicitly stating that 'get' returns the requested properties and 'set' returns a confirmation or updated settings. As is, it is adequate but leaves some gaps.
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 the definition already documents parameters well. The description adds context about the 'op' parameter and the purpose of 'data' and 'props', but mostly reiterates schema content without deeper semantic enrichment.
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 gets or sets the authenticated user's account settings, specifying the 'op' parameter to differentiate between read and write operations. It is distinct from sibling tools like 'billing' or 'alert' which handle other concerns.
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 'get' versus 'set' based on the operation. However, it does not provide guidance on when to use this tool versus alternatives, nor does it mention any prerequisites or exclusions.
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.
Discussions
No comments yet. Be the first to start the discussion!