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 declares the examination is non-invasive, honors robots.txt, blocks SSRF targets (localhost, private nets, metadata), and enforces timeouts and page-size caps. What it still omits is the read-only guarantee stated outright and any rate-limit or failure-mode behavior for unreachable sites.

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 one-line summary is front-loaded, then grouped bullets for scope, a security block, and an Args block. The bulleted inventory is longer than strictly necessary but each item maps to real work the tool performs, so little is wasted.

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 two-parameter read audit with an output schema present, the description covers scope, safety posture, and both inputs. The return value is legitimately left to the output schema, so the only shortfall is the absent routing guidance against overlapping siblings.

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 0%, so the description must compensate and largely does: the Args block gives a URL format example and explains that check_broken_links spot-checks up to 10 internal links. The 'up to 10' cap is genuine added meaning beyond the schema's bare boolean; only minor gaps (URL normalization, scheme handling) remain.

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 first line gives a concrete verb and resource ('Analyze a business website') followed by an enumerated scope (SSL, meta, headings, contacts, socials, broken links). It is clear what the tool does, but it never distinguishes itself from the overlapping sibling check_seo or find_social_profiles, which a reader could otherwise confuse with this sweep.

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 — an agent can infer this is the pre-outreach technical audit step, but there is no explicit when-to-use statement, no prerequisites, and no pointer to alternatives like check_seo when only SEO data is needed. The default-on broken-link check is the only decision guidance offered.

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 enumerates every signal checked, discloses the 0-100 scoring plus prioritized errors/warnings/info, and sets an explicit expectation about what the score is not. It omits operational traits an agent would want — that it fetches the live page, how long it takes, and whether results are cached or rate-limited.

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 and the bulleted checklist is scannable and well organized. There is redundancy between the 'Output' bullet list and the 'Returns' line ('Structured SEO audit report'), and the Args/Returns sections are stock docstring boilerplate that the schema already provides.

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 single-parameter diagnostic tool with an output schema, the description supplies everything essential: what is evaluated, what the score means, what the report contains, and the key limitation. Only minor operational details are absent, and the output schema covers return-value structure.

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 0% on the single url parameter, so the description must compensate; it adds a format hint via the example 'https://example.com' and the phrase 'target website URL'. It says nothing about whether scheme, trailing paths, subdomains, or non-resolving URLs are accepted, so the semantics are only partially filled in.

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 opening line states a specific verb and resource ('Run a technical on-page SEO audit on a business website') and the nine-item checklist pins down the scope precisely. It never names the sibling analyze_website or explains how this differs from it, so the agent must infer the boundary between a general website analysis and this SEO-specific audit.

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 'Notice' clarifies a when-not ('not an official Google ranking assessment or proprietary PageRank score'), which prevents misuse as a ranking predictor. However, there is no explicit guidance on when to pick this over analyze_website or other siblings, and no stated prerequisites such as whether the site must be publicly reachable or HTML-based.

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 disclose the analysis dimensions and delivered artifacts (strengths, weaknesses, opportunities, positioning summary). It omits operational traits an agent would want: whether it performs live crawling, expected latency or cost, and any limits on competitor count.

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 bulleted dimension list is front-loaded and earns its space, but the Outputs block duplicates a return value already covered by the output schema, and the Args section restates what the schema requires. Some trimming would sharpen it.

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 two-parameter nested-object tool with an output schema, the description gives enough on inputs and analytical scope to call it correctly. What is missing is practical guidance on how many competitors to pass and what depth of object fields are expected.

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 0% and the schema is a bare object with additionalProperties, so the description's note that target_business must include 'name' with optional 'website', 'category', 'city' is genuinely load-bearing. Competitor dict fields are left unspecified, presumably assumed to match the target shape.

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 first sentence states a specific verb and resource: benchmarking a target business against a list of competitors. The enumerated dimensions make the scope unambiguous, though it never explicitly distinguishes itself from siblings like find_competitors or score_lead.

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?

