Black Label Real Estate Website MCP

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

No annotations exist, so the description carries the full burden. It usefully discloses the key behavioral trait of a checkout-creation tool: it does not charge and defers payment to Stripe's hosted page. It omits other important traits such as whether repeated calls create multiple sessions, what permissions are required, and whether sessions expire.

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?

Three short sentences with zero padding. The core behavior (creates checkout, returns continue_url) is front-loaded, followed by the redirect instruction and the no-charge caveat, in an effective information order.

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 correctly does the work of explaining the return value (continue_url). But for a purchase-initiating tool with no annotations and fully undocumented parameters, it leaves out auth requirements, idempotency/session behavior, and the quantity=1 limitation.

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% and there are 2 parameters. The description implies offer_id selects 'one offer' but never explains the enum values, and it completely ignores quantity, whose maximum of 1 means multi-unit purchases are impossible — a constraint an agent should know before calling.

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 ('Start a purchase of one offer') and immediately clarifies that a continue_url is produced for a Stripe-hosted page. It implicitly separates itself from get_checkout (starting vs retrieving), but never names that sibling explicitly, so the differentiation is left to inference.

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 explains the downstream flow ('send the buyer there to pay'), which implies when the tool is used, and adds the caveat that it does not charge. However, it gives no explicit when-to-use vs get_checkout, no prerequisites (auth, existing customer), and no guidance on whether to call this once or per buyer.

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 provided, the description carries the full behavioral burden. It usefully discloses that results are broken out per state and cover two tiers (live and archived), but says nothing about freshness, whether archived coverage can lag, or the shape/size of the response.

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?

A single compact clause with no filler, and the key scope qualifiers ('per-state', 'live tier', 'archived tier') are front-loaded. The telegraphic noun-phrase style reads slightly like a fragment rather than a full statement of behavior.

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 zero-parameter read tool with no output schema, the description gives the essential content of the return value (tier-split per-state counts). It still leaves the distinction from estate_stats and the exact meaning of 'coverage' undefined, which is a real gap given the crowded sibling set.

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 tool takes zero parameters, so the baseline of 4 applies. The description correctly implies the tool is unfiltered and global rather than scoped by any input.

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 resource (county and property counts) and a clear scope (per-state, spanning both the live and archived tiers), which lets an agent know exactly what it returns. It does not, however, distinguish itself from the sibling estate_stats, so an agent cannot tell the two apart on the description alone.

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 when-to-use guidance, no mention of prerequisites, and no reference to the sibling estate_stats or any alternative. The agent must infer the use case entirely from the phrase 'coverage counts'.

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 disclosure burden, yet it says nothing about read-only nature, permissions, pagination behavior (despite a per_page cap of 25), or result shape. For a data-retrieval tool with zero annotation coverage, this leaves the agent uninformed about basic 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?

