momentic

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

With no annotations, the description carries the full burden and does it well: it discloses that text is entity-decoded, that pageLoaded:false means refused/error/challenge, and precisely which fields become null (title, schemaTypes, wordCount) and why. It does not mention authentication needs, rate limits, or redirect behavior, so it is not exhaustive.

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 is front-loaded, but the body is a single sprawling sentence packed with nested parentheticals that is hard to parse in one pass. Almost every clause carries information, yet the structure sacrifices readability for density.

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 and no annotations, the description supplies the return-shape inventory and the null/failure semantics an agent needs, which is substantial for a one-parameter read tool. It stops short of covering rate limits or redirect/timeout behavior, so it is not fully complete.

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% for the single url parameter, so the baseline is 3. The description adds real meaning by qualifying the URL as public and by noting the Accept: text/markdown negotiation behavior, which tells the agent something the schema does not.

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 (fetches) and resource (any public URL) and enumerates the exact on-page SEO signals returned, which strongly separates it from site-level siblings like analyze_site or raw-fetch tools like get_page. It never explicitly names or contrasts with a sibling, so it falls just short of the 5 bar.

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 implied by the purpose (analyze on-page SEO for a given URL), and 'any public URL' hints that it works externally unlike site-scoped tools. However, there is no explicit when-to-use, when-not-to-use, or statement of which sibling to pick for a site-wide versus single-page question.

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?

With no annotations, the description carries the full burden and does so well: it defines the tri-state found value (true / false including HTML catch-all pages / null with checked:false for blocked, erroring, or timed-out requests treated as unknown). It also discloses internal behavior such as RFC 9309 parsing, sitemap index following, gzip reads, and what aiBotStatus vs aiBotDisallows mean.

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 opening clause is well front-loaded, and semicolons separate concerns, but the body is a single dense semicolon chain including a long bot list that burdens parsing. Much of it is useful spec detail rather than filler, yet it is not economically expressed.

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?

For a complex multi-endpoint probe with no output schema and no annotations, the description is largely complete: it names every checked resource and defines the result semantics needed to interpret them. The missing piece is selection guidance relative to sibling tools.

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?

Only one parameter, whose schema description coverage is 100% and already documents that a root domain or full URL is accepted. The description reinforces 'domain root' probing but adds no syntax or format meaning beyond the schema, so the 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 ('Probes') and resource ('a domain root') and enumerates exactly the artifacts inspected (llms.txt, robots.txt, sitemap, well-known files, Link header), so the scope is unmistakable. It does not explicitly distinguish itself from siblings like analyze_page or check_bots, which is the main clarity gap.

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?

No statement of when to call this versus siblings (analyze_page, check_bots) and no prerequisites or exclusions. The parentheticals explain how to read outputs rather than when to invoke the tool, so selection guidance is left to inference.

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?

With no annotations, the description carries the full burden and discloses key behavior: cached questions return immediately, new questions take about 30 seconds, and an in-progress answer should be retried after roughly 30 seconds. It also explains that answers are AI-written from momenticmarketing.com pages with sources, though it does not explicitly state read-only safety or rate limits.

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

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

The description is front-loaded with purpose and scope, and the latency/retry guidance earns its place. It is slightly wordy in restating the source pages, but overall efficient for a tool with no annotations.

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?

For a simple one-parameter tool with no output schema, the description covers purpose, topic scope, return content, source attribution, latency, and retry behavior. Nothing essential for correct invocation 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 description coverage is 100%, so the single question parameter is already documented. The description adds no syntax or format details beyond what the schema provides; 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?

It states a specific verb and resource — asking a question and returning an AI-written answer with sources — and clearly scopes it to Momentic and SEO/AI search topics. That scope distinguishes it from sibling tools like search, get_page, and analyze_site.

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 gives clear when-to-use context by listing topic areas (services, Atlas, team, case studies, pricing, AI chatbot market share, AI Overviews, llms.txt, AI crawlers, query fan out). It does not explicitly name when not to use it or compare against sibling tools, but the intended context is clear.

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?

With no annotations, the description carries the full burden and does so thoroughly: it enumerates all verdict values (blocked-403, challenged-by-cdn, inconclusive-not-bot-specific, etc.), explains that summary.blocked counts only bot-specific blocks while timeouts/errors are counted separately, and discloses the important caveat that requests originate from Cloudflare's network rather than the bot operators' IPs.

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 core action is front-loaded in the first clause, and the long verdict enumeration is justified because no output schema exists and the agent needs it to interpret results. The final robots.txt-token sentence is slightly redundant with the schema but reinforces an important exclusion, so it still 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 and no annotations, the description supplies everything an agent needs: what is fetched, what the response contains (per-bot status, WAF/CDN headers, verdict), how the summary is counted, and the network-origin caveat. Nothing material is missing for correct invocation or interpretation.

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: it names the default UA set that userAgents falls back to and reiterates that robots.txt-only tokens are excluded. It adds little on url or timeoutMs beyond the schema, keeping it short of 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 (probes) and resource (a URL with AI crawler user agents) plus the exact scope: per-bot reachability with a Chrome baseline. It is clearly distinguishable from siblings like analyze_page, get_page, and analyze_site, which are content/audit tools rather than WAF-layer bot reachability probes.

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 clear context for when this tool is appropriate ('Reveals WAF/CDN-layer blocks that robots.txt audits miss') and clarifies what is out of scope (robots.txt tokens like Google-Extended are not probed). It does not, however, explicitly contrast itself with any named sibling or state when NOT to use it.

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

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