There is no statement of when to use this versus find_competitors, score_lead, or generate_business_report, and no preconditions (e.g. that competitors must already be identified). Usage is only inferable from the name and the word 'benchmark'.

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 supplied, so the description carries the full behavioral burden. It does disclose the return dict keys (output_path, row_count, format, attribution) and what each format physically produces, but it never states where files land when output_path is omitted, whether existing files are overwritten, or that this tool writes to disk at all.

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 sentence is front-loaded and the format bullets are genuinely informative about output differences. The Args block duplicates schema field names, but each entry adds at least one detail (ranges, aliases), so little of it is pure repetition.

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 six-parameter tool with no annotations and no output schema, the definition covers purpose, all parameters, and the shape of the return value. What is missing is side-effect detail — default write location and overwrite behavior — which matters for a tool that produces files.

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 0%, so the description must compensate, and it largely does: every one of the six parameters is explained, the 1-200 limit range and default 50 are added beyond the bare schema, and the 'excel'/'xlsx' alias plus default 'csv' are clarified. Remaining gap is output_path, described only as 'optional' with no default-location or overwrite semantics.

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 states a specific pair of actions (search businesses, export results) and the concrete artifact produced (xlsx/csv/json file), which an agent can grasp immediately. It does not explicitly distinguish itself from the sibling search_businesses, leaving the boundary between 'search and view' and 'search and export' implicit.

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 word 'export' and the format list, so an agent can infer this is the tool for producing files. However, there is no explicit when-to-use statement, no mention that search_businesses should be preferred for interactive lookups, and no guidance on choosing between formats beyond a one-word gloss.

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 supplied, the description carries the full burden and discloses real behavior: the discovery sources, the exclusion of directories/social/aggregators to isolate a primary domain, and the discovery_method field that tells the caller how the result was obtained. It omits failure/ambiguity handling (e.g., multiple candidate domains) and any latency or rate-limit expectations, 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?

The opening sentence is front-loaded with the purpose, followed by mechanism, then structured Args/Returns blocks. The parameter listing duplicates the schema's property names, but given 0% schema coverage that repetition is functional rather than wasteful.

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 Returns block is genuinely necessary and covers each returned field including the nullable website and the discovery_method enum-like values. What is missing is guidance on the disambiguation path (what happens on multiple or zero matches) and parameter precedence, given a modest 3-parameter tool.

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 0%, so the description must compensate, and it does: all three parameters are documented with concrete examples ('Blue Bottle Coffee', 'San Francisco', 'osm_node_123'). It does not explain how business_id interacts with business_name or whether one takes precedence, nor how location constrains the search.

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 states a specific verb and resource ('Find and verify the official website of a business') and sharpens the scope by explaining that directories, social links, and aggregators are filtered out. That filtering detail alone makes it distinguishable from sibling tools like find_social_profiles and analyze_website.

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?

There is some useful context (it uses local knowledge providers plus free web search, so no paid API key is required), which implies it is the cheap first step before analyze_website. However, it never explicitly says when to prefer this over its siblings, when not to use it, or what to do if the name is ambiguous.

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 supplied, the description carries the full load and does so reasonably: it discloses the data source (OpenStreetMap), the ODbL attribution obligation, that no paid API keys are needed, that geographically proximate but unrelated businesses are filtered out, and that confidence levels are reported. It leaves gaps around cost/latency (enrich_websites implied to perform live website tests), behavior when the business is not found, and that it is a read-only operation.

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 a good one-line summary, but it then reverts to a docstring with a Features bullet list, an Args block and a Returns line, and several bullets (websites, contact info, ratings) restate what the Args section already conveys. Structure is legible but padded relative to the information gained.

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?

An output schema exists and the description defers to it appropriately ("Structured competitor research report"), so the main burden is inputs and behavior, both covered across 8 parameters. What is missing is minor but real: how city/state/country combine for geocoding, and whether business_category materially improves direct-vs-indirect matching.

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 0%, so the description must compensate and largely does: every one of the 8 parameters is addressed with meaning or an example, including the 1-20 range and default of max_competitors, which is not encoded anywhere in the schema, and the effect of enrich_websites (tests competitor sites for availability and digital channels). Examples are given for business_name, business_category, city, state and country.

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?

Opens with a specific verb+resource pair ("Discover and analyze competitors of a target business") and then narrows it further by explaining direct vs indirect competitor logic and the OpenStreetMap/taxonomy basis. Sibling tools like search_businesses and compare_businesses are never named, so an agent must infer the boundary itself, which keeps it short of a 5.

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 description explains what the tool produces and gives argument examples, so an agent can guess this is the discovery step before compare_businesses or score_lead. There is no explicit when-to-use / when-not-to-use statement, no mention of what must already exist (e.g. a known business_name), and no routing to alternatives.

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 supplied, the description carries the full behavioral burden and discloses meaningful traits: SSRF prevention, robots.txt compliance, filtering of share widgets and intent links, and scope limited to public B2B/official brand profiles. It stops short of covering rate limits, timeout behavior, or failure modes.

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 the core purpose and uses short bulleted lists for platforms and security behavior. The Args and Returns sections are somewhat redundant given the input schema and output schema, but the overall structure remains 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?

