LeadIntel

Overview Schema Source Related Servers Discussions Admin

find_competitors

Discover direct and indirect competitors for a target business using OpenStreetMap and taxonomy rules, with confidence levels, contact details, ratings, and digital presence analysis.

Instructions

    Discover and analyze competitors of a target business.

    Finds industry rivals using OpenStreetMap and semantic taxonomy rules.
    Distinguishes direct competitors (exact specialization overlap) from
    indirect competitors (broader category overlap), explaining confidence levels.

    Features:
    - Filters out unrelated businesses (does not mistake mere geographical proximity for competition).
    - Identifies competitor websites, contact info, ratings, and reviews.
    - Analyzes digital presence (website status, mobile readiness, social media footprint).
    - Zero paid API keys required; respects OpenStreetMap ODbL attribution.

    Args:
        business_name: Name of the target business (e.g. 'Acme Tech Solutions', 'Blue Bottle Coffee').
        business_category: Industry/category of the business (e.g. 'Software Development', 'Cafe').
        city: Optional city (e.g. 'San Francisco', 'London').
        state: Optional state/province (e.g. 'CA', 'TX').
        country: Optional country (e.g. 'US', 'UK').
        website: Optional target company website URL.
        max_competitors: Maximum competitors to return (1-20, default 5).
        enrich_websites: If True, tests competitor websites for availability and digital channels.

    Returns:
        Structured competitor research report.

Input Schema

Name	Required	Description	Default
`city`	No
`state`	No
`country`	No
`website`	No
`business_name`	Yes
`enrich_websites`	No
`max_competitors`	No
`business_category`	No

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Nov 4, 2026

TDQS

A3.9/5.0

Behavior4/5

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

With no annotations supplied, the description carries the full load and does so reasonably: it discloses the data source (OpenStreetMap), the ODbL attribution obligation, that no paid API keys are needed, that geographically proximate but unrelated businesses are filtered out, and that confidence levels are reported. It leaves gaps around cost/latency (enrich_websites implied to perform live website tests), behavior when the business is not found, and that it is a read-only operation.

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

Conciseness3/5

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

Front-loaded with a good one-line summary, but it then reverts to a docstring with a Features bullet list, an Args block and a Returns line, and several bullets (websites, contact info, ratings) restate what the Args section already conveys. Structure is legible but padded relative to the information gained.

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?

An output schema exists and the description defers to it appropriately ("Structured competitor research report"), so the main burden is inputs and behavior, both covered across 8 parameters. What is missing is minor but real: how city/state/country combine for geocoding, and whether business_category materially improves direct-vs-indirect matching.

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

Parameters5/5

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

Schema description coverage is 0%, so the description must compensate and largely does: every one of the 8 parameters is addressed with meaning or an example, including the 1-20 range and default of max_competitors, which is not encoded anywhere in the schema, and the effect of enrich_websites (tests competitor sites for availability and digital channels). Examples are given for business_name, business_category, city, state and country.

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?

Opens with a specific verb+resource pair ("Discover and analyze competitors of a target business") and then narrows it further by explaining direct vs indirect competitor logic and the OpenStreetMap/taxonomy basis. Sibling tools like search_businesses and compare_businesses are never named, so an agent must infer the boundary itself, which keeps it 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?

Usage is only implied: the description explains what the tool produces and gives argument examples, so an agent can guess this is the discovery step before compare_businesses or score_lead. There is no explicit when-to-use / when-not-to-use statement, no mention of what must already exist (e.g. a known business_name), and no routing to alternatives.

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

Deploy Server