A
licenseNot graded
qualityC
maintenanceEnables iterative deep research by integrating AI agents with search engines, web scraping, and large language models for efficient data gathering and comprehensive reporting.
8
323
MIT
Webhound MCP
by WebhoundAI
Enables Windsurf (by Codeium) to leverage Webhound's budgeted research for cited reports and datasets.
Enables GitHub Copilot to use Webhound's budget-controlled research capabilities for generating cited reports and datasets.
Allows ChatGPT (OpenAI) to use Webhound for budget-controlled research, returning cited outputs.
Integrates Webhound's research capabilities into Replit Agent, allowing budgeted research and data extraction.
Webhound MCP
Website · Thesis · MCP setup · npm · Official registry
Research has no natural stopping point. A prompt tells an agent what to investigate, but it does not tell the agent how much work the question deserves.
Webhound adds that missing control. Give it a prompt and a dollar budget; it spends that effort searching, reading, verifying, and assembling a cited report or structured dataset. The completed result includes the working documents, sources, claim traces, limitations, and evidence pack behind the answer.
Run Webhound from any MCP-speaking agent. Webhound creates private, budgeted reports and datasets, runs as the agent's research sidecar, accepts non-interrupting source-backed notes, diagnoses failures, and returns cited outputs with sources and claim traces.
This package is the local stdio transport. Webhound also supports hosted MCP at:
https://api.webhound.ai/api/v2/mcpClient-native packages
This repository also packages the hosted MCP and the webhound-research skill
for GitHub Copilot, Claude Code, Cursor, and Kiro:
GitHub Copilot uses
plugin.json,.mcp.json, andskills/webhound-research/SKILL.md.Claude Code uses
.claude-plugin/plugin.json,.mcp.json, and the same skill. The included marketplace can be tested withclaude plugin marketplace add WebhoundAI/webhound-mcp, thenclaude plugin install webhound@webhound.Cursor uses
.cursor-plugin/plugin.json,mcp.json, and the same skill.Kiro uses
POWER.mdandmcp.json.
Both MCP files point to Webhound's production remote endpoint and contain no
API key, bearer token, static OAuth client, or shared publisher credential.
Every person authorizes their own Webhound account through OAuth.
The oauthScopes entry in mcp.json is required by Kiro so it requests
Webhound's two supported scopes instead of Kiro's unrelated defaults. Cursor
ignores that Kiro-specific field and completes OAuth from Webhound's published
authorization metadata.
The shared skill teaches each client the same public contract:
Hound is Webhound's research harness, built with DeepSeek V4 Pro and GPT-5.4 across planning, execution, verification, and assembly.
The prompt defines the investigation. The dollar budget controls research effort.
done=trueis the completion gate. The agent then inspects the evidence pack when the answer depends on the research trail.
ChatGPT developer mode:
Turn on Developer mode under Settings → Security and login.
Open Settings → Plugins, create an app, and use the hosted MCP URL above.
Click Connect. ChatGPT opens Webhound's authorization page.
Sign in to Webhound and approve the requested MCP scopes. Do not paste an API key into the OAuth flow.
The ChatGPT app can accept attachments and return normal MCP status, output, working documents, claims, and sources. Webhound deliberately does not attach a custom interactive panel beneath tool calls. Public distribution still requires plugin submission through OpenAI.
Replit Agent:
The install link supplies only Webhound's hosted MCP URL. Replit discovers Webhound's OAuth metadata and each person authorizes their own account; the payload contains no API key, bearer token, OAuth client secret, or shared publisher credential.
n8n:
Install n8n-nodes-webhound
through Settings → Community Nodes. It exposes native report, dataset,
watch/wait, output, evidence-pack, account, and help operations. Spend-bearing
starts require both an explicit dollar budget and a separate confirmation.
Each n8n user or workspace supplies its own encrypted Webhound API key; the
package contains no shared publisher credential.
Related MCP server: GPT Researcher MCP Server
Install
Create a Webhound API key, then add the stdio server to your agent:
{
"mcpServers": {
"webhound": {
"command": "npx",
"args": ["-y", "webhound-mcp@0.5.3"],
"env": {
"WEBHOUND_KEY": "wh_..."
}
}
}
}Claude hosted connector:
https://api.webhound.ai/api/v2/mcpPaste the URL into Claude's custom connector flow. The hosted server exposes OAuth discovery, authorize, and token endpoints for that connect flow.
Smithery:
Add the public
webhound/webhoundserver to your own Smithery toolbox.Every new Smithery connection starts in
auth_requiredand opens a Webhound setup screen that asks that user for their own Webhound API key.Webhound exchanges that key for a scoped MCP token stored on that Smithery connection.
Connecting another client to the same already-authorized toolbox may not prompt again; that is reuse of the same user's saved connection, not a publisher credential shared with other users.
Do not distribute one user's private toolbox endpoint as if it were a shared Webhound credential. Other users should add Webhound to their own toolbox or connect to the hosted Webhound MCP URL directly.
Manus:
Open: https://manus.im/app/plugins
Choose: Create → Add MCP by URL
Server name: Webhound
Server URL: https://api.webhound.ai/api/v2/mcp
Advanced settings: leave emptySave, sign in to Webhound, approve the connection, then start a new Manus task and send:
Call webhound_onboarding once with client set to hosted. Send its
immediate_next_message exactly once. Treat agent_playbook.conversation_flow as
the canonical sequence; the matching first entry is already consumed, so after
I reply continue with the next unconsumed entry. setup_flow is reference-only
and next_action is only the entry instruction. Do not repeatedly call
onboarding to advance it. Continue the first run through done=true and return
the output with sources and provenance. If I change the subject, drop
onboarding immediately. Do not create or edit workspace rules unless I
explicitly ask.Other hosted clients should use the same server URL with OAuth when supported.
Only clients that do not support OAuth should use a manually generated Webhound
key in their bearer-token or Authorization advanced setting.
Claude Code:
claude mcp add --transport http webhound https://api.webhound.ai/api/v2/mcp
# Local stdio alternative:
claude mcp add --transport stdio webhound --env WEBHOUND_KEY=wh_... -- npx -y webhound-mcp@0.5.3Codex:
[mcp_servers.webhound]
command = "npx"
args = ["-y", "webhound-mcp@0.5.3"]
[mcp_servers.webhound.env]
WEBHOUND_KEY = "wh_..."Cursor and Claude Desktop use the JSON shape above.
Cline CLI:
cline mcp add webhound \
--transport streamable-http \
--header "Authorization: Bearer wh_..." \
--yes \
https://api.webhound.ai/api/v2/mcpYou can also use the local stdio JSON shape above in Cline's MCP settings. After saving local stdio config, restart the agent session or open a new one if the Webhound tools do not appear. Many clients load MCP servers only when a session starts.
VS Code:
{
"servers": {
"webhound": {
"type": "stdio",
"command": "npx",
"args": ["-y", "webhound-mcp@0.5.3"],
"env": {
"WEBHOUND_KEY": "wh_..."
}
}
}
}Use the same stdio server shape for Windsurf. Windsurf commonly stores it in
~/.codeium/windsurf/mcp_config.json.
Hound
Hound is the research harness exposed by Webhound, not a selectable foundation model or mode. It is built with DeepSeek V4 Pro and GPT-5.4 across planning, execution, verification, and assembly. It is not a direct pass-through to one model and should not be described as "resolving" to a single provider backend.
The prompt defines what to investigate. The user's dollar budget defines how much research effort Hound can spend searching, reading, writing, and verifying before assembly. The MCP does not expose alternate model tiers or modes.
Defaults
Recommended setup defaults:
budget:
$5product:
reportfree run: honor the saved preference; use automatically only when enabled, or after explicit one-run consent for an exact
$5report or dataset
As a rule of thumb, $1 buys about 15 minutes of research, so the $5
default is about 75 minutes. Recommended starting points are $2 quick, $5
standard, $10 deep, and $20 exhaustive/highest-stakes (about 300 minutes
or five hours). These are not caps; users can choose a larger custom budget or
say how long they want Webhound to research, using about $1 per 15 minutes.
webhound_onboarding returns the client-aware guided first-run flow, including
account and included-run state, the budget model, setup-first versus jump-in,
report-versus-dataset guidance, waiting through done=true, provenance,
export, and billing follow-up. Hosted clients such as Manus receive the full
research flow but no workspace-writing flow unless the user explicitly
requests that separate action. Starting a normal report or dataset never
triggers workspace-rule setup.
New users may have one non-divisible free run pass. It covers one exact $5 report or dataset. It can be used from the Webhound UI, API, hosted MCP, or this stdio MCP package.
Agents can read and update defaults with:
webhound_onboardingwebhound_helpwebhound_uninstallwebhound_get_defaultswebhound_set_defaults
If a user explicitly requests workspace rules, the agent must show the complete proposed content and exact destination before writing. After approval, it reads the file back and rejects empty or frontmatter-only content.
Tool Flow
The core lifecycle is detached and visible:
Start work with
webhound_start_reportorwebhound_start_dataset.Watch with
webhound_watchorwebhound_wait.While Webhound runs, keep doing useful independent work when it can improve the result. If the calling agent finds a concrete source-backed note, save it with
webhound_add_sidecar_notes. This does not interrupt the current Planner -> Executor -> Verifier cycle.Sidecar notes are shared state. Use
webhound_list_sidecar_notesto inspect what has already been saved andwebhound_update_sidecar_noteto correct, restore, or dismiss a note without steering the session.Treat
done=trueas the authoritative finished signal.If a run is still healthy and your environment can sleep, schedule a check-in, create a reminder, or run a one-time heartbeat, use
runtime_estimate.recommended_next_check_secondsand callwebhound_watchthen. If it is still running, repeat using the updated estimate. If only a few minutes remain, usewebhound_wait.If a spend-bearing action returns
billing_requiredor a running session returnscredit_exhausted, send the user tohttps://www.webhound.ai/billingto add credits, add a card, or enable auto-recharge. Ask them to ping you when done. After they reply, callwebhound_accountto confirm billing is ready, then retry the original start/add-budget/resume action.If
awaiting_input, reply withwebhound_send_messageusingreason="awaiting_input"; that resumes the session.Use
webhound_send_messagewithreason="user_guidance"only when the user changes the objective, scope, constraints, or deliverable. Do not use steering for ordinary source suggestions.Only when the user explicitly asks to reduce the remaining report scope or finish with the research already gathered, call
webhound_set_budget. Readbudget_control.minimum_target_budgetfrom watch/session status when they want to finish at the nearest safe boundary. Lowering the budget does not bypass assembly: the revised budget becomes the stopping boundary, and Webhound runs normal final assembly afterward. Never do this merely because partial notes look sufficient or the run is taking time.When
done=trueandoutput_ready=true, callwebhound_get_sessionfor the complete canonical session in one response. If a terminal run has no output, treat its typedEMPTY_OUTPUTorDATASET_ZERO_ROWSalert as a failure rather than claiming success.webhound_get_evidence_packreturns that same complete session plus evidence-follow-up guidance. Use it when the answer depends on the research trail.Use
webhound_get_outputfor the complete polished result orwebhound_export_sessionwhen the user needs a file. Use the claims and sources tools when you need one focused surface.For datasets, inspect rows/schema plus sources; export CSV/JSON when the user needs to use the data elsewhere.
After reading/exporting the final output and evidence pack, use your own judgment to surface a few focused threads the user could pull next. Ground them in concrete things the session uncovered: unexplained entities, source gaps, paper trails, contested claims, missing rows, or narrow comparisons. These should be optional deeper follow-ups, not generic "research more" suggestions. If several are independent, they can be started in parallel as separate Webhound runs.
If the user asks for a shareable link, use
webhound_get_shareable_link. It makes that report or dataset public to anyone with the link and returns the right share URL:/document/:idfor reports,/dataset/:idfor datasets. It is not Explore publishing and does not create a/p/:slugpublication.
Budget controls depth. As a rule of thumb, $1 buys about 15 minutes of
research. A healthy run may keep searching, reading, writing, and verifying
through several waits while it uses the budget. More budget means more room for
research before final assembly; it is not a signal for the calling agent to
hurry the run. Do not send finalize/wrap-up guidance or stop the session just
because partial working notes look usable.
Dataset schema forms
Omit schema to let Webhound infer a concise schema. When fields matter, use
exactly one of these forms.
Native Webhound schema:
{
"entity_name": "Company",
"attributes": [
{ "name": "company_name", "type": "string", "is_primary": true },
{ "name": "website", "type": "string", "standard_format": "url" },
{ "name": "employee_count", "type": "number" }
]
}Object JSON Schema:
{
"type": "object",
"title": "Company",
"required": ["company_name"],
"properties": {
"company_name": {
"type": "string",
"description": "Official company name",
"x-webhound-primary": true
},
"website": { "type": "string", "format": "uri" },
"employee_count": { "type": "integer" }
}
}Native schemas require at least one is_primary: true field. For JSON Schema,
x-webhound-primary: true wins; otherwise the first required property, then
the first property, becomes the deterministic primary field. The start response
echoes normalized_schema before the dataset begins.
Public Tools
webhound_healthwebhound_onboardingwebhound_helpwebhound_uninstallwebhound_get_defaultswebhound_set_defaultswebhound_start_reportwebhound_start_datasetwebhound_watchwebhound_waitwebhound_add_sidecar_noteswebhound_list_sidecar_noteswebhound_update_sidecar_notewebhound_send_messagewebhound_stopwebhound_resumewebhound_add_budgetwebhound_set_budgetwebhound_get_outputwebhound_export_sessionwebhound_get_evidence_packwebhound_get_shareable_linkwebhound_get_claimswebhound_get_sourceswebhound_search_sessionswebhound_list_sessionswebhound_get_sessionwebhound_upload_filewebhound_accountwebhound_diagnose
Supported upload formats are CSV, XLSX, PDF, DOCX, TXT, Markdown, and VTT. Convert legacy XLS/DOC files to XLSX/DOCX before uploading. MIME type, filename extension, and recognizable file bytes are checked before the upload reaches Webhound.
Completion And Diagnostics
webhound_watch returns:
done: terminal statusoutput_ready: an artifact exists; wait fordone=truebefore treating it as finalcompletion_reason:budget_complete,natural_complete,awaiting_input,user_stopped,credit_exhausted,failed, orstuck_or_emptyalerts: structured issues with next actionsbudget_control: whether a report budget can be reduced, current spend and budget, and the nearest safe lower targetnext_research_instruction: guidance for the calling agent to derive focused next investigations from the final output and underlying evidence pack
Do not present a run as successful if alerts contains an error such as empty_output, dataset_zero_rows, or credit_exhausted. For credit_exhausted, use the returned billing_url and user_message_template; do not leave the user with a raw error.
If webhound_wait returns still_running=true, that is normal. Use the
returned runtime estimate to schedule the next check-in when the agent
environment supports timers/reminders/automations, then call webhound_watch
at that time. Use webhound_add_sidecar_notes for source-backed notes found by
the calling agent. Use webhound_send_message(reason="awaiting_input") for
checkpoint replies and webhound_send_message(reason="user_guidance") for
real user intent changes, not for normal elapsed time or source suggestions.
Use webhound_stop only when the user explicitly asks to stop, pause, or
cancel the run.
CLI
webhound-mcp --help
webhound-mcp --version
webhound-mcp --self-test--self-test checks that the package loads and that the launch tool list is present. Use webhound_health from an MCP client to verify live auth and account state.
Local Development
git clone https://github.com/WebhoundAI/webhound-mcp.git
cd webhound-mcp
npm install
WEBHOUND_KEY=wh_... WEBHOUND_API_BASE=http://localhost:5000/api/v2 node bin/server.mjsRun the package self-test without credentials:
npm run self-test
npm test
npm run test:coverage
npm run verify
npm run release:checkThe test suite is fully offline and enforces 91% line, 75% branch, and 88% function coverage across the MCP runtime. npm run verify also rebuilds the published bundle, checks the CLI self-test, verifies canonical-runtime parity, inspects the packed artifact, and installs it into a temporary consumer project.
Before publishing, compare this checkout with the canonical webhound-server/mcp
runtime:
npm run parity:compare -- /absolute/path/to/webhound-server/mcpLicense
MIT
Available Tools
30 toolswebhound_accountWebhound AccountARead-onlyIdempotent
Read credits, recent usage, free-run status, and defaults. Does not spend.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| body | No | |
| code | No | |
| data | No | |
| tool | Yes | |
| error | No | |
| usage | No | |
| status | No | |
| billing | No | |
| blocked | No | |
| credits | No | |
| message | No | |
| summary | Yes | |
| defaults | No | |
| free_run | No | |
| no_spend | No | |
| required | No | |
| retryable | No | |
| top_up_url | No | |
| api_message | No | |
| billing_url | No | |
| next_action | No | |
| next_actions | No | |
| authenticated | No | |
| error_details | No | |
| original_tool | No | |
| action_started | No | |
| schema_version | Yes | |
| current_balance | No | |
| session_started | No | |
| research_harness | No | |
| credit_balance_usd | No | |
| auto_recharge_enabled | No | |
| can_start_default_run | No | |
| user_message_template | No | |
| retry_after_user_confirms | No | |
| can_start_default_paid_run | No | |
| reserved_credit_balance_usd | No | |
| available_credit_balance_usd | No | |
| can_start_any_onboarding_run | No | |
| credit_availability_verified | No | |
| minimum_supported_budget_usd | No | |
| can_start_any_onboarding_paid_run | No | |
| can_start_standard_onboarding_run | No | |
| can_start_standard_onboarding_paid_run | No | |
| billing_configured_for_uninterrupted_runs | No |
TDQS
A4.2/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, but the description adds valuable behavioral context by listing what information is read (credits, recent usage, etc.) and reinforcing safety. No contradictions exist between description and annotations.
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 two sentences long, front-loaded with the action and resources, and every word earns its place. No unnecessary information.
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 tool has zero parameters, comprehensive annotations, and an output schema, the description is mostly complete. It could be slightly vague about 'recent usage' (time period not defined), but overall it sufficiently describes the tool's purpose.
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?
There are no parameters, and schema description coverage is 100% trivially. The description does not need to add parameter info, and it correctly implies no input is needed. Baseline of 4 is appropriate.
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 uses the specific verb 'Read' and lists the exact resources (credits, recent usage, free-run status, defaults). It clearly distinguishes from sibling tools by stating 'Does not spend', making it clear that this is a read-only account overview tool.
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?
The description implies read-only usage by stating 'Does not spend', but it does not explicitly mention when to use this tool versus siblings like webhound_get_defaults or webhound_get_claims. No alternatives or exclusions are provided, leaving the agent to infer context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
webhound_add_budgetAdd Webhound BudgetC
Add research budget and optional guidance/context to a session.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| amount | Yes | ||
| file_ids | No | ||
| guidance | No | ||
| session_id | Yes | ||
| context_session_ids | No |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| url | No | |
| body | No | |
| code | No | |
| cost | No | |
| data | No | |
| done | No | |
| kind | No | |
| name | No | |
| tool | Yes | |
| error | No | |
| agents | No | |
| alerts | No | |
| amount | No | |
| budget | No | |
| status | No | |
| blocked | No | |
| dataset | No | |
| healthy | No | |
| message | No | |
| product | No | |
| resumed | No | |
| stopped | No | |
| summary | Yes | |
| accepted | No | |
| activity | No | |
| free_run | No | |
| no_spend | No | |
| required | No | |
| documents | No | |
| retryable | No | |
| checked_at | No | |
| is_running | No | |
| message_id | No | |
| new_budget | No | |
| session_id | No | |
| top_up_url | No | |
| api_message | No | |
| billing_url | No | |
| next_action | No | |
| total_spent | No | |
| amount_added | No | |
| credit_limit | No | |
| next_actions | No | |
| output_ready | No | |
| session_type | No | |
| current_spend | No | |
| error_details | No | |
| original_tool | No | |
| action_started | No | |
| budget_control | No | |
| current_budget | No | |
| guidance_added | No | |
| schema_version | Yes | |
| current_balance | No | |
| mcp_next_action | No | |
| previous_budget | No | |
| session_started | No | |
| status_snapshot | No | |
| completion_state | No | |
| research_harness | No | |
| runtime_estimate | No | |
| sidecar_guidance | No | |
| agent_instruction | No | |
| completion_reason | No | |
| followup_check_in | No | |
| assembly_triggered | No | |
| forbidden_next_tools | No | |
| auto_recharge_enabled | No | |
| successful_completion | No | |
| user_message_template | No | |
| retry_after_user_confirms | No |
TDQS
C2.6/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate the tool is not read-only, not idempotent, and not destructive, but the description adds minimal behavioral context. It does not disclose whether multiple calls accumulate budget or override, nor does it mention any prerequisites or side effects.
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 description is a single sentence and front-loads the main action, but it sacrifices clarity for brevity. It could be longer to cover missing parameter semantics while remaining concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters, 0% schema coverage, and a similar sibling tool, the description is insufficient. It fails to explain the meaning of 'add' vs 'set', the role of 'file_ids', or the expected format of 'guidance'. The output schema exists but does not compensate for input ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must explain parameters. It mentions 'amount', 'guidance', and 'context' (implied by 'context'), but omits 'session_id' and 'file_ids'. No details on format, constraints, or relationships between parameters are given.
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 adds a research budget and optional guidance/context to a session. However, it does not differentiate from the sibling 'webhound_set_budget', which could lead to confusion about whether 'add' means increment or initial set.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not specify when to use this tool over alternatives like 'webhound_set_budget' or other session-modifying tools, leaving the agent without context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
webhound_add_sidecar_notesAdd Webhound Sidecar NotesA
Save concrete source-backed notes or hypotheses found by the calling agent while Webhound keeps running. No spend. Does not interrupt the Planner/Executor/Verifier cycle and does not change session status. Do not use for user intent changes.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| notes | Yes | ||
| session_id | Yes |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| body | No | |
| code | No | |
| data | No | |
| note | No | |
| tool | Yes | |
| count | No | |
| error | No | |
| notes | No | |
| saved | No | |
| status | No | |
| blocked | No | |
| message | No | |
| skipped | No | |
| summary | Yes | |
| no_spend | No | |
| required | No | |
| retryable | No | |
| session_id | No | |
| top_up_url | No | |
| api_message | No | |
| billing_url | No | |
| next_action | No | |
| interrupting | No | |
| next_actions | No | |
| error_details | No | |
| original_tool | No | |
| action_started | No | |
| schema_version | Yes | |
| current_balance | No | |
| session_started | No | |
| auto_recharge_enabled | No | |
| user_message_template | No | |
| retry_after_user_confirms | No |
TDQS
A4.2/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false (write) and openWorldHint=true (side effects). The description adds valuable context: 'No spend', 'Does not interrupt the Planner/Executor/Verifier cycle', and 'Does not change session status.' These details go beyond the annotations, though some aspects like storage limits are not mentioned.
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 three sentences, each adding distinct value: purpose, behavioral guarantees, and usage boundaries. It is front-loaded and contains no fluff.
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 a tool that adds notes to a running session, the description covers purpose, behavioral impact, and usage constraints. It does not mention what happens if the session is invalid or whether notes accumulate or overwrite, but the output schema exists to clarify return values. Slightly incomplete but adequate.
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?
The input schema already describes many parameters (summary, hypothesis, source_urls) with explanations. The tool description adds only a general note about 'concrete source-backed notes or hypotheses', which aligns with the schema but provides no additional detail. With schema coverage existing, a score of 3 is appropriate.
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 action 'Save concrete source-backed notes or hypotheses', specifies the context 'while Webhound keeps running', and explicitly distinguishes from other tools by stating 'Do not use for user intent changes.' It leaves no ambiguity about the tool's purpose.
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 tells when to use (save discovered notes/hypotheses) and what not to use for (user intent changes). It also notes that it does not affect the running cycle or session status. However, it does not explicitly contrast with sibling tools like list or update sidecar notes, which would strengthen guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
webhound_diagnoseDiagnose Webhound SessionARead-onlyIdempotent
Explain whether a session is healthy, done, usable, and what to do next. For a healthy running session, the correct next action is to keep waiting; budget use is the point of the run. Do not stop or force finalization because the run is slow.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| session_id | Yes |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| url | No | |
| body | No | |
| code | No | |
| cost | No | |
| data | No | |
| done | No | |
| kind | No | |
| name | No | |
| tool | Yes | |
| error | No | |
| agents | No | |
| alerts | No | |
| budget | No | |
| status | No | |
| blocked | No | |
| dataset | No | |
| healthy | No | |
| message | No | |
| product | No | |
| resumed | No | |
| stopped | No | |
| summary | Yes | |
| accepted | No | |
| activity | No | |
| free_run | No | |
| no_spend | No | |
| required | No | |
| documents | No | |
| retryable | No | |
| checked_at | No | |
| is_running | No | |
| message_id | No | |
| new_budget | No | |
| session_id | No | |
| top_up_url | No | |
| api_message | No | |
| billing_url | No | |
| next_action | No | |
| total_spent | No | |
| amount_added | No | |
| credit_limit | No | |
| next_actions | No | |
| output_ready | No | |
| session_type | No | |
| current_spend | No | |
| error_details | No | |
| original_tool | No | |
| action_started | No | |
| budget_control | No | |
| current_budget | No | |
| guidance_added | No | |
| schema_version | Yes | |
| current_balance | No | |
| mcp_next_action | No | |
| previous_budget | No | |
| session_started | No | |
| status_snapshot | No | |
| completion_state | No | |
| research_harness | No | |
| runtime_estimate | No | |
| sidecar_guidance | No | |
| agent_instruction | No | |
| completion_reason | No | |
| followup_check_in | No | |
| assembly_triggered | No | |
| forbidden_next_tools | No | |
| auto_recharge_enabled | No | |
| successful_completion | No | |
| user_message_template | No | |
| retry_after_user_confirms | No |
TDQS
A4.5/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, establishing a non-destructive, safe profile. The description adds behavioral context about budgeting and waiting, which helps agents understand the intended workflow beyond the annotations.
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 concise with two sentences. The purpose is front-loaded, and every sentence adds value. No unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's diagnostic nature and the existence of an output schema (not detailed but present), the description covers what the tool does, when to use it, and what actions to avoid. It is complete for its intended role.
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?
The only parameter is session_id, which is self-explanatory from its name. However, schema description coverage is 0%, meaning the schema provides no explanatory text. The description does not add any parameter-specific details, but the single parameter's meaning is obvious given the tool's purpose.
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's purpose: 'Explain whether a session is healthy, done, usable, and what to do next.' This is a specific verb ('Explain') and resource (session status), and it distinguishes from siblings like webhound_health and webhound_wait by also providing next-action guidance.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: it explains when to use the tool (to diagnose session state) and what the correct next action is ('keep waiting; budget use is the point'). It also warns against stopping or forcing finalization, preventing common misuse.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
webhound_export_sessionExport Webhound SessionARead-onlyIdempotent
Export a completed report or dataset as Markdown, HTML, TXT, JSON traces, CSV, JSONL, or PDF. Does not spend credits. Wait for done=true before exporting unless the user explicitly asks for a partial artifact.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| format | No | auto | |
| select | No | output | |
| doc_name | No | ||
| session_id | Yes | ||
| allow_partial | No | Set true only if the user explicitly asks for an interim/partial export before done=true. | |
| include_content | No | ||
| include_binary_base64 | No | Binary exports default to a download URL because base64 is not useful agent context. Set true only when raw binary bytes are required in the MCP response. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| url | No | |
| body | No | |
| code | No | |
| cost | No | |
| data | No | |
| done | No | |
| kind | No | |
| name | No | |
| tool | Yes | |
| error | No | |
| agents | No | |
| alerts | No | |
| budget | No | |
| format | No | |
| status | No | |
| blocked | No | |
| content | No | |
| dataset | No | |
| healthy | No | |
| message | No | |
| omitted | No | |
| product | No | |
| resumed | No | |
| stopped | No | |
| summary | Yes | |
| accepted | No | |
| activity | No | |
| delivery | No | |
| encoding | No | |
| filename | No | |
| free_run | No | |
| no_spend | No | |
| required | No | |
| documents | No | |
| mime_type | No | |
| retryable | No | |
| row_count | No | |
| checked_at | No | |
| is_running | No | |
| message_id | No | |
| new_budget | No | |
| session_id | No | |
| size_bytes | No | |
| top_up_url | No | |
| api_message | No | |
| billing_url | No | |
| next_action | No | |
| total_spent | No | |
| amount_added | No | |
| credit_limit | No | |
| download_url | No | |
| next_actions | No | |
| output_ready | No | |
| session_type | No | |
| current_spend | No | |
| download_note | No | |
| error_details | No | |
| original_tool | No | |
| action_started | No | |
| budget_control | No | |
| content_base64 | No | |
| current_budget | No | |
| document_count | No | |
| guidance_added | No | |
| schema_version | Yes | |
| complete_export | No | |
| current_balance | No | |
| mcp_next_action | No | |
| previous_budget | No | |
| session_started | No | |
| status_snapshot | No | |
| completion_state | No | |
| research_harness | No | |
| runtime_estimate | No | |
| sidecar_guidance | No | |
| agent_instruction | No | |
| completion_reason | No | |
| content_truncated | No | |
| followup_check_in | No | |
| supported_formats | No | |
| assembly_triggered | No | |
| binary_download_url | No | |
| forbidden_next_tools | No | |
| auto_recharge_enabled | No | |
| successful_completion | No | |
| user_message_template | No | |
| evidence_pack_instruction | No | |
| next_research_instruction | No | |
| retry_after_user_confirms | No | |
| export_deferred_until_done | No |
TDQS
A4/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds that credits are not consumed and that waiting for done=true is required. No contradictions with annotations.
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 sentences, no filler. First sentence delivers the core action and outputs. Second sentence adds crucial behavioral guidance. Every word serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 parameters, low schema coverage, and many siblings, the description covers the main action and a key constraint. However, it lacks details on parameter options and does not differentiate from similar export/retrieve siblings beyond listing formats.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is low (29%). Description does not explain most parameters (format, select, doc_name, include_content, include_binary_base64) beyond implicit mentions. Only hints at allow_partial via the 'wait for done' rule.
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 verb 'export' and specifies the resource as a completed report or dataset. It lists exact output formats (Markdown, HTML, TXT, JSON traces, CSV, JSONL, PDF), which distinguishes it from sibling tools like webhound_get_output or webhound_get_evidence_pack.
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?
Provides explicit conditions: wait for done=true unless user requests partial. Also states 'Does not spend credits,' giving cost context. However, no direct comparison with alternative sibling tools for similar tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
webhound_get_claimsGet Webhound ClaimsBRead-onlyIdempotent
Read normalized claim traces and provenance for a session.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| session_id | Yes |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| body | No | |
| code | No | |
| data | No | |
| tool | Yes | |
| count | No | |
| error | No | |
| total | No | |
| claims | No | |
| status | No | |
| blocked | No | |
| message | No | |
| sources | No | |
| summary | Yes | |
| no_spend | No | |
| required | No | |
| retryable | No | |
| claim_type | No | |
| session_id | No | |
| top_up_url | No | |
| api_message | No | |
| billing_url | No | |
| claim_count | No | |
| next_action | No | |
| next_actions | No | |
| error_details | No | |
| original_tool | No | |
| action_started | No | |
| schema_version | Yes | |
| current_balance | No | |
| session_started | No | |
| provenance_level | No | |
| auto_recharge_enabled | No | |
| user_message_template | No | |
| retry_after_user_confirms | No |
TDQS
B3.4/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. Description adds the type of data ('normalized claim traces and provenance') but no additional behavioral details like auth requirements or response format.
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?
Single sentence with no redundancy. All words earn their place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Output schema exists, so return values are covered. However, 'normalized claim traces' is domain-specific and may be unclear to new users. Lacks explanation of what makes a claim 'normalized'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage at 0% means description must compensate. It implies session_id is the session, but does not define what a valid session_id is or provide format constraints. Minimal added value over schema.
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?
Description clearly states verb 'Read', resource 'normalized claim traces and provenance', and scope 'for a session'. Distinguishes from siblings like webhound_get_session which reads session details, not claims.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., webhound_get_session, webhound_get_sources). No prerequisites or context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
webhound_get_defaultsGet Webhound MCP DefaultsARead-onlyIdempotent
Read the saved MCP defaults for budget, product, and free-run use. The MCP always uses Hound.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| body | No | |
| code | No | |
| data | No | |
| tool | Yes | |
| error | No | |
| source | No | |
| status | No | |
| blocked | No | |
| message | No | |
| summary | Yes | |
| no_spend | No | |
| required | No | |
| retryable | No | |
| top_up_url | No | |
| updated_at | No | |
| agent_rules | No | |
| api_message | No | |
| billing_url | No | |
| next_action | No | |
| next_actions | No | |
| error_details | No | |
| original_tool | No | |
| action_started | No | |
| schema_version | Yes | |
| current_balance | No | |
| default_product | No | |
| session_started | No | |
| research_harness | No | |
| default_budget_usd | No | |
| auto_recharge_enabled | No | |
| user_message_template | No | |
| retry_after_user_confirms | No | |
| use_free_run_when_available | No |
TDQS
A4.5/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint true, destructiveHint false, idempotentHint true. The description adds context that 'The MCP always uses Hound.' This extra behavioral note is useful but does not contradict annotations.
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 two sentences, front-loaded with the main action, and every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and an output schema exists (handling return values), the description provides sufficient context for a read-only getter.
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?
There are no parameters, and schema coverage is 100% (empty). The description does not need to add parameter information, meeting the baseline of 4 for zero-parameter tools.
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 reads saved MCP defaults for budget, product, and free-run use. It uses a specific verb ('Read') and resource ('MCP defaults'), and implicitly distinguishes from its sibling 'webhound_set_defaults'.
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 implies use when defaults need to be retrieved, and it's a read-only operation. However, it does not explicitly state when to use vs. alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
webhound_get_evidence_packGet Webhound Evidence PackARead-onlyIdempotent
Read the full evidence payload for a completed Webhound session: final output, working docs, claim traces, sources, and export links. Use this before serious follow-up answers so Webhound value is not reduced to only the polished output document.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| kind | No | auto | |
| session_id | Yes | ||
| allow_partial | No | Set true only if the user explicitly asks for an interim evidence snapshot before done=true. | |
| include_claims | No | ||
| include_sources | No | ||
| include_working_docs | No |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| url | No | |
| body | No | |
| code | No | |
| cost | No | |
| data | No | |
| done | No | |
| kind | No | |
| name | No | |
| tool | Yes | |
| error | No | |
| tasks | No | |
| usage | No | |
| agents | No | |
| alerts | No | |
| budget | No | |
| claims | No | |
| output | No | |
| status | No | |
| blocked | No | |
| dataset | No | |
| exports | No | |
| healthy | No | |
| message | No | |
| notepad | No | |
| omitted | No | |
| product | No | |
| resumed | No | |
| session | No | |
| sources | No | |
| stopped | No | |
| summary | Yes | |
| accepted | No | |
| activity | No | |
| artifact | No | |
| evidence | No | |
| free_run | No | |
| messages | No | |
| metadata | No | |
| no_spend | No | |
| required | No | |
| artifacts | No | |
| documents | No | |
| retryable | No | |
| truncated | No | |
| checked_at | No | |
| is_running | No | |
| message_id | No | |
| new_budget | No | |
| session_id | No | |
| top_up_url | No | |
| actual_kind | No | |
| api_message | No | |
| billing_url | No | |
| diagnostics | No | |
| next_action | No | |
| total_spent | No | |
| amount_added | No | |
| content_hash | No | |
| credit_limit | No | |
| generated_at | No | |
| next_actions | No | |
| output_ready | No | |
| session_type | No | |
| working_docs | No | |
| current_spend | No | |
| error_details | No | |
| original_tool | No | |
| sidecar_notes | No | |
| action_started | No | |
| budget_control | No | |
| current_budget | No | |
| guidance_added | No | |
| requested_kind | No | |
| research_state | No | |
| schema_version | Yes | |
| current_balance | No | |
| mcp_next_action | No | |
| phase_summaries | No | |
| previous_budget | No | |
| research_agents | No | |
| session_started | No | |
| status_snapshot | No | |
| complete_session | No | |
| completion_state | No | |
| content_markdown | No | |
| research_harness | No | |
| runtime_estimate | No | |
| session_revision | No | |
| sidecar_guidance | No | |
| agent_instruction | No | |
| completion_reason | No | |
| followup_check_in | No | |
| assembly_triggered | No | |
| excluded_by_request | No | |
| forbidden_next_tools | No | |
| auto_recharge_enabled | No | |
| successful_completion | No | |
| user_message_template | No | |
| complete_evidence_pack | No | |
| evidence_pack_instruction | No | |
| next_research_instruction | No | |
| retry_after_user_confirms | No | |
| evidence_pack_deferred_until_done | No |
TDQS
A3.8/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool as read-only and idempotent. The description adds context about the content of the evidence pack but does not disclose additional behavioral traits like authorization needs, rate limits, or behavior for incomplete sessions. It does not contradict annotations.
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 only two sentences, both purposeful. The first sentence defines the action and deliverables, the second provides usage advice. No redundant or extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description need not detail return values. However, with 6 parameters and low schema coverage, the description lacks parameter guidance, and it does not specify prerequisites (e.g., session must be completed). It is adequate but not fully comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is low (17% - only allow_partial has a description). The tool description does not explain any parameters or their defaults, leaving the agent to rely on parameter names which are reasonably self-explanatory but lack formal guidance.
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 reads the full evidence payload for a completed Webhound session, listing specific components (final output, working docs, claim traces, sources, export links). This distinguishes it from siblings like webhound_get_output and webhound_get_claims.
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 advises using this tool before serious follow-up answers to preserve Webhound value, implying a when-to-use scenario. It does not explicitly mention when not to use it or list alternatives, but the guidance is clear and contextual.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
webhound_get_outputGet Webhound OutputBRead-onlyIdempotent
Read final report/working document or dataset rows. By default this is for terminal sessions only; do not read or summarize partial working notes while a healthy run is still running.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| kind | No | auto | |
| select | No | output | |
| doc_name | No | ||
| session_id | Yes | ||
| allow_partial | No | Set true only if the user explicitly asks for an interim/partial update before done=true. Partial output is not final and is not a reason to stop or finalize the run. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| url | No | |
| body | No | |
| code | No | |
| cost | No | |
| data | No | |
| done | No | |
| kind | No | |
| name | No | |
| page | No | |
| rows | No | |
| tool | Yes | |
| error | No | |
| agents | No | |
| alerts | No | |
| budget | No | |
| schema | No | |
| status | No | |
| blocked | No | |
| dataset | No | |
| healthy | No | |
| message | No | |
| omitted | No | |
| product | No | |
| resumed | No | |
| showing | No | |
| sources | No | |
| stopped | No | |
| summary | Yes | |
| accepted | No | |
| activity | No | |
| artifact | No | |
| doc_name | No | |
| doc_type | No | |
| free_run | No | |
| no_spend | No | |
| required | No | |
| documents | No | |
| is_output | No | |
| page_size | No | |
| retryable | No | |
| truncated | No | |
| checked_at | No | |
| is_running | No | |
| message_id | No | |
| new_budget | No | |
| session_id | No | |
| top_up_url | No | |
| total_rows | No | |
| actual_kind | No | |
| api_message | No | |
| billing_url | No | |
| document_id | No | |
| next_action | No | |
| total_lines | No | |
| total_spent | No | |
| amount_added | No | |
| credit_limit | No | |
| next_actions | No | |
| output_ready | No | |
| session_type | No | |
| current_spend | No | |
| error_details | No | |
| original_tool | No | |
| selection_key | No | |
| action_started | No | |
| budget_control | No | |
| current_budget | No | |
| document_state | No | |
| guidance_added | No | |
| requested_kind | No | |
| schema_version | Yes | |
| complete_output | No | |
| current_balance | No | |
| mcp_next_action | No | |
| previous_budget | No | |
| session_started | No | |
| status_snapshot | No | |
| completion_state | No | |
| content_markdown | No | |
| research_harness | No | |
| runtime_estimate | No | |
| sidecar_guidance | No | |
| agent_instruction | No | |
| completion_reason | No | |
| followup_check_in | No | |
| assembly_triggered | No | |
| available_documents | No | |
| forbidden_next_tools | No | |
| auto_recharge_enabled | No | |
| successful_completion | No | |
| user_message_template | No | |
| evidence_pack_instruction | No | |
| next_research_instruction | No | |
| retry_after_user_confirms | No | |
| output_deferred_until_done | No |
TDQS
B3.4/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond the annotations (readOnlyHint=true, idempotentHint=true) by warning against reading partial working notes during an active run, which is a key behavioral constraint. It does not contradict any annotations. While it lacks details on rate limits or authentication, the annotation set already covers the safety profile, and the warning adds valuable context.
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 two sentences long, front-loaded with the purpose, and includes only essential information. Every sentence serves a clear function: stating the tool's action and providing a critical usage constraint. No unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having 5 parameters and a low schema coverage (20%), the description is minimal and does not explain multiple parameter options or their interplay. It lacks details about the 'kind' and 'select' enums, and while an output schema exists, the description does not hint at what the output contains. The warning about partial runs is useful, but overall the description is incomplete for this tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 5 parameters with only 20% description coverage (only allow_partial has a description). The description does not explain the meaning of 'kind' (auto/report/dataset) or 'select' (output/working/latest) parameters, nor does it clarify the role of doc_name. Given the low schema coverage, the description should compensate, but it does not, leaving the agent to guess parameter semantics.
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 reads final reports, working documents, or dataset rows. It distinguishes itself from sibling tools by specifying 'terminal sessions only' and by focusing on reading output rather than other operations. However, the phrase 'terminal sessions' could be more explicit, and it doesn't fully differentiate from other read tools like get_session or get_evidence_pack.
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?
The description provides a clear when-not-to-use: do not read partial working notes while a healthy run is running. However, it does not explicitly mention when to use this tool over alternative sibling tools, such as webhound_get_session or webhound_get_evidence_pack. The guidance is present but incomplete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
webhound_get_sessionGet Webhound SessionARead-onlyIdempotent
Read the complete canonical session in one uncapped response: prompts, messages, phases, tasks, agents, final and working documents, dataset rows, claims, sources, notes, diagnostics, usage history, and artifact links. Nothing is paginated, truncated, or omitted.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| session_id | Yes |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| url | No | |
| body | No | |
| code | No | |
| cost | No | |
| data | No | |
| done | No | |
| kind | No | |
| name | No | |
| tool | Yes | |
| error | No | |
| notes | No | |
| tasks | No | |
| usage | No | |
| agents | No | |
| alerts | No | |
| budget | No | |
| status | No | |
| blocked | No | |
| dataset | No | |
| healthy | No | |
| message | No | |
| notepad | No | |
| omitted | No | |
| product | No | |
| resumed | No | |
| session | No | |
| stopped | No | |
| summary | Yes | |
| accepted | No | |
| activity | No | |
| evidence | No | |
| free_run | No | |
| messages | No | |
| metadata | No | |
| no_spend | No | |
| required | No | |
| artifacts | No | |
| documents | No | |
| retryable | No | |
| truncated | No | |
| checked_at | No | |
| is_running | No | |
| message_id | No | |
| new_budget | No | |
| session_id | No | |
| top_up_url | No | |
| api_message | No | |
| billing_url | No | |
| diagnostics | No | |
| next_action | No | |
| total_spent | No | |
| amount_added | No | |
| content_hash | No | |
| credit_limit | No | |
| generated_at | No | |
| next_actions | No | |
| output_ready | No | |
| session_type | No | |
| current_spend | No | |
| error_details | No | |
| original_tool | No | |
| sidecar_notes | No | |
| action_started | No | |
| artifact_links | No | |
| budget_control | No | |
| current_budget | No | |
| guidance_added | No | |
| research_state | No | |
| schema_version | Yes | |
| current_balance | No | |
| mcp_next_action | No | |
| phase_summaries | No | |
| previous_budget | No | |
| research_agents | No | |
| session_started | No | |
| status_snapshot | No | |
| complete_session | No | |
| completion_state | No | |
| content_markdown | No | |
| research_harness | No | |
| runtime_estimate | No | |
| session_revision | No | |
| sidecar_guidance | No | |
| agent_instruction | No | |
| completion_reason | No | |
| followup_check_in | No | |
| assembly_triggered | No | |
| forbidden_next_tools | No | |
| auto_recharge_enabled | No | |
| successful_completion | No | |
| user_message_template | No | |
| retry_after_user_confirms | No |
TDQS
A4/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, so the bar is lower. The description adds valuable context: 'uncapped response', 'nothing is paginated, truncated, or omitted', which discloses behavior beyond schema. No contradiction with annotations.
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?
The description is a single sentence that efficiently lists all components of the session. It is front-loaded with the core action and resource. Slightly dense with commas, but no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only, simple-parameter tool with an output schema, the description covers all necessary context: what the tool does, what it returns, and key behavioral traits (no pagination). No gaps identified.
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 0%, but the single parameter 'session_id' is self-explanatory. The description implies its purpose by mentioning session, but does not add explicit detail about the parameter's format or constraints. Baseline 3 is appropriate.
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 verb 'Read' and the resource 'complete canonical session', listing all included data types. It distinguishes from siblings like webhound_get_output or webhound_get_claims by emphasizing the comprehensive, uncapped nature.
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?
The description implies use when needing the full session, but does not explicitly state when not to use or mention alternatives. Sibling tools exist for partial data, but no comparative guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
webhound_get_sourcesGet Webhound SourcesARead-onlyIdempotent
Read source inventory and citation counts for a session.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| session_id | Yes |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| body | No | |
| code | No | |
| data | No | |
| tool | Yes | |
| count | No | |
| error | No | |
| total | No | |
| claims | No | |
| status | No | |
| blocked | No | |
| message | No | |
| sources | No | |
| summary | Yes | |
| no_spend | No | |
| required | No | |
| retryable | No | |
| session_id | No | |
| top_up_url | No | |
| api_message | No | |
| billing_url | No | |
| next_action | No | |
| next_actions | No | |
| source_count | No | |
| error_details | No | |
| original_tool | No | |
| action_started | No | |
| schema_version | Yes | |
| current_balance | No | |
| session_started | No | |
| provenance_level | No | |
| auto_recharge_enabled | No | |
| user_message_template | No | |
| retry_after_user_confirms | No |
TDQS
A3.5/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint, so the safety profile is clear. The description adds that it 'reads' sources, consistent with annotations, but offers no additional behavioral details (e.g., behavior with invalid session_id, pagination, or rate limits).
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 a single, well-structured sentence that is appropriately concise and front-loaded, containing no unnecessary words.
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 tool's simplicity (one required parameter) and the presence of an output schema, the description adequately covers the tool's purpose. It could mention the optional nature of the return or the format, but the output schema fills that gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description should compensate but only implies the session_id parameter via 'for a session'. It does not describe the parameter's format, constraints, or acceptable values beyond what the schema provides (required string).
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 action 'Read' and the resource 'source inventory and citation counts' for a specific scope 'for a session'. It distinguishes this tool from siblings like webhound_get_claims or webhound_get_output, which focus on different resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. No mention of prerequisites, when not to use, or how it complements sibling tools like webhound_get_evidence_pack or webhound_get_claims.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
webhound_healthWebhound HealthARead-onlyIdempotent
No-spend health check: auth, API status, credits, free-run pass, defaults, and MCP version.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| mcp | No | |
| body | No | |
| code | No | |
| data | No | |
| tool | Yes | |
| error | No | |
| errors | No | |
| health | No | |
| status | No | |
| account | No | |
| blocked | No | |
| credits | No | |
| message | No | |
| summary | Yes | |
| defaults | No | |
| free_run | No | |
| no_spend | No | |
| required | No | |
| services | No | |
| mcp_ready | No | |
| retryable | No | |
| top_up_url | No | |
| api_message | No | |
| billing_url | No | |
| next_action | No | |
| next_actions | No | |
| api_reachable | No | |
| authenticated | No | |
| error_details | No | |
| original_tool | No | |
| action_started | No | |
| schema_version | Yes | |
| current_balance | No | |
| session_started | No | |
| auto_recharge_enabled | No | |
| user_message_template | No | |
| retry_after_user_confirms | No |
TDQS
A4/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, establishing safety. The description adds value by detailing exactly what aspects are checked (auth, API, credits, etc.) and labeling it as 'no-spend,' which implies no cost. This contextualizes the tool's behavior beyond the annotations.
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 a single, well-structured sentence that conveys the tool's purpose efficiently. Every word has a purpose, and there is no redundancy or unnecessary detail.
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 zero parameters and the presence of an output schema (not shown), the description covers the necessary context for a simple health check. The term 'free-run pass' is slightly ambiguous but overall the description is complete for the tool's simplicity.
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?
With zero parameters and 100% schema coverage, the description adds no parameter-level detail, but baseline for no parameters is 4. The description does not need to compensate further.
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 specifies exactly what the tool does: a no-spend health check covering auth, API status, credits, free-run pass, defaults, and MCP version. It clearly identifies the resource (Webhound service) and the action (health check), distinguishing it from siblings like webhound_diagnose which likely provides deeper diagnostics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives such as webhound_diagnose. The term 'no-spend' hints at a lightweight check, but there is no clear statement of when to prefer this over other siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
webhound_helpWebhound HelpARead-onlyIdempotent
No-spend topic-aware guide for explaining Hound, budgets, completion, setup, reports, datasets, sources, billing, troubleshooting, or general Webhound behavior.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| topic | No | ||
| question | No |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| body | No | |
| code | No | |
| data | No | |
| tool | Yes | |
| error | No | |
| topic | No | |
| answer | No | |
| status | No | |
| blocked | No | |
| message | No | |
| summary | Yes | |
| examples | No | |
| no_spend | No | |
| question | No | |
| required | No | |
| retryable | No | |
| top_up_url | No | |
| api_message | No | |
| billing_url | No | |
| next_action | No | |
| next_actions | No | |
| error_details | No | |
| original_tool | No | |
| related_tools | No | |
| action_started | No | |
| related_topics | No | |
| schema_version | Yes | |
| common_mistakes | No | |
| current_balance | No | |
| requested_topic | No | |
| session_started | No | |
| agent_behavior_rules | No | |
| auto_recharge_enabled | No | |
| user_message_template | No | |
| retry_after_user_confirms | No | |
| suggested_user_facing_wording | No |
TDQS
A3.6/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, indicating safe read-only behavior. The description adds the useful context 'No-spend' (no budget cost), going beyond annotations. However, it does not disclose other traits like response format or rate limits.
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 a single concise sentence that front-loads the key properties ('No-spend topic-aware guide') and covers the tool's purpose without wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, the description provides adequate context for a help tool. The existence of an output schema reduces the need to explain return values. However, it could elaborate on the expected use of the 'question' parameter or limitations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description does not elaborate on the parameters beyond listing topics in the enum. While the enum values are somewhat self-explanatory, the description adds no additional meaning for the 'question' parameter, missing an opportunity to explain its purpose or required format.
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 this is a 'topic-aware guide' for explaining Webhound concepts, with a specific verb ('explaining') and resource ('Webhound behavior'). It distinguishes from sibling tools like webhound_add_budget or webhound_watch, which are action-oriented, by being a help/FAQ tool.
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?
The description implies usage for help and guidance by listing covered topics, but it does not explicitly state when to use this tool versus alternatives. It lacks exclusions or context about when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
webhound_list_sessionsList Webhound SessionsCRead-onlyIdempotent
List recent Webhound sessions.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | ||
| type | No | all | |
| limit | No | ||
| status | No | all |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| body | No | |
| code | No | |
| data | No | |
| page | No | |
| tool | Yes | |
| count | No | |
| error | No | |
| limit | No | |
| total | No | |
| status | No | |
| blocked | No | |
| message | No | |
| summary | Yes | |
| has_more | No | |
| no_spend | No | |
| required | No | |
| sessions | No | |
| page_size | No | |
| retryable | No | |
| top_up_url | No | |
| api_message | No | |
| billing_url | No | |
| next_action | No | |
| total_count | No | |
| total_pages | No | |
| next_actions | No | |
| error_details | No | |
| original_tool | No | |
| action_started | No | |
| schema_version | Yes | |
| current_balance | No | |
| session_started | No | |
| auto_recharge_enabled | No | |
| user_message_template | No | |
| retry_after_user_confirms | No |
TDQS
C2.9/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (readOnlyHint, destructiveHint, idempotentHint) already indicate this is a safe, read-only operation. The description adds 'recent' but does not clarify ordering or pagination behavior. Since annotations cover the safety profile, the description provides marginal additional value, warranting a 3.
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?
The description is a single, concise sentence with no wasted words. However, it could be slightly expanded to include parameter hints without becoming verbose. Nonetheless, it is efficiently written.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema and multiple optional parameters, the description is too sparse. It does not explain what 'recent' means, default ordering, or how to filter sessions. The tool's complexity demands more context for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description does not explain any of the four parameters (page, type, limit, status). With enums for type and status, the description should clarify their meaning to help the AI agent use them correctly. The lack of parameter information is a critical deficiency.
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 verb 'List' and resource 'Webhound sessions'. However, it does not differentiate from sibling tools like webhound_search_sessions or webhound_get_session, which could cause confusion about which tool to use for listing vs searching or retrieving a single session.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives, no 'when not' or prerequisites mentioned. Given the many sibling tools for specific actions (search, get, export, etc.), the lack of usage context is a significant gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
webhound_list_sidecar_notesList Webhound Sidecar NotesARead-onlyIdempotent
Read shared sidecar notes for a session. No spend. Use this to see what the calling agent has already shared with Webhound before adding, correcting, or dismissing notes.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| status | No | all | |
| session_id | Yes |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| body | No | |
| code | No | |
| data | No | |
| tool | Yes | |
| count | No | |
| error | No | |
| notes | No | |
| status | No | |
| blocked | No | |
| message | No | |
| summary | Yes | |
| no_spend | No | |
| required | No | |
| retryable | No | |
| session_id | No | |
| top_up_url | No | |
| api_message | No | |
| billing_url | No | |
| next_action | No | |
| interrupting | No | |
| next_actions | No | |
| error_details | No | |
| original_tool | No | |
| action_started | No | |
| schema_version | Yes | |
| current_balance | No | |
| session_started | No | |
| auto_recharge_enabled | No | |
| user_message_template | No | |
| retry_after_user_confirms | No |
TDQS
A3.7/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate `readOnlyHint=true` and `destructiveHint=false`, so the description's addition of 'No spend' provides a cost behavioral trait beyond what annotations cover. This adds value without contradicting the annotations.
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 only two sentences (16 words), front-loaded with the purpose, and contains no unnecessary information. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although an output schema exists (so return values are covered there) and annotations are present, the description lacks parameter documentation for the 3 parameters. For a tool with filters (`status` enum, `limit`), this omission makes the description incomplete for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 3 parameters with 0% description coverage, meaning the description provides no explanation for `session_id`, `limit`, or `status`. Given low coverage, the description must compensate but fails to do so, leaving the agent without guidance on parameter usage.
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 'Read shared sidecar notes for a session' with a specific verb and resource. It distinguishes from sibling tools like `webhound_add_sidecar_notes` and `webhound_update_sidecar_note` by using 'read' and implying it's a listing operation.
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 provides an explicit usage scenario: 'Use this to see what the calling agent has already shared with Webhound before adding, correcting, or dismissing notes.' This tells the agent when to invoke the tool, though it doesn't explicitly mention when not to use it or name alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
webhound_onboardingWebhound OnboardingARead-onlyIdempotent
No-spend, client-aware guided onboarding. Local agents receive the full setup-first versus jump-in flow; hosted clients receive a research-first flow with no filesystem setup unless the user explicitly requests approval-gated workspace-rule guidance. Budget maps to about 15 minutes per $1: $5 is about 75 minutes and $20 is about 300 minutes (5 hours). The $2/$5/$10/$20 tiers are starting points, not caps.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| client | No | Identify the calling agent when known. Omitted or generic callers receive the research-first, filesystem-safe flow. | generic |
| capabilities | No | ||
| workspace_rules_requested | No | Set true only when the user explicitly asks for workspace-rule guidance as a separate action. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| body | No | |
| code | No | |
| data | No | |
| step | No | |
| tool | Yes | |
| error | No | |
| client | No | |
| status | No | |
| billing | No | |
| blocked | No | |
| choices | No | |
| flow_id | No | |
| message | No | |
| summary | Yes | |
| free_run | No | |
| no_spend | No | |
| required | No | |
| retryable | No | |
| setup_flow | No | |
| top_up_url | No | |
| api_message | No | |
| billing_url | No | |
| client_mode | No | |
| next_action | No | |
| budget_model | No | |
| flow_version | No | |
| next_actions | No | |
| account_state | No | |
| error_details | No | |
| flow_sequence | No | |
| hosted_safety | No | |
| original_tool | No | |
| action_started | No | |
| agent_playbook | No | |
| budget_summary | No | |
| schema_version | Yes | |
| current_balance | No | |
| session_started | No | |
| workspace_rules | No | |
| onboarding_version | No | |
| recommended_defaults | No | |
| setup_timing_choices | No | |
| user_facing_guidance | No | |
| auto_recharge_enabled | No | |
| suggested_agent_rules | No | |
| topic_change_behavior | No | |
| user_message_template | No | |
| first_artifact_choices | No | |
| immediate_next_message | No | |
| retry_after_user_confirms | No |
TDQS
A4.4/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds behavioral context: it's 'No-spend', guided, and client-aware with specific flow differences. It aligns with annotations and adds value beyond them.
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 concise with 4 sentences, front-loaded with the core purpose, and each sentence adds meaningful information without 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?
Given the tool's complexity (nested objects, output schema), the description covers the main behavioral aspects—client-aware flows and budget mapping. The output schema handles return values, so no further detail is needed. Minor gap: does not explain the capabilities parameter's role.
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 67% with descriptions for client and workspace_rules_requested. The description adds meaning by explaining the flow differences for 'hosted' vs 'local' clients and how workspace_rules_requested is only honored when user explicitly asks. The capabilities parameter is not described, but the description partially compensates.
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 that the tool provides 'No-spend, client-aware guided onboarding' and distinguishes between local and hosted clients, specifying different flows. This uniquely identifies the tool's purpose among sibling tools like webhound_help or webhound_account.
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 explains when to use the tool (onboarding new agents) and provides context for different client types (local vs hosted) and budget mapping. It does not explicitly mention when not to use or provide direct alternatives, but the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
webhound_resumeResume Webhound SessionA
Resume a paused/completed/awaiting-input session with optional additional budget and guidance.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| file_ids | No | ||
| guidance | No | ||
| session_id | Yes | ||
| additional_budget | No | ||
| context_session_ids | No |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| url | No | |
| body | No | |
| code | No | |
| cost | No | |
| data | No | |
| done | No | |
| kind | No | |
| name | No | |
| tool | Yes | |
| error | No | |
| agents | No | |
| alerts | No | |
| budget | No | |
| status | No | |
| blocked | No | |
| dataset | No | |
| healthy | No | |
| message | No | |
| product | No | |
| resumed | No | |
| stopped | No | |
| summary | Yes | |
| accepted | No | |
| activity | No | |
| free_run | No | |
| no_spend | No | |
| required | No | |
| documents | No | |
| retryable | No | |
| checked_at | No | |
| is_running | No | |
| message_id | No | |
| new_budget | No | |
| session_id | No | |
| top_up_url | No | |
| api_message | No | |
| billing_url | No | |
| next_action | No | |
| total_spent | No | |
| amount_added | No | |
| credit_limit | No | |
| next_actions | No | |
| output_ready | No | |
| session_type | No | |
| current_spend | No | |
| error_details | No | |
| original_tool | No | |
| action_started | No | |
| budget_control | No | |
| current_budget | No | |
| guidance_added | No | |
| schema_version | Yes | |
| current_balance | No | |
| mcp_next_action | No | |
| previous_budget | No | |
| session_started | No | |
| status_snapshot | No | |
| completion_state | No | |
| research_harness | No | |
| runtime_estimate | No | |
| sidecar_guidance | No | |
| additional_budget | No | |
| agent_instruction | No | |
| completion_reason | No | |
| followup_check_in | No | |
| assembly_triggered | No | |
| forbidden_next_tools | No | |
| auto_recharge_enabled | No | |
| successful_completion | No | |
| user_message_template | No | |
| retry_after_user_confirms | No |
TDQS
A3.8/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds context beyond annotations by specifying the allowable session states for resumption and optional parameters. Annotations already indicate the tool is not read-only or destructive, and the description clarifies the mutation is a resume operation. No contradictions.
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 a single sentence that efficiently conveys the tool's core purpose and optional features without extraneous words.
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 presence of an output schema and annotations, the description adequately covers when to use the tool and its basic behavior. It could mention error handling (e.g., if session not found) but is largely complete for the complexity level.
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?
With 0% schema coverage, the description partially compensates by explaining 'additional budget' and 'guidance' parameters. However, it omits 'file_ids' and 'context_session_ids', leaving their purpose unclear. schema coverage is high.
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 verb 'Resume' and the resource 'Webhound Session', specifying the session states that can be resumed (paused/completed/awaiting-input). However, it does not explicitly distinguish this tool from siblings like 'webhound_start_report' or 'webhound_wait'.
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?
The description mentions optional additional budget and guidance, hinting at when to use these parameters. However, it provides no guidance on when not to use this tool (e.g., if session is still active) or alternatives like 'webhound_wait' for running sessions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
webhound_search_sessionsSearch Webhound SessionsBRead-onlyIdempotent
Semantic search across prior Webhound sessions.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| body | No | |
| code | No | |
| data | No | |
| tool | Yes | |
| count | No | |
| error | No | |
| query | No | |
| total | No | |
| status | No | |
| blocked | No | |
| message | No | |
| results | No | |
| summary | Yes | |
| no_spend | No | |
| required | No | |
| sessions | No | |
| retryable | No | |
| top_up_url | No | |
| api_message | No | |
| billing_url | No | |
| next_action | No | |
| next_actions | No | |
| error_details | No | |
| original_tool | No | |
| action_started | No | |
| schema_version | Yes | |
| current_balance | No | |
| session_started | No | |
| auto_recharge_enabled | No | |
| user_message_template | No | |
| retry_after_user_confirms | No | |
| active_exact_matches_added | No |
TDQS
B3.1/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and destructiveHint=false, establishing the tool as safe and non-destructive. The description adds the notion of 'semantic search,' which offers some behavioral nuance beyond annotations, but does not elaborate on other traits like response format or pagination. Given the annotations, a score of 3 is appropriate.
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 description is a single sentence, which is concise, but it omits necessary detail about parameters and usage. It is minimal but not well-structured to convey all needed information efficiently. The brevity here actually undermines completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has two parameters (one required) and a vague description, the agent lacks sufficient context to invoke it correctly. The existence of an output schema reduces the need to explain return values, but the parameter semantics are absent. The description is too thin for a tool with this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at 0%, the input schema provides no hints about the meaning of 'query' or 'limit'. The description does not mention either parameter, forcing the agent to guess their semantics. This is a critical gap, as the tool has only two parameters and they are essential for correct invocation.
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 'Semantic search across prior Webhound sessions,' identifying the action ('semantic search') and resource ('prior Webhound sessions'). It distinguishes from sibling tools like 'webhound_list_sessions' (likely a listing) and 'webhound_get_session' (retrieval of one) by specifying a search paradigm.
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?
The description implies usage for searching sessions with a query, but does not explicitly state when to use this over alternatives like 'webhound_list_sessions' or 'webhound_get_session'. No exclusion criteria or context is provided, leaving the agent to infer from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
webhound_send_messageSteer Webhound SessionA
Send user-provided guidance to a session. Use reason="awaiting_input" to answer a checkpoint and resume. Use reason="user_guidance" only for a real user objective/scope/constraint/deliverable change. Use webhound_add_sidecar_notes for source suggestions.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| reason | Yes | user_guidance interrupts/replans for a real user change. awaiting_input replies to a checkpoint and resumes. Do not use for elapsed time, impatience, partial notes, or ordinary source notes. | |
| message | Yes | ||
| session_id | Yes |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| url | No | |
| body | No | |
| code | No | |
| cost | No | |
| data | No | |
| done | No | |
| kind | No | |
| name | No | |
| note | No | |
| tool | Yes | |
| error | No | |
| agents | No | |
| alerts | No | |
| budget | No | |
| queued | No | |
| reason | No | |
| status | No | |
| blocked | No | |
| dataset | No | |
| healthy | No | |
| message | No | |
| product | No | |
| resumed | No | |
| stopped | No | |
| summary | Yes | |
| accepted | No | |
| activity | No | |
| free_run | No | |
| no_spend | No | |
| required | No | |
| documents | No | |
| retryable | No | |
| checked_at | No | |
| created_at | No | |
| is_running | No | |
| message_id | No | |
| new_budget | No | |
| session_id | No | |
| top_up_url | No | |
| api_message | No | |
| billing_url | No | |
| next_action | No | |
| total_spent | No | |
| amount_added | No | |
| credit_limit | No | |
| interrupting | No | |
| next_actions | No | |
| output_ready | No | |
| session_type | No | |
| current_spend | No | |
| error_details | No | |
| original_tool | No | |
| action_started | No | |
| budget_control | No | |
| current_budget | No | |
| guidance_added | No | |
| schema_version | Yes | |
| current_balance | No | |
| mcp_next_action | No | |
| previous_budget | No | |
| resumes_session | No | |
| session_started | No | |
| status_snapshot | No | |
| completion_state | No | |
| research_harness | No | |
| runtime_estimate | No | |
| sidecar_guidance | No | |
| agent_instruction | No | |
| completion_reason | No | |
| followup_check_in | No | |
| assembly_triggered | No | |
| forbidden_next_tools | No | |
| auto_recharge_enabled | No | |
| successful_completion | No | |
| user_message_template | No | |
| retry_after_user_confirms | No |
TDQS
A4.4/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explains behavioral aspects like answering checkpoints and interrupting/replanning, which goes beyond the annotations. However, it could mention whether sending a message triggers any asynchronous actions or requires a follow-up.
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 very concise, consisting of three short sentences that are front-loaded with the core purpose. Every sentence adds value without 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?
Given the tool's complexity (two distinct use cases), the description covers the main scenarios well. It could mention the expected behavior after sending (e.g., whether the session waits for further input), but the presence of an output schema reduces the need to describe return values.
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?
The schema covers 33% of parameters (reason has description). The description adds significant context for the 'reason' parameter by explaining the two enum values, but provides no additional info for 'message' or 'session_id'. This partially compensates for low schema coverage.
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's purpose as sending user-provided guidance to a session. It distinguishes from sibling tool webhound_add_sidecar_notes by specifying that tool is for source suggestions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use each reason value ('awaiting_input' vs 'user_guidance'), and directs users to an alternative tool for source suggestions, clearly indicating when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
webhound_set_budgetLower Webhound Report BudgetADestructive
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.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| session_id | Yes | ||
| target_budget | Yes | New 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_reduction | Yes | Must be true only when the user explicitly asked to lower this report budget or finish at a lower research scope. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| url | No | |
| body | No | |
| code | No | |
| cost | No | |
| data | No | |
| done | No | |
| kind | No | |
| name | No | |
| tool | Yes | |
| error | No | |
| agents | No | |
| alerts | No | |
| budget | No | |
| status | No | |
| blocked | No | |
| dataset | No | |
| healthy | No | |
| message | No | |
| product | No | |
| resumed | No | |
| stopped | No | |
| summary | Yes | |
| accepted | No | |
| activity | No | |
| free_run | No | |
| no_spend | No | |
| required | No | |
| documents | No | |
| retryable | No | |
| checked_at | No | |
| is_running | No | |
| message_id | No | |
| new_budget | No | |
| session_id | No | |
| top_up_url | No | |
| api_message | No | |
| billing_url | No | |
| next_action | No | |
| total_spent | No | |
| amount_added | No | |
| credit_limit | No | |
| next_actions | No | |
| output_ready | No | |
| session_type | No | |
| current_spend | No | |
| error_details | No | |
| original_tool | No | |
| target_budget | No | |
| action_started | No | |
| budget_control | No | |
| current_budget | No | |
| guidance_added | No | |
| schema_version | Yes | |
| current_balance | No | |
| mcp_next_action | No | |
| previous_budget | No | |
| session_started | No | |
| status_snapshot | No | |
| completion_state | No | |
| research_harness | No | |
| runtime_estimate | No | |
| sidecar_guidance | No | |
| agent_instruction | No | |
| completion_reason | No | |
| followup_check_in | No | |
| assembly_triggered | No | |
| completion_contract | No | |
| forbidden_next_tools | No | |
| resumed_for_assembly | No | |
| auto_recharge_enabled | No | |
| minimum_target_budget | No | |
| successful_completion | No | |
| user_message_template | No | |
| requested_target_budget | No | |
| retry_after_user_confirms | No | |
| adjusted_to_cover_current_spend | No |
TDQS
A4.2/5.0
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.
webhound_set_defaultsSet Webhound MCP DefaultsADestructive
Update only the provided default budget/product/free-run fields for future MCP runs; omitted fields keep their saved values. The MCP always uses Hound. Do not use this for private workspace-derived rules; save those locally in the agent workspace.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| default_product | No | ||
| default_budget_usd | No | ||
| use_free_run_when_available | No |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| body | No | |
| code | No | |
| data | No | |
| tool | Yes | |
| error | No | |
| source | No | |
| status | No | |
| blocked | No | |
| message | No | |
| summary | Yes | |
| no_spend | No | |
| required | No | |
| retryable | No | |
| top_up_url | No | |
| updated_at | No | |
| agent_rules | No | |
| api_message | No | |
| billing_url | No | |
| next_action | No | |
| next_actions | No | |
| error_details | No | |
| original_tool | No | |
| action_started | No | |
| schema_version | Yes | |
| current_balance | No | |
| default_product | No | |
| session_started | No | |
| research_harness | No | |
| default_budget_usd | No | |
| auto_recharge_enabled | No | |
| user_message_template | No | |
| retry_after_user_confirms | No | |
| use_free_run_when_available | No |
TDQS
A3.8/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide destructiveHint=true and readOnlyHint=false, but the description adds context: 'The MCP always uses Hound' and 'omitted fields keep their saved values' (partial update). It does not elaborate on what makes this destructive (e.g., overwriting shared defaults) or any side effects, making the added value moderate.
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 sentences, zero waste. First sentence states core functionality and partial-update behavior; second adds a crucial usage constraint. Every sentence is essential and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 3 optional parameters and an output schema (not shown), the description covers main purpose and a key exclusion. However, it omits what happens when no parameters are provided and does not clarify the destructive nature hinted by annotations. It is adequate but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description only mentions the fields ('default budget/product/free-run') without explaining allowed values or constraints. The partial-update behavior is implied but not detailed per parameter. This insufficiently compensates for the missing schema descriptions.
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 states 'Update only the provided default budget/product/free-run fields for future MCP runs; omitted fields keep their saved values.' This clearly identifies the action (update defaults), the resource (future MCP runs), and distinguishes from siblings like webhound_set_budget or webhound_get_defaults by specifying partial updates and the target.
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 says 'Do not use this for private workspace-derived rules; save those locally in the agent workspace,' which gives a clear when-not-to-use condition. However, it does not name alternative tools for setting workspace-derived rules, so it stops short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
webhound_start_datasetStart Webhound DatasetA
Start a private long-running dataset with Hound, Webhound's DeepSeek V4 Pro + GPT-5.4 research harness. Budget controls extraction depth; watch until done=true. Do not force finalization before done=true.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| title | No | ||
| budget | No | ||
| prompt | Yes | ||
| schema | No | Optional explicit schema. Native example: {"entity_name":"Company","attributes":[{"name":"company_name","type":"string","is_primary":true,"description":"Official company name"},{"name":"website","type":"string","standard_format":"url"},{"name":"employee_count","type":"number"}]} JSON Schema example: {"type":"object","title":"Company","required":["company_name"],"properties":{"company_name":{"type":"string","description":"Official company name","x-webhound-primary":true},"website":{"type":"string","format":"uri"},"employee_count":{"type":"integer"}}} | |
| file_ids | No | ||
| enable_checkpoints | No | ||
| context_session_ids | No | ||
| use_free_run_when_available | No |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| url | No | |
| body | No | |
| code | No | |
| cost | No | |
| data | No | |
| done | No | |
| kind | No | |
| name | No | |
| tool | Yes | |
| error | No | |
| agents | No | |
| alerts | No | |
| budget | No | |
| status | No | |
| blocked | No | |
| dataset | No | |
| healthy | No | |
| message | No | |
| product | No | |
| resumed | No | |
| stopped | No | |
| summary | Yes | |
| accepted | No | |
| activity | No | |
| free_run | No | |
| no_spend | No | |
| required | No | |
| documents | No | |
| retryable | No | |
| checked_at | No | |
| is_running | No | |
| message_id | No | |
| new_budget | No | |
| session_id | No | |
| top_up_url | No | |
| api_message | No | |
| billing_url | No | |
| next_action | No | |
| total_spent | No | |
| amount_added | No | |
| credit_limit | No | |
| next_actions | No | |
| output_ready | No | |
| session_type | No | |
| current_spend | No | |
| error_details | No | |
| original_tool | No | |
| schema_source | No | |
| action_started | No | |
| budget_control | No | |
| current_budget | No | |
| guidance_added | No | |
| schema_version | Yes | |
| current_balance | No | |
| mcp_next_action | No | |
| previous_budget | No | |
| schema_warnings | No | |
| session_started | No | |
| status_snapshot | No | |
| completion_state | No | |
| research_harness | No | |
| runtime_estimate | No | |
| sidecar_guidance | No | |
| agent_instruction | No | |
| completion_reason | No | |
| followup_check_in | No | |
| normalized_schema | No | |
| assembly_triggered | No | |
| schema_input_format | No | |
| forbidden_next_tools | No | |
| auto_recharge_enabled | No | |
| successful_completion | No | |
| user_message_template | No | |
| retry_after_user_confirms | No |
TDQS
A3.9/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate openWorldHint=true, but description adds context about the tool being asynchronous and long-running. It warns against premature finalization. No contradictions. However, it does not elaborate on side effects or non-idempotent behavior beyond annotations.
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 extremely concise—two sentences—with the main action first and usage notes second. No extraneous words, effectively front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description does not explain return values or the complex 'schema' parameter. For a tool with 8 parameters and asynchronous behavior, the description is too brief to be complete. An AI agent would lack critical details for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 13%, and the description barely explains any parameters. Only 'budget' is mentioned ('controls extraction depth'). Other critical parameters like 'prompt', 'schema', 'file_ids' etc. are not described, leaving the agent without sufficient guidance.
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 verb 'start' and the resource 'private long-running dataset' with specific technology details (DeepSeek V4 Pro + GPT-5.4 research harness). It distinguishes from sibling tools like webhound_start_report, which is for reports.
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 provides guidance on usage: 'Budget controls extraction depth; watch until done=true. Do not force finalization before done=true.' It implicitly suggests using webhound_watch after starting. However, it does not explicitly state when not to use this tool or compare directly to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
webhound_start_reportStart Webhound ReportA
Start a private long-running report with Hound, Webhound's DeepSeek V4 Pro + GPT-5.4 research harness. Budget controls research depth; watch until done=true. Do not force finalization before done=true.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| title | No | ||
| budget | No | ||
| prompt | Yes | ||
| file_ids | No | ||
| enable_checkpoints | No | ||
| context_session_ids | No | ||
| output_instructions | No | ||
| use_free_run_when_available | No |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| url | No | |
| body | No | |
| code | No | |
| cost | No | |
| data | No | |
| done | No | |
| kind | No | |
| name | No | |
| tool | Yes | |
| error | No | |
| agents | No | |
| alerts | No | |
| budget | No | |
| status | No | |
| blocked | No | |
| dataset | No | |
| healthy | No | |
| message | No | |
| product | No | |
| resumed | No | |
| stopped | No | |
| summary | Yes | |
| accepted | No | |
| activity | No | |
| free_run | No | |
| no_spend | No | |
| required | No | |
| documents | No | |
| retryable | No | |
| checked_at | No | |
| is_running | No | |
| message_id | No | |
| new_budget | No | |
| session_id | No | |
| top_up_url | No | |
| api_message | No | |
| billing_url | No | |
| next_action | No | |
| total_spent | No | |
| amount_added | No | |
| credit_limit | No | |
| next_actions | No | |
| output_ready | No | |
| session_type | No | |
| current_spend | No | |
| error_details | No | |
| original_tool | No | |
| action_started | No | |
| budget_control | No | |
| current_budget | No | |
| guidance_added | No | |
| schema_version | Yes | |
| current_balance | No | |
| mcp_next_action | No | |
| previous_budget | No | |
| session_started | No | |
| status_snapshot | No | |
| completion_state | No | |
| research_harness | No | |
| runtime_estimate | No | |
| sidecar_guidance | No | |
| agent_instruction | No | |
| completion_reason | No | |
| followup_check_in | No | |
| assembly_triggered | No | |
| forbidden_next_tools | No | |
| auto_recharge_enabled | No | |
| successful_completion | No | |
| user_message_template | No | |
| retry_after_user_confirms | No |
TDQS
A3.9/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate a mutation (readOnlyHint=false) and non-idempotent nature. Description adds critical behavioral details: the report is long-running, budget affects depth, and finalization should wait until done=true. No contradiction with annotations.
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?
The description is brief (two sentences) and front-loads the action. It avoids unnecessary detail, but could be more structured (e.g., listing key parameters). Still efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (8 params, no param descriptions), the description covers starting and monitoring but omits many parameter semantics. Since output schema exists, return values are covered, but parameter documentation is lacking.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must explain parameters, but only mentions 'budget' implicitly. Other parameters (title, file_ids, enable_checkpoints, etc.) are not described, leaving significant ambiguity for the agent.
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 action: start a private long-running report with the Hound research harness. It specifies the verb 'start' and the resource 'report', distinguishing it from sibling tools like webhound_start_dataset.
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?
Provides explicit guidance: 'Budget controls research depth; watch until done=true. Do not force finalization before done=true.' This tells when to use (start and watch) and what not to do (premature finalization). Could be improved by noting that this is for starting, not monitoring.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
webhound_stopStop Webhound SessionADestructive
Pause/stop a running Webhound report or dataset without deleting it. Use only when the user explicitly asks to stop, pause, or cancel. Do not use for healthy long-running sessions, normal budget use, warning-level tool errors, or because partial notes look sufficient.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| session_id | Yes | ||
| user_requested_stop | Yes | Must be true only when the user explicitly asked to stop/pause/cancel this Webhound run. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| url | No | |
| body | No | |
| code | No | |
| cost | No | |
| data | No | |
| done | No | |
| kind | No | |
| name | No | |
| tool | Yes | |
| error | No | |
| agents | No | |
| alerts | No | |
| budget | No | |
| status | No | |
| blocked | No | |
| dataset | No | |
| healthy | No | |
| message | No | |
| product | No | |
| resumed | No | |
| stopped | No | |
| summary | Yes | |
| accepted | No | |
| activity | No | |
| free_run | No | |
| no_spend | No | |
| required | No | |
| documents | No | |
| retryable | No | |
| checked_at | No | |
| is_running | No | |
| message_id | No | |
| new_budget | No | |
| session_id | No | |
| top_up_url | No | |
| api_message | No | |
| billing_url | No | |
| next_action | No | |
| total_spent | No | |
| amount_added | No | |
| credit_limit | No | |
| next_actions | No | |
| output_ready | No | |
| session_type | No | |
| current_spend | No | |
| error_details | No | |
| original_tool | No | |
| action_started | No | |
| budget_control | No | |
| current_budget | No | |
| guidance_added | No | |
| schema_version | Yes | |
| current_balance | No | |
| mcp_next_action | No | |
| previous_budget | No | |
| session_started | No | |
| status_snapshot | No | |
| completion_state | No | |
| research_harness | No | |
| runtime_estimate | No | |
| sidecar_guidance | No | |
| agent_instruction | No | |
| completion_reason | No | |
| followup_check_in | No | |
| assembly_triggered | No | |
| forbidden_next_tools | No | |
| auto_recharge_enabled | No | |
| successful_completion | No | |
| user_message_template | No | |
| retry_after_user_confirms | No |
TDQS
A4.1/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations include destructiveHint: true, signaling destructiveness. The description adds that stopping does not delete, but does not fully disclose behavioral implications like side effects on partial data or resumability. With annotations covering the destructive nature, the description adds some nuance but lacks comprehensive behavioral details.
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 two sentences: first defines purpose, second provides usage guidance. No wasted words, front-loaded with key information.
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 tool's simplicity, the description covers core behavior and usage context. However, it omits details like error handling or what happens to partial data. Since an output schema exists, return values are not required, but more context could be beneficial.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50% (only user_requested_stop has a description in the schema). The tool description does not add any semantics for session_id or further clarify parameters. Since coverage is not high and the description fails to compensate, the parameter semantics are poorly supported.
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 action (Pause/stop) and resource (running Webhound report or dataset), and explicitly clarifies that it does not delete the session. This distinguishes it from sibling tools like webhound_uninstall and webhound_resume.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use (only when user asks to stop/pause/cancel) and when not to use (healthy sessions, normal budget use, warnings, partial notes). This provides clear guidance and exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
webhound_uninstallUninstall Webhound MCPCRead-onlyIdempotent
No-spend guidance for removing Webhound MCP config and Webhound-specific local rules from an agent workspace. Does not revoke keys automatically.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| client | No | generic | |
| include_rules_cleanup | No |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| body | No | |
| code | No | |
| data | No | |
| tool | Yes | |
| error | No | |
| steps | No | |
| client | No | |
| status | No | |
| blocked | No | |
| message | No | |
| summary | Yes | |
| no_spend | No | |
| required | No | |
| retryable | No | |
| top_up_url | No | |
| api_message | No | |
| billing_url | No | |
| next_action | No | |
| revokes_key | No | |
| client_label | No | |
| next_actions | No | |
| error_details | No | |
| guidance_only | No | |
| original_tool | No | |
| action_started | No | |
| schema_version | Yes | |
| current_balance | No | |
| session_started | No | |
| key_revocation_note | No | |
| auto_recharge_enabled | No | |
| likely_rule_locations | No | |
| user_message_template | No | |
| retry_after_user_confirms | No | |
| suggested_user_facing_wording | No |
TDQS
C2.6/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description claims the tool removes config and rules (modifying state), but annotations set 'readOnlyHint=true', indicating a read-only operation. This is a clear contradiction, reducing transparency and potentially misleading the agent.
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?
The description is concise (two sentences) and straight to the point. It could be slightly more structured but avoids unnecessary fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has two parameters, no required fields, and an output schema (not shown), the description is insufficiently complete. It omits parameter explanations and fails to fully cover the tool's behavior beyond the initial removal statement.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must explain parameters. It mentions 'removing config and local rules' but fails to describe the 'client' enum or the 'include_rules_cleanup' boolean, leaving the agent without crucial usage context.
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 uninstalls Webhound MCP config and local rules, using a specific verb ('uninstall') and resource. It distinguishes from siblings like 'webhound_stop' and 'webhound_resume', which have different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description lacks guidance on when to use this tool versus alternatives (e.g., 'webhound_stop' or 'webhound_resume'). It does not mention prerequisites, when not to use it, or suggest other tools for different scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
webhound_update_sidecar_noteUpdate Webhound Sidecar NoteADestructive
Edit, restore, or dismiss one shared sidecar note. No spend. Does not interrupt the Planner/Executor/Verifier cycle and does not change session status.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| status | No | Set to dismissed to remove it from future planner intake; set to pending to restore it. | |
| note_id | Yes | ||
| summary | No | Concise sourced note or hypothesis for Webhound to consider later. | |
| confidence | No | ||
| hypothesis | No | Set true only when this is explicitly a hypothesis without source URLs. | |
| session_id | Yes | ||
| source_urls | No | Source URLs backing the note. Required unless hypothesis=true. | |
| why_it_matters | No | ||
| suggested_angle | No |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| body | No | |
| code | No | |
| data | No | |
| note | No | |
| tool | Yes | |
| error | No | |
| status | No | |
| blocked | No | |
| message | No | |
| summary | Yes | |
| updated | No | |
| no_spend | No | |
| required | No | |
| retryable | No | |
| session_id | No | |
| top_up_url | No | |
| api_message | No | |
| billing_url | No | |
| next_action | No | |
| interrupting | No | |
| next_actions | No | |
| error_details | No | |
| original_tool | No | |
| action_started | No | |
| schema_version | Yes | |
| current_balance | No | |
| session_started | No | |
| auto_recharge_enabled | No | |
| user_message_template | No | |
| retry_after_user_confirms | No |
TDQS
A4.1/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (destructiveHint, openWorldHint), the description adds 'No spend' and non-interruption guarantees, which are key behavioral traits. It does not elaborate on side effects of dismissal or restoration.
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 extremely concise: one sentence stating purpose, followed by two short behavioral statements. Every word adds value, and key information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 9 parameters and a destructive hint, the description is brief. It does not explain return values from the output schema, nor does it detail what 'dismiss' entails beyond what the schema says. Some gaps remain, but the core purpose is clear.
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 44%, and the tool description does not add any parameter-level information. The actions (edit, restore, dismiss) imply which parameters are relevant but do not clarify their semantics beyond the schema.
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 'Edit, restore, or dismiss one shared sidecar note,' which are specific actions on a well-defined resource. It distinguishes from siblings like add_sidecar_notes and list_sidecar_notes by focusing on modification.
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 provides context on when to use: 'No spend. Does not interrupt the Planner/Executor/Verifier cycle and does not change session status.' This implies it's safe for routine modifications. However, it does not explicitly mention when to use alternatives like add_sidecar_notes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
webhound_upload_fileUpload Webhound FileA
Upload a CSV, XLSX, PDF, DOCX, TXT, Markdown, or VTT ChatGPT attachment, local file, text, or base64 content for use in a report or dataset. Convert legacy XLS/DOC files to XLSX/DOCX first.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| text | No | ||
| files | No | ||
| file_name | No | ||
| mime_type | No | ||
| local_path | No | ||
| content_base64 | No |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| id | No | |
| ok | Yes | |
| body | No | |
| code | No | |
| data | No | |
| size | No | |
| tool | Yes | |
| error | No | |
| files | No | |
| status | No | |
| blocked | No | |
| file_id | No | |
| message | No | |
| summary | Yes | |
| file_ids | No | |
| filename | No | |
| no_spend | No | |
| required | No | |
| file_name | No | |
| mime_type | No | |
| retryable | No | |
| size_bytes | No | |
| top_up_url | No | |
| api_message | No | |
| billing_url | No | |
| next_action | No | |
| next_actions | No | |
| error_details | No | |
| original_tool | No | |
| action_started | No | |
| schema_version | Yes | |
| current_balance | No | |
| session_started | No | |
| extraction_status | No | |
| auto_recharge_enabled | No | |
| user_message_template | No | |
| retry_after_user_confirms | No |
TDQS
A3.7/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate non-read-only and non-destructive behavior, which aligns with the upload action. The description adds supported file types and a conversion requirement, but lacks details on size limits, authentication needs, or success/failure responses. The openWorldHint suggests variability, so the description provides moderate transparency.
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?
The description is concise: two sentences that front-load the core purpose and supported formats, followed by a critical usage note. It wastes no words, though it could be slightly more structured for readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (6 parameters, no required ones) and existence of an output schema, the description covers essential aspects (file types, conversion) but omits how to combine parameters or the expected response shape. It's adequate for a simple tool but could be more comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate. It briefly mentions 'text' or base64 content and lists supported file types, but does not explain the role of each parameter (e.g., local_path vs files vs content_base64) or constraints. This leaves significant ambiguity for an agent.
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's purpose: upload files of various formats (CSV, XLSX, PDF, etc.) for use in reports or datasets. It also notes conversion of legacy formats. There are no sibling tools with similar functionality, so the purpose is distinct and well-defined.
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 provides a usage tip ('Convert legacy XLS/DOC files to XLSX/DOCX first') and implies the tool is a prerequisite for report/dataset tools. While it doesn't explicitly state when not to use it or list alternatives, the context from sibling tools suggests no other upload option exists, making the guidance adequate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
webhound_waitWait For Webhound SessionARead-onlyIdempotent
Bounded wait wrapper around webhound_watch. Max 110 seconds, then returns still_running if not terminal. still_running is normal for budgeted research; call wait/watch again unless status is awaiting_input or a blocking alert is present. Do not finalize or stop a healthy running session.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| session_id | Yes | ||
| max_wait_seconds | No | ||
| poll_interval_seconds | No |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| url | No | |
| body | No | |
| code | No | |
| cost | No | |
| data | No | |
| done | No | |
| kind | No | |
| name | No | |
| tool | Yes | |
| error | No | |
| agents | No | |
| alerts | No | |
| budget | No | |
| status | No | |
| blocked | No | |
| dataset | No | |
| healthy | No | |
| message | No | |
| polling | No | |
| product | No | |
| resumed | No | |
| stopped | No | |
| summary | Yes | |
| accepted | No | |
| activity | No | |
| free_run | No | |
| no_spend | No | |
| required | No | |
| documents | No | |
| retryable | No | |
| checked_at | No | |
| is_running | No | |
| message_id | No | |
| new_budget | No | |
| session_id | No | |
| top_up_url | No | |
| api_message | No | |
| billing_url | No | |
| next_action | No | |
| total_spent | No | |
| amount_added | No | |
| credit_limit | No | |
| next_actions | No | |
| output_ready | No | |
| session_type | No | |
| current_spend | No | |
| error_details | No | |
| original_tool | No | |
| still_running | No | |
| action_started | No | |
| budget_control | No | |
| current_budget | No | |
| guidance_added | No | |
| schema_version | Yes | |
| action_required | No | |
| current_balance | No | |
| mcp_next_action | No | |
| previous_budget | No | |
| session_started | No | |
| status_snapshot | No | |
| completion_state | No | |
| research_harness | No | |
| runtime_estimate | No | |
| sidecar_guidance | No | |
| agent_instruction | No | |
| completion_reason | No | |
| followup_check_in | No | |
| assembly_triggered | No | |
| forbidden_next_tools | No | |
| auto_recharge_enabled | No | |
| successful_completion | No | |
| user_message_template | No | |
| retry_after_user_confirms | No |
TDQS
A3.8/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that it is non-destructive, idempotent (returning still_running is normal and can be retried), and warns against finalizing sessions. Annotations already indicate readOnly and idempotent, and description adds context about budgeted research and alert handling. No contradiction.
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?
Two sentences, front-loaded with core purpose. Efficiently conveys key usage constraints, though missing param documentation could be considered a gap rather than conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Does not describe all possible return statuses (only mentions still_running and awaits_input/alert). Output schema exists but is not leveraged. Missing details about what triggers terminal vs non-terminal outcomes beyond the timeout.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but description does not explain any parameter. Only 'max 110 seconds' implicitly relates to max_wait_seconds. No explanation of session_id or poll_interval_seconds meaning or constraints.
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?
Clearly states it is a 'bounded wait wrapper around webhound_watch' with a max time of 110 seconds, and specifies the 'still_running' return. Differentiates from sibling watch by indicating it is a wrapper with a timeout.
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?
Provides explicit guidance: 'still_running is normal for budgeted research; call wait/watch again unless status is awaiting_input or a blocking alert is present. Do not finalize or stop a healthy running session.' Could elaborate on when to use wait vs watch directly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
webhound_watchWatch Webhound SessionARead-onlyIdempotent
Authoritative session watcher. done=true means the run is terminal. output_ready=true without done=true can still be intermediate; keep waiting unless the user explicitly asks for a partial update.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| session_id | Yes |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| url | No | |
| body | No | |
| code | No | |
| cost | No | |
| data | No | |
| done | No | |
| kind | No | |
| name | No | |
| tool | Yes | |
| error | No | |
| agents | No | |
| alerts | No | |
| budget | No | |
| status | No | |
| blocked | No | |
| dataset | No | |
| healthy | No | |
| message | No | |
| product | No | |
| resumed | No | |
| stopped | No | |
| summary | Yes | |
| accepted | No | |
| activity | No | |
| free_run | No | |
| no_spend | No | |
| required | No | |
| documents | No | |
| retryable | No | |
| checked_at | No | |
| is_running | No | |
| message_id | No | |
| new_budget | No | |
| session_id | No | |
| top_up_url | No | |
| api_message | No | |
| billing_url | No | |
| next_action | No | |
| total_spent | No | |
| amount_added | No | |
| credit_limit | No | |
| next_actions | No | |
| output_ready | No | |
| session_type | No | |
| current_spend | No | |
| error_details | No | |
| original_tool | No | |
| action_started | No | |
| budget_control | No | |
| current_budget | No | |
| guidance_added | No | |
| schema_version | Yes | |
| current_balance | No | |
| mcp_next_action | No | |
| previous_budget | No | |
| session_started | No | |
| status_snapshot | No | |
| completion_state | No | |
| research_harness | No | |
| runtime_estimate | No | |
| sidecar_guidance | No | |
| agent_instruction | No | |
| completion_reason | No | |
| followup_check_in | No | |
| assembly_triggered | No | |
| forbidden_next_tools | No | |
| auto_recharge_enabled | No | |
| successful_completion | No | |
| user_message_template | No | |
| retry_after_user_confirms | No |
TDQS
A3.7/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint, idempotentHint, and non-destructive. The description adds value by explaining that 'done=true' is terminal and 'output_ready=true' alone may be intermediate, which provides behavioral context beyond the structured annotations.
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 efficient sentences that front-load the core purpose and then add immediate usage nuance. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the essential return flags (done, output_ready) but does not mention other possible output fields. Given that an output schema exists (though not provided), the description could be more complete about the full response structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage and the description does not explain the sole parameter 'session_id' (e.g., format, source). Since the description fails to compensate for the schema's lack of parameter documentation, this dimension is low.
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 it is an 'authoritative session watcher' and explains key flags (done, output_ready), making the purpose specific and understandable. However, it does not explicitly differentiate from sibling tools like webhound_wait or webhound_get_session, which may also monitor sessions.
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 provides explicit guidance on when to keep waiting (output_ready without done means intermediate) and when a user might request a partial update. This is helpful for correct usage, but it does not mention when to choose this tool over siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
30 tool updates
v0.5.3- First observed
webhound_account - First observed
webhound_add_budget - First observed
webhound_add_sidecar_notes - First observed
webhound_diagnose - First observed
webhound_export_session - First observed
webhound_get_claims - First observed
webhound_get_defaults - First observed
webhound_get_evidence_pack - First observed
webhound_get_output - First observed
webhound_get_session - First observed
webhound_get_shareable_link - First observed
webhound_get_sources - First observed
webhound_health - First observed
webhound_help - First observed
webhound_list_sessions - First observed
webhound_list_sidecar_notes - First observed
webhound_onboarding - First observed
webhound_resume - First observed
webhound_search_sessions - First observed
webhound_send_message - First observed
webhound_set_budget - First observed
webhound_set_defaults - First observed
webhound_start_dataset - First observed
webhound_start_report - First observed
webhound_stop - First observed
webhound_uninstall - First observed
webhound_update_sidecar_note - First observed
webhound_upload_file - First observed
webhound_wait - First observed
webhound_watch
TDQS
B3.4/5.0
Disambiguation5/5
Each tool targets a distinct function: budget management, session lifecycle, report/dataset operations, evidence gathering, note management, communication, and utilities. Despite 30 tools, there is clear separation of concerns with no overlapping purposes.
Naming Consistency4/5
All tools share the 'webhound_' prefix and mostly follow a verb_noun pattern (e.g., webhound_add_budget, webhound_start_report). However, a few tools are named with nouns only (webhound_health, webhound_onboarding, webhound_help, webhound_account), which is a minor inconsistency.
Tool Count2/5
With 30 tools, the surface is large. While each tool serves a specific need in a complex research assistant, the count exceeds the typical well-scoped range (3-15) and falls into the 'too many' category, potentially overwhelming for agents.
Completeness4/5
The tool set covers the full research lifecycle: create, monitor, pause, resume, stop, budget, output, export, evidence, claims, sources, notes, search, and file upload. Minor gaps exist (no delete session, no edit report), but core workflows are well-supported.
Maintenance
ActivityMaintained
ResponsivenessNo issues
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
- WebhoundOAuthai.webhound
Budgeted reports and datasets with Hound, Webhound's DeepSeek V4 Pro + GPT-5.4 research harness.
Web research for agents: quality-scored Google search, webpage extraction, and deep research.
Source-traced evidence research for AI agents. We organise the evidence; you decide.
Web search, fetch, extract, and research for AI agents. Markdown output + AI-synthesized answers.
Related MCP Servers
- AlicenseNot gradedqualityCmaintenanceEnhances LLM applications with deep autonomous web research capabilities, delivering higher quality information than standard search tools by exploring and validating numerous trusted sources.368MIT
- AlicenseAqualityAmaintenanceEvidence-backed web research for AI agents. Real-time search with cited claims, confidence scores, and compare mode showing raw LLM hallucination vs evidence-backed answers.520Apache 2.0
- AlicenseAqualityDmaintenanceA multi-agent research system that decomposes complex queries into targeted sub-questions, searches the web in parallel, scores source credibility, and synthesizes findings into structured markdown reports.11MIT
Appeared in Searches
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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