For a one-parameter extraction tool, the description supplies purpose, platform coverage, filtering behavior, security constraints, and the URL argument example. An output schema exists, so return-value details need not be extensive, and the description is complete enough to call the 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 description coverage is 0%, so the description must compensate for the single url parameter. It does so by defining url as the business website URL and giving an example like 'https://acme.example', adding useful meaning beyond the bare 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 a specific verb and resource: extracting verified official social media profiles from a business website, with an explicit list of platforms. It distinguishes the task from generic website analysis by focusing on social profile discovery, though it does not explicitly contrast itself with sibling tools like analyze_website.

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 stated goal of discovering social profiles on a business site. However, there is no explicit when-to-use guidance, no exclusions, and no routing to alternatives such as analyze_website or find_business_website.

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 substantial work: it discloses the local Ollama endpoint (http://localhost:11434), that no cloud AI calls or tokens are used, that output is grounded and will not invent revenue or purchasing intent, and that a missing Ollama returns a clean error rather than crashing. What is missing is latency/throughput expectations and determinism, both material for an LLM-backed tool an agent may chain.

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 sentence and safeguards are front-loaded and earn their place, but the output bullet list overlaps the Returns line and the Args block restates the schema's parameter names. Some phrasing is redundant ('Zero cloud AI calls or tokens used' says the same thing twice). Docstring boilerplate ('Args:', 'Returns:') leaks into the agent-facing text.

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?

An output schema exists, so the brief Returns line is proportionate. For a nine-parameter generative tool with zero annotation coverage, the description covers privacy posture, evidence grounding, and failure behavior, which is most of what an agent needs. The remaining gap is workflow ordering relative to the sibling analysis tools and expected runtime.

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 0% and all nine parameters are bare typed objects, so the description is the only source of meaning. Its Args block supplies provenance for each optional payload ('Results from compare_businesses tool') and marks required vs optional, plus the model default. It does not describe the internal shape of the evidence objects, so the agent must know what those sibling tools return.

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 states a specific verb and resource: generating evidence-based strategic business insights via local Ollama, and enumerates the concrete outputs (executive summary, SEO opportunities, lead score interpretation, recommendations). It clearly implies synthesis across the audit tools rather than outreach or reporting. It stops short of naming the closest siblings (generate_business_report, generate_outreach), so an agent must infer the boundary.

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: each optional argument is annotated as 'Results from analyze_website tool', 'Results from check_seo tool', etc., which sketches a pipeline order without stating it. There is no explicit when-to-use vs generate_business_report or generate_outreach, and no when-not guidance. The one operational exclusion present is the Ollama-not-running case, which is a failure mode rather than a selection rule.

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 supplied, the description carries the full burden and does well: it discloses offline operation without AI or paid APIs, supported output formats, and ODbL attribution handling. Gaps remain on whether the tool is purely computational (no side effects) and how missing optional inputs affect the rendered sections.

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 with purpose first, then capabilities, then Args. The 12-item section list is long but earns its place by telling the agent what data to gather; the Features list is slightly padded but short.

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?

A complex 8-parameter aggregator, yet the description covers inputs, formats, offline behavior, and attributions; an output schema exists so return values need only minimal mention. The main omission is guidance on graceful degradation when optional inputs are absent.

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 0%, so the description must compensate, and it largely does: each of the 8 parameters is explained, business_info's required 'name' plus optional fields are spelled out beyond the permissive schema, and output_format's enum and default are restated. It does not specify the nested shape expected for the analysis payloads, which all accept arbitrary objects.

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 ('Generate a comprehensive 12-section business intelligence report') and enumerates the exact content, so an agent knows precisely what it produces. The 'Synthesizes technical audits, SEO evaluations, social presence scans...' sentence distinguishes it from the sibling tools that produce those individual inputs.

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 Args block implicitly defines the pipeline by naming the sibling tool each input comes from (analyze_website, check_seo, find_social_profiles, find_competitors, score_lead, generate_business_insights/generate_outreach), and every input except business_info is marked optional. It lacks an explicit statement of when to prefer this aggregator over calling individual tools, or whether partial inputs yield a degraded report.

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 deliver real value: it discloses the local Ollama model (no third-party data transfer), that output is grounded in verified data, and that it will not fabricate guarantees or budgets. It also sketches the return shape. It omits operational behavior an agent needs, such as expected latency/cost of an LLM call, behavior when all optional inputs are null, and what happens if the Ollama model is unavailable.

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 is front-loaded, followed by a scannable per-channel breakdown, then safeguards, then args. Dense but well organized with no filler sentences; the args block earns its space given the schema has no descriptions.

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 an 11-param, annotation-free generation tool with an output schema, the description covers inputs, output shape, data-handling policy, and content constraints. The remaining gap is edge-case behavior (missing optional inputs, model failure) and the fact that the output schema's structure is only vaguely gestured at as 'Dict containing multi-channel outreach drafts'.

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 0%, so the description must compensate across 11 params, and it does list every one with a short gloss and a required marker. Its biggest contribution is provenance mapping — naming which sibling tool produces website_analysis, seo_audit, social_profiles, competitor_comparison, and lead_score_data — which the schema cannot express. It still leaves the expected shape of those nested objects undefined, so an agent knows where to get them but not what they should contain.

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 ('Generate personalized, multi-channel B2B outreach messages') and enumerates exactly what is produced across three channels, including length constraints. It never explicitly contrasts itself with siblings like generate_business_insights or generate_business_report, so differentiation is implicit rather than stated.

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: tagging inputs as 'Results from analyze_website tool' / 'check_seo' / 'score_lead' sketches a pipeline order without stating when to call this versus the report/insight generators. There is no guidance on required prerequisites, no note that richer optional inputs yield more personalized drafts, and no when-not-to-use case.

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 substantial work: it discloses multi-provider resolution (OSM, demo fixtures), the conditional enrichment side behavior, the ODbL attribution obligation, and a privacy constraint against scraping PII. It does not say whether enrichment results are persisted or whether the enrichment call adds latency, which are the remaining behavioral gaps.

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 is front-loaded in the first sentence, followed by behavior, args, returns, and compliance in a predictable structure. The Returns and Compliance blocks are justified because no output schema or annotations exist, though the prose is slightly 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?

For a two-parameter read tool with no annotations and no output schema, the description covers purpose, both parameters, the full return shape including attribution and enriched_fields, and compliance obligations. An agent has everything needed to invoke it 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 coverage is 0%, so the description must compensate, and it largely does: it gives concrete ID format examples ('osm_node_12345', 'osm_way_67890', 'demo_001') and explains that auto_enrich_website triggers a search only when the website is absent from OSM tags. It omits the default value of true, which the schema does carry.

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 enriched details for a specific business by ID") and the lookup-by-ID framing distinguishes it from the search_businesses sibling. It stops short of naming siblings explicitly, so the differentiation is implied rather than stated.

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?

There is no explicit when-to-use or when-not-to-use guidance, and no routing to alternatives such as search_businesses (to find an ID first) or find_business_website (the dedicated website lookup). The agent must infer the workflow position from the parameter name alone.

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 supplied, so the description carries the whole burden. It does usefully disclose that scoring is deterministic, that missing inputs reduce confidence rather than trigger arbitrary penalties, that verified defects are separated from missing data, and that no paid APIs are used; but it never states that the tool is side-effect-free/read-only, nor anything about scoring cost or execution 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?

Purpose and rubric are front-loaded, and each block (scoring categories, opportunity scores, compliance, args, returns) is clearly separated. The seven-item points breakdown and the compliance bullets are informative rather than filler, though the section headers duplicate what the Args/Returns blocks already imply, so the text is longer than strictly needed.

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?

An output schema exists, so return values need not be spelled out, yet the description still usefully signals that the report includes an overall score, priority tier, service opportunities and a recommended package. For an eight-parameter pure-computation tool with no annotations, the only real omission is the weights key contract and nested input shapes.

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 0%, so the description must compensate, and it largely does by naming all eight parameters, marking business_name required and the rest optional, and telling the agent which sibling tool produces each input object. The gap is 'weights', which is documented only as 'custom weight overrides for the 7 categories' with no key names or value conventions, even though the schema leaves it as a free-form number map. The expected shapes of the nested analysis objects are likewise undescribed.

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 ('Evaluate and score a business lead') plus the domain ('digital services suitability'), and the rubric makes obvious what the output measures. It never names a sibling, so the agent must infer on its own how this differs from generate_business_insights or generate_business_report.

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 context is conveyed through the parameter docs: the optional inputs are labelled 'Results from analyze_website tool', 'check_seo tool', 'find_social_profiles tool' and 'compare_businesses tool', which effectively describes an upstream pipeline. There is no explicit when-not or contrast with the report/insight-generation 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 data source and licence, the degraded demo fallback, the 1-50 result cap, the provider field revealing which mode ran, and a mandatory attribution obligation. It omits rate limits, ordering of results, and latency expectations for a live external API.

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 one-line purpose followed by Args and Returns blocks that are easy to scan. The Returns section is justified because no output schema exists, though the compliance bullet list partially repeats the attribution note already stated above.

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?

Covers what the agent needs: inputs with formats, echoed outputs, provider/mode signaling, caveat note field, and the attribution duty. Only minor gaps remain, such as result ordering and failure handling beyond the demo fallback.

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 0%, so the description must compensate and does: all four parameters get meaning, worked examples ("coffee shop", "Austin, TX", "48.8566,2.3522"), the "*" wildcard convention, the accepted limit range and default, and the critical fact that omitting location silently degrades to demo data.

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 businesses) and names the exact mechanism and data source: live OpenStreetMap/Overpass discovery with a demo-data fallback. An agent can tell this is the discovery entry point rather than a detail/export sibling like get_business_details or export_leads.

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 operational context: no API key required, demo mode when the network is unavailable, and location is required for live OSM search. It does not, however, explicitly route the agent to siblings (e.g. after finding candidates, use get_business_details or score_lead), so the when-not-to-use side is only implied.

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