Description discloses behavior: pure computation, URL normalization defaults, and O(N^2) complexity for findMentions. However, no annotations are provided, and the description does not mention error handling, rate limits, or authentication requirements.

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 description is informative but verbose (over 100 words). It is front-loaded with the main purpose but could be more structured (e.g., bullet points) to improve readability. Still, every sentence adds value.

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?

Given the absence of an output schema, the description adequately lists the return types. However, it lacks information about error scenarios, input size limits, and authorization requirements. For a complex tool with nested objects, more completeness would be beneficial.

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?

The description adds significant value beyond the schema by specifying the exact input structure (e.g., 'url, internalLinks: [{href, anchor}], title?, bodyText?') and explaining the effects of options like hubCount, findMentions with performance note, and normalizeUrls. Schema description coverage is 50%, but the description compensates well.

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 clearly states the tool performs pure graph computation over a crawled page set, listing specific outputs like orphan pages, hubs, authorities, PageRank-lite, etc. It distinguishes from sibling tools by its focus on multi-page link graph analysis.

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?

No explicit guidance on when to use this tool versus alternatives like analyze_page or search. The description implies it's for link graph analysis but does not provide when-to-use or when-not-to-use instructions.

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?

No annotations exist, so the description fully carries the burden. It declares the tool is a 'Pure HTML parser' (no side effects), details exactly which href types are skipped, and describes the output structure. All behavioral traits are disclosed, making the tool's behavior predictable.

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 description is moderately concise and front-loaded with the key phrase 'Pure HTML parser.' Every sentence provides specific information, though it could be slightly shorter without losing clarity. Structure is logical.

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?

Given the tool's simplicity, the description explains the output thoroughly (fields returned, internal vs external, skipped links) and links to its intended downstream use (compute_link_graph). No output schema exists, but the description compensates fully.

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%, with both parameters well-described in the schema. The description adds minimal extra meaning for parameters beyond what the schema provides (e.g., baseUrl used for resolution). Baseline of 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?

The description uses a specific verb ('extract') and clearly defines the resource (links from HTML). It explicitly states the output format (absolute, internal vs external, cleaned anchor text, rel, nofollow) and what is skipped (fragments, mailto:, etc.). This distinguishes it from siblings like compute_link_graph, which consumes its output.

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?

The description explains that it is designed to feed compute_link_graph and that it should be called per page crawled from the user's machine. This gives clear context for when to use it, though it does not explicitly list scenarios where it should not be used (e.g., if no raw HTML is available).

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?

No annotations are provided, so the description bears the full burden. It does not disclose behavioral traits beyond the purpose, such as read-only nature, caching, or rate limits. For a simple data retrieval with no parameters, this is adequate but not thorough.

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 description is two sentences long, front-loaded with the primary function, and contains no superfluous words. Every sentence 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?

Given no output schema, the description does not detail the return format. However, it suffices for a simple tool returning a canonical description. It could mention the format (e.g., plain text), but the use cases are well-covered.

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?

There are no parameters, and schema description coverage is 100%. The description adds no parameter info, but none is needed, so the baseline of 4 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?

The description clearly states the tool returns the canonical AI-readable description of Momentic from /llms.txt, specifying the resource and its use for brand info, positioning, services, and contact. It distinguishes from sibling tools like analyze_page or search.

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?

The description indicates when to use the tool ('for authoritative brand info...'), but does not explicitly mention when not to use it or provide alternatives. However, the context signals and sibling tools make it sufficiently clear.

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?

With no annotations, the description should disclose behavioral traits; it mentions 'uses Cloudflare's Markdown for Agents' but omits details on auth, error handling, rate limits, or whether the operation is read-only.

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?

Two sentences, front-loaded with the core function and usage, no unnecessary words or redundancy.

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?

For a simple tool with one required parameter and no output schema, the description covers the basic purpose and parameter usage, but lacks details on return format beyond Markdown, error cases, or behavioral guarantees.

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% with a single parameter described. The description reinforces the schema's explanation and adds concrete examples ('/team/jane-doe'), but does not provide significant additional meaning 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?

The description clearly states the tool fetches a Momentic page as Markdown, specifies the verb ('Fetches'), resource ('Momentic page'), and output format, and distinguishes from siblings like analyze_page by focusing on raw content retrieval.

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?

The description provides clear instructions on parameter format ('absolute path like "/team/jane-doe" or a full URL'), but does not explicitly state when to use this tool versus alternatives like analyze_page or search.

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?

Without annotations, the description discloses the data source (sitemap.xml) and filtering. However, it omits details like return format, pagination, rate limits, or authentication 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?

