Skip to main content
Glama

score_lead

Evaluate and score business leads for digital services fit with a deterministic 0–100 rating, then identify service opportunities and a recommended package.

Instructions

    Evaluate and score a business lead for digital services suitability.

    Calculates a deterministic 0-100 overall prospect score based on:
    1. Website quality (max 20 pts)
    2. Technical SEO (max 20 pts)
    3. Social media presence (max 15 pts)
    4. Contact accessibility (max 10 pts)
    5. Mobile readiness (max 10 pts)
    6. Digital presence gaps vs competitors (max 15 pts)
    7. Business relevance & localization (max 10 pts)

    Opportunity Analysis:
    Provides specialized opportunity scores (0-100) for:
    - Website Development
    - SEO Services
    - Social Media Management
    - Digital Marketing

    Compliance & Ethics:
    - Missing inputs reduce confidence and evidence completeness, avoiding arbitrary score penalties.
    - Verified defects are separated from missing information.
    - Does not speculate on customer purchasing budget or guarantee conversion.
    - Uses zero paid APIs or tokens.

    Args:
        business_name: Name of the business (required).
        business_category: Industry/category description.
        website_analysis: Results from analyze_website tool (optional).
        seo_audit: Results from check_seo tool (optional).
        social_profiles: Results from find_social_profiles tool (optional).
        competitor_comparison: Results from compare_businesses tool (optional).
        contact_info: Available phone, email, or address dictionary (optional).
        weights: Optional custom weight overrides for the 7 categories.

    Returns:
        Structured lead evaluation report including overall score, priority tier,
        service opportunities, and recommended package.
    

Input Schema

NameRequiredDescriptionDefault
weightsNo
seo_auditNo
contact_infoNo
business_nameYes
social_profilesNo
website_analysisNo
business_categoryNo
competitor_comparisonNo

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.8/5.0
Behavior3/5

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

No annotations are supplied, so the description carries the whole burden. It does usefully disclose that scoring is deterministic, that missing inputs reduce confidence rather than trigger arbitrary penalties, that verified defects are separated from missing data, and that no paid APIs are used; but it never states that the tool is side-effect-free/read-only, nor anything about scoring cost or execution limits.

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?

Purpose and rubric are front-loaded, and each block (scoring categories, opportunity scores, compliance, args, returns) is clearly separated. The seven-item points breakdown and the compliance bullets are informative rather than filler, though the section headers duplicate what the Args/Returns blocks already imply, so the text is longer than strictly needed.

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, so return values need not be spelled out, yet the description still usefully signals that the report includes an overall score, priority tier, service opportunities and a recommended package. For an eight-parameter pure-computation tool with no annotations, the only real omission is the weights key contract and nested input shapes.

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 description coverage is 0%, so the description must compensate, and it largely does by naming all eight parameters, marking business_name required and the rest optional, and telling the agent which sibling tool produces each input object. The gap is 'weights', which is documented only as 'custom weight overrides for the 7 categories' with no key names or value conventions, even though the schema leaves it as a free-form number map. The expected shapes of the nested analysis objects are likewise undescribed.

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 ('Evaluate and score a business lead') plus the domain ('digital services suitability'), and the rubric makes obvious what the output measures. It never names a sibling, so the agent must infer on its own how this differs from generate_business_insights or generate_business_report.

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?

Usage context is conveyed through the parameter docs: the optional inputs are labelled 'Results from analyze_website tool', 'check_seo tool', 'find_social_profiles tool' and 'compare_businesses tool', which effectively describes an upstream pipeline. There is no explicit when-not or contrast with the report/insight-generation siblings.

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