Analook — Competitor Intelligence
Server Details
Competitor intelligence for AI agents — SEO, traffic, social, Product Hunt, pricing, AI insights.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- Gingiris/Competitor-analysis-tool
- GitHub Stars
- 0
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.4/5 across 8 of 8 tools scored.
Each tool has a clearly distinct purpose: analyze_competitor vs run_growth_audit are different analysis types; get_report, get_report_markdown, get_report_status serve the same job but distinct roles (data retrieval, formatting, polling); list_my_reports and browse_public_reports are for listing user's or public reports. No overlap.
All tool names follow a consistent verb_noun pattern in snake_case (e.g., analyze_competitor, get_report_status, run_growth_audit). No mixing of conventions.
The server has 8 tools, well-scoped for its competitor intelligence purpose. It covers submission, retrieval, status polling, listing, and a separate audit function without overloading.
The tool surface is complete for the domain: submission of two analysis types, retrieval in JSON and Markdown, status polling, listing own reports, and browsing public reports. No obvious missing operations like delete or update are needed for this use case.
Available Tools
8 toolsanalyze_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
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| lang | No | ||
| product_name | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses behavioral traits: authentication required, deducts 1 credit, typical duration 2-5 minutes, and the return format (success with job_id, error on failure). 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 and well-structured: a one-line purpose, then bullet-like details, followed by parameter descriptions with examples. Every sentence adds value with 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 no output schema, the description documents both success and error return values, polling behavior, and duration. It provides complete context for a submission tool, leaving no gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It does so excellently: explains url with example, product_name as optional override (defaults to domain), lang with defaults. This adds meaning beyond the bare 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's purpose: 'Submit a competitor analysis job.' It specifies the scope (analyzes a website across 15+ data sources) and explicitly mentions sibling tools (get_report_status, get_report) for retrieving results, distinguishing it from other tools.
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 tells when to use the tool (to analyze a competitor website) and what to do next (poll with get_report_status). It does not explicitly state when not to use or compare with other analysis tools like run_growth_audit, but the guidance is clear and includes post-submission steps.
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'
| Name | Required | Description | Default |
|---|---|---|---|
| category | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description reveals it is a read-only operation requiring no authentication or credits, and returns public reports. It does not detail pagination or ordering, but for a simple browse tool this is sufficient.
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 short paragraphs: first states purpose and output, second gives usage guidance and parameter details. No redundancy, front-loaded, every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, output, parameter guidance, and usage context. Missing return format details (e.g., list length, ordering) but adequate for a simple browse tool with one optional parameter.
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 description adds examples for the category parameter ('AI / Agents', etc.), compensating for the 0% schema description coverage and the lack of enums in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Browse' and resource 'public competitor-intelligence report gallery', specifies the returned fields (product name, domain, category, link), and distinguishes from sibling tools like analyze_competitor which generate reports.
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: 'before spending a credit on a fresh one', and implies not to use for specific reports. Provides context about no authentication/credits, but does not explicitly name alternative tools.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses return structure and the fact that while running only status/progress is returned. It doesn't mention blocking or polling behavior, but for a fetch tool this is adequate transparency.
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 and well-structured: purpose first, then args, then returns with a note about running state. 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 only one parameter and no output schema, the description covers the necessary information: parameter origin, return shape when complete vs running. It could mention error handling for invalid job_id, but overall complete for its 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 0%, but the description explains the job_id parameter thoroughly: it comes from run_growth_audit() and starts with 'ga-', providing essential meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it fetches a Growth Audit's three reports as Markdown. It distinguishes from siblings like run_growth_audit (which starts the audit) and get_report_status, making the 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 specifies that the job_id comes from run_growth_audit() and provides a prefix pattern ('ga-'), giving clear context on when to use this tool. No explicit alternatives or when-not-to-use guidance, but the sibling names imply the workflow.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries full burden. It discloses return format (structured JSON) and error cases, but does not explicitly state the tool is read-only or describe any side effects.
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 with purpose, then lists contents, then args. The content list is somewhat lengthy but each sentence is relevant. No wasted 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?
Covers return value content, error handling, and precondition. With one parameter and no output schema, the description adequately informs an agent.
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 single parameter job_id is described with context: 'ID from analyze_competitor(); status must be completed', adding meaning beyond the schema's minimal 'Job Id' title.
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 'Fetch the full competitor analysis report as structured JSON', specifying the verb 'Fetch' and the resource 'competitor analysis report'. It distinguishes from siblings like get_report_markdown and get_report_status.
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 that job_id comes from analyze_competitor() and that status must be 'completed', indicating when to use the tool. Also notes that it returns an error if not found or not ready, but does not explicitly mention alternatives.
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}
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses the return format (markdown or error) and the prerequisite status, but does not explicitly state the tool is read-only or describe error conditions, rate limits, or auth requirements. Adequate but not fully transparent.
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: a one-line purpose, a one-line usage hint, and a structured args/returns section. Every sentence adds value without repetition or filler.
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 simplicity (one parameter, no output schema), the description covers purpose, parameter origin, status precondition, and return format. It lacks info on error details or permissions, but is largely complete for an agent to invoke 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?
The schema has 0% description coverage, so the description must compensate. It adds meaning by explaining that job_id should come from analyze_competitor() and must have a 'completed' status, which is beyond the schema's type/required fields. This helps agents use the parameter correctly.
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 uses a specific verb 'Fetch' and identifies the resource as 'the competitor analysis report as human-readable Markdown', clearly distinguishing it from sibling tools like 'get_report' (likely JSON) or 'browse_public_reports'. It also states suitability for agents preferring text, adding purpose context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use this tool ('Suitable for piping into agents that prefer text... or for direct display to end users') and provides a prerequisite: job_id from analyze_competitor() with status 'completed'. It does not explicitly list alternatives or when not to use, but the context is clear.
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}
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries the burden. Discloses return format and that it's a polling operation, but doesn't confirm read-only nature or lack of side effects.
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?
Very concise with a clear Docstring structure (Args, Returns). Every sentence provides essential 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?
Covers purpose, parameter, and return value adequately for a simple poll tool. Lacks mention of error handling or rate limits, but not critical.
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 0%, but description explains job_id as 'ID returned from analyze_competitor()', adding meaningful context beyond the schema's title.
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 'Poll an analysis job's status', which is a specific verb+resource. It distinguishes from siblings like analyze_competitor and get_report.
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?
Specifies that job_id comes from analyze_competitor(), implying it should be used after starting a job. Does not explicitly state when not to use, but context is clear.
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}, ...]}
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, so description carries full burden. It discloses authentication requirement, lightweight return (not full data), and directs to another tool for full details. Lists returned fields. Adequate transparency.
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, front-loaded with purpose, then auth, return type, and link to sibling. No excess. Returns format included efficiently.
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 parameters, no output schema, description fully explains behavior: auth, limit, return fields, and reference to get_report. Complete enough for a simple list 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?
Zero parameters; schema coverage 100%. Baseline 4 applies. Description adds nothing about params (none exist).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it lists recent competitor analysis reports (verb+resource+scope). It distinguishes from siblings like get_report (fetch full) and browse_public_reports (public vs own).
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?
Describes when to use (list recent reports, up to 50). Mentions authentication and directs to get_report for full details. Implicitly distinguishes from siblings but lacks explicit when-not statements.
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'
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| lang | No | ||
| product_name | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description fully discloses behavioral traits: takes 4-6 minutes, requires authentication, deducts 10 credits, and requires polling with get_growth_audit. No contradictions with any 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?
Concise description front-loaded with purpose, use case, and behavioral details, then clearly lists parameters. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Describes output reports, duration, cost, and polling workflow. Missing explicit mention that return value is a job_id, but implied via polling reference. Sufficient for agents.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, description adds meaning for all three parameters: url (required), product_name (optional override), lang (default 'en' or 'zh'). Could specify url format or allowed lang values more precisely.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it runs a full Growth Audit producing three reports (Executive Summary, Diagnosis Report, 30-day Action Plan), and explicitly distinguishes from analyze_competitor by describing different output structure.
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 ('how do I grow THIS product') and when not ('what is this competitor doing' – use analyze_competitor), providing clear guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!