It is a single short fragment with no wasted words and the scoping keys are front-loaded, but the brevity comes from under-specification rather than discipline. A tool with three parameters and no annotations needs more than one noun phrase.

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 annotations, no output schema, 0% parameter coverage, and a 25-item page cap, the description is too thin to let an agent call the tool confidently. It omits return format, pagination, and how results relate to sibling tools such as estate_search or estate_coverage.

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. It clarifies that 'name' means owner name and that 'state' scopes the lookup, which adds real value, but the third parameter (per_page, max 25) is left entirely undocumented in both the description and 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 fragment identifies a specific resource ('an owner's parcel portfolio') and its two lookup keys ('by state and owner name'), so an agent can roughly infer it returns parcels for an owner. However, there is no verb (retrieve/list/lookup) and nothing distinguishing it from siblings like estate_search, estate_parcel, or estate_coverage, which plausibly overlap on the same parcel data.

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 gives no when-to-use guidance, no conditions or prerequisites, and never mentions the closely related siblings (estate_search, estate_parcel). The agent must guess whether this is the right tool for an owner lookup versus a general parcel 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?

No annotations are provided, so the description carries the full burden. It implies a read by using 'lookup', but discloses nothing about permissions, rate limits, failure behavior for unknown parcel IDs, or what the result contains.

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?

A single front-loaded sentence with zero filler and no redundancy. It is efficient, though the brevity comes partly from under-specification rather than tight editing.

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 lookup with no annotations and no output schema, the description should at least describe return shape and identifier formats. It says nothing about results, errors, or whether matches are unique, leaving the agent unable to predict the outcome.

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 is the only source of parameter meaning. It usefully identifies both required parameters and frames them as the composite exact-match key, but adds no expected format (e.g., state abbreviation vs full name, parcel_id syntax), which is a real gap for an exact lookup.

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 (lookup) and resource (parcel) plus the keys used, so the core action is unambiguous. However, it does not distinguish itself from nearby siblings like estate_search, estate_owner, or estate_property_audit, which also concern parcels.

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 word 'Exact' weakly implies that fuzzy/partial matching belongs to estate_search, but that alternative is never named and no when-to-use or when-not-to-use condition is given. The agent must infer routing from a single adjective.

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. It does add real behavioral context: the data is public-record, dated, and scoped to a 3-mile radius, and it explicitly disclaims appraisal/ARV/profit outputs so the agent knows not to expect valuation. However, it says nothing about read-only nature, auth requirements, or result size.

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?

A single densely packed sentence with the resource and scope front-loaded and the negative constraints parenthetically appended. No wasted words, though the terse phrasing leaves real gaps rather than being purely economical.

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 annotations, no output schema, and four undocumented parameters mean the description should do far more than it does. It never clarifies which identifier to supply or what the returned audit contains, which is a critical gap for a lookup-style 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?

Four parameters with 0% schema description coverage, and the description only obliquely references 'a parcel'. It does not explain the difference between id, parcel_id, record_id, or what state is for, leaving the identifier choice ambiguous.

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 resource (property audit), its scope (latest dated, public-record, 3-mile context) and a clear negative boundary (no appraisal, ARV or profit claim). The term 'audit' is distinct from siblings like estate_parcel or estate_owner, though the description never explicitly contrasts with them.

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?

Use is only implied by the noun phrase; there is no statement of when to call this versus estate_parcel, estate_owner, or estate_coverage, and no prerequisites or exclusions. An agent must infer the triggering condition entirely.

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 behavioral burden. It usefully discloses the preview-tier limit (25 rows per page) and the location prerequisite, which are non-obvious constraints. It says nothing about auth, rate limits, or result shape, so it adds value but leaves meaningful 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?

Two tight sentences with zero filler, and the purpose leads before the usage constraint. Efficient and well front-loaded, though there is room to fold in a bit more param context without bloat.

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 20-parameter tool with no annotations and no output schema, the description is thin: it covers the central location prerequisite and the page-size ceiling but never mentions pagination via page, per_page, or the free-text lookup paths (q, address, owner_name). Adequate for basic invocation, not for confident full use.

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 only 5%, so the description must compensate. It meaningfully groups the filter parameters – category, value (min/max), date (sold_after/before), and toggle (absentee/owner_occupied) filters – and names the location parameters, adding real structure. But it omits q, address, owner_name, page, and per_page, leaving a substantial share of the 20 parameters undocumented.

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 ('Search') and resource ('public property records'), so the agent knows exactly what the tool does. It does not distinguish itself from related siblings like estate_property_audit, estate_owner, or estate_stats, which share the same domain, so it falls 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?

The description supplies a real prerequisite – filters require a location (state, county, city, zip or map bounds) – which tells the agent when the tool is usable. However, it offers no when-to-use/when-not guidance and never names an alternative sibling such as estate_property_audit or estate_stats, leaving routing 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?

No annotations are provided, so the description carries the full behavioral burden. It does disclose the shape of the result set (counts plus a freshness metric), which is useful, but it never states that the call is side-effect free, whether results are cached, or how 'freshness' should be interpreted.

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?

A single front-loaded sentence that names the resource first and then the payload. Every token earns its place; nothing is padded or repeated.

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's enumeration of returned fields does the work of documenting the response. Complete enough for a zero-parameter read tool, though the meaning of 'freshness' remains unspecified.

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 tool takes zero parameters, so per the rubric the baseline is 4. There is nothing further the description could add on parameter 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?

States a specific resource and effect: it returns corpus totals for the public-records API, and enumerates the concrete metrics (total_records, live_properties, archived_properties, states, counties, freshness). That is enough to separate it from siblings like estate_search or estate_parcel, though it never explicitly contrasts with the closest-sounding sibling, estate_coverage.

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 when-to-use statement, no prerequisites, and no named alternative. An agent can infer that this is the endpoint for aggregate counts, but nothing tells it to prefer this over estate_coverage when it wants coverage-style statistics.

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 the full burden. 'Read' weakly implies a non-mutating operation, but the description says nothing about required authentication, error or expiry behavior, or whether the checkout is retrieved as a live or frozen snapshot.

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?

A single well-formed sentence with zero filler, and the resource is front-loaded after the verb. It is arguably over-terse for a tool whose domain is ambiguous, but nothing in it 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 one-parameter read with no output schema and no annotations, the definition is minimally adequate: it establishes the lookup key and the relationship to create_checkout. It omits the return shape, error semantics, and id format, which an agent would need to use it confidently.

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% and the single parameter 'checkout_id' is a bare string with no description. The tool description adds no format, provenance, or validity information (e.g. whether the id comes from create_checkout's response), so the agent must guess the parameter's 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?

States a specific verb ('Read') and resource ('checkout'), and explicitly ties the tool to its sibling 'create_checkout', which helps an agent place it in the lifecycle. It stops short of 5 because it never clarifies what a 'checkout' represents in this domain (order? cart? grant?), so the resource remains somewhat abstract.

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 rather than stated: the phrase 'started with create_checkout' signals that this tool is the read counterpart to a creation flow. There is no explicit when-to-use, no exclusions, and no guidance on what to do if the checkout does not exist or is expired.

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 behavioral burden. It does disclose meaningful traits of the returned data — Stripe-verified prices, billing terms, delivery, live availability — implying a read-only, availability-sensitive listing. However, it says nothing about freshness, caching, pagination, or auth requirements, so gaps remain.

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?

A single front-loaded sentence with no filler; every clause describes a distinct aspect of the payload. It is efficient, though a sentence fragment rather than a fully formed directive.

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 must roughly convey what comes back, and it does by naming prices, billing terms, delivery, and availability. For a zero-parameter list tool this is close to sufficient, though it omits shape, count, and freshness details.

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 tool takes zero parameters, so per the rubric the baseline is 4. There is nothing for the description to clarify or compensate for.

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 identifies the resource precisely ('everything an agent can buy from Black Label Real Estate') and clearly separates it from all siblings, none of which deal with a product catalog. It never states an explicit verb like 'list', but the enumerative intent is unmistakable from the phrasing.

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 guidance on when to call this versus alternatives, and no mention of the natural next step (create_checkout) or any prerequisites. The agent must infer that this is the discovery entry point before checkout.

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 it does disclose genuinely useful traits: the two output formats (Cloudflare Markdown for Agents vs stripped text) and a hard 40,000-character truncation cap. However it is silent on auth requirements, how the format is selected, behavior for non-blbestate.com URLs, and 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?

One dense sentence that front-loads the action and resource, then appends the output formats and size cap. Nothing is wasted and nothing needs to be re-read.

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 read tool with no output schema or annotations, the description covers the essentials: scope, output format, and truncation limit. It leaves the format-selection mechanism and error behavior unexplained, which is a minor gap at this complexity level.

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% and the single `url` param has only `format: uri`, so the description must compensate. It partially does by restricting the target to a blbestate.com page, but adds no syntax, path, or format guidance for the URL itself.

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 (read) and resource (one blbestate.com page), plus the output formats produced. The word 'one' implicitly contrasts with the sibling search_pages, though the sibling is never named outright, so it falls just short of full differentiation.

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 for fetching a single known URL rather than searching. There is no statement of when to prefer this over search_pages or estate_search, and no prerequisites or exclusions.

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. It usefully discloses the search scope (URL path only, not page content) and the return shape ('URLs with a match score'), which is valuable given there is no output schema. It says nothing about read-only status, result limits, pagination, or rate limits.

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

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

Two short sentences with zero filler; the purpose and scope are front-loaded and the return shape follows immediately. Nothing 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 simple two-parameter search with no output schema and no annotations, the description covers what it searches and what it returns. It still leaves query syntax (single vs. multiple terms, matching rules) and result-count behavior unaddressed, which an agent would need to guess at.

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. It adds real meaning for 'query' by stating the terms are matched against URL path words (implying free-text token matching against paths, not page bodies), but it says nothing about multi-word/AND-OR behavior. The 'limit' parameter is at least self-documenting in the schema via default and min/max.

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 gives a specific verb ('Find'), a scoped resource ('pages on blbestate.com'), and the matching mechanism ('words in their URL path (sitemap search)'). This clearly separates it from content-oriented siblings like read_page, though it never names an alternative explicitly.

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 parenthetical '(sitemap search)' and the URL-path scoping imply this is a URL/title lookup rather than a full-text content search, which hints at when to prefer it over read_page. However, no explicit when-to-use, when-not-to-use, or named alternative is given.

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 the full burden. It does disclose what the call returns (links to sitemap, docs, contact and discovery documents), implying a harmless read operation, but says nothing about authentication, rate limits, or whether any state changes. Adequate but thin for a tool with zero annotation coverage.

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?

A single front-loaded sentence with no filler; the resource identity comes first and the returned artifacts follow. Nothing is padded or repeated.

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 zero-parameter, output-schema-less info tool, the description gives the agent a reasonable inventory of what comes back (sitemap, docs, contact, discovery documents) and needs no output schema. It stops short of describing structure/format or the relationship to sibling discovery 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?

The schema has zero parameters, so there is nothing for the description to disambiguate and the baseline is 4. The description correctly implies a parameterless, single-shot fetch rather than suggesting any filtering options.

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 names the concrete resource (Black Label Real Estate / blbestate.com) and enumerates what it returns: sitemap, docs, contact, and discovery documents. The verb is implicit (retrieve site overview) but the intent is unmistakable. It does not differentiate itself from siblings like read_page or search_pages, which could plausibly return similar content.

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 statement, and no alternative sibling is named. An agent cannot tell from this text whether site_info or read_page/search_pages is the right entry point for discovery. Only a faint implication exists that this is an orientation/entry-point tool.

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