Skip to main content
Glama

Lower Webhound Report Budget

webhound_set_budget
Destructive

Reduce the budget of an active research report only when the user explicitly requests to narrow scope or conclude the investigation.

Instructions

Lower a running or paused report budget only after the user explicitly asks to reduce the remaining research scope or finish with the research already gathered. This changes the report stopping boundary; Webhound then performs normal final assembly. Never use this because partial notes look sufficient, the run is taking time, or the agent wants an earlier result.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
session_idYes
target_budgetYesNew total report budget, lower than the current budget. To finish with current research, use budget_control.minimum_target_budget from webhound_watch or webhound_get_session.
user_requested_budget_reductionYesMust be true only when the user explicitly asked to lower this report budget or finish at a lower research scope.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
okYes
urlNo
bodyNo
codeNo
costNo
dataNo
doneNo
kindNo
nameNo
toolYes
errorNo
agentsNo
alertsNo
budgetNo
statusNo
blockedNo
datasetNo
healthyNo
messageNo
productNo
resumedNo
stoppedNo
summaryYes
acceptedNo
activityNo
free_runNo
no_spendNo
requiredNo
documentsNo
retryableNo
checked_atNo
is_runningNo
message_idNo
new_budgetNo
session_idNo
top_up_urlNo
api_messageNo
billing_urlNo
next_actionNo
total_spentNo
amount_addedNo
credit_limitNo
next_actionsNo
output_readyNo
session_typeNo
current_spendNo
error_detailsNo
original_toolNo
target_budgetNo
action_startedNo
budget_controlNo
current_budgetNo
guidance_addedNo
schema_versionYes
current_balanceNo
mcp_next_actionNo
previous_budgetNo
session_startedNo
status_snapshotNo
completion_stateNo
research_harnessNo
runtime_estimateNo
sidecar_guidanceNo
agent_instructionNo
completion_reasonNo
followup_check_inNo
assembly_triggeredNo
completion_contractNo
forbidden_next_toolsNo
resumed_for_assemblyNo
auto_recharge_enabledNo
minimum_target_budgetNo
successful_completionNo
user_message_templateNo
requested_target_budgetNo
retry_after_user_confirmsNo
adjusted_to_cover_current_spendNo
Behavior4/5

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

Beyond annotations (destructiveHint, openWorldHint), the description explains that lowering changes the stopping boundary and triggers normal final assembly. It also reinforces the behavioral constraint on user_requested_budget_reduction, adding value over the annotations alone.

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?

The description is exceptionally concise: two substantive sentences plus a prohibition, with no extraneous words. It front-loads the core action and follows with conditions and restrictions, making it easy to scan.

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?

Given the annotations, output schema (not shown but indicated as present), and parameter constraints, the description is largely complete. It covers preconditions (running or paused), effect (changes stopping boundary, final assembly), and usage guidelines. Minor gaps include lack of explicit session_id purpose and error handling, but these are offset by the output schema.

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 coverage is 67%; the description adds little beyond schema for target_budget and user_requested_budget_reduction, but does not mention session_id at all. While the schema provides adequate descriptions for two parameters, the missing session_id description reduces clarity.

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?

The description clearly states the tool lowers a running or paused report budget, using specific verb 'lower' and resource 'report budget'. It distinguishes from sibling tools like webhound_add_budget by focusing on reduction and specifying when to use it.

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 explicitly states when to use the tool ('only after the user explicitly asks to reduce...') and provides clear prohibitions ('Never use this because...'). However, it does not name alternative tools for scenarios like stopping or increasing budget, relying on implicit differentiation from siblings.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/WebhoundAI/webhound-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server