Two sentences: first states purpose and source, second explains optional parameter. No redundant words, front-loaded.

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?

For a simple list tool with one optional param and no output schema, the description covers the core functionality and usage. Minor gap: no mention of output structure (e.g., list of URLs).

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?

Single parameter with 100% schema coverage. Description adds example values and clarifies default behavior (omit to list all), complementing the schema's generic description.

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?

Clearly states it lists pages from a specific sitemap URL, with optional section filter. Distinguishes from siblings like get_page (single page) and search (cross-site search).

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?

Explains optional section filter and default behavior (list all). Does not explicitly state when not to use or list alternatives, but the context is clear enough for an agent.

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?

No annotations are provided, so the description carries full burden. It discloses that the tool uses free APIs with no authentication, and explains behavior like returning alternativeMatches when a name search yields multiple candidates. It does not mention rate limits or caching, but for a read-only lookup, these are less critical.

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 description is fairly long but every sentence adds value. It is front-loaded with the main purpose and method of use. Minor trimming could be possible, but overall it is efficient for the amount of information conveyed.

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?

Given that there is no output schema, the description thoroughly explains the return values including qid, label, description, instanceOf, sameAs, sitelinks, Wikipedia summary, sections, and alternativeMatches. It also covers all four parameters and provides use cases. The tool is fully specified for an AI agent to invoke 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%, but the description adds value beyond the schema by explaining how the 'name' parameter resolves to the top match and returns alternatives, and describes the effect of skipWikipedia. This provides deeper meaning for parameter usage.

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 clearly states it resolves a brand/topic/person to a structured entity record built from Wikidata and Wikipedia. It lists the three ways to call it (name, qid, wikipediaTitle) and details the return fields. This distinguishes it from sibling tools like analyze_page or get_brand_overview.

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?

The description explicitly states to pass exactly one of name, qid, or wikipediaTitle. It also provides context for when to use the tool (entity-graph alignment checks, content briefs). However, it does not explicitly mention when not to use this tool or suggest alternatives, which would be helpful.

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?

No annotations are provided, so the description bears full responsibility. It fully discloses that the tool is a parser that does not fetch, lists all markers it extracts, and describes what it returns (per-source ISO dates, freshest source, cross-source spread, heuristic flags). This leaves no ambiguity about its behavior.

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 description is a single paragraph but packs significant information efficiently. It front-loads 'Pure parser (no fetching)' as the key caveat. Every sentence adds value; however, it could be broken into smaller sections for readability.

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?

Given the tool's complexity (four parameters including nested objects, no output schema), the description is remarkably complete. It explains the purpose of each parameter, enumerates all extracted markers, and describes the return value components (per-source dates, freshest source, spread, heuristic flags). It also ties the tool to a specific usage context (geo-aeo-readiness skill).

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% with descriptions for all four parameters. The tool description adds context beyond the schema: url is 'for context', headers are expected with 'lowercased keys', and sitemapEntry is a 'parsed sitemap entry'. It does not fully detail the structure of the output object but compensates by listing return fields in free text.

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 clearly states it is a 'pure parser (no fetching)' and enumerates exactly which freshness markers it extracts (HTTP Last-Modified, sitemap lastmod, JSON-LD dates, etc.). It identifies the tool's resource (freshness markers in HTML) and distinguishes it from sibling tools like 'get_page' (which fetches) by emphasizing it does not fetch.

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?

The description specifies the tool is for extracting freshness signals and notes its use in the 'geo-aeo-readiness skill's freshness check'. It implies when to use (when you need to parse freshness markers from already-fetched HTML) but does not explicitly state when not to use it or provide direct comparisons to alternatives among the 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?

With no annotations, the description carries the full burden and does well: it discloses the result cap (up to 10), relevance ranking, the newest-first ordering rule and its trigger words, the tracker-specific sort by Google announcement date, the per-result fields, and the important index-coverage caveat that pages published after Webflow's sitemap rebuild are included. It omits failure/empty-result behavior and whether queries are free-text or fielded, which keeps it short of 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?

Front-loads the core purpose, then ordering behavior and the get_page handoff. The long parenthetical inventory of content types is dense but earns its place by defining the index scope; the sentence could still be trimmed without loss.

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, so the description must describe returns — and it does, listing URL, title, content type, published date, author and best-matching passage. Combined with ordering rules, result limits, and the get_page escape hatch, 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%, so a 3 is the floor; the description goes beyond it by explaining that `recent` is implied by words like latest/newest/most recent, that tracker pages sort by Google's announcement date, and that `format=json` returns structured fields including tracker status/announced/started/completed/kind. The `type` enum values are already fully documented in the schema, so the marginal gain is modest rather than maximal.

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+resource ('Full-text search across every page on momenticmarketing.com') and enumerates the indexed content types, so the agent knows exactly what corpus is covered. It also differentiates itself from the sibling get_page by routing the agent there for full-page reads.

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 clear context (search when you need ranked, passage-level matches across the site) and names the follow-up alternative ('Read a full page with get_page'). It does not, however, address when to prefer list_pages or lookup_entity over search, so exclusions are incomplete.

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