AlpineLead OI

Configure autonomous hunter

hunter_configure

Idempotent

Use when the user wants AlpineLead OI to keep looking for new opportunities over time. Supports conservative, active and aggressive modes with a hard credit cap so autonomous prospecting cannot overspend.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`region`	No	Optional target region/state/canton.
`country`	No	Austria, Germany, Switzerland or DACH.	Österreich
`enabled`	Yes	Enable or pause autonomous Hunter runs.
`district`	No	Optional target district.
`industry`	No	Target industry/category.
`hunt_mode`	No	Hunter behavior: conservative, active or aggressive. Aggressive keeps hunting until target or budget cap.	active
`offer_prompt`	No	What the user sells and the opportunity Hunter should look for.
`target_count`	No	Desired accepted leads per run.
`cadence_hours`	No	Hunter cadence in hours.
`minimum_score`	No	Minimum personal/opportunity score accepted by Hunter.
`max_credits_per_run`	No	Hard prepaid credit cap per Hunter run. Default 31 credits.

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

Changed2 schema fields changedSep 2, 2026

addedInput schema / properties / hunt_mode

Added value: +{
+  "default": "active",
+  "description": "Hunter behavior: conservative, active or aggressive. Aggressive keeps hunting until target or budget cap.",
+  "title": "Hunt Mode",
+  "type": "string"
+}

addedInput schema / properties / max_credits_per_run

Added value: +{
+  "default": 31,
+  "description": "Hard prepaid credit cap per Hunter run. Default 31 credits.",
+  "maximum": 101,
+  "minimum": 6,
+  "title": "Max Credits Per Run",
+  "type": "integer"
+}

First observedAug 23, 2026

TDQS

A4/5.0

Behavior4/5

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

Annotations already indicate idempotent and non-destructive behavior. The description adds useful behavioral context: it supports conservative, active, and aggressive modes, and enforces a hard credit cap to prevent overspending. This goes beyond the annotations and clarifies the autonomous cost guardrail.

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?

Two concise sentences with high signal. The first sentence front-loads the usage condition, and the second adds key behavioral boundaries. No filler or redundancy.

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-parameter configuration tool, the description is relatively brief but supported by a fully documented schema and an output schema. It captures the core decision, ongoing autonomous prospecting, and the critical safety guardrail (credit cap). It could explicitly mention persistence or relationship to hunter_run, but the provided context is largely sufficient.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema fully documents all 11 parameters. The description's mention of modes and credit cap largely mirrors what is already in the schema (hunt_mode, max_credits_per_run), adding no significant extra semantic meaning. Baseline 3 is appropriate.

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 clearly states the tool configures AlpineLead OI to keep looking for opportunities over time, which is a specific verb and resource. It also distinguishes the ongoing nature of the hunter from one-off operations, though it does not explicitly name siblings like hunter_run.

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 description opens with 'Use when the user wants AlpineLead OI to keep looking for new opportunities over time,' giving a clear trigger condition. It does not mention exclusions or explicitly compare against alternative tools, but the use case is well-scoped enough for an agent.

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

All AlpineLead OI tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

C2.4/5.0

Disambiguation2/5

Several tools overlap or duplicate: run_sales_mission intentionally duplicates check_sales_mission_status and get_sales_mission_result, and there are multiple capability/routing tools (get_capabilities, match_alpinelead_capability, get_alpinelead_recommendation_packet, recommend_next_tool) with similar purposes. Blank descriptions for several nexus_* tools make their boundaries even harder for an agent to determine.

Naming Consistency2/5

All names use snake_case, but there is no consistent verb_noun pattern. The set mixes prefixed families (agentpub_*, nexus_*, predictive_*_info), noun-only names (winning_pattern, learning_engine), reversed noun_verb names (radar_check, hunter_run), and get/check/run/status variants for closely related operations.

Tool Count1/5

56 tools is far beyond a well-scoped server surface. Many are one-off info, status, or diagnostic tools that could be consolidated into parameterized tools. This places an excessive routing burden on the agent and dilutes the core sales workflow.

Completeness3/5

The core lead-to-CRM workflow is fairly complete: discovery, analysis, qualification, sales kit generation, HubSpot push, and learning/feedback loops are covered. However, there are notable gaps such as no way to list or retrieve saved analyses, no explicit stop/cancel for Hunter or Sales Mission runs, and no update/cancel operations for Nexus tasks.

Resources

Need Help?