Skip to main content
Glama

generate_business_insights

Synthesizes website audits, SEO checks, competitor benchmarks, and lead scores into evidence-based strategic business insights and actionable service recommendations.

Instructions

    Generate evidence-based strategic business insights using local Ollama AI.

    Synthesizes technical audits, competitor benchmarks, and lead scores to provide:
    - Executive summary of digital maturity
    - Clear explanations for digital marketing and SEO opportunities
    - Strategic interpretation of the deterministic lead score
    - Grounded competitor insights
    - Actionable service recommendations (Web Dev, SEO, Social, Marketing)

    Ethical & Operational Safeguards:
    - Connects to local Ollama (http://localhost:11434). Zero cloud AI calls or tokens used.
    - Grounded strictly in provided evidence; never invents revenue, budgets, or purchasing intent.
    - If Ollama is not installed or running, returns a clean informative error without crashing.

    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).
        lead_score_data: Results from score_lead tool (optional).
        contact_info: Available contact details (optional).
        model: Optional Ollama model override (default: configured OLLAMA_MODEL, e.g. 'llama3').

    Returns:
        Structured AI insights grounded in verified facts.
    

Input Schema

NameRequiredDescriptionDefault
modelNo
seo_auditNo
contact_infoNo
business_nameYes
lead_score_dataNo
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.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 substantial work: it discloses the local Ollama endpoint (http://localhost:11434), that no cloud AI calls or tokens are used, that output is grounded and will not invent revenue or purchasing intent, and that a missing Ollama returns a clean error rather than crashing. What is missing is latency/throughput expectations and determinism, both material for an LLM-backed tool an agent may chain.

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?

The opening sentence and safeguards are front-loaded and earn their place, but the output bullet list overlaps the Returns line and the Args block restates the schema's parameter names. Some phrasing is redundant ('Zero cloud AI calls or tokens used' says the same thing twice). Docstring boilerplate ('Args:', 'Returns:') leaks into the agent-facing text.

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 the brief Returns line is proportionate. For a nine-parameter generative tool with zero annotation coverage, the description covers privacy posture, evidence grounding, and failure behavior, which is most of what an agent needs. The remaining gap is workflow ordering relative to the sibling analysis tools and expected runtime.

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 0% and all nine parameters are bare typed objects, so the description is the only source of meaning. Its Args block supplies provenance for each optional payload ('Results from compare_businesses tool') and marks required vs optional, plus the model default. It does not describe the internal shape of the evidence objects, so the agent must know what those sibling tools return.

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 and resource: generating evidence-based strategic business insights via local Ollama, and enumerates the concrete outputs (executive summary, SEO opportunities, lead score interpretation, recommendations). It clearly implies synthesis across the audit tools rather than outreach or reporting. It stops short of naming the closest siblings (generate_business_report, generate_outreach), so an agent must infer the boundary.

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: each optional argument is annotated as 'Results from analyze_website tool', 'Results from check_seo tool', etc., which sketches a pipeline order without stating it. There is no explicit when-to-use vs generate_business_report or generate_outreach, and no when-not guidance. The one operational exclusion present is the Ollama-not-running case, which is a failure mode rather than a selection rule.

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