Skip to main content
Glama
Sign In
LeadIntel

LeadIntel

by rushikesheleven
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

generate_business_report

Synthesize website audits, SEO, social, competitor, and lead-scoring data into a 12-section business intelligence report in Markdown, HTML, or JSON.

Instructions

    Generate a comprehensive 12-section business intelligence report.

    Synthesizes technical audits, SEO evaluations, social presence scans,
    competitor benchmarks, lead scores, and optional AI strategic insights.

    Report Sections:
    1. Executive Summary
    2. Business Overview
    3. Digital Presence Assessment
    4. Website Technical Audit
    5. SEO Analysis
    6. Social Media Analysis
    7. Competitor Benchmarking
    8. Lead Qualification & Scoring
    9. Identified Digital Opportunities
    10. Recommended Service Packages
    11. Suggested Multi-Channel Outreach
    12. Data Sources, Attributions & Limitations

    Features:
    - Works completely offline without AI or external paid APIs.
    - Outputs in Markdown, HTML, or structured JSON.
    - Accurately references OpenStreetMap ODbL attributions.

    Args:
        business_info: Dict containing at least 'name', plus optional 'category', 'city', 'website'.
        website_analysis: Output from analyze_website tool (optional).
        seo_audit: Output from check_seo tool (optional).
        social_profiles: Output from find_social_profiles tool (optional).
        competitor_research: Output from find_competitors tool (optional).
        lead_score_data: Output from score_lead tool (optional).
        ai_insights: Output from generate_business_insights or generate_outreach tool (optional).
        output_format: 'markdown' (default), 'html', or 'json'.

    Returns:
        Dict containing the rendered report content, format, and metadata.

Input Schema

NameRequiredDescriptionDefault
seo_auditNo
ai_insightsNo
business_infoYes
output_formatNomarkdown
lead_score_dataNo
social_profilesNo
website_analysisNo
competitor_researchNo

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.3/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 burden and does well: it discloses offline operation without AI or paid APIs, supported output formats, and ODbL attribution handling. Gaps remain on whether the tool is purely computational (no side effects) and how missing optional inputs affect the rendered sections.

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?

Well front-loaded with purpose first, then capabilities, then Args. The 12-item section list is long but earns its place by telling the agent what data to gather; the Features list is slightly padded but short.

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?

A complex 8-parameter aggregator, yet the description covers inputs, formats, offline behavior, and attributions; an output schema exists so return values need only minimal mention. The main omission is guidance on graceful degradation when optional inputs are absent.

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: each of the 8 parameters is explained, business_info's required 'name' plus optional fields are spelled out beyond the permissive schema, and output_format's enum and default are restated. It does not specify the nested shape expected for the analysis payloads, which all accept arbitrary objects.

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 ('Generate a comprehensive 12-section business intelligence report') and enumerates the exact content, so an agent knows precisely what it produces. The 'Synthesizes technical audits, SEO evaluations, social presence scans...' sentence distinguishes it from the sibling tools that produce those individual inputs.

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?

The Args block implicitly defines the pipeline by naming the sibling tool each input comes from (analyze_website, check_seo, find_social_profiles, find_competitors, score_lead, generate_business_insights/generate_outreach), and every input except business_info is marked optional. It lacks an explicit statement of when to prefer this aggregator over calling individual tools, or whether partial inputs yield a degraded report.

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

Deploy Server

Other Tools