Skip to main content
Glama

Analook — Competitor Intelligence

by io.github.Gingiris-1031
OverviewDiscussionsAdmin

Server Details

Competitor intelligence for AI agents — SEO, traffic, social, Product Hunt, pricing, AI insights.

If you are the author of this connector, you can claim ownership by verifying the domain or GitHub account it belongs to. Claimed connector authors can inspect health checks, view analytics, and manage their listing.
Status
Healthy
Uptime
100.0% over 52 days
Last Tested
Transport
Streamable HTTP · MCP 2025-06-18
URL
Repository
Gingiris-1031/Competitor-analysis-tool
GitHub Stars
110
Server Listing
Analook

TDQS

A3.9/5.0

Scored across 8 tools

Disambiguation4/5

Most tools are clearly distinct: job submission (analyze_competitor, run_growth_audit), polling (get_report_status), and retrieval (get_report, get_report_markdown, get_growth_audit) form a coherent workflow. The main soft spot is get_report vs get_report_markdown, which fetch the identical report in two formats, and get_growth_audit which is a fetch while run_growth_audit is a submit — but descriptions disambiguate well.

Naming Consistency4/5

Names follow a mostly consistent snake_case verb_noun pattern (get_report, list_my_reports, browse_public_reports). Minor deviation: job submission uses two different verbs — 'analyze_competitor' vs 'run_growth_audit' — for conceptually similar actions, which slightly breaks predictability.

Tool Count5/5

Eight tools is well-scoped for a competitor-intelligence service. Each tool maps to a distinct lifecycle step (discover, submit, poll, retrieve, list) with no filler, and the two job types justify their separate submit/fetch tools.

Completeness4/5

The core lifecycle is covered: discovery (browse_public_reports), submission, status polling, structured and markdown retrieval, listing, plus the growth-audit variant. Minor gaps exist — no job cancellation, report deletion, or credit/account status check — but agents can work around these.

Available Tools

8 tools
analyze_competitorAInspect

Submit a competitor analysis job.

Analyzes a competitor's website across 15+ data sources (SEO, traffic,
social, Product Hunt, GitHub, Wayback Machine history, AI-generated
insights, etc.) and returns a job_id. Use get_report_status(job_id) to
poll and get_report(job_id) to retrieve results when status='completed'.

Typical analysis takes 2-5 minutes. Requires authentication (deducts 1
credit from your Analook balance).

Args:
    url: Competitor website URL (e.g. 'https://linear.app' or 'lovable.dev')
    product_name: Optional product name override (defaults to domain)
    lang: Report language, 'en' (default) or 'zh' for Chinese output

Returns:
    {job_id: str, status: 'started', poll_url: str} on success
    {error: str, hint?: str} on auth/validation failure
ParametersJSON Schema
NameRequiredDescriptionDefault
urlYes
langNo
contextYesExplain in 15-25 words, in third person, why this tool is called and how it supports the user's goal. For analytics only. You MUST describe only the abstract purpose of the tool call. NEVER include, repeat, paraphrase, or infer personal, sensitive, or identifying information from the user request or tool results, including names, emails, phone numbers, IPs, IDs, or credentials. You MUST generalize specific entities into roles such as "a user", "the customer", or "an account". Example: "Retrieving a customer's recent orders to investigate a billing issue and help support determine the appropriate resolution."
llm_modelYesThe exact model identifier you (the assistant) are running as, taken from your system prompt or environment (e.g. "claude-opus-4-8", "gpt-5.2"). Used for analytics only. If you do not know your model identifier with certainty, pass "unknown" — never guess.
product_nameNo
conversation_idNoPass the exact conversation_id from the server's previous response, unchanged. The server provides it on the first call — never invent one, and do not issue parallel tool calls until you have it. Keep passing the same conversation_id for the rest of the conversation, including after later user messages or on a different task; do not reset it when the user starts a new request.

TDQS

A4.6/5.0
Behavior5/5

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

With no annotations present, the description carries the full burden and does so well: it discloses the async job_id contract, expected 2-5 minute duration, authentication requirement, a 1-credit deduction, and error/hint shapes on failure. This is exactly the operational context an agent needs to invoke it safely.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the action, then groups workflow routing, timing/auth, and Args/Returns blocks cleanly. Slightly long but every section earns its place; no redundant filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description supplies the return contract ({job_id, status, poll_url} and the error form) plus polling instructions and timing expectations. Nothing an agent needs to call it correctly is missing.

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

Parameters4/5

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

Schema coverage is 50%, so the description usefully compensates by documenting url with concrete examples, product_name's override/default-to-domain behavior, and lang's 'en'/'zh' values. The remaining params (context, llm_model, conversation_id) already carry schema descriptions, so coverage is effectively complete.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Submit a competitor analysis job') and immediately clarifies scope with 'across 15+ data sources'. It clearly separates itself from get_report_status, get_report, and run_growth_audit by defining the async submit behavior.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly routes the agent through the workflow: use get_report_status(job_id) to poll and get_report(job_id) once status='completed'. It does not, however, explain when to choose this over the sibling run_growth_audit, leaving one alternative comparison unaddressed.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

browse_public_reportsAInspect

Browse Analook's public competitor-intelligence report gallery.

Returns recently published public reports (product name, domain, category,
and a link). No authentication or credits required — a fast way to discover
existing analyses before spending a credit on a fresh one.

Args:
    category: Optional filter, e.g. 'AI / Agents', 'Dev Tools',
              'Crypto / Web3', 'Marketing / SEO', 'SaaS / Other'
ParametersJSON Schema
NameRequiredDescriptionDefault
contextYesExplain in 15-25 words, in third person, why this tool is called and how it supports the user's goal. For analytics only. You MUST describe only the abstract purpose of the tool call. NEVER include, repeat, paraphrase, or infer personal, sensitive, or identifying information from the user request or tool results, including names, emails, phone numbers, IPs, IDs, or credentials. You MUST generalize specific entities into roles such as "a user", "the customer", or "an account". Example: "Retrieving a customer's recent orders to investigate a billing issue and help support determine the appropriate resolution."
categoryNo
llm_modelYesThe exact model identifier you (the assistant) are running as, taken from your system prompt or environment (e.g. "claude-opus-4-8", "gpt-5.2"). Used for analytics only. If you do not know your model identifier with certainty, pass "unknown" — never guess.
conversation_idNoPass the exact conversation_id from the server's previous response, unchanged. The server provides it on the first call — never invent one, and do not issue parallel tool calls until you have it. Keep passing the same conversation_id for the rest of the conversation, including after later user messages or on a different task; do not reset it when the user starts a new request.

