Skip to main content
Glama
Sign In
LeadIntel

LeadIntel

by rushikesheleven
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

generate_outreach

Create personalized B2B outreach drafts for email, LinkedIn, and WhatsApp using verified lead data, so sales teams can start relevant prospect conversations from grounded insights.

Instructions

    Generate personalized, multi-channel B2B outreach messages using local Ollama AI.

    Produces ready-to-use drafts across 3 channels:
    - Email pitch: Structured subject line + 3-paragraph value-first pitch referencing verified findings.
    - LinkedIn message: Concise connection request (< 300 characters).
    - WhatsApp Business: Respectful, direct conversational pitch (< 120 words).

    Ethical & Operational Safeguards:
    - Uses local Ollama model (no third-party cloud data transfer).
    - Grounded exclusively in verified technical data.
    - Does not invent fake claims, guarantees, or assume prospect budgets.

    Args:
        business_name: Target company name (required).
        business_category: Business industry/category.
        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: Contact details dictionary (optional).
        agency_name: Your digital agency or company name.
        sender_name: Name of the person/role sending the message.
        model: Optional Ollama model override.

    Returns:
        Dict containing multi-channel outreach drafts.

Input Schema

NameRequiredDescriptionDefault
modelNo
seo_auditNo
agency_nameNoOur Agency
sender_nameNoLead Specialist
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
Behavior3/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 deliver real value: it discloses the local Ollama model (no third-party data transfer), that output is grounded in verified data, and that it will not fabricate guarantees or budgets. It also sketches the return shape. It omits operational behavior an agent needs, such as expected latency/cost of an LLM call, behavior when all optional inputs are null, and what happens if the Ollama model is unavailable.

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

Conciseness5/5

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

Purpose is front-loaded, followed by a scannable per-channel breakdown, then safeguards, then args. Dense but well organized with no filler sentences; the args block earns its space given the schema has no descriptions.

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?

For an 11-param, annotation-free generation tool with an output schema, the description covers inputs, output shape, data-handling policy, and content constraints. The remaining gap is edge-case behavior (missing optional inputs, model failure) and the fact that the output schema's structure is only vaguely gestured at as 'Dict containing multi-channel outreach drafts'.

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 across 11 params, and it does list every one with a short gloss and a required marker. Its biggest contribution is provenance mapping — naming which sibling tool produces website_analysis, seo_audit, social_profiles, competitor_comparison, and lead_score_data — which the schema cannot express. It still leaves the expected shape of those nested objects undefined, so an agent knows where to get them but not what they should contain.

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 ('Generate personalized, multi-channel B2B outreach messages') and enumerates exactly what is produced across three channels, including length constraints. It never explicitly contrasts itself with siblings like generate_business_insights or generate_business_report, so differentiation is implicit rather than stated.

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: tagging inputs as 'Results from analyze_website tool' / 'check_seo' / 'score_lead' sketches a pipeline order without stating when to call this versus the report/insight generators. There is no guidance on required prerequisites, no note that richer optional inputs yield more personalized drafts, and no when-not-to-use case.

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