Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@LLM Brand Monitor MCP Server List all my brand monitoring projects."
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
MCP server for LLM Brand Monitor — a platform that tracks how AI models mention your brand.
Connect Claude, Cursor, Windsurf, or any MCP-compatible client to manage brand monitoring projects, run scans across 350+ LLMs, and analyze results — all through natural language.
Add to your claude_desktop_config.json:
{
"mcpServers": {
"lbm": {
"command": "npx",
"args": ["-y", "@serpstat/llm-brand-monitor-mcp"],
"env": {
"LBM_API_KEY": "lbm_your_key_here"
}
}
}
}claude mcp add lbm-mcp -e LBM_API_KEY=lbm_your_key_here -- npx -y @serpstat/llm-brand-monitor-mcpgit clone https://github.com/SerpstatGlobal/llm-brand-monitor-mcp.git
cd llm-brand-monitor-mcp
npm install && npm run buildThen add to your MCP client config:
{
"mcpServers": {
"lbm": {
"command": "node",
"args": ["/path/to/llm-brand-monitor-mcp/dist/index.js"],
"env": {
"LBM_API_KEY": "lbm_your_key_here"
}
}
}
}LBM_API_KEY=lbm_your_key_here npx @modelcontextprotocol/inspector node dist/index.jsRelated MCP server: ai-visibility-mcp
Sign up at llmbrandmonitor.com
Open your Profile page
Copy your API key (starts with lbm_)
17 tools across 4 categories:
Tool | What it does |
| List all brand monitoring projects |
| Get project details with prompts and models |
| Create a new project |
| Update project name, models, or monitoring settings |
| Archive a project |
| Add monitoring prompts to a project |
| Remove a prompt from a project |
Tool | What it does |
| Start a scan — sends prompts to LLMs and collects responses |
| Check scan progress |
| View scan history |
Tool | What it does |
| Browse monitoring results (brand mentions, status) |
| Read the full LLM response for a specific result |
| See which competitor brands LLMs mention |
| See which URLs and domains LLMs cite |
| Competitor mention trends over time |
Tool | What it does |
| List 350+ available LLM models |
| Check credit balance and usage stats |
You: "What brand monitoring projects do I have?"
Claude: → lbm_list_projects
You: "Run a scan on the Serpstat project"
Claude: → lbm_run_scan (asks you to confirm — scans spend credits)
→ lbm_get_scan_status (polls until complete)
You: "Show me the results — which models mentioned my brand?"
Claude: → lbm_list_results
You: "What did GPT-5 say exactly?"
Claude: → lbm_get_transcript
You: "Who are my competitors according to AI models?"
Claude: → lbm_list_competitorsAll list tools return compact CSV by default instead of verbose JSON. This reduces token usage by 80–96%, keeping responses within context limits.
# Default (CSV) — 3-6 key columns
competitor,mentions,visibility_pct
Competitor A,178,72.4
Competitor B,105,42.7
# Full JSON — pass include_all_fields: true
{"data": [{"competitor_id": "...", "competitor_name": "Competitor A", ...}]}All list tools support offset and limit for pagination.
Variable | Required | Default | Description |
| Yes | — | API key from llmbrandmonitor.com |
| No |
| API base URL |
| No |
|
|
Errors include actionable hints for the LLM:
Error | Hint |
| Check balance with |
| Wait a few seconds and retry |
| Call |
| API key is invalid — check |
npm install
npm run build # TypeScript → dist/
npm test # 126 testsFull REST API docs: llmbrandmonitor.com/api-docs
MIT
WHEN TO USE: To add one or more monitoring prompts to a project. Prompts are the questions asked to LLMs (e.g. "What are the best tools for X?"). Max 50 per request, 100 per project total. REQUIRES: project_id from lbm_list_projects. RETURNS: Array of created prompts with prompt_id. NEXT STEP: Call lbm_run_scan to run a scan with the new prompts.
| Name | Required | Description | Default |
|---|---|---|---|
| prompts | Yes | Array of prompts to add (max 50) | |
| project_id | Yes | Project ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint=false and destructiveHint=false. The description adds constraints (max 50/100, returns array of prompts) not present in annotations, increasing transparency. 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?
The description is extremely concise, using clear section headers (WHEN TO USE, REQUIRES, RETURNS, NEXT STEP). Every sentence adds value; no wasted 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.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately covers return type. All parameters are documented in schema and referenced in description. Tool is simple and the description covers prerequisites, limits, and next steps. Complete for the tool's complexity.
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%, but the description adds value by explaining the return type ('Array of created prompts with prompt_id') and noting the max limit (50) per request, which is not in the schema. Provides useful context 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 action ('add...prompts'), identifies the resource ('to a project'), and explains what prompts are. This distinguishes from sibling tools like lbm_delete_prompt. Purpose is immediately clear.
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 includes a 'WHEN TO USE' section, specifies required project_id from lbm_list_projects, and notes max limits. It does not explicitly mention when not to use, but the context is sufficient. A minimal gap in stating alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
WHEN TO USE: To archive a project that is no longer needed. Archived projects are hidden but not deleted. REQUIRES: project_id from lbm_list_projects. Confirm with user before archiving.
| Name | Required | Description | Default |
|---|---|---|---|
| project_id | Yes | Project ID to archive |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true and idempotentHint=true. Description adds that projects are 'hidden but not deleted' and requires user confirmation, which provides useful behavioral context beyond annotations.
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 extremely concise, using only three sentences with clear section headers ('WHEN TO USE', 'REQUIRES'). Every sentence adds value without 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?
For a single-parameter tool with no output schema, the description covers purpose, effect, prerequisites, and user confirmation. It is fully adequate for an agent to use correctly.
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 describes project_id as 'Project ID to archive' with 100% coverage. Description adds that it should come from lbm_list_projects, adding sourcing context that goes beyond the schema description.
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 action 'archive a project' and the effect 'hidden but not deleted', distinguishing it from siblings like lbm_create_project or lbm_list_projects.
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 provides a 'WHEN TO USE' directive, requires project_id from lbm_list_projects, and instructs to confirm with user. This gives clear context for when and how to invoke the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
WHEN TO USE: To create a new brand monitoring project. RETURNS: Created project object with generated id. NEXT STEP: Call lbm_run_scan to start monitoring.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | Brand domain (required, e.g. "example.com") | |
| models | Yes | LLM model IDs to monitor (required). Call lbm_list_models to get available IDs. | |
| prompts | Yes | Array of monitoring prompts (required) | |
| language | Yes | 2-letter ISO language code (required, e.g. "en", "uk") | |
| location | Yes | Country name, 2-letter ISO code, or "auto" (required) | |
| brand_name | Yes | Brand name to monitor (required) | |
| project_name | Yes | Project name (required) | |
| auto_monitoring | No | Optional auto monitoring config |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false, destructiveHint=false, idempotentHint=false. The description does not add behavioral traits beyond these, such as authorization requirements, uniqueness constraints, or side effects. For a creation tool, more context on behavior (e.g., whether names must be unique) would be helpful, but annotations already cover the safety profile.
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 concise with three sentences, each on a new line and front-loaded with a clear label ('WHEN TO USE', 'RETURNS', 'NEXT STEP'). Every sentence adds value, and there is no wasted 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 tool's complexity (8 parameters, 7 required, nested objects, no output schema), the description is minimal. It covers the high-level purpose and next step but lacks details on parameter constraints, expected input formats, or the structure of the returned object. Additional context would improve completeness.
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 input schema already describes all parameters. The description does not add additional parameter-level meaning; it only mentions the return value. Baseline is 3, and no improvement 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 clearly states the tool's purpose: 'To create a new brand monitoring project.' The verb 'create' and the resource 'brand monitoring project' are specific, and it distinguishes this tool from sibling tools such as lbm_update_project and lbm_list_projects.
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 explicitly states 'WHEN TO USE: To create a new brand monitoring project' and provides a next step ('Call lbm_run_scan to start monitoring'). While it gives clear context, it does not include explicit exclusions or alternatives, such as when to use lbm_update_project instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
WHEN TO USE: To remove a specific prompt from a project. REQUIRES: project_id and prompt_id. Get prompt_id from lbm_get_project (prompts array). NOTE: Project must have at least 2 prompts; cannot delete from archived project. Confirm with user before deleting.
| Name | Required | Description | Default |
|---|---|---|---|
| prompt_id | Yes | Prompt ID to delete (from lbm_get_project) | |
| project_id | Yes | Project ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide destructiveHint and idempotentHint. Description adds constraints (min prompts, archived project restriction) and user confirmation step, adding value beyond annotations.
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 usage context, no superfluous information.
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?
Fully covers all necessary information for a parameterized delete operation, including constraints and prior interaction needed (lbm_get_project).
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 has 100% coverage for both parameters. Description adds context that prompt_id comes from lbm_get_project, complementing the schema descriptions.
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 'To remove a specific prompt from a project,' using a specific verb and resource, and distinguishes from sibling tools like lbm_add_prompts and lbm_archive_project.
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?
Provides explicit when-to-use context, prerequisites (project_id, prompt_id from lbm_get_project), constraints (minimum 2 prompts, not archived), and recommends user confirmation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
WHEN TO USE: To see competitor mention trends over time — which competitors were mentioned by LLMs across multiple scans and how their visibility changed. Use for competitive trend analysis and reporting. REQUIRES: project_id from lbm_list_projects. RETURNS: Historical competitor mention statistics per date, with per-model breakdowns. NOTE: Response structure may differ between time_range and start_date/end_date params.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Items per page (default: 20, max: 100) | |
| offset | No | Items to skip (default: 0) | |
| end_date | No | End date YYYY-MM-DD (required with start_date) | |
| project_id | Yes | Project ID | |
| start_date | No | Start date YYYY-MM-DD (overrides time_range) | |
| time_range | No | Time range shortcut (default: 30d). Overridden by start_date/end_date. | |
| model_filter | No | Optional: comma-separated model IDs | |
| prompt_filter | No | Optional: comma-separated prompt texts |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as read-only, idempotent, and non-destructive. The description adds valuable behavioral context about response structure varying between time_range and start_date/end_date parameters, and specifies the return type.
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?
Front-loaded 'WHEN TO USE' and 'REQUIRES' sections, efficiently using four sentences to convey purpose, prerequisites, returns, and a behavioral note. No unnecessary words.
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 (8 params, no output schema), the description provides a clear overview of purpose, return type, and a key behavioral caveat. It lacks examples but the schema covers parameter details, making it sufficiently complete.
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 parameters are well-documented. Description adds meaning by clarifying the overriding relationship between start_date and time_range, and notes response structure differences, which goes 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?
Description clearly states the tool retrieves competitor mention trends over time, with per-model breakdowns. It distinguishes from sibling tools like lbm_list_results or lbm_get_transcript by focusing on historical trend analysis.
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?
Provides explicit context for use (competitive trend analysis and reporting) and a prerequisite (project_id from lbm_list_projects). However, it does not explicitly exclude alternative tools or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
WHEN TO USE: To get full details of a specific brand monitoring project including all prompts. REQUIRES: project_id from lbm_list_projects. RETURNS: Project object with id, name, description, status, models, prompts array, schedule, and stats.
| Name | Required | Description | Default |
|---|---|---|---|
| project_id | Yes | Project ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, idempotentHint, destructiveHint. The description adds value by detailing the returned fields (id, name, description, status, models, prompts array, schedule, stats), which annotations do not cover. No contradiction.
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 with clear structuring: WHEN TO USE, REQUIRES, RETURNS. Every part earns its place, no fluff, front-loaded with 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 input (one required param) and no output schema, the description fully covers the tool's purpose, prerequisites, and return structure. It is complete for selection and invocation.
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 project_id as 'Project ID' with 100% coverage. The description adds that the ID comes from lbm_list_projects, which provides useful sourcing context 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 'To get full details of a specific brand monitoring project including all prompts'. The verb 'get' and resource 'project' are specific, and the scope ('full details, all prompts') distinguishes it from sibling tools like lbm_list_projects.
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 includes 'WHEN TO USE' and 'REQUIRES: project_id from lbm_list_projects', providing clear context and prerequisite. No explicit when-not-to-use is given, but the indication is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
WHEN TO USE: To check the status of a running or completed scan. REQUIRES: project_id and scan_id from lbm_run_scan or lbm_list_scans. RETURNS: Scan object with status (pending/running/completed/failed), progress, start/end times, and result count. NEXT STEP: When status="completed", call lbm_list_results to see monitoring results.
| Name | Required | Description | Default |
|---|---|---|---|
| scan_id | Yes | Scan ID from lbm_run_scan | |
| project_id | Yes | Project ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark it as read-only and idempotent. Description adds valuable behavioral context: return fields (status, progress, times, result count) and no side effects mentioned. Slight missing info on polling behavior, but still strong.
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?
Concise, structured with labeled sections (WHEN TO USE, REQUIRES, RETURNS, NEXT STEP). Every sentence provides 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 status-checking tool with no output schema, it fully covers purpose, inputs, output details, and next step. Adequate given the tool's simplicity.
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%. Description adds meaning by stating scan_id comes from lbm_run_scan or lbm_list_scans, clarifying parameter provenance 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 checks the status of a scan (verb+resource). It distinguishes from siblings like lbm_run_scan and lbm_list_scans by focusing on status retrieval.
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?
Explicit WHEN TO USE section says exactly when to use this tool. REQUIRES lists prerequisites with provenance. NEXT STEP provides follow-up action.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
WHEN TO USE: To read the full verbatim LLM response for a specific monitoring result. Use when the user wants to see exactly what an LLM said about their brand. REQUIRES: project_id and result_id from lbm_list_results. RETURNS: Full transcript text, model name, prompt text, and metadata (brand_mentioned, sentiment, links found).
| Name | Required | Description | Default |
|---|---|---|---|
| result_id | Yes | Result ID from lbm_list_results | |
| project_id | Yes | Project ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, idempotentHint, and destructiveHint. Description adds value by detailing what is returned (transcript text, model name, prompt text, metadata), which is beyond annotations and helps the agent understand the output.
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 sentences, each serving a distinct purpose: when to use, requirements, and return values. No wasted words, effectively front-loaded with usage context.
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 no output schema, description adequately covers return values. All required parameters are documented with dependencies. Minimal gaps given the tool's simplicity and strong annotations.
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 descriptions cover 100% of parameters, already stating 'Result ID from lbm_list_results' and 'Project ID'. Description reiterates this dependency but adds no new semantic detail beyond schema, so baseline of 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 explicitly states 'To read the full verbatim LLM response for a specific monitoring result', providing a specific verb and resource. It distinguishes from siblings like lbm_list_results by focusing on retrieving a single transcript rather than listing results.
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 includes 'WHEN TO USE' and specifies prerequisites ('REQUIRES: project_id and result_id from lbm_list_results'), giving clear context. However, it does not explicitly state when not to use or mention alternatives, though siblings are known.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
WHEN TO USE: To check credit balance and usage statistics. Call this before lbm_run_scan to confirm the user has enough credits. RETURNS: Current credit balance, credits used this period, credits per scan estimate, and usage breakdown by model and project.
| Name | Required | Description | Default |
|---|---|---|---|
| end_date | No | End date ISO 8601 for usage period (required if start_date provided) | |
| start_date | No | Start date ISO 8601 for usage period (optional, default: current month start) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the description's burden is reduced. It adds value by detailing the return values (credit balance, usage, estimate, breakdown), which provides behavioral context beyond the annotations.
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 extremely concise at two sentences, with the first sentence front-loading the usage guidance. Every word serves a purpose, 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 absence of an output schema, the description adequately lists the types of information returned. It covers purpose, usage context, and return content, though it lacks details on parameter format or potential edge cases. Still quite complete for a read-only stats 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 the schema already fully documents the two parameters. The description does not add any additional meaning or constraints beyond what the schema provides, thus a baseline score of 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?
The description clearly states the tool checks credit balance and usage statistics, and explicitly distinguishes it from sibling tools by advising to call this before lbm_run_scan. The verb 'check' and resource 'credit balance and usage statistics' are specific and unambiguous.
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 explicit guidance on when to use the tool: 'Call this before lbm_run_scan to confirm the user has enough credits.' This clearly instructs the agent on the optimal invocation context and implies when not to use it (after a scan or when not needing pre-check).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
WHEN TO USE: To see which competitor brands were mentioned by LLMs in responses to this project's prompts. Shows competitive landscape as seen by AI models. REQUIRES: project_id from lbm_list_projects. RETURNS: Compact CSV with competitor name, mention count, frequency % (default limit: 20). Set include_all_fields=true for full JSON. Pass higher limit only if user explicitly asks for more.
| Name | Required | Description | Default |
|---|---|---|---|
| tags | No | Optional: filter by comma-separated prompt tags | |
| limit | No | Max competitors to return (default: 20, max: 100) | |
| offset | No | Items to skip (default: 0) | |
| project_id | Yes | Project ID | |
| include_all_fields | No | Set true for full JSON response. Default: false (compact CSV — recommended). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool as read-only, idempotent, and non-destructive. The description adds valuable behavioral context: the default output is a compact CSV with competitor name, mention count, and frequency %, and the option to get full JSON via include_all_fields. This clarifies the response format beyond what annotations provide.
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 extremely concise at four sentences, with clear labels (WHEN TO USE, REQUIRES, RETURNS). Every sentence adds essential information without redundancy, making it easy to parse quickly.
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 5 parameters and no output schema, the description covers return format (CSV vs JSON fields) and defaults (limit 20). It mentions offset but not pagination behavior or error cases. Still, it provides enough context for typical use, and annotations cover safety.
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%, but the description adds practical guidance: setting include_all_fields=true for full JSON, and 'Pass higher limit only if user explicitly asks for more.' This helps the agent make informed decisions about parameter values, enhancing the bare schema descriptions.
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's function: 'To see which competitor brands were mentioned by LLMs in responses to this project's prompts.' It specifies the scope (competitor brands, from LLM responses) and distinguishes it from sibling tools, which focus on scans, projects, or models, making its purpose unambiguous.
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 includes a 'WHEN TO USE' section that directly states its context, and explicitly requires 'project_id from lbm_list_projects,' indicating a prerequisite. However, it does not mention when not to use the tool or suggest alternatives, though no obvious alternative exists among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
WHEN TO USE: To see which URLs and domains LLMs cited in their responses — useful for understanding what sources AI models trust for this topic. REQUIRES: project_id from lbm_list_projects. RETURNS: Compact CSV with domain, mentions, unique_urls (default limit: 20). Set include_all_fields=true for full JSON with individual URLs. Pass higher limit only if user explicitly asks for more.
| Name | Required | Description | Default |
|---|---|---|---|
| tags | No | Optional: filter by comma-separated prompt tags | |
| limit | No | Max links to return (default: 20, max: 100) | |
| domain | No | Optional: filter by exact domain | |
| offset | No | Items to skip (default: 0) | |
| project_id | Yes | Project ID | |
| min_frequency | No | Optional: minimum result mentions | |
| include_all_fields | No | Set true for full JSON response. Default: false (compact CSV — recommended). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnly, idempotent, non-destructive. The description adds behavioral details: return format (compact CSV vs. full JSON), default limit, and pagination (offset). 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?
The description is concise, uses clear headings (WHEN TO USE, REQUIRES, RETURNS), and front-loads the most important information. Every sentence adds value without 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 7 parameters and no output schema, the description covers return format, filtering capabilities, pagination, and prerequisites. It could mention sorting or more detail about the CSV columns, but overall it is sufficiently complete.
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?
All 7 parameters have schema descriptions (100% coverage). The description adds value by emphasizing the default limit (20), the include_all_fields toggle, and a usage hint about passing a higher limit only on user request.
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's purpose: 'To see which URLs and domains LLMs cited in their responses'. This is a specific verb+resource combination that distinguishes it from sibling tools like list_results or get_transcript.
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 clear usage context, starting with 'WHEN TO USE' and specifying a prerequisite ('REQUIRES: project_id from lbm_list_projects'). It does not explicitly say when not to use, but the context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
WHEN TO USE: To discover which LLM models are available for brand monitoring scans. Call this before creating a project or running a scan if the user wants to choose specific models. RETURNS: Compact CSV with model_id, name, provider, web_search (default). Set include_all_fields=true for full JSON with pricing.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Items per page (default: 20, max: 100) | |
| offset | No | Items to skip (default: 0) | |
| include_all_fields | No | Set true for full JSON response. Default: false (compact CSV — recommended). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and idempotent. Description adds return format details (compact CSV by default, full JSON with pricing) and parameter effect, extending beyond annotations without contradiction.
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 concise sections (WHEN TO USE, RETURNS) plus a parameter note. No redundant sentences, front-loaded with key usage guidance.
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?
With no output schema, description adequately explains return format and parameter behavior. Provides sufficient context for correct invocation given tool simplicity.
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%. Description adds value by explaining the effect of include_all_fields and recommending default (compact CSV). Also describes what is returned, supplementing 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 discovers available LLM models for brand monitoring scans, with explicit direction to call it before creating a project or running a scan. It distinguishes itself from sibling tools focused on scans and projects.
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 when to use (before creating project or running scan) and guides on include_all_fields parameter. Lacks mention of when not to use or explicit alternatives, but context is sufficient given sibling diversity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
WHEN TO USE: To get a list of all brand monitoring projects for the current user. Use as the FIRST step to discover available projects before working with scans or results. RETURNS: Compact CSV with id, brand_name, status, visibility_pct, models_count, prompts_count (default). Set include_all_fields=true for full JSON. NEXT STEP: Use lbm_get_project with a specific project id for full details.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Items per page (default: 20, max: 100) | |
| offset | No | Items to skip (default: 0) | |
| status | No | Optional: filter by status (active, inactive, pending) | |
| include_all_fields | No | Set true for full JSON response. Default: false (compact CSV — recommended). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the description doesn't need to repeat safety. Instead, it adds value by explaining default output format (CSV vs JSON) and pagination behavior, which are beyond what annotations provide.
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 concise with a clear structure: WHEN TO USE, RETURNS, NEXT STEP. Every sentence provides necessary information without redundancy, and key points are front-loaded.
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 that this is a read-only list tool with full schema coverage and explicit output format description, the description is complete. It covers pagination, filtering, and next steps, leaving no gaps for an agent to misunderstand how to use it.
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%, but the description adds context about when to use include_all_fields (default compact CSV recommended) and implies pagination usage. This additional guidance enhances understanding beyond raw schema descriptions.
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 'get a list of all brand monitoring projects for the current user,' specifying the verb, resource, and context. It distinguishes from siblings like lbm_get_project by indicating this is the first step before deeper details.
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 as the FIRST step' and provides a next step (lbm_get_project). While no alternatives are explicitly excluded, the guidance is clear and contextual. A score of 4 reflects that exclusions are implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
WHEN TO USE: To get monitoring results for a project — how LLMs responded to brand monitoring prompts. REQUIRES: project_id from lbm_list_projects. RETURNS: Compact CSV with result_id, prompt, model, brand_mentioned, status (default limit: 20). Set include_all_fields=true for full JSON. NEXT STEP: Use lbm_get_transcript with a result_id to read the full LLM response text.
| Name | Required | Description | Default |
|---|---|---|---|
| tags | No | Optional: filter by comma-separated prompt tags (OR logic) | |
| limit | No | Items per page (default: 20, max: 100) | |
| offset | No | Items to skip (default: 0) | |
| status | No | Optional: filter by status (success, failure, pending, queued) | |
| scan_id | No | Optional: filter by specific scan | |
| project_id | Yes | Project ID | |
| include_all_fields | No | Set true for full JSON response. Default: false (compact CSV — recommended). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint, idempotentHint), the description discloses return format (Compact CSV with specific fields), default limit (20), and the option for full JSON via include_all_fields. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, uses clear uppercase labels (WHEN TO USE, REQUIRES, RETURNS, NEXT STEP), and is front-loaded with essential info. Every sentence adds value without waste.
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 7 parameters (fully described in schema) and no output schema, the description covers all critical aspects: when to use, prerequisites, return format, default behavior, and next step. It adequately supports the agent in invoking the tool correctly.
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%, but the description adds context beyond parameter descriptions, such as the overall return format and the recommendation for compact CSV. It reinforces the meaning of include_all_fields and the default limit, though some parameter details are redundant with 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 'To get monitoring results for a project — how LLMs responded to brand monitoring prompts.' This uses a specific verb ('get') and resource, distinguishing it from siblings like lbm_list_projects (lists projects) and lbm_get_transcript (gets full transcript).
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 starts with 'WHEN TO USE' and provides prerequisite ('project_id from lbm_list_projects'), plus a 'NEXT STEP' to use lbm_get_transcript for full text, guiding the agent on when and after to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
WHEN TO USE: To see the scan history for a project — all past and current scans with their statuses. REQUIRES: project_id from lbm_list_projects. RETURNS: Compact CSV with scan_id, status, created_at, results_count (default). Set include_all_fields=true for full JSON.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Items per page (default: 20, max: 100) | |
| offset | No | Items to skip (default: 0) | |
| status | No | Optional: filter by status (queued, running, completed, partial, failed) | |
| project_id | Yes | Project ID | |
| include_all_fields | No | Set true for full JSON response. Default: false (compact CSV — recommended). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true and destructiveHint=false. Description adds default output format (CSV) and effect of include_all_fields, consistent 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with clear sections (WHEN TO USE, REQUIRES, RETURNS). Every sentence is informative and front-loaded.
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?
Tool has 5 params and no output schema. Description covers return format and fields, necessary prerequisite, and optional filters. Lacks pagination details but schema covers them.
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 covers 100% of params. Description adds context for include_all_fields (recommended default) and lists default return fields (scan_id, status, created_at, results_count), adding value beyond 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 it lists scan history for a project with statuses. It distinguishes from siblings like lbm_get_scan_status (single scan) by being a list operation.
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 states when to use and requires project_id from lbm_list_projects. Does not list alternatives but sibling tools imply differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
WHEN TO USE: To start a new monitoring scan for a project — sends prompts to all configured LLMs and collects responses. REQUIRES: project_id from lbm_list_projects. Project must have at least one prompt (use lbm_add_prompts if needed). RETURNS: Created scan object with scan_id and status="pending". NEXT STEP: Poll lbm_get_scan_status with scan_id until status="completed". CAUTION: This SPENDS user credits. Always confirm with the user before running.
| Name | Required | Description | Default |
|---|---|---|---|
| models | No | Optional: override which LLM models to use for this scan. Defaults to project models. | |
| project_id | Yes | Project ID to scan | |
| prompt_ids | No | Optional: specific prompt IDs to scan. Default: all project prompts. | |
| use_web_search | No | Optional: enable web search for this scan |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate destructiveHint=true and readOnlyHint=false. The description adds crucial behavioral context: 'SPENDS user credits' and 'Always confirm with the user before running.' It also mentions the return state 'status="pending"'. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with section headers (WHEN TO USE, REQUIRES, RETURNS, NEXT STEP, CAUTION). Every sentence adds value; no verbosity.
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?
The description covers the full workflow: how to start, what is returned, what to do next, and caution about credits. Given no output schema, it provides enough context for agent usage.
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 minimal extra meaning beyond the schema: it restates that project_id is required and mentions defaults briefly, but these are already in the schema. No significant new parameter insights.
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's action: 'To start a new monitoring scan for a project — sends prompts to all configured LLMs and collects responses.' It distinguishes from siblings like lbm_get_scan_status and lbm_list_scans.
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 explicitly provides 'WHEN TO USE', 'REQUIRES' (project_id from lbm_list_projects, project with at least one prompt), 'NEXT STEP' (poll lbm_get_scan_status), and 'CAUTION' (spends credits, confirm with user). This gives clear guidance on when and how to use the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
WHEN TO USE: To update project name, models, or auto monitoring settings. Only provided fields are updated. NOTE: brand_name and prompts cannot be modified via this endpoint. Use lbm_add_prompts/lbm_delete_prompt for prompt changes. REQUIRES: project_id from lbm_list_projects. RETURNS: Updated project object.
| Name | Required | Description | Default |
|---|---|---|---|
| models | No | New list of LLM model IDs to monitor | |
| project_id | Yes | Project ID | |
| project_name | No | New project name | |
| auto_monitoring | No | Auto monitoring settings |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint=false, destructiveHint=false, idempotentHint=true. The description adds that 'Only provided fields are updated,' matching idempotent behavior, and details return value. No contradiction.
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 plus a note, front-loaded with 'WHEN TO USE'. Every sentence is necessary, no waste. Structured clearly with notes and returns.
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 4 params (1 required), nested object, no output schema, the description covers what can be updated, what cannot, prerequisites, return value. Complete for a mutation 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%, baseline 3. The description adds behavioral meaning: partial update and constraints on brand_name/prompts, going beyond schema descriptions.
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 updates project name, models, or auto monitoring settings. It distinguishes from siblings by noting that brand_name and prompts cannot be modified and directs to lbm_add_prompts/lbm_delete_prompt for those.
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 explicitly states when to use (update project fields) and when not to (brand_name/prompts). It also lists a prerequisite: project_id from lbm_list_projects. Alternatives are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.0.1lbm_add_promptslbm_archive_projectlbm_create_projectlbm_delete_promptlbm_get_historylbm_get_projectlbm_get_scan_statuslbm_get_transcriptlbm_get_usagelbm_list_competitorslbm_list_linkslbm_list_modelslbm_list_projectslbm_list_resultslbm_list_scanslbm_run_scanlbm_update_projectEach tool has a clearly distinct purpose, targeting specific resources (projects, prompts, scans, results, competitors, links, history, usage) with unique actions (list, get, create, update, archive, add, delete, run). There is no functional overlap.
All tools follow a consistent `lbm_verb_noun` pattern in snake_case. Verbs are standard and nouns are appropriately singular or plural, making it easy to infer tool behavior from names.
With 17 tools, the scope is well-balanced. It covers full lifecycle management (CRUD for projects, prompts, scans, results) and adds analytics (competitors, links, history, usage) without unnecessary bloat.
The surface is nearly complete, covering all major operations. Minor gaps exist: no dedicated tool to update prompts (only add/delete) and no permanent project deletion (only archive). These are workable but not critical.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
AI-visibility monitoring for your brand across ChatGPT, Claude, Perplexity & Gemini.
Brand visibility auditing across LLMs, AI search, and answer engines with GEO reports and scores.
Check if ChatGPT, Perplexity & Gemini mention or cite a brand. Share of voice + GEO/AEO tracking.
AI visibility analytics for brand mentions, citations, sentiment, and GEO reports
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/SerpstatGlobal/llm-brand-monitor-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