TDQS

A3.5/5.0
Behavior3/5

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

With no annotations, the description carries the full burden and does add real value: it discloses that no authentication or credits are required and enumerates the returned fields. It stops short of covering pagination, result limits (how many 'recently published' reports), or rate behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

It is front-loaded with purpose, then mechanism, then args — a sensible order. It is appropriately sized with little waste, though the bare 'Args:' block is slightly redundant with the schema.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description usefully enumerates returned fields (product name, domain, category, link) and the access model (no auth/credits), which is enough for a simple read-only browse tool. Minor gaps around pagination/volume remain but are not critical to correct invocation.

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

Parameters3/5

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

Schema coverage is 75%, so most parameters are already documented. The description adds meaning for the `category` filter by giving concrete example values, which the schema (no enums, plain anyOf string) does not provide. It says nothing about the meta-parameters context/llm_model/conversation_id, which is acceptable since they are analytics plumbing.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb (browse) and resource (Analook's public competitor-intelligence report gallery), and clarifies it returns recently published public reports. It distinguishes itself from similar siblings like list_my_reports through the 'public gallery' framing, though it doesn't explicitly contrast them.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives a clear usage context — discover existing analyses before spending a credit on a fresh one — which implies when to prefer it over a paid analysis. However, it doesn't name the alternative tools (e.g. analyze_competitor, list_my_reports) or state exclusions explicitly, leaving the agent to infer routing.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_growth_auditAInspect

Fetch a Growth Audit's three reports (Executive Summary, Diagnosis, Action Plan) as Markdown.

Args:
    job_id: ID from run_growth_audit() (starts with 'ga-')

Returns:
    {status, reports: {executive_summary, diagnosis_report, action_plan}}
    while running, only {status, progress} is returned.
ParametersJSON Schema
NameRequiredDescriptionDefault
job_idYes
contextYesExplain in 15-25 words, in third person, why this tool is called and how it supports the user's goal. For analytics only. You MUST describe only the abstract purpose of the tool call. NEVER include, repeat, paraphrase, or infer personal, sensitive, or identifying information from the user request or tool results, including names, emails, phone numbers, IPs, IDs, or credentials. You MUST generalize specific entities into roles such as "a user", "the customer", or "an account". Example: "Retrieving a customer's recent orders to investigate a billing issue and help support determine the appropriate resolution."
llm_modelYesThe exact model identifier you (the assistant) are running as, taken from your system prompt or environment (e.g. "claude-opus-4-8", "gpt-5.2"). Used for analytics only. If you do not know your model identifier with certainty, pass "unknown" — never guess.
conversation_idNoPass the exact conversation_id from the server's previous response, unchanged. The server provides it on the first call — never invent one, and do not issue parallel tool calls until you have it. Keep passing the same conversation_id for the rest of the conversation, including after later user messages or on a different task; do not reset it when the user starts a new request.

TDQS

A3.7/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does disclose the key async trait: while the job is running, only {status, progress} is returned. That is genuine behavioral context beyond structured fields. It lacks auth/error/rate-limit disclosure but covers the most important trait.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the purpose in the first sentence, then uses compact Args/Returns sections. Every line is informative with no filler, though the docstring style is slightly verbose in its section formatting.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description steps in to explain the return shape both when complete and while running, which is exactly the missing piece. Only error handling and explicit sibling routing remain unaddressed.

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

Parameters3/5

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

job_id is elaborated with format hints ('starts with ga-', source from run_growth_audit()), adding value beyond the bare schema. With 75% schema description coverage the remaining parameters (context, llm_model, conversation_id) are already documented in 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.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (Fetch) and resource (a Growth Audit's three named reports) and specifies the output format (Markdown). It clearly distinguishes itself from run_growth_audit by referencing it as the source of job_id, though it doesn't differentiate from the similar get_report/get_report_markdown siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The job_id arg note ('ID from run_growth_audit()') implies the required preceding workflow, which is useful context. However, there is no explicit when-to-use guidance versus get_report, get_report_markdown, or get_report_status, so the agent must infer the routing.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_reportAInspect

Fetch the full competitor analysis report as structured JSON.

Reports contain: website snapshot, Wayback Machine history, SEO/traffic
data (DataForSEO), social media presence, Product Hunt launches, GitHub
stats, pricing, funding, AI-generated business insights, growth
playbooks, and more.

Args:
    job_id: ID from analyze_competitor(); status must be 'completed'

Returns:
    The full report dict (nested structure), or {error} if not found / not ready.
ParametersJSON Schema
NameRequiredDescriptionDefault
job_idYes
contextYesExplain in 15-25 words, in third person, why this tool is called and how it supports the user's goal. For analytics only. You MUST describe only the abstract purpose of the tool call. NEVER include, repeat, paraphrase, or infer personal, sensitive, or identifying information from the user request or tool results, including names, emails, phone numbers, IPs, IDs, or credentials. You MUST generalize specific entities into roles such as "a user", "the customer", or "an account". Example: "Retrieving a customer's recent orders to investigate a billing issue and help support determine the appropriate resolution."
llm_modelYesThe exact model identifier you (the assistant) are running as, taken from your system prompt or environment (e.g. "claude-opus-4-8", "gpt-5.2"). Used for analytics only. If you do not know your model identifier with certainty, pass "unknown" — never guess.
conversation_idNoPass the exact conversation_id from the server's previous response, unchanged. The server provides it on the first call — never invent one, and do not issue parallel tool calls until you have it. Keep passing the same conversation_id for the rest of the conversation, including after later user messages or on a different task; do not reset it when the user starts a new request.

TDQS

A3.9/5.0
Behavior3/5

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

With no annotations, the description carries the full burden, and it does disclose the failure mode ('{error} if not found / not ready') and that the return is a nested dict. It does not state whether the call is read-only, whether job_id is scoped to the caller, or any auth/rate-limit behavior, leaving meaningful behavioral gaps for a tool with no annotation coverage.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded purpose sentence, followed by a contents summary and a conventional Args/Returns block. The content enumeration is long but earns its place by scoping the payload; no filler sentences.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema, so the description must convey the return shape, and it does so by listing report sections and flagging the error object and nested structure. Combined with the precondition on job_id, an agent has enough to call correctly; only the pagination/size behavior of the large payload is unaddressed.

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

Parameters3/5

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

Schema description coverage is 75%, so the schema already documents context, llm_model, and conversation_id in detail. The description adds real value only for job_id, giving its origin and the 'completed' precondition, but adds nothing for the remaining three parameters; baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb ('Fetch') and resource ('full competitor analysis report as structured JSON'), and the enumeration of report contents makes the scope concrete. It implicitly separates itself from sibling get_report_markdown by specifying output, so an agent can distinguish the two without opening schemas.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly names the source of the argument ('ID from analyze_competitor()') and the precondition ('status must be completed'), which tells the agent when this call is valid. It does not name alternatives such as get_report_status or get_report_markdown for the not-ready case, so it stops short of full routing guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_report_markdownAInspect

Fetch the competitor analysis report as human-readable Markdown.

Suitable for piping into agents that prefer text over structured JSON,
or for direct display to end users.

Args:
    job_id: ID from analyze_competitor(); status must be 'completed'

Returns:
    {markdown: str} or {error: str}
ParametersJSON Schema
NameRequiredDescriptionDefault
job_idYes
contextYesExplain in 15-25 words, in third person, why this tool is called and how it supports the user's goal. For analytics only. You MUST describe only the abstract purpose of the tool call. NEVER include, repeat, paraphrase, or infer personal, sensitive, or identifying information from the user request or tool results, including names, emails, phone numbers, IPs, IDs, or credentials. You MUST generalize specific entities into roles such as "a user", "the customer", or "an account". Example: "Retrieving a customer's recent orders to investigate a billing issue and help support determine the appropriate resolution."
llm_modelYesThe exact model identifier you (the assistant) are running as, taken from your system prompt or environment (e.g. "claude-opus-4-8", "gpt-5.2"). Used for analytics only. If you do not know your model identifier with certainty, pass "unknown" — never guess.
conversation_idNoPass the exact conversation_id from the server's previous response, unchanged. The server provides it on the first call — never invent one, and do not issue parallel tool calls until you have it. Keep passing the same conversation_id for the rest of the conversation, including after later user messages or on a different task; do not reset it when the user starts a new request.

TDQS

A4/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does well: it discloses a state prerequisite (status must be 'completed'), the return shape ({markdown: str} or {error: str}), and the error branch. It leaves implicit that this is a read-only operation, but the 'Fetch' framing and prerequisite make the behavior predictable.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with purpose, then usage rationale, then Args/Returns blocks — every section earns its place. Slightly more prose than strictly necessary but no waste.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema exists, but the description supplies the return shape and error case, and gives the precondition for a successful call. An agent has enough to invoke it correctly; only the read-only/reversibility nuance is unstated.

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

Parameters4/5

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

Schema coverage is 75%, and the description adds the crucial semantics for job_id that the schema omits (the schema only titles it 'Job Id' with no description): its source tool and required status. The remaining analytics parameters are documented in the schema itself.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource (fetch the competitor analysis report) plus the format (human-readable Markdown), which implicitly distinguishes it from the structured get_report sibling. It doesn't name the alternative explicitly, but the Markdown-vs-JSON framing makes the distinction legible.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives clear usage context (piping into text-preferring agents, or direct display to end users) and a prerequisite: job_id must come from analyze_competitor() with status 'completed'. It stops short of explicitly naming get_report as the JSON alternative and 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.

get_report_statusAInspect

Poll an analysis job's status.

Args:
    job_id: ID returned from analyze_competitor()

Returns:
    {status: 'running'|'completed'|'failed', progress?: str, report_url?: str}
ParametersJSON Schema
NameRequiredDescriptionDefault
job_idYes
contextYesExplain in 15-25 words, in third person, why this tool is called and how it supports the user's goal. For analytics only. You MUST describe only the abstract purpose of the tool call. NEVER include, repeat, paraphrase, or infer personal, sensitive, or identifying information from the user request or tool results, including names, emails, phone numbers, IPs, IDs, or credentials. You MUST generalize specific entities into roles such as "a user", "the customer", or "an account". Example: "Retrieving a customer's recent orders to investigate a billing issue and help support determine the appropriate resolution."
llm_modelYesThe exact model identifier you (the assistant) are running as, taken from your system prompt or environment (e.g. "claude-opus-4-8", "gpt-5.2"). Used for analytics only. If you do not know your model identifier with certainty, pass "unknown" — never guess.
conversation_idNoPass the exact conversation_id from the server's previous response, unchanged. The server provides it on the first call — never invent one, and do not issue parallel tool calls until you have it. Keep passing the same conversation_id for the rest of the conversation, including after later user messages or on a different task; do not reset it when the user starts a new request.

TDQS

A3.9/5.0
Behavior4/5

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

With no annotations, the description carries the full behavioral burden, and it does disclose the return contract inline: status is one of 'running'|'completed'|'failed' plus optional progress and report_url. That is meaningful behavioral context for a polling tool, though it omits polling cadence and any failure/retry semantics.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short lines with the purpose front-loaded, then Args and Returns. Every sentence carries information and there is no filler or repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema, and the description correctly compensates by documenting the return shape and its enum-like status values. It leaves some gaps (how report_url relates to get_report/get_report_markdown, polling interval), but an agent can call and interpret this tool correctly.

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

Parameters4/5

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

Schema coverage is 75%, so the schema already documents context, llm_model, and conversation_id; the description adds the one piece of meaning the schema lacks for the key parameter, stating job_id is 'ID returned from analyze_competitor()'. It adds nothing for the other three, but those are analytics plumbing already described in the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific verb and resource ('Poll an analysis job's status'), which is clearly distinct from result-fetching siblings like get_report or get_report_markdown. It also anchors the tool to the analyze_competitor workflow via the job_id provenance. However, it never explicitly names a sibling or states what it is not, so it stops short of a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

'Poll' implies repeated invocation after analyze_competitor(), and the job_id provenance gives an implicit entry point. But there is no explicit guidance on when to stop polling, when to switch to get_report, or any alternative-condition statement, so usage is only implied.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_my_reportsAInspect

List your recent competitor analysis reports (up to 50).

Requires authentication. Returns a lightweight list (id, url,
product_name, created_at, status) — use get_report(job_id) to fetch
the full report for any of them.

Returns:
    {reports: [{id, url, product_name, created_at, status}, ...]}
ParametersJSON Schema
NameRequiredDescriptionDefault
contextYesExplain in 15-25 words, in third person, why this tool is called and how it supports the user's goal. For analytics only. You MUST describe only the abstract purpose of the tool call. NEVER include, repeat, paraphrase, or infer personal, sensitive, or identifying information from the user request or tool results, including names, emails, phone numbers, IPs, IDs, or credentials. You MUST generalize specific entities into roles such as "a user", "the customer", or "an account". Example: "Retrieving a customer's recent orders to investigate a billing issue and help support determine the appropriate resolution."
llm_modelYesThe exact model identifier you (the assistant) are running as, taken from your system prompt or environment (e.g. "claude-opus-4-8", "gpt-5.2"). Used for analytics only. If you do not know your model identifier with certainty, pass "unknown" — never guess.
conversation_idNoPass the exact conversation_id from the server's previous response, unchanged. The server provides it on the first call — never invent one, and do not issue parallel tool calls until you have it. Keep passing the same conversation_id for the rest of the conversation, including after later user messages or on a different task; do not reset it when the user starts a new request.

TDQS

A3.9/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and mostly succeeds: it discloses the authentication requirement, the 50-item cap, the exact fields returned, and the recommended follow-up tool. It omits ordering/pagination behavior and any note on what happens beyond the cap, which are minor gaps.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the core purpose in the first line, then layers auth, return shape, and follow-up guidance. The explicit 'Returns:' block is slightly redundant with the inline field list, but overall the text is tight and every section is purposeful.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema and no annotations, the description supplies the missing pieces: return fields, auth requirement, item cap, and the follow-up path to get_report. It is sufficient for correct invocation, with only pagination/ordering details left unspecified.

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

Parameters3/5

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

Schema description coverage is 100%, and the three parameters (context, llm_model, conversation_id) are analytics plumbing fully documented in the schema. The description adds nothing about parameters, so the baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource — 'List your recent competitor analysis reports' — with a clear scope cap of 50. The possessive 'your' distinguishes it from the sibling browse_public_reports, though the alternative is not named explicitly. An agent can identify the tool's function immediately.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly routes the agent to get_report(job_id) for full report contents, which is the key usage decision for this tool. It gives clear context (this is the lightweight discovery call) but does not explicitly contrast with browse_public_reports, leaving that inference to the agent.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

run_growth_auditAInspect

Run a full Growth Audit — three linked strategic reports for a product.

Unlike analyze_competitor (a single 15-signal intelligence snapshot), a
Growth Audit produces an Executive Summary + a Diagnosis Report + a 30-day
Action Plan, grounded in real channel/tactic playbooks. Best for 'how do I
grow THIS product' rather than 'what is this competitor doing'.

Takes ~4-6 minutes. Requires authentication and deducts 10 credits. Poll
with get_growth_audit(job_id) until status='completed'.

Args:
    url: Product website URL to audit
    product_name: Optional product name override (defaults to domain)
    lang: Report language, 'en' (default) or 'zh'
ParametersJSON Schema
NameRequiredDescriptionDefault
urlYes
langNo
contextYesExplain in 15-25 words, in third person, why this tool is called and how it supports the user's goal. For analytics only. You MUST describe only the abstract purpose of the tool call. NEVER include, repeat, paraphrase, or infer personal, sensitive, or identifying information from the user request or tool results, including names, emails, phone numbers, IPs, IDs, or credentials. You MUST generalize specific entities into roles such as "a user", "the customer", or "an account". Example: "Retrieving a customer's recent orders to investigate a billing issue and help support determine the appropriate resolution."
llm_modelYesThe exact model identifier you (the assistant) are running as, taken from your system prompt or environment (e.g. "claude-opus-4-8", "gpt-5.2"). Used for analytics only. If you do not know your model identifier with certainty, pass "unknown" — never guess.
product_nameNo
conversation_idNoPass the exact conversation_id from the server's previous response, unchanged. The server provides it on the first call — never invent one, and do not issue parallel tool calls until you have it. Keep passing the same conversation_id for the rest of the conversation, including after later user messages or on a different task; do not reset it when the user starts a new request.

TDQS

A4.8/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and does so well: ~4-6 minute runtime, authentication requirement, 10-credit deduction, and the async polling pattern with the specific status sentinel. These are exactly the behavioral traits an agent needs before committing to an expensive call.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the what, then the sibling contrast, then the operational constraints, then args — a logical order with no filler sentences. The Args block is mildly redundant in form but earns its place because those three params lack schema descriptions.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite having no output schema, the description names the three returned reports, sets the runtime and cost expectations, and specifies the async retrieval path. Nothing an agent needs to invoke and then collect the result is missing.

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

Parameters4/5

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

Schema coverage is 50%: context, llm_model, and conversation_id are already documented in the schema, while url, product_name, and lang are not. The Args section supplies meaning for exactly those three undocumented params, including the default-domain behavior of product_name and the lang enum values. Coverage is effectively complete, though it adds little beyond the bare parameter names.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Run a full Growth Audit') and immediately enumerates the three concrete deliverables: Executive Summary, Diagnosis Report, and 30-day Action Plan. It explicitly distinguishes itself from the sibling analyze_competitor by contrasting the output shape and the question each answers.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides an explicit use-when/use-instead pairing: 'Best for how do I grow THIS product rather than what is this competitor doing', naming analyze_competitor as the alternative. It also states the polling follow-up (get_growth_audit until status='completed'), so the agent knows the full call sequence.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 8 tool updates
    • Changedanalyze_competitor1 field changed
      • changedInput schema / properties / conversation_id / description
        Previous value: -"Echo the conversation_id from the server's previous response. The server provides it on the first call — never invent one, and do not issue parallel tool calls until you have it."New value: +"Pass the exact conversation_id from the server's previous response, unchanged. The server provides it on the first call — never invent one, and do not issue parallel tool calls until you have it. Keep passing the same conversation_id for the rest of the conversation, including after later user messages or on a different task; do not reset it when the user starts a new request."
    • Changedbrowse_public_reports1 field changed
      • changedInput schema / properties / conversation_id / description
        Previous value: -"Echo the conversation_id from the server's previous response. The server provides it on the first call — never invent one, and do not issue parallel tool calls until you have it."New value: +"Pass the exact conversation_id from the server's previous response, unchanged. The server provides it on the first call — never invent one, and do not issue parallel tool calls until you have it. Keep passing the same conversation_id for the rest of the conversation, including after later user messages or on a different task; do not reset it when the user starts a new request."
    • Changedget_growth_audit1 field changed
      • changedInput schema / properties / conversation_id / description
        Previous value: -"Echo the conversation_id from the server's previous response. The server provides it on the first call — never invent one, and do not issue parallel tool calls until you have it."New value: +"Pass the exact conversation_id from the server's previous response, unchanged. The server provides it on the first call — never invent one, and do not issue parallel tool calls until you have it. Keep passing the same conversation_id for the rest of the conversation, including after later user messages or on a different task; do not reset it when the user starts a new request."
    • Changedget_report1 field changed
      • changedInput schema / properties / conversation_id / description
        Previous value: -"Echo the conversation_id from the server's previous response. The server provides it on the first call — never invent one, and do not issue parallel tool calls until you have it."New value: +"Pass the exact conversation_id from the server's previous response, unchanged. The server provides it on the first call — never invent one, and do not issue parallel tool calls until you have it. Keep passing the same conversation_id for the rest of the conversation, including after later user messages or on a different task; do not reset it when the user starts a new request."
    • Changedget_report_markdown1 field changed
      • changedInput schema / properties / conversation_id / description
        Previous value: -"Echo the conversation_id from the server's previous response. The server provides it on the first call — never invent one, and do not issue parallel tool calls until you have it."New value: +"Pass the exact conversation_id from the server's previous response, unchanged. The server provides it on the first call — never invent one, and do not issue parallel tool calls until you have it. Keep passing the same conversation_id for the rest of the conversation, including after later user messages or on a different task; do not reset it when the user starts a new request."
    • Changedget_report_status1 field changed
      • changedInput schema / properties / conversation_id / description
        Previous value: -"Echo the conversation_id from the server's previous response. The server provides it on the first call — never invent one, and do not issue parallel tool calls until you have it."New value: +"Pass the exact conversation_id from the server's previous response, unchanged. The server provides it on the first call — never invent one, and do not issue parallel tool calls until you have it. Keep passing the same conversation_id for the rest of the conversation, including after later user messages or on a different task; do not reset it when the user starts a new request."
    • Changedlist_my_reports1 field changed
      • changedInput schema / properties / conversation_id / description
        Previous value: -"Echo the conversation_id from the server's previous response. The server provides it on the first call — never invent one, and do not issue parallel tool calls until you have it."New value: +"Pass the exact conversation_id from the server's previous response, unchanged. The server provides it on the first call — never invent one, and do not issue parallel tool calls until you have it. Keep passing the same conversation_id for the rest of the conversation, including after later user messages or on a different task; do not reset it when the user starts a new request."
    • Changedrun_growth_audit1 field changed
      • changedInput schema / properties / conversation_id / description
        Previous value: -"Echo the conversation_id from the server's previous response. The server provides it on the first call — never invent one, and do not issue parallel tool calls until you have it."New value: +"Pass the exact conversation_id from the server's previous response, unchanged. The server provides it on the first call — never invent one, and do not issue parallel tool calls until you have it. Keep passing the same conversation_id for the rest of the conversation, including after later user messages or on a different task; do not reset it when the user starts a new request."
  2. 8 tool updates
    • Changedanalyze_competitor3 fields changed
      • changedInput schema / properties / context / description
        Previous value: -"Explain why you are calling this tool and how it fits into the user's overall goal. This parameter is used for analytics and user intent tracking. YOU MUST provide 15-25 words (count carefully). NEVER use first person ('I', 'we', 'you') - maintain third-person perspective. NEVER include sensitive information such as credentials, passwords, or personal data. Example (20 words): \"Searching across the organization's repositories to find all open issues related to performance complaints and latency issues for team prioritization.\""New value: +"Explain in 15-25 words, in third person, why this tool is called and how it supports the user's goal. For analytics only. You MUST describe only the abstract purpose of the tool call. NEVER include, repeat, paraphrase, or infer personal, sensitive, or identifying information from the user request or tool results, including names, emails, phone numbers, IPs, IDs, or credentials. You MUST generalize specific entities into roles such as \"a user\", \"the customer\", or \"an account\". Example: \"Retrieving a customer's recent orders to investigate a billing issue and help support determine the appropriate resolution.\""
      • addedInput schema / properties / llm_model
        Added value: +{
+  "description": "The exact model identifier you (the assistant) are running as, taken from your system prompt or environment (e.g. \"claude-opus-4-8\", \"gpt-5.2\"). Used for analytics only. If you do not know your model identifier with certainty, pass \"unknown\" — never guess.",
+  "type": "string"
+}
      • changedInput schema / required
        Previous value: -[
-  "url",
-  "context"
-]New value: +[
+  "url",
+  "context",
+  "llm_model"
+]
    • Changedbrowse_public_reports3 fields changed
      • changedInput schema / properties / context / description
        Previous value: -"Explain why you are calling this tool and how it fits into the user's overall goal. This parameter is used for analytics and user intent tracking. YOU MUST provide 15-25 words (count carefully). NEVER use first person ('I', 'we', 'you') - maintain third-person perspective. NEVER include sensitive information such as credentials, passwords, or personal data. Example (20 words): \"Searching across the organization's repositories to find all open issues related to performance complaints and latency issues for team prioritization.\""New value: +"Explain in 15-25 words, in third person, why this tool is called and how it supports the user's goal. For analytics only. You MUST describe only the abstract purpose of the tool call. NEVER include, repeat, paraphrase, or infer personal, sensitive, or identifying information from the user request or tool results, including names, emails, phone numbers, IPs, IDs, or credentials. You MUST generalize specific entities into roles such as \"a user\", \"the customer\", or \"an account\". Example: \"Retrieving a customer's recent orders to investigate a billing issue and help support determine the appropriate resolution.\""
      • addedInput schema / properties / llm_model
        Added value: +{
+  "description": "The exact model identifier you (the assistant) are running as, taken from your system prompt or environment (e.g. \"claude-opus-4-8\", \"gpt-5.2\"). Used for analytics only. If you do not know your model identifier with certainty, pass \"unknown\" — never guess.",
+  "type": "string"
+}
      • changedInput schema / required
        Previous value: -[
-  "context"
-]New value: +[
+  "context",
+  "llm_model"
+]
    • Changedget_growth_audit3 fields changed
      • changedInput schema / properties / context / description
        Previous value: -"Explain why you are calling this tool and how it fits into the user's overall goal. This parameter is used for analytics and user intent tracking. YOU MUST provide 15-25 words (count carefully). NEVER use first person ('I', 'we', 'you') - maintain third-person perspective. NEVER include sensitive information such as credentials, passwords, or personal data. Example (20 words): \"Searching across the organization's repositories to find all open issues related to performance complaints and latency issues for team prioritization.\""New value: +"Explain in 15-25 words, in third person, why this tool is called and how it supports the user's goal. For analytics only. You MUST describe only the abstract purpose of the tool call. NEVER include, repeat, paraphrase, or infer personal, sensitive, or identifying information from the user request or tool results, including names, emails, phone numbers, IPs, IDs, or credentials. You MUST generalize specific entities into roles such as \"a user\", \"the customer\", or \"an account\". Example: \"Retrieving a customer's recent orders to investigate a billing issue and help support determine the appropriate resolution.\""
      • addedInput schema / properties / llm_model
        Added value: +{
+  "description": "The exact model identifier you (the assistant) are running as, taken from your system prompt or environment (e.g. \"claude-opus-4-8\", \"gpt-5.2\"). Used for analytics only. If you do not know your model identifier with certainty, pass \"unknown\" — never guess.",
+  "type": "string"
+}
      • changedInput schema / required
        Previous value: -[
-  "job_id",
-  "context"
-]New value: +[
+  "job_id",
+  "context",
+  "llm_model"
+]
    • Changedget_report3 fields changed
      • changedInput schema / properties / context / description
        Previous value: -"Explain why you are calling this tool and how it fits into the user's overall goal. This parameter is used for analytics and user intent tracking. YOU MUST provide 15-25 words (count carefully). NEVER use first person ('I', 'we', 'you') - maintain third-person perspective. NEVER include sensitive information such as credentials, passwords, or personal data. Example (20 words): \"Searching across the organization's repositories to find all open issues related to performance complaints and latency issues for team prioritization.\""New value: +"Explain in 15-25 words, in third person, why this tool is called and how it supports the user's goal. For analytics only. You MUST describe only the abstract purpose of the tool call. NEVER include, repeat, paraphrase, or infer personal, sensitive, or identifying information from the user request or tool results, including names, emails, phone numbers, IPs, IDs, or credentials. You MUST generalize specific entities into roles such as \"a user\", \"the customer\", or \"an account\". Example: \"Retrieving a customer's recent orders to investigate a billing issue and help support determine the appropriate resolution.\""
      • addedInput schema / properties / llm_model
        Added value: +{
+  "description": "The exact model identifier you (the assistant) are running as, taken from your system prompt or environment (e.g. \"claude-opus-4-8\", \"gpt-5.2\"). Used for analytics only. If you do not know your model identifier with certainty, pass \"unknown\" — never guess.",
+  "type": "string"
+}
      • changedInput schema / required
        Previous value: -[
-  "job_id",
-  "context"
-]New value: +[
+  "job_id",
+  "context",
+  "llm_model"
+]
    • Changedget_report_markdown3 fields changed
      • changedInput schema / properties / context / description
        Previous value: -"Explain why you are calling this tool and how it fits into the user's overall goal. This parameter is used for analytics and user intent tracking. YOU MUST provide 15-25 words (count carefully). NEVER use first person ('I', 'we', 'you') - maintain third-person perspective. NEVER include sensitive information such as credentials, passwords, or personal data. Example (20 words): \"Searching across the organization's repositories to find all open issues related to performance complaints and latency issues for team prioritization.\""New value: +"Explain in 15-25 words, in third person, why this tool is called and how it supports the user's goal. For analytics only. You MUST describe only the abstract purpose of the tool call. NEVER include, repeat, paraphrase, or infer personal, sensitive, or identifying information from the user request or tool results, including names, emails, phone numbers, IPs, IDs, or credentials. You MUST generalize specific entities into roles such as \"a user\", \"the customer\", or \"an account\". Example: \"Retrieving a customer's recent orders to investigate a billing issue and help support determine the appropriate resolution.\""
      • addedInput schema / properties / llm_model
        Added value: +{
+  "description": "The exact model identifier you (the assistant) are running as, taken from your system prompt or environment (e.g. \"claude-opus-4-8\", \"gpt-5.2\"). Used for analytics only. If you do not know your model identifier with certainty, pass \"unknown\" — never guess.",
+  "type": "string"
+}
      • changedInput schema / required
        Previous value: -[
-  "job_id",
-  "context"
-]New value: +[
+  "job_id",
+  "context",
+  "llm_model"
+]
    • Changedget_report_status3 fields changed
      • changedInput schema / properties / context / description
        Previous value: -"Explain why you are calling this tool and how it fits into the user's overall goal. This parameter is used for analytics and user intent tracking. YOU MUST provide 15-25 words (count carefully). NEVER use first person ('I', 'we', 'you') - maintain third-person perspective. NEVER include sensitive information such as credentials, passwords, or personal data. Example (20 words): \"Searching across the organization's repositories to find all open issues related to performance complaints and latency issues for team prioritization.\""New value: +"Explain in 15-25 words, in third person, why this tool is called and how it supports the user's goal. For analytics only. You MUST describe only the abstract purpose of the tool call. NEVER include, repeat, paraphrase, or infer personal, sensitive, or identifying information from the user request or tool results, including names, emails, phone numbers, IPs, IDs, or credentials. You MUST generalize specific entities into roles such as \"a user\", \"the customer\", or \"an account\". Example: \"Retrieving a customer's recent orders to investigate a billing issue and help support determine the appropriate resolution.\""
      • addedInput schema / properties / llm_model
        Added value: +{
+  "description": "The exact model identifier you (the assistant) are running as, taken from your system prompt or environment (e.g. \"claude-opus-4-8\", \"gpt-5.2\"). Used for analytics only. If you do not know your model identifier with certainty, pass \"unknown\" — never guess.",
+  "type": "string"
+}
      • changedInput schema / required
        Previous value: -[
-  "job_id",
-  "context"
-]New value: +[
+  "job_id",
+  "context",
+  "llm_model"
+]
    • Changedlist_my_reports3 fields changed
      • changedInput schema / properties / context / description
        Previous value: -"Explain why you are calling this tool and how it fits into the user's overall goal. This parameter is used for analytics and user intent tracking. YOU MUST provide 15-25 words (count carefully). NEVER use first person ('I', 'we', 'you') - maintain third-person perspective. NEVER include sensitive information such as credentials, passwords, or personal data. Example (20 words): \"Searching across the organization's repositories to find all open issues related to performance complaints and latency issues for team prioritization.\""New value: +"Explain in 15-25 words, in third person, why this tool is called and how it supports the user's goal. For analytics only. You MUST describe only the abstract purpose of the tool call. NEVER include, repeat, paraphrase, or infer personal, sensitive, or identifying information from the user request or tool results, including names, emails, phone numbers, IPs, IDs, or credentials. You MUST generalize specific entities into roles such as \"a user\", \"the customer\", or \"an account\". Example: \"Retrieving a customer's recent orders to investigate a billing issue and help support determine the appropriate resolution.\""
      • addedInput schema / properties / llm_model
        Added value: +{
+  "description": "The exact model identifier you (the assistant) are running as, taken from your system prompt or environment (e.g. \"claude-opus-4-8\", \"gpt-5.2\"). Used for analytics only. If you do not know your model identifier with certainty, pass \"unknown\" — never guess.",
+  "type": "string"
+}
      • changedInput schema / required
        Previous value: -[
-  "context"
-]New value: +[
+  "context",
+  "llm_model"
+]
    • Changedrun_growth_audit3 fields changed
      • changedInput schema / properties / context / description
        Previous value: -"Explain why you are calling this tool and how it fits into the user's overall goal. This parameter is used for analytics and user intent tracking. YOU MUST provide 15-25 words (count carefully). NEVER use first person ('I', 'we', 'you') - maintain third-person perspective. NEVER include sensitive information such as credentials, passwords, or personal data. Example (20 words): \"Searching across the organization's repositories to find all open issues related to performance complaints and latency issues for team prioritization.\""New value: +"Explain in 15-25 words, in third person, why this tool is called and how it supports the user's goal. For analytics only. You MUST describe only the abstract purpose of the tool call. NEVER include, repeat, paraphrase, or infer personal, sensitive, or identifying information from the user request or tool results, including names, emails, phone numbers, IPs, IDs, or credentials. You MUST generalize specific entities into roles such as \"a user\", \"the customer\", or \"an account\". Example: \"Retrieving a customer's recent orders to investigate a billing issue and help support determine the appropriate resolution.\""
      • addedInput schema / properties / llm_model
        Added value: +{
+  "description": "The exact model identifier you (the assistant) are running as, taken from your system prompt or environment (e.g. \"claude-opus-4-8\", \"gpt-5.2\"). Used for analytics only. If you do not know your model identifier with certainty, pass \"unknown\" — never guess.",
+  "type": "string"
+}
      • changedInput schema / required
        Previous value: -[
-  "url",
-  "context"
-]New value: +[
+  "url",
+  "context",
+  "llm_model"
+]
  3. 8 tool updates
    • Changedanalyze_competitor3 fields changed
      • addedInput schema / properties / context
        Added value: +{
+  "description": "Explain why you are calling this tool and how it fits into the user's overall goal. This parameter is used for analytics and user intent tracking. YOU MUST provide 15-25 words (count carefully). NEVER use first person ('I', 'we', 'you') - maintain third-person perspective. NEVER include sensitive information such as credentials, passwords, or personal data. Example (20 words): \"Searching across the organization's repositories to find all open issues related to performance complaints and latency issues for team prioritization.\"",
+  "type": "string"
+}
      • addedInput schema / properties / conversation_id
        Added value: +{
+  "description": "Echo the conversation_id from the server's previous response. The server provides it on the first call — never invent one, and do not issue parallel tool calls until you have it.",
+  "type": "string"
+}
      • changedInput schema / required
        Previous value: -[
-  "url"
-]New value: +[
+  "url",
+  "context"
+]
    • Changedbrowse_public_reports3 fields changed
      • addedInput schema / properties / context
        Added value: +{
+  "description": "Explain why you are calling this tool and how it fits into the user's overall goal. This parameter is used for analytics and user intent tracking. YOU MUST provide 15-25 words (count carefully). NEVER use first person ('I', 'we', 'you') - maintain third-person perspective. NEVER include sensitive information such as credentials, passwords, or personal data. Example (20 words): \"Searching across the organization's repositories to find all open issues related to performance complaints and latency issues for team prioritization.\"",
+  "type": "string"
+}
      • addedInput schema / properties / conversation_id
        Added value: +{
+  "description": "Echo the conversation_id from the server's previous response. The server provides it on the first call — never invent one, and do not issue parallel tool calls until you have it.",
+  "type": "string"
+}
      • addedInput schema / required
        Added value: +[
+  "context"
+]
    • Changedget_growth_audit3 fields changed
      • addedInput schema / properties / context
        Added value: +{
+  "description": "Explain why you are calling this tool and how it fits into the user's overall goal. This parameter is used for analytics and user intent tracking. YOU MUST provide 15-25 words (count carefully). NEVER use first person ('I', 'we', 'you') - maintain third-person perspective. NEVER include sensitive information such as credentials, passwords, or personal data. Example (20 words): \"Searching across the organization's repositories to find all open issues related to performance complaints and latency issues for team prioritization.\"",
+  "type": "string"
+}
      • addedInput schema / properties / conversation_id
        Added value: +{
+  "description": "Echo the conversation_id from the server's previous response. The server provides it on the first call — never invent one, and do not issue parallel tool calls until you have it.",
+  "type": "string"
+}
      • changedInput schema / required
        Previous value: -[
-  "job_id"
-]New value: +[
+  "job_id",
+  "context"
+]
    • Changedget_report3 fields changed
      • addedInput schema / properties / context
        Added value: +{
+  "description": "Explain why you are calling this tool and how it fits into the user's overall goal. This parameter is used for analytics and user intent tracking. YOU MUST provide 15-25 words (count carefully). NEVER use first person ('I', 'we', 'you') - maintain third-person perspective. NEVER include sensitive information such as credentials, passwords, or personal data. Example (20 words): \"Searching across the organization's repositories to find all open issues related to performance complaints and latency issues for team prioritization.\"",
+  "type": "string"
+}
      • addedInput schema / properties / conversation_id
        Added value: +{
+  "description": "Echo the conversation_id from the server's previous response. The server provides it on the first call — never invent one, and do not issue parallel tool calls until you have it.",
+  "type": "string"
+}
      • changedInput schema / required
        Previous value: -[
-  "job_id"
-]New value: +[
+  "job_id",
+  "context"
+]
    • Changedget_report_markdown3 fields changed
      • addedInput schema / properties / context
        Added value: +{
+  "description": "Explain why you are calling this tool and how it fits into the user's overall goal. This parameter is used for analytics and user intent tracking. YOU MUST provide 15-25 words (count carefully). NEVER use first person ('I', 'we', 'you') - maintain third-person perspective. NEVER include sensitive information such as credentials, passwords, or personal data. Example (20 words): \"Searching across the organization's repositories to find all open issues related to performance complaints and latency issues for team prioritization.\"",
+  "type": "string"
+}
      • addedInput schema / properties / conversation_id
        Added value: +{
+  "description": "Echo the conversation_id from the server's previous response. The server provides it on the first call — never invent one, and do not issue parallel tool calls until you have it.",
+  "type": "string"
+}
      • changedInput schema / required
        Previous value: -[
-  "job_id"
-]New value: +[
+  "job_id",
+  "context"
+]
    • Changedget_report_status3 fields changed
      • addedInput schema / properties / context
        Added value: +{
+  "description": "Explain why you are calling this tool and how it fits into the user's overall goal. This parameter is used for analytics and user intent tracking. YOU MUST provide 15-25 words (count carefully). NEVER use first person ('I', 'we', 'you') - maintain third-person perspective. NEVER include sensitive information such as credentials, passwords, or personal data. Example (20 words): \"Searching across the organization's repositories to find all open issues related to performance complaints and latency issues for team prioritization.\"",
+  "type": "string"
+}
      • addedInput schema / properties / conversation_id
        Added value: +{
+  "description": "Echo the conversation_id from the server's previous response. The server provides it on the first call — never invent one, and do not issue parallel tool calls until you have it.",
+  "type": "string"
+}
      • changedInput schema / required
        Previous value: -[
-  "job_id"
-]New value: +[
+  "job_id",
+  "context"
+]
    • Changedlist_my_reports3 fields changed
      • addedInput schema / properties / context
        Added value: +{
+  "description": "Explain why you are calling this tool and how it fits into the user's overall goal. This parameter is used for analytics and user intent tracking. YOU MUST provide 15-25 words (count carefully). NEVER use first person ('I', 'we', 'you') - maintain third-person perspective. NEVER include sensitive information such as credentials, passwords, or personal data. Example (20 words): \"Searching across the organization's repositories to find all open issues related to performance complaints and latency issues for team prioritization.\"",
+  "type": "string"
+}
      • addedInput schema / properties / conversation_id
        Added value: +{
+  "description": "Echo the conversation_id from the server's previous response. The server provides it on the first call — never invent one, and do not issue parallel tool calls until you have it.",
+  "type": "string"
+}
      • addedInput schema / required
        Added value: +[
+  "context"
+]
    • Changedrun_growth_audit3 fields changed
      • addedInput schema / properties / context
        Added value: +{
+  "description": "Explain why you are calling this tool and how it fits into the user's overall goal. This parameter is used for analytics and user intent tracking. YOU MUST provide 15-25 words (count carefully). NEVER use first person ('I', 'we', 'you') - maintain third-person perspective. NEVER include sensitive information such as credentials, passwords, or personal data. Example (20 words): \"Searching across the organization's repositories to find all open issues related to performance complaints and latency issues for team prioritization.\"",
+  "type": "string"
+}
      • addedInput schema / properties / conversation_id
        Added value: +{
+  "description": "Echo the conversation_id from the server's previous response. The server provides it on the first call — never invent one, and do not issue parallel tool calls until you have it.",
+  "type": "string"
+}
      • changedInput schema / required
        Previous value: -[
-  "url"
-]New value: +[
+  "url",
+  "context"
+]
  4. 4 tool updates
    • Changedanalyze_competitor1 field changed
      • addedInput schema / properties / lang
        Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Lang"
+}
    • Addedbrowse_public_reports
    • Addedget_growth_audit
    • Addedrun_growth_audit
  5. 5 tool updates
    • First observedanalyze_competitor
    • First observedget_report
    • First observedget_report_markdown
    • First observedget_report_status
    • First observedlist_my_reports

Related MCP Connectors

Related MCP Servers

  • competlab-mcp-server

    competlab
    A
    license
    A
    quality
    A
    maintenance
    Competitive intelligence platform with 24 tools. Monitor competitor pricing, content, positioning, tech stacks, and AI visibility — track how ChatGPT, Claude, and Gemini rank your brand.
    48
    3
    MIT

  • intelica-mcp

    teodorofodocrispin-cmyk
    A
    license
    A
    quality
    D
    maintenance
    Competitive intelligence for AI agents — analyze any URL or company description and get structured JSON with positioning, pain points, competitors, and unique market angles. Payments via x402 protocol ($0.05 USDC on Base mainnet), no accounts required.
    4
    1
    MIT

  • techstack-detective-mcp

    emily397
    F
    license
    Not graded
    quality
    C
    maintenance
    Provides AI agents with tools to detect Shopify apps, WordPress plugins, DNS/email/SaaS footprint, and estimate SaaS spend for competitive intelligence and vendor research.
    -

  • toolradar-mcp

    Nadeus
    A
    license
    A
    quality
    A
    maintenance
    Give your AI agent access to 8,400+ software tools — search, compare, get pricing, find alternatives, and discover the best tool for any use case.
    8
    53 npm
    4
    MIT
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources