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

Annotations already declare readOnly, idempotent, non-destructive, and openWorld, so the safety profile is covered. The description adds real value beyond that by disclosing the mechanism (a single HTTP HEAD request, not a full page fetch), the reported metrics, and the exact response object. Minor ambiguity remains between 'the RaivatEdu website' and 'a market home page', and failure behavior (e.g., what status is returned when unreachable) is unspecified.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the core purpose, then usage guidance, then args and return shape — a sensible ordering. The Args block largely duplicates the schema, which is mild redundancy, but the sentence count stays tight.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema present, the description correctly supplies the JSON return shape, including reachable/status/url/response_time_ms/checked_at, which the agent needs to interpret results. It is nearly complete; only error/unreachable semantics and pagination-irrelevant edge cases are left unstated.

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

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

Schema description coverage is 100% and both parameters are enums with documented defaults, so the schema does the heavy lifting. The Args section restates the market enum and the default-configuration behavior without adding syntax or edge-case meaning beyond what the schema already says. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb ('Check whether ... is reachable and how fast it responds') with the exact target URL, and the HEAD-request detail pins down the mechanism. This is clearly distinguishable from siblings like raivatedu_get_website_info or raivatedu_get_page_content, which fetch content rather than probe liveness.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly gives use contexts: 'confirm the site is up before running other tools, or to diagnose failures.' That is actionable guidance an agent can act on. It stops short of naming an explicit alternative or a when-not condition, so it is not a 5.

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

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

Annotations already declare readOnlyHint/idempotentHint/destructiveHint=false, so the safety profile is covered; the description adds real value by disclosing the data provenance (Organization JSON-LD contact points) and reiterating that no messages are sent. It does not discuss caching, freshness, or failure behavior when a contact point is absent, keeping it below a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose and the key negative constraint are front-loaded in the first two sentences, with details following in a scannable Args/Returns layout. The Returns JSON block is somewhat verbose but compensates for the absence of an output schema, so it largely earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description supplies the full return shape including nullable fields, and the only two parameters are fully documented. A caller has everything needed to invoke it correctly and interpret the response.

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

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

Schema description coverage is 100% and both parameters already carry enum lists and default explanations in the schema. The description restates the market options and the response_format default without adding syntax or semantics beyond the structured fields, so baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Retrieve RaivatEdu's publicly listed contact details') and enumerates exactly what is returned (sales, support, security emails plus contact/demo URLs). This is clearly distinguishable from siblings like get_website_info or list_pages without opening either schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives a clear context for use (reading published contact data) and an explicit when-not ('does NOT submit forms or send messages'), which prevents a plausible misuse. It does not name a sibling alternative for related lookups such as get_website_info, so it falls short of a 5.

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

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

Annotations already declare readOnly/idempotent/non-destructive, and the description adds substantive behavior beyond them: the whitelist enforcement, robots.txt blocking of /api/ paths, text truncation, and the specific error strings with the recommended recovery call. That is exactly the kind of constraint an agent needs before invoking.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Well front-loaded: purpose, constraint, return contents, then parameters and errors in a predictable order. Slightly over-long because the Args block duplicates a schema that already has 100% description coverage, but the return-shape and error sections earn their space given there is no output schema.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema available, the description supplies the full JSON return shape (url, title, headings, text, faqs, links) and documents the failure modes. For a read-only fetch tool with four parameters and enum output, nothing an agent needs to call it correctly is missing.

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

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

Schema coverage is 100%, so the Args block is largely restatement under the baseline-3 rule. It does add real meaning in one place: distinguishing response_format 'markdown' as a human-readable summary versus 'json' as the full structured object, which clarifies the semantic difference the enum alone doesn't convey.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb pair and resource: 'Fetch and summarize the text of a specific public RaivatEdu page,' and immediately narrows scope to known public pages. This distinguishes it from raivatedu_search_content (query-based) and raivatedu_list_pages (discovery), so an agent can route correctly without opening any schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It states the selection rule explicitly ('the page MUST be one of the known public pages'), names the discovery alternative (raivatedu_list_pages), and gives concrete exclusions (arbitrary/external URLs refused, /api/ blocked by robots.txt). The only minor omission is not naming raivatedu_search_content as the alternative for keyword lookup, but the when/when-not framing is otherwise complete.

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

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

Annotations already declare readOnly/idempotent/non-destructive/openWorld, so the safety profile is covered. The description goes further by disclosing provenance (schema.org Offers in the /pricing page JSON-LD), that amounts are numeric rather than pre-formatted, that each market prices in local currency, and that Enterprise is open-ended or sales-quoted. It stops short of saying anything about freshness/caching or failure modes when a market lacks a pricing page.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Well front-loaded: purpose first, then source, then args, then return shape, then caveats. It is somewhat longer than needed because the enum list for market and the response_format explanation duplicate schema content that is already at 100% coverage.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema, yet the description supplies the complete JSON return shape including field names, optionality (minUsers/maxUsers/url) and type expectations (price as number). Combined with the numeric-amount and open-ended-Enterprise notes, an agent has everything needed to call and consume the result.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning: the market parameter determines the currency and the plan set ('Each market prices in its local currency'), with a concrete example (India: Starter/Professional/Enterprise in INR). The response_format description largely restates the schema enum, so it is not uniformly additive.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource: 'Retrieve RaivatEdu's subscription plans and prices for a given market.' This is clearly distinct from the sibling listing tools (list_features, list_solutions, list_resources, get_page_content) — none of them return pricing, so an agent can route here without ambiguity.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It establishes the selection context (price a specific market, with the configured market as the fallback) and explains where the data comes from, which tells the agent this is the authoritative pricing source rather than a generic page fetch. It does not state any when-not conditions or name an alternative for, say, sales-quoted enterprise pricing beyond a brief note.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so safety is covered; the description earns credit on top by disclosing provenance — data comes from schema.org JSON-LD (Organization + SoftwareApplication + WebSite) embedded in the site and reflects published copy rather than assumptions. It does not cover failure modes for an openWorld fetch (site unreachable, missing JSON-LD), which is the main remaining gap.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose sentence is front-loaded and the document is organized into purpose, provenance, args, and returns, so a scanning agent finds what it needs quickly. The Args block is largely redundant with a fully documented schema, costing some density, though the Returns shape earns its space since no output schema exists.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, spelling out the returned JSON shape (product, organization, markets, source_url) is the right compensation and makes the tool's output predictable. What remains unaddressed is error behavior on a live-site fetch and whether a market override changes source_url — small but real gaps for an openWorld read.

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

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

Schema description coverage is 100% and both parameters carry enums and defaults, so the schema already does the work. The description's Args section repeats the same locale list and defaults without adding syntax, interaction effects, or guidance on choosing a market, so baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb ('Return') and a precisely enumerated resource: product identity, the organization behind it, and the markets/currencies served. That enumeration implicitly carves out scope against siblings such as get_pricing, list_features, and get_contact_information, so an agent can pick this for the overview call without opening another schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is only implied: the 'high-level information' framing suggests this is the orientation call to make first, but there is no explicit statement of when to prefer it over get_contact_information or get_pricing, and no stated prerequisites or exclusions. An agent can infer intent but is not routed.

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

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

Annotations already cover safety (readOnly, idempotent, non-destructive), so the description's added value is the cost disclosure that include_descriptions triggers per-page live fetches, plus the full return shape. That is genuine behavioral context beyond the structured fields, though it doesn't address failure behavior when a page fetch fails.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the one-line purpose and the fixed-section list, then Args and Returns in scannable blocks. No sentence is filler; even the parenthetical enumeration of the nine areas earns its place by setting agent expectations for the count.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema, and the description compensates by documenting the exact JSON shape including the optional description field. Combined with param semantics, sibling routing, and the fixed nine-item scope, an agent has everything needed to call and interpret this correctly.

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

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

Schema description coverage is 100%, so all three parameters are already fully documented with enums and defaults. The description largely restates the schema ("market (optional): locale for the URLs", "include_descriptions (boolean)") with only marginal added meaning about what the locale affects.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ("List the product feature areas RaivatEdu documents"), then enumerates all nine sections so the agent knows exactly what the result set contains. Calling them "fixed site sections" differentiates this from the generic page/solution/resource listing siblings without opening their schemas.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly routes the agent onward: "Use raivatedu_get_page_content on a returned URL for the full write-up of a feature," which tells it this is an index tool, not a content-retrieval tool. It stops short of naming when-not-to-use or contrasting with raivatedu_list_pages / list_solutions / list_resources.

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

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

Annotations already declare readOnly, idempotent, non-destructive, so the safety profile is covered. The description adds genuine behavioral context beyond that: the set is 'verified' and 'derived from the site's sitemap,' it enumerates the page categories actually returned, and it documents the response_format tradeoff (human-readable summary vs. full structured object).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with purpose, then the category inventory, then Args, then return shape — a logical order with no filler sentences. The long enumeration of pages (home, pricing, enterprise, features...) is somewhat redundant with the documented return shape, but it does set agent expectations cheaply.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema exists, yet the description supplies the exact JSON shape ({market, count, pages:[{path,url,type,market}]}) and the markdown-vs-json behavior, plus zero required parameters and the default market are all clear. An agent can call this correctly and chain into raivatedu_get_page_content without further probing.

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

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

