Webhound MCP

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.5.3
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.
Average 3.8/5 across 30 of 30 tools scored. Lowest: 2.6/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 22 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
This repository includes a glama.json configuration file.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

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.
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.
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.
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.
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.
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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate a mutation (readOnlyHint=false, destructiveHint=false). The description confirms it creates shareable links and clarifies it does not publish, but omits details like idempotency (idempotentHint=false suggests new links per call, unmentioned), permission requirements, or whether existing links are overwritten. Adds some context but could be richer.
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 front-loaded with the key action. It efficiently conveys the tool's purpose and a key constraint (no publishing). One could argue for a perfect score, but the lack of parameter description slightly reduces efficiency.
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 (1 parameter, output schema exists), the description is moderately complete. It covers the main behavior and constraints but misses parameter details and edge cases (e.g., error handling, session existence). The presence of an output schema mitigates the need for return value explanations, but parameter gaps remain.
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 the single parameter 'session_id'. It does not – the parameter is not mentioned at all. The parameter name is somewhat self-explanatory, but the description should clarify that it's the session ID of the report or dataset to share. This is a significant gap.
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 action: 'Make a report or dataset accessible to anyone with the link and return the share URL.' It distinguishes between report and dataset URL formats and explicitly states what it does not do (publish to Explore or create slug publications), effectively differentiating it from siblings.
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 the usage context (share-only) and mentions the URL formats, but it does not explicitly guide when to use this tool versus alternatives like 'webhound_export_session' or 'webhound_start_report'. No direct 'use when' or 'when not' guidance is provided, leaving the agent to infer.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![webhound-mcp MCP server](https://glama.ai/mcp/servers/WebhoundAI/webhound-mcp/badges/card.svg)](https://glama.ai/mcp/servers/WebhoundAI/webhound-mcp)

Score Badge

Copy to your README.md:

[![webhound-mcp MCP server](https://glama.ai/mcp/servers/WebhoundAI/webhound-mcp/badges/score.svg)](https://glama.ai/mcp/servers/WebhoundAI/webhound-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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