novada-mcp
OfficialServer Quality Checklist
Latest release: v0.1.1
- Disambiguation4/5
Most tools have clearly distinct purposes, especially within categories like proxies and scraping. However, novada_browser and novada_browser_flow overlap significantly, and the large number of proxy types (residential, ISP, datacenter, mobile, static, dedicated) could confuse an agent despite detailed descriptions.
Naming Consistency3/5Tools consistently use 'novada_' prefix and underscores, but the verb/noun placement varies: some are verb-first (novada_crawl, novada_extract), others noun-first (novada_browser, novada_health). Within categories (e.g., novada_proxy_*) naming is consistent, but cross-category inconsistency is notable.
Tool Count3/534 tools is high for an MCP server, bordering on excessive. While each tool has a distinct purpose, the number could be streamlined (e.g., merging redundant proxy tools or browser tools). It feels slightly bloated for the domain of web scraping and proxy services.
Completeness4/5The tool set covers account management, content retrieval, proxy configuration, browser automation, platform scraping, monitoring, and verification. Minor gaps exist: no proxy account update/delete, no async task cancellation, and no explicit session management tools. Overall, it's fairly complete for the stated purpose.
Average 4.6/5 across 34 of 34 tools scored. Lowest: 3.1/5.
See the Tool Scores section below for per-tool breakdowns.
- 0 of 1 community issues answered or closed in the last 6 months
- 421 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
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.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add
glama.jsonto 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
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (readOnlyHint=false, destructiveHint=false, idempotentHint=false, openWorldHint=true) are complemented by the description stating async behavior and polling requirement. However, the parameter mismatch between description and schema undermines reliability.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections, front-loaded with purpose, and provides workflow steps without redundancy. Slightly longer due to useful usage notes, but every sentence adds value except the parameter mismatch.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is complex (async, 3 required params including nested objects), but the description fails to explain the actual schema parameters or return value format (no output schema). The missing parameter mapping makes it incomplete for an agent to correctly invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description contradicts the schema by stating 'Required: url' and optional 'scraper_type' and 'country', which are not in the schema. The actual parameters (platform, operation, params) are not explained beyond schema descriptions, so the description adds confusion rather than value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it submits an async scraping task and returns a task_id, distinguishing from synchronous novada_scrape. However, the description mentions URL as required while the schema requires platform, operation, and params, causing confusion about the actual parameters.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides a workflow (submit → poll → retrieve), describes when to use (async for JS-heavy, rate-limited, long-running), and offers an alternative (novada_scrape for 129 platforms). Also includes a note about contacting support for placeholder task_ids.
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 declare readOnlyHint=true and destructiveHint=false, indicating a safe read operation. The description adds behavioral details: it wraps a POST endpoint, supports pagination with 'page' and 'page_size' (max 200), and reveals a server-side typo compatibility where 'start_time' also emits 'strat_time.' 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is five lines: three sentences and a bullet list. The first sentence clearly states the tool's purpose. Every line adds value—purpose, usage, parameters, auth—without unnecessary fluff. Could be slightly more streamlined, but it's well-structured and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 parameters (2 required), pagination, a status filter, and no output schema, the description covers purpose, usage, parameter details (including a known bug), auth fallback, and pagination limits. It is complete enough for an agent to use effectively, though response format is not described.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 60% (3 of 5 params have descriptions). The description supplements the schema by listing all parameters, noting date formats (YYYY-MM-DD), the 'strat_time' bug, pagination max (200), and status filter options. This adds meaningful context beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves 'Paginated capture-task logs' and specifies its use for 'auditing what was captured, debugging failed capture jobs.' It also mentions the underlying API endpoint, distinguishing it from sibling tools that focus on scraping, proxies, or other non-log actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance with 'Best for: Auditing what was captured, debugging failed capture jobs.' It also notes the optional parameters and auth fallback. While it doesn't explicitly state when not to use the tool, the guidance is sufficient for an agent to determine appropriate contexts.
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 operational context: fastest/cost-effective, for non-anti-bot targets, requires env vars, and escalation behavior on block. No contradiction with annotations; the description enriches behavioral understanding.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with purpose, then bullet-style best-for/not-for, params, formats, and agent_instruction. Each section is concise. Minor redundancy between agent_instruction and best-for/not-for, but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, usage guidelines, parameter summary (though schema covers details), required env vars, and formats. No output schema exists, but return value (proxy credentials) is implied by format options. Lacks explicit note on response structure, but adequate for tool simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with good parameter descriptions. The description's parameter section repeats schema info without adding new semantic value. Baseline 3 is appropriate as the description adds no extra meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: routing requests through datacenter IPs for high-volume scraping of targets without aggressive anti-bot. It distinguishes from siblings by explicitly noting that novada_extract and novada_crawl handle proxy routing internally, and that these credentials are for external HTTP clients.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly lists best-for (APIs, public data feeds, high-volume non-protected targets), not-for (novada_extract, novada_crawl), and provides an agent_instruction with escalation path (isp → residential if blocked). This gives clear guidance on when and how to use the tool vs. 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 already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. Description adds meaningful behavioral context like analyzing sentiment, extracting claims, identifying competitor mentions, and listing output components. 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear sections (Best for, Not for, Output, Models supported). No redundant sentences; every line adds value. Front-loaded with purpose and usage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Input parameters fully documented. No output schema, but description covers output components (sentiment, claims, competitor mentions, source URLs). Could mention pagination or limits, but not critical for this use case.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline 3. Description repeats model list and output expectations but doesn't add new semantics beyond the schema descriptions. Topics parameter remains generic.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool monitors AI model references for a brand, with specific verbs 'check how AI models reference'. Explicitly distinguishes from sibling tools like novada_search and novada_scrape in the 'Not for' section.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use ('Use when you need to check how AI models...'), best-for, and not-for sections with specific tool alternatives (novada_search, novada_scrape), giving clear decision criteria.
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?
Description adds behavioral details beyond annotations: crawl time scaling (~1.4s/page), minimum 28s at max_pages=20, and that instructions are path-level filtering. Annotations already indicate safe read (readOnlyHint=true) and open world, so good complement.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (Best for, Not for, Common mistakes, When to use). Every sentence adds value, no fluff, front-loaded with key purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description and parameter descriptions for 'format' cover return format. The tool's complexity is addressed with usage advice and performance caveats, making it complete for an agent to use effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 80%, so schema already documents most parameters. The tool description adds some usage tips (e.g., not to exceed 10 pages for large sites) but doesn't significantly expand parameter semantics beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Tool description clearly states it crawls multiple pages from a site using BFS/DFS up to 20 pages. It specifies use cases like doc site ingestion and contrasts with siblings novada_extract and novada_map, making its purpose distinct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides 'Best for' and 'Not for' sections, including alternatives like novada_extract and novada_map. Lists common mistakes and when to use, offering clear 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?
Annotations already indicate read-only, non-destructive, idempotent. Description adds return format (Markdown table), grouping, and status legend, enhancing transparency 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with sections (agent_instruction, Returns, Filter, Status legend). Slightly verbose but clear and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but description explains return format and status legend. Single optional param with full coverage. Complete for a discovery tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters with enum and description. Description adds value by explaining omitting lists all, and using filter to narrow. Provides usage context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists all available Novada tools with name, description, category, and status. It distinguishes from siblings by being a discovery tool, while siblings are specific actions like scraping or monitoring.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to call first for new tasks to find the right tool. Mentions filtering by category. No explicit when-not, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate write but not destructive or idempotent. The description adds critical behavioral details: two-step confirm gate, preview without confirm, dry-run behavior, wire format, and auth fallback. This goes well 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (warning, behavior, best for, params, wire format, auth). It is slightly long but every sentence adds value. Front-loaded with crucial warning and behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description should cover return values and errors. It explains the preview and confirm gate well, but does not mention typical success response or error scenarios. Still, the key behavioral context is present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by summarizing all parameters in a list, clarifying product codes, that limit_flow is a string, and password storage. It provides additional context beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Create a proxy sub-account' with a specific verb and resource. It distinguishes from siblings like novada_proxy_account_list by focusing on creation, and provides clear 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description says 'Best for: Provisioning a team-member or per-project sub-account' and explains the two-step confirm gate. It gives clear context but does not explicitly state when not to use or list alternatives, though the sibling list provides 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 already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and the description adds practical behavioral context such as requiring environment variables and being for external HTTP clients, 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Description is well-structured with bold headers and bullet points, front-loading the key purpose. It is somewhat lengthy but every sentence adds value, with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, usage context, parameter summary, required environment variables, and format options, and differentiates from sibling proxy tools, making it complete for a proxy configuration tool with no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all parameters. The description summarizes parameters and adds minor context (e.g., 'sticky IP' for session_id), but the schema already provides sufficient meaning, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool routes requests through 4G/5G mobile IPs, specifying the resource (mobile IPs) and verb (route), and distinguishes it from siblings by focusing on mobile-targeted content.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly lists best-for and not-for scenarios, including specific sibling tools (novada_extract, novada_crawl) and clarifies these credentials are for external HTTP clients, providing excellent guidance on when to use.
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, idempotentHint, so no contradiction. Description adds value by specifying the return type (status table with activation links), which is 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Very concise: two sentences plus a bullet point for returns. All information is front-loaded and succinct.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters, output schema, or complex behavior, the description is fully complete. It clearly explains purpose, use cases, and output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters, baseline 4. Description doesn't need to add parameter info, but it implies the tool uses the API key contextually.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the verb 'Check' and resource 'which Novada API products are active'. It distinguishes from sibling tools by focusing on account-level health and first-time setup, not a specific product.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly lists best use cases: first-time setup, diagnosing failures, confirming account activation. No explicit alternatives, but the context of siblings implies when to use other tools.
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 read-only, non-destructive, idempotent behavior. The description adds session-scoped state persistence (not persisted across restarts) and details the hash comparison process. This adds value beyond annotations without 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with bold section headers and bullet points. It is fairly concise, though slightly long, but every section adds distinct value. No redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains the return type (changed/unchanged + field-level diffs) despite no output schema. It also covers session scoping and the baseline mechanism. Could mention error handling, but it is sufficiently complete for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description enriches parameters with context: for 'fields', it gives an example with price and availability and mentions percentage change; for 'format', it explains the output difference. This goes beyond the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Detect changes on a web page over time' with a specific verb (detect), resource (web page), and temporal scope. It also distinguishes from sibling tools like novada_extract and novada_crawl by specifying what it is not for.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit use cases (e.g., price monitoring, stock tracking) and explicitly states when not to use (one-time extraction, full crawl) with alternatives. Also explains the baseline and comparison workflow, giving clear context for invocation.
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 behavioral context beyond annotations: session expiration (10 min), action limit (20 per call), and that sessions preserve state. While annotations indicate non-destructive and non-idempotent behavior, the description clarifies operational constraints. 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (Best for, Actions, Sessions, Fallback, Not for). It is concise with no wasted words, yet covers all essential information for an AI agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description adequately covers use cases, constraints (action limit, session expiry), and fallback. It could mention the return format, but given the complexity and the presence of sibling tools for comparison, it is nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds value by summarizing action types and explaining session_id usage, which goes beyond the schema's property descriptions. This helps agents understand the tool's capabilities beyond raw parameter definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Execute' and the resource 'multi-step browser automation with Novada's cloud browser'. It specifies use cases like JS-heavy sites, login flows, and multi-page sequences, distinguishing it from siblings such as novada_browser, novada_extract, and novada_scrape.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit 'Best for', 'Not for', and 'Fallback' sections provide direct guidance on when to use this tool and when to use alternatives. It also details session reuse and expiration, giving agents clear decision criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description adds behavioral details beyond annotations: fallback mechanism from sitemap to BFS crawl, output format (URL list only), and limitation on JavaScript SPAs with a flag. Annotations already declare read-only and idempotent, consistent with description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a single paragraph and bullet points, no redundant text. Structure is clear: usage context, best for, not for, and a note.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, usage guidance, behavioral details, and limitations. No output schema, but description mentions output format. Could add more on return structure or error handling, but sufficient for a URL-discovery tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is low (20%), and the description does not explain individual parameters like search, limit, or include_subdomains in detail. However, the overall purpose and behavior context somewhat compensate, and simple parameters like url and limit are self-explanatory.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: to discover URLs on a site using sitemap or BFS crawl, returning only a URL list. It distinguishes itself from siblings like novada_extract and novada_crawl.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit 'Best for' and 'Not for' sections provide clear guidance on when to use (site structure discovery, finding correct subpage) and when not to (reading page content), with alternatives mentioned.
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 provide readOnlyHint, idempotentHint. Description adds environment variable requirements and notes that the tool returns proxy config for external clients, not internal use. 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear sections (Best for, Not for, Params, Formats, Requires). Every sentence is informative. No redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, usage, parameter details, and environment setup. Although no output schema, the formats parameter explains possible return values. Could mention if other parameters are required for certain formats, but overall sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with good per-parameter descriptions. The description adds a summary and clarifies the relationship between city and country (requires country). This adds value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool routes requests through residential IPs for anti-bot bypass and geo-restricted content. It distinguishes from sibling tools like novada_proxy_datacenter and novada_proxy_isp by specifying 'real home ISP addresses' and 'best anti-bot bypass'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly lists best use cases (anti-bot protected, geo-restricted) and what not to use it for (novada_extract/crawl handle proxy internally). Provides escalation guidance ('escalate here from isp/datacenter when blocked').
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 read-only, idempotent, open-world. Description adds behavioral details: reranking, optional enrichment with latency cost, engine speed differences. 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: main description plus bullet points for use/not-for/tip. Every sentence provides useful guidance without redundancy. Front-loaded with key facts.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers tool purpose, parameter highlights, use vs. alternatives. No output schema, but return content is described. Could mention result count limits, but overall sufficient for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 69% (high). Description adds value by clarifying enrich_top as shorthand for extract_options.top_n=1 and noting DuckDuckGo speed. Guide helps parameter selection beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it searches the web via 5 engines, returns titles/URLs/snippets reranked by relevance, and distinguishes itself from sibling tools like novada_research and novada_extract. It provides specific use cases and exclusions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly lists 'Use for' (current events, fact lookup, etc.) and 'Not for' (reading a URL, multi-source report) with alternative tools named. Also includes a tip about engine speed for DuckDuckGo.
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. Description adds authentication details (NOVADA_DEVELOPER_API_KEY falls back to NOVADA_API_KEY) and that it wraps a POST endpoint, which is behavioral context beyond annotations. 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three short, focused sentences/paragraphs. First clause states purpose immediately. 'Best for' and 'Not for' sections are concise and actionable. Auth info appended without redundancy. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With zero parameters, complete annotations, and no output schema, the description covers purpose, usage guidance, and auth. Missing return value description, but for a simple balance read, the implied result (currency amount) is clear enough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has zero parameters, so schema coverage is trivially 100%. Description adds no parameter info (none needed). Baseline for 0 params is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it reads the master Novada wallet balance (currency). Distinguishes from per-product balance tools by naming novada_plan_balance_all as the alternative. The verb 'Read' and resource 'wallet balance' are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Best for: Confirming credit available before launching billable scraper/proxy jobs' and 'Not for: Per-product MB/quota — use novada_plan_balance_all', providing both when-to-use and when-not-to-use with an alternative 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 and destructiveHint=false. The description adds valuable behavioral context: the tool emits both start_time and a typo'd 'strat_time' for forward compatibility, and specifies authentication requirements, which go beyond annotation contents.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, well-structured with bold headers for each section (Best for, Not for, Params, Auth), and every sentence adds unique value. No unnecessary repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, parameters, pagination, auth, and a behavioral quirk. However, without an output schema, the response shape is not described, which is a minor gap for completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds significant context beyond schema: clarifies optionality of date parameters with server defaults, page_size maximum, and the dual emission of start_time and strat_time, elevating the score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Paginated wallet transaction / usage history' and explicitly distinguishes from siblings with 'Best for' and 'Not for' sections, naming alternative tools like novada_traffic_daily and novada_plan_balance_all.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use ('Auditing recent spend, exporting billing rows') and when-not-to-use ('Aggregate by-product spend', 'current balances') with specific alternative tool names, offering clear decision 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?
Annotations already provide readOnlyHint, destructiveHint, idempotentHint. Description adds valuable context: returns proxy URL/shell commands/curl flag, requires specific env vars. 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with sections, front-loaded with purpose, every sentence is informative. No redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, description explains return formats (url, env, curl) and prerequisites (env vars). Complete for a proxy-generation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but description adds guidance on type selection ('residential for most anti-bot scenarios') and format purpose. This goes beyond schema descriptions, earning above baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: routing HTTP requests through residential/mobile IPs. It uses specific verbs like 'route' and 'bypass', and distinguishes itself from specialized siblings like novada_proxy_residential.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit 'Best for' and 'Not for' sections direct when to use this tool vs alternatives (novada_extract, novada_search, and specialized proxy tools). Also mentions sticky sessions and geo-targeting scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description adds significant behavioral context beyond annotations: wire format (multipart/form-data), auth requirements (NOVADA_DEVELOPER_API_KEY fallback), and parameter details like status filter and exact-match filter. No contradictions with annotations (readOnlyHint, destructiveHint, idempotentHint).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise, structured with bullet-like lines. First line states purpose, second gives best-for, third details parameters. No wasted words—every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, use cases, parameters, wire format, and auth. Missing response format details (no output schema), but for a read-only list tool, this is adequate. Minor gap but still robust.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but description adds extra meaning: notes that product codes are same as create, clarifies API field names (limit vs page_size, account vs username), and mentions limit max of 200. This adds value beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description starts with 'List proxy sub-accounts' which is a specific verb+resource. It distinguishes from sibling tools like novada_proxy_account_create by focusing on listing, and adds context about wrapping a POST API.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
States 'Best for: Auditing sub-accounts, finding account names before rotating credentials', giving clear use-case guidance. While it doesn't explicitly say when not to use, the context is sufficient for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond the annotations (readOnlyHint, destructiveHint, idempotentHint) by detailing that the proxy looks like a real home user and requires specific environment variables. It also explains output format options, which is not covered by 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear headings and bullet points, making key information easy to find. It is concise without unnecessary words, and every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters (all well-documented in schema), no output schema, and annotations, the description covers purpose, usage guidelines, behavioral details, environment variable requirements, agent instructions, and output formats, making it fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed parameter descriptions. The description restates parameters in a summary line but adds no additional meaning beyond what the schema provides. Therefore, baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states that the tool routes requests through ISP-assigned IPs that resemble real home users, specifying its ideal use for social media and ecommerce platforms. This clearly distinguishes it from siblings such as novada_proxy_datacenter and novada_proxy_residential.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear best-for and not-for sections, explicitly stating it is not for novada_extract or novada_crawl as they handle proxy routing internally. It also advises escalating to novada_proxy_residential for stronger anti-bot needs, offering explicit alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds behavioral context beyond annotations: status values, retry behavior, and next-action instruction. Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and description aligns with 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured, concise sentences with clear sections. Every sentence adds value, no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Complete for a polling tool with one parameter, no output schema. Explains return values, retry logic, and next steps. Annotations cover safety/idempotency.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one parameter (task_id) with 100% schema description coverage. The description reinforces its origin from novada_scraper_submit but adds no additional syntax or constraints beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool checks the status of an async scraping task by task_id, lists return values, and distinguishes itself from siblings by referencing novada_scraper_submit and novada_scraper_result.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use (after novada_scraper_submit), retry instructions with exponential backoff, what to do on complete (call novada_scraper_result) and on failure (re-submit or use alternatives).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds value beyond annotations by stating 'No auth required: This tool works even when NOVADA_API_KEY is not set,' which is critical behavioral insight. It also details the output (env var status, setup commands, active tools). Annotations already indicate read-only, non-destructive, idempotent behavior, and the description reinforces and contextualizes that.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four sentences, front-loaded with the main purpose, and structured with bullet-style points. Every sentence adds value: purpose, use cases, output details, and auth requirements.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite lacking an output schema, the description thoroughly explains the output (status of env vars, setup commands, active tools). For a simple diagnostic tool, this is complete and leaves no ambiguity about what the tool returns.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so schema coverage is 100%. The description adds meaning by explaining what the tool does and what it outputs, compensating for the lack of parameters. A baseline of 4 is appropriate for a parameterless tool with clear purpose.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool checks environment configuration and provides step-by-step setup instructions. It clearly distinguishes from sibling tools, which focus on account summaries, browsing, scraping, etc., by positioning itself as the first-time setup and diagnostic tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description specifies 'Use for: First-time setup, diagnosing missing credentials, getting exact config snippets' and notes it is safe to call before API key is configured. While it doesn't explicitly list when not to use it, the use cases are clear. No direct alternative tool is mentioned, but the sibling list implies this is the only setup-oriented tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations show readOnlyHint=true, describing a safe read operation. Description adds significant context: parallel fan-out, partial failure handling, return structure (total_mb, per-product, error flags), and the typo parameter behavior. 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with sections (main action, best for, returns, params, auth). Each sentence is informative; a minor reduction in length would be possible but current length is justified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, description fully explains return values (total_mb, per-product, error flags) and handling of partial failures. Covers all essential aspects for a traffic aggregation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but description adds defaults (7 days ago, today), typo behavior ('emits both start_time AND strat_time'), and optional products subset. This meaningfully extends the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb ('aggregate') and resource ('daily traffic consumption') with specific scope ('across all 5 Novada proxy products in PARALLEL'). Distinguishes from siblings by mentioning fan-out to multiple endpoints.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit best-for use cases: 'How much have we spent on proxies in the last N days?' and dashboarding. Also explains partial failure behavior, but does not explicitly state when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly, idempotent, openWorld. Description adds valuable detail: runs supporting/skeptical/fact-check searches, returns verdict types and confidence 0-100. Warns verdict is not definitive, which is crucial context 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three short paragraphs efficiently covering purpose, usage guidance, and behavioral note. No wasted words; front-loaded with key info.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, description explains return types (verdict + confidence). Covers search strategy and limitations. Complete for a simple 2-param tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage 100% so baseline is 3. Description reinforces that 'claim' is a factual claim (min 10 chars) and 'context' optional for narrowing, but doesn't add substantial new meaning beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it verifies factual claims against web sources using 3 parallel searches. It distinguishes from siblings novada_research (open-ended) and novada_extract (specific URLs), making purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly lists 'Best for' and 'Not for' with specific alternative tools. Provides note about verdict being signal-based, guiding appropriate use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate non-readonly, non-destructive, non-idempotent, open-world. Description adds critical behavioral details: session expiration (10 min), environment variable requirement, and action constraints. 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Description is well-organized with bullet points and clear sections. Each sentence adds value; no fluff. It front-loads the main use case and efficiently covers actions, sessions, and constraints.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers actions, sessions, constraints, platform notes, and environmental requirements. Missing output description (e.g., what screenshot returns), but the tool is complex and the description is fairly thorough. Could add return value hints for each action.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% coverage with detailed descriptions for all parameters. Description adds extra context like chaining actions, max 20 actions, session reuse speed benefits, but the schema already explains each param well. The description adds value beyond schema but not dramatically.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool's purpose: 'interact with a web page — click buttons, fill forms, scroll, take screenshots, or execute JavaScript.' It lists specific actions and explicitly distinguishes from siblings (novada_extract, novada_scrape, novada_unblock), making it unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit 'Best for:' and 'Not for:' sections with sibling tool names. Also includes platform-specific guidance (TikTok geo-restrictions, SPA wait strategies) and constraint that close_session/list_sessions must be alone.
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 mark it as read-only, idempotent, and non-destructive. Description adds context: auto-escalation mechanism (static -> JS -> Browser CDP), batch parallelism for up to 10 URLs, and performance notes (auto is 15-100x faster). 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with headings, bullet points, and key rules. Every sentence adds value. No redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, description explains all return formats (markdown, text, html, json) and the structured markdown document for batch. All 7 parameters are adequately described, including edge cases like max_chars truncation. For a complex extraction tool, this is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but description adds significant value: explains the alias relationship between url and urls, describes the structured batch output format, warns about max_chars default, and clarifies render modes beyond enum values. For fields, it explains the extraction order (JSON-LD first, then pattern matching).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description starts with a clear verb+resource: 'Extract clean content from any URL.' It explicitly distinguishes from sibling tools (novada_map, novada_crawl, novada_scrape) by contrasting their purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Has explicit 'Use for:' and 'Not for:' sections listing specific use cases and alternatives. Provides a key rule about leaving render='auto' and when to override, which guides correct invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (readOnly, idempotent) are complemented by description details: exclusive IP, no sharing, session-to-IP mapping, and requirement for env vars. No contradiction; the description adds context 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (purpose, best/not for, params, formats, agent_instruction, requires). Every sentence adds value, no redundancy. It is concise yet comprehensive.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While there is no output schema, the description explains output formats (url, env, curl) and mentions environment variable requirements. It adequately describes the tool's purpose and usage, though it could mention error handling or rate limits. Given the annotations and sibling context, it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but description adds value by summarizing parameters: 'url (optional)', 'session_id (REQUIRED — maps to your exclusive dedicated IP)', and listing formats. This clarifies the purpose of each parameter beyond the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool routes requests through an exclusive datacenter IP with clean reputation, distinguishing it from siblings like novada_proxy_residential. It specifies the verb 'route' and resource 'requests', and explicitly indicates when not to use it (novada_extract/crawl).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides 'Best for' and 'Not for' sections, naming alternatives (novada_proxy_residential) and explaining that novada_extract/crawl handle proxy routing internally. Also mentions required environment variables, giving clear when-to-use 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?
Annotations already indicate readOnly=true and destructive=false. The description adds context on output formats (markdown, json, toon), example usage, and references a resource for operation details. It doesn't contradict annotations and provides useful behavioral insight.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured with clear sections, bullet points, and a code block example. Every sentence serves a purpose without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having no output schema, the description covers all necessary aspects: purpose, usage guidance, parameter details with examples, output format options, and cross-referencing a resource for more info. It is fully complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All 5 parameters have schema descriptions (100% coverage). The description adds significant value by providing concrete examples for platform, operation, and params, explaining the limit default/max, and describing each format. This greatly aids the agent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool extracts structured data from specific platforms, lists supported platforms, and distinguishes from sibling tools like novada_extract and novada_crawl, making the purpose crystal clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear when-to-use (best for e-commerce, social, etc.) and when-not-to-use (general web pages, unknown domains) guidance, with specific sibling tool names, and directs to a resource for discovering platforms and operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=true, destructiveHint=false, idempotentHint=true, which are consistent with the description. The description adds valuable behavioral details: parallel execution of three internal tools, derived fields (expired/expires_at_human, unavailable_products), and the return structure (headline, sections, agent_instruction). 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections: purpose, best-for scenarios, return structure, rationale for combining calls, and authentication. Every sentence adds necessary context, and the length is appropriate for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and no output schema, the description fully explains the tool's behavior, including the aggregated output format (headline, sections, agent_instruction) and the derived fields. It also covers authentication fallback. All necessary context for an agent to invoke and use the tool correctly is provided.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so the description does not need to explain parameter meaning. It implicitly conveys that no input is required. The baseline for zero-parameter tools is 4, and the description adds value by explaining what the tool does with its implicit inputs (auth tokens).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is a 'single-call account dashboard' that aggregates wallet, plan, and capture data. It explicitly answers the purpose: 'What's my Novada account status?' and distinguishes itself from sibling tools like novada_wallet_balance and novada_plan_balance_all by combining them into one call with parallel execution.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit best-for scenarios ('What's my Novada account status?', 'How much do I have left?', 'one-shot health snapshot') and explains why it is better than making three separate calls (halves round-trip cost). Also mentions authentication requirements and fallback behavior.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses important behaviors beyond annotations: degraded mode (one probe failure does not hard-fail the whole check), returns per-product table with latency and notes, and provides activation links for unavailable products. Annotations only indicate read-only and idempotent; description adds rich 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with bold headings and bullet points. It is front-loaded with the core purpose, then uses clear sections for agent instruction, returns, degraded mode, activation links, and difference from sibling. Every sentence adds value, no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having no parameters and no output schema, the description fully covers what the agent needs to know: return format, error handling behavior, activation links, and comparison to sibling. It is complete for effective tool use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so baseline is 4. The description adds no parameter-level detail because none exist, but it explains the tool's output and behavior, which is appropriate for a parameterless tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Extended health check that tests ALL Novada product endpoints in parallel and returns detailed per-product status.' It also explicitly distinguishes from its sibling 'novada_health' by noting it tests 6 products (including Unblock API) instead of 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes an agent instruction: 'Call this when novada_health shows an issue and you need per-product details, or when setting up Novada for the first time and want to confirm every product is reachable.' It also details the difference from novada_health, helping the agent choose the correct tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds valuable behavioral context: 'same IP every request', 'dedicated ISP IP that never changes', 'same session_id always returns the same IP'. This explains the static nature beyond annotations, and there is 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with bold labels and bullet points, but slightly verbose. Repeats 'same IP every request' in both the intro and agent_instruction. However, front-loads key information and is easy to scan. Could be trimmed slightly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but the description explains return formats: 'url', 'env', 'curl'. Lists required env vars (NOVADA_PROXY_USER, etc.). Distinguishes from siblings by specifying this is a static ISP proxy. Covers prerequisites, use cases, and constraints for a complete understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the description adds meaning: explains that country determines distinct IP pool, session_id determines dedicated IP, format options ('url', 'env', 'curl'). Provides additional context like 'each country has a distinct pool of dedicated IPs' and 'maxLength: 64' for session_id.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Route requests through a dedicated static ISP IP that never changes'. It specifies the verb ('Route'), resource ('static ISP IP'), and distinguishing scope ('same IP every request for a given session_id + country'). This differentiates it from sibling proxy tools like novada_proxy_datacenter or novada_proxy_dedicated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit 'Best for:' and 'Not for:' sections provide clear guidance. 'Best for: Account management, login-dependent workflows, platforms that flag IP changes as suspicious.' 'Not for: novada_extract or novada_crawl — they handle proxy routing internally.' Also specifies that credentials are for own HTTP clients, not internal tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, destructiveHint, idempotentHint. Description adds concrete details: 3-10 parallel searches, dedup, top 5 sources, synthesized cited report, depth options.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with sections for use/not-use/depth/advantage, but each sentence earns its place. Slightly verbose but justified by complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given complexity of the tool and no output schema, description fully explains behavior and output (synthesized cited report). No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 75% (3 of 4 params have descriptions). Description adds value by explaining query as alias, depth options with search counts, focus with examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it performs parallel searches, extracts content, and synthesizes a cited report. Distinguishes from sibling tools novada_search and novada_extract.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly describes when to use (complex questions, comparative analysis) and when not (single fact lookup, reading one URL), with alternatives named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, destructiveHint=false, idempotentHint=true. Description adds behavioral details not in annotations: returns raw HTML (not cleaned text), latency 9-16 seconds, unimplemented parameters (wait_ms, block_resources, auto_runs). 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Long but well-structured with sections (best for, tip, not for, common mistakes, when to use). Every sentence adds value, though slightly verbose. Front-loaded with primary purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 9 parameters and no output schema, the description is highly complete: explains return type (raw HTML), use cases, limitations, latency, errors to avoid, alternatives. Covers all critical aspects for agent decision-making.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema coverage is 89%, and description adds valuable context: method parameter clarifies distinction from novada_extract, wait_for explained, max_chars with truncation, unimplemented parameters noted. Provides meaning beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool's purpose: 'Use when you need the raw rendered HTML of a blocked or JS-heavy page.' It specifies the verb (get raw HTML) and resource (blocked/JS-heavy page), and distinguishes from siblings like novada_extract (cleaned text) and novada_scrape (structured data). Clear and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides extensive when-to-use and when-not-to-use guidance: best for raw HTML when novada_extract fails, not for cleaned text (use novada_extract) or structured data (use novada_scrape). Includes common mistakes and alternatives. Explicit and comprehensive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly, non-destructive, idempotent. Description adds key behaviors: parallel execution, partial failure isolation, raw server response fields (balance_mb, remaining_mb, plan_mb), and auth fallback. 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Highly structured with sections, very concise. Every sentence adds value. No filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the schema covers parameters fully, annotations cover safety, and description explains parallel execution, partial failures, and return structure, the description is complete for the tool's moderate complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage 100% with enum on products. Description adds meaning: omitting queries all 6, 'optional subset', and documents typical response fields. Goes beyond schema by explaining behavior of optional parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it provides per-product balance across all 6 Novada flow products in parallel, with a specific verb ('balance') and resource ('products'). It distinguishes from sibling tool 'novada_wallet_balance' for master wallet currency balance.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit 'Best for' (quota check, pre-flight) and 'Not for' (master wallet balance) sections, with direct sibling reference. Also notes partial failures isolation, guiding appropriate use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds context beyond annotations: it explains that the result is only available upon task completion, that a not_ready response is returned for pending tasks, and details the output formats. Annotations already indicate readOnly and idempotent, and the description is consistent with 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with bullet points and clear sections. It is front-loaded with the main purpose, and every sentence adds value without redundancy. It earns its length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with two parameters and no output schema, the description is complete. It explains the prerequisite (novada_scraper_status), the output formats, error handling (not_ready, contact support), and relates to sibling tools. No gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds meaningful context: task_id is linked to novada_scraper_submit, and format options are explained with real-world use cases (human-readable table, structured JSON, raw API response). This goes beyond the schema's simple enum values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the completed result of an async scraping task by task_id. It uses a specific verb ('Retrieve') and resource ('completed result'), and distinguishes from sibling tools like novada_scraper_submit (submit) and novada_scraper_status (check status).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidelines are provided: call novada_scraper_status first to confirm task completion, and note that calling on a pending task returns a not_ready response. It also advises contacting support with the task_id if errors occur. This clearly tells when and when not to use the tool.
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:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/NovadaLabs/novada-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server