Schema coverage is 100%, so the schema already documents all three params including enums, defaults, and the 'configured market' fallback. The Args block in the description largely restates the schema, with only the example type values ('feature', 'solution', 'resource-article') adding marginal illustration that the schema also includes. Baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('List the public pages available on RaivatEdu for a market') and frames the result as a 'navigation map of the site,' which distinguishes it from content-fetching siblings. It also names the natural follow-up tool, raivatedu_get_page_content, making the boundary between listing and retrieval explicit.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Clear about context of use: this is the entry point for discovering paths, and 'Feed any returned path to raivatedu_get_page_content' gives explicit next-step routing. It stops short of exclusions — it never says whether to prefer raivatedu_list_features or raivatedu_list_solutions when only one category is wanted, despite those siblings existing.

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

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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint, so the safety profile is covered. The description's one real behavioral disclosure is that include_descriptions triggers live per-item fetching and is slower — but that is already spelled out in the schema. Nothing is said about failure modes or what happens for a market with no articles.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Well front-loaded: the purpose and the follow-up tool come first, then Args, then Returns. The Args section largely duplicates a fully-covered schema, so it costs a few lines that do not earn their place, but the overall structure is scannable and not padded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema, and the description compensates by giving the exact JSON return shape (market, landing_pages, count, articles with optional description), which is what an agent needs to plan a follow-up call. It does not mention pagination or whether the article list is complete, but for a small static catalogue that is a minor gap.

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

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

Schema description coverage is 100% and all three parameters are fully documented with enums and defaults, so the baseline is 3. The description's Args block restates the same defaults (market falls back to the configured market, include_descriptions default false) without adding syntax or constraint detail beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource (list RaivatEdu's publicly available educational resource articles) and enumerates the two things returned: article catalogue plus the resources/blog/guides/help landing pages. It distinguishes itself from the retrieval sibling by naming raivatedu_get_page_content as the way to read article bodies.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly gives the follow-up route: "Use raivatedu_get_page_content on a URL to read the full article text," which makes the list-then-fetch pattern unambiguous. It does not, however, contrast with raivatedu_list_pages or raivatedu_search_content, so the agent must infer when this catalogue listing beats those siblings.

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

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

Annotations already declare readOnly, idempotent, non-destructive, open-world. The description adds non-obvious cost information: include_descriptions triggers one live HTTP request per item and is slower, versus returning only verified labels and URLs by default. It could say more about failure behavior when a live fetch fails, but the cost disclosure is genuinely useful.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with purpose, then segment enumeration, then the follow-up tool, then params and return shape. The Args and Returns sections duplicate structured data, which is mild waste, but the overall ordering and length remain easy to scan.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema present, the description supplies the exact JSON return shape including field names and the optional description field. Combined with the segment list and follow-up routing, an agent has everything needed to call and consume this tool correctly.

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

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

Schema coverage is 100% and the enumerated market values, defaults, and format options are already documented in the schema. The description's Args block largely restates them ('defaults to the configured market', 'default false', 'default markdown') without adding new semantics such as URL pattern per market. Baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('List the audience/solution segments RaivatEdu targets') and immediately enumerates the four segments, so the agent knows exactly what comes back. This is clearly differentiated from sibling listing tools like list_pages and list_features by naming the resource domain (audience segments).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly routes the agent forward: use raivatedu_get_page_content on a returned URL for segment-specific pitch content, and explains when to set include_descriptions (only when summaries are needed). It does not state when to prefer raivatedu_list_pages instead for general page discovery, so it falls short of full when/when-not guidance.

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

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

Annotations already declare read-only/idempotent/non-destructive, and the description adds substantial beyond that: no public search API exists, it is a client-side fetch over ~28 curated pages rather than a full crawl, and no-match returns an empty array instead of an error. These are exactly the operational caveats an agent needs.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with purpose and mechanism, then args, returns and notes in a scannable order. The args section largely restates the schema, which is mild redundancy, but the returns block earns its space since there is no output schema.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description supplies the full return shape, including score and snippet fields, plus the empty-results behavior and the bounded crawl scope. Nothing an agent needs to call and interpret this tool is missing.

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

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

Schema coverage is 100%, so the baseline is 3; the description adds a genuinely new semantic detail in that words are matched case-insensitively and the search spans title, headings, description and body. The remaining arg listings duplicate the schema, so it does not earn a 5.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Search the public RaivatEdu website') plus what is returned ('most relevant pages with matching snippets'). It also distinguishes itself from raivatedu_get_page_content by framing this as the discovery step before drilling in.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly names the use case ('where does the site talk about X?') and names the follow-up tool raivatedu_get_page_content, so an agent knows both when to use it and what to do next. The alternative for full page text is effectively routed to the sibling.

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