Black Label Real Estate Website MCP

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

Annotations already indicate a write operation (readOnlyHint=false) and non-idempotency. The description adds context: it returns a continue_url and explicitly states it does not charge anything, which goes beyond the structured metadata and clarifies side effects.

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 sentences with no fluff. The main purpose is front-loaded, followed by the return value and a safety note. 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?

For a simple two-parameter tool with annotations covering safety and idempotency, the description provides enough to call it: it explains the purpose, the return URL, and that no charge occurs. It lacks explicit parameter value guidance, but the schema enum covers that. Overall, it is complete for typical 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 description coverage is 0%, so the description must explain the parameters. It says 'one offer' which implies offer_id selects the offer and quantity is 1, but it does not explain the enum values (realestate-mac/windows) or that quantity is fixed at 1 due to min/max constraints. The description provides minimal semantic help.

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 clear verb ('Start a purchase') and resource ('one offer'), and specifies the return value (continue_url). It distinguishes itself from siblings like get_checkout and list_products by focusing on initiating a checkout rather than querying or listing.

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 implies when to use it (when starting a purchase) but does not explicitly mention alternatives or when not to use it. Siblings like get_checkout exist for checking status, but no guidance is given, so usage is only implied.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds context about the two tiers (live and archived), which is useful behavioral information about the data scope. However, it does not disclose potential edge cases, error conditions, or response details. Since annotations cover safety, a 3 is appropriate.

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 sentence that is information-dense and front-loaded. It specifies the scope (per-state), the content (county and property counts), and the tiers (live and archived). No wasted 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 no-input, read-only tool, the description is adequate. It explains what data will be returned without needing an output schema. It could potentially mention the output format, but given the simplicity, this is a minor omission. The tool is unlikely to be misused with this description.

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 input schema has zero parameters, so the description has no obligation to explain parameter meaning. The baseline of 4 applies because there is nothing to document, and the description does not need to compensate for any parameter gaps.

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 provides per-state county and property counts, split between live and archived tiers. This names the resource and granularity, and implies a read operation. While it doesn't explicitly distinguish it from siblings like estate_stats, the specific mention of 'coverage' and tiers gives enough clarity for an agent.

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 no guidance on when to use this tool versus its siblings. It does not mention alternatives, prerequisites, or exclusions. An agent would have to infer usage from the title and context, which is a significant gap given the presence of similar tools like estate_stats.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds no distinct behavioral disclosure beyond what annotations provide—no mention of pagination, output shape, or limits. It is not contradictory, but it also offers no extra behavioral context.

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, short phrase with no filler or redundancy. It front-loads the essential resource type and the two key filters. While it could be more detailed, it is concise and structured appropriately for its length, so it earns a high score without reaching maximum because it omits useful structure like explicit sentence form.

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?

The tool has three parameters, no output schema, and a very brief description. It does not explain what an 'owner portfolio' contains, whether results are paginated (despite the per_page parameter), or what the response format looks like. With no output schema, the description carries a heavier burden, and it falls short of giving the agent enough context to anticipate the tool's output and use it 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 interpret the parameter names. It clarifies that 'state' and 'name' are the state and owner name used to filter the portfolio, which is valuable. However, it says nothing about per_page or its purpose, and offers no value formats or examples, only partially compensating for the gap.

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 title 'Look up an owner portfolio' supplies the verb, and the description 'An owner's parcel portfolio by state and owner name' names the specific resource (owner parcel portfolio) and two filter dimensions. This is enough to differentiate it from siblings like estate_search or estate_stats, but it does not explicitly contrast against them or mention whether it is the only owner-portfolio tool, losing the last point.

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 usage guidance is provided. The description gives no context on when to choose this tool over alternatives like estate_search or estate_parcel, no mention of what it is not suitable for, and no prerequisites or fallback conditions. The agent is left to infer applicability from the 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds the 'exact' match behavior, which is useful but minimal. It does not disclose any edge cases, error behavior, or response format, which would add more value.

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, front-loaded sentence with no redundant words. It conveys the core purpose and parameters efficiently.

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 lookup tool, the description is minimal. With no output schema, it does not hint at what the response contains, and it lacks any mention of error cases, pagination, or how to handle invalid inputs. Given the 0% schema coverage, the description should provide more context to be fully usable by an agent.

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 only repeats the parameter names ('state' and 'parcel_id') without explaining their meaning, expected formats (e.g., state code vs full name), or any constraints. For a tool with only two parameters, this is a significant gap.

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 action ('lookup') and resource ('parcel'), and mentions the two required parameters (state and parcel_id). The word 'exact' hints at a precise, single-record retrieval, which distinguishes it from the broader 'estate_search' sibling, though it does not name the 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 description implies this tool is for when you have a specific parcel_id and state, as opposed to searching. However, it does not explicitly state when to use this versus estate_search or other siblings, nor does it mention any exclusions or prerequisites. The guidance is only implied by the word 'exact'.

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

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

Annotations already declare readOnly, openWorld, idempotent, and non-destructive behavior. The description adds value by specifying 'Latest dated' and the 3-mile context, plus the explicit exclusion of appraisal, ARV, and profit claims. This goes beyond the annotations and clarifies what the audit does not include.

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, compact sentence that front-loads the core purpose and key constraints. It wastes no words and is easy to parse. The parenthetical adds essential 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?

The tool has four parameters with no schema descriptions and no output schema, so the description must compensate. It clarifies the purpose and exclusions but leaves parameter usage completely unexplained. An agent would not know what to pass in each field, nor what the return format is. This is inadequate for correct invocation.

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 description does not explain any of the four parameters (id, state, parcel_id, record_id). It does not clarify which are needed, how they relate to the parcel, or how to use them. The description provides no parameter meaning beyond the schema, which is a major gap.

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 latest dated public-record property audit for a parcel, with a specific 3-mile context. It also explicitly excludes appraisal, ARV, and profit claims, which differentiates it from potential siblings. The title 'Read a property audit' reinforces the purpose.

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 use this tool versus alternatives like estate_search or estate_parcel. The description does not mention any conditions, alternatives, or prerequisites. It only describes what it does, not when to choose 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?

The description adds behavioral details beyond annotations: the preview tier limit of 25 rows per page and the location prerequisite for certain filters. These are not present in the annotations (readOnly, idempotent, non-destructive) and provide useful context about pagination and input constraints. No contradiction with annotations.

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

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

The description is two sentences with no wasted words. It front-loads the core purpose and then adds the key constraint. It is concise and well-structured, though it could be slightly expanded for parameter clarification.

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 has 20 parameters, no output schema, and moderate complexity, the description is too thin. It mentions page size and a location requirement but does not explain return format, how filters combine, or how to construct a valid query. The absence of output schema increases the burden on the description, which it fails to meet.

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% (only state has a description). The description groups filters into categories (category, value, date, toggle) but does not map them to actual parameter names like max_value, sold_after, owner_occupied, etc. It does not clarify the meaning of q, zip, city, or map bounds parameters. With 20 parameters, this is insufficient to guide correct invocation.

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 searches public property records, with a specific verb and resource. It mentions preview tier, which is extra detail. However, it does not explicitly differentiate from sibling tools like estate_owner or estate_parcel, so it's not fully distinct.

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 a constraint: category, value, date, and toggle filters require a location. This is useful guidance for when to include location parameters. However, it does not specify when to use this tool versus sibling alternatives, such as estate_owner or estate_parcel, so the selection guidance is incomplete.

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

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

Annotations already cover read-only, idempotent, and non-destructive traits. The description adds value by specifying the global scope ('corpus totals') and the freshness field, which implies a timestamp. It does not contradict annotations and provides meaningful behavioral context beyond the structured fields.

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 conveys the resource, purpose, and output fields without any filler. The parenthetical list is compact and immediately actionable.

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 parameterless, read-only stats tool with annotations covering safety and idempotency, the description fully specifies the expected return content (totals, live/archived counts, states, counties, freshness). No additional guidance is needed for an agent to call it 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?

The tool has zero parameters, so the schema fully describes them (vacuous). The description correctly avoids over-explaining and instead clarifies the output fields, which is appropriate for a parameterless tool.

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

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

The description states a clear verb ('totals') and resource ('public-records API'), and enumerates the exact fields returned. This distinguishes it from sibling tools like estate_search (search) and estate_owner/parcel (individual records), making its purpose unambiguous.

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 implies usage when corpus-level statistics are needed, but it does not explicitly differentiate from estate_coverage or provide when-not-to-use guidance. With no parameters and a simple read-only scope, the context is clear but lacks explicit 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?

Annotations already cover readOnlyHint, idempotentHint, and non-destructiveness. The description adds the precondition that the checkout must have been started by create_checkout, but does not disclose response contents or error behavior, which is acceptable given the strong 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 communicates both the action and the required precondition with no filler. Every word serves a purpose.

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 read operation with one obvious identifier parameter and rich annotations, the description is sufficiently complete. It could mention the return shape, but the title already indicates status and no output schema is present.

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?

With only one parameter, checkout_id, the schema name is self-explanatory and the description confirms it identifies the checkout to read. However, schema description coverage is 0%, and the description itself adds no parameter-level detail, so it only earns average credit.

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 action ('Read'), a resource ('checkout'), and explicitly ties the tool to create_checkout, distinguishing it from the creating sibling. The title reinforces that it reads checkout status.

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 clearly implies the tool is used after create_checkout has started a checkout. It doesn't explicitly name alternatives or exclusions, but the relationship to its creator sibling provides sufficient context for appropriate selection.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds valuable context about the returned data (Stripe-verified prices, billing terms, delivery, live availability), going beyond the structured annotations without contradicting them.

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, well-structured sentence that front-loads the core purpose ('Everything an agent can buy') followed by the key value propositions. There is zero redundancy or filler; every word 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?

For a simple, parameterless list tool with annotations covering safety, the description is complete. It explicitly states what is returned (products with prices, billing, delivery, availability) and implies it's a full catalog. No output schema exists, so the description fully covers the informational needs of the agent.

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 has zero parameters, so the schema is empty. The baseline for 0 params is 4, and the description doesn't need to explain any parameters. It correctly focuses on the output content, which is appropriate for a parameterless tool.

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

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

The description clearly states the verb (list) and resource (products purchasable from Black Label Real Estate), and it distinguishes itself from sibling tools like create_checkout or estate_search by focusing specifically on the catalog of purchasable items with pricing and availability details.

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 context: this tool returns everything an agent can buy, which implicitly tells the agent when to use it (e.g., before purchasing). It doesn't explicitly mention alternatives or exclusions, but since no other sibling tool lists products, the usage is unambiguous and well-contextualized.

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

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

Annotations already declare readOnly, idempotent, and non-destructive behavior. The description adds useful behavioral context: it returns Markdown or stripped text and caps output at 40,000 characters. It does not describe truncation handling, but the annotation coverage lowers the burden.

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 sentence that front-loads the verb and resource, then packs in the format and limit without wasted words. Every element 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?

For a one-parameter read tool with strong annotations and no output schema, this is nearly complete: it states what to pass, what domain is allowed, and what output to expect. The only minor gap is how an agent selects between Markdown and stripped text, since no format parameter exists.

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 carry the meaning. It usefully constrains the url parameter to an https://blbestate.com page and describes the output representation. This goes beyond the generic 'format: uri' in 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 uses a specific verb ('Read') and resource ('one https://blbestate.com page'), and specifies output formats and a character limit. It clearly distinguishes this single-page reader from sibling tools like search_pages or estate_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?

Usage is implied: use this tool when you need the content of a specific page. However, it does not explicitly state when not to use it, nor name alternatives like search_pages for finding pages.

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

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

Annotations already signal read-only, idempotent, non-destructive behavior confession. The description adds useful behavioral details beyond annotations: it is a sitemap search against URL paths and returns URLs with match scores. It does not discuss sorting or pagination, but for a simple read-only search tool these are minor omissions.

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 compact and front-loaded: it opens with the primary purpose本体, then specifies the matching mechanism, and closes with the output type. There is no filler or redundant restatement of the tool name or title.

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-only search tool with well-defined annotations, the description is largely complete. It states what is searched, how matching works, and what is returned. Since no output schema exists, the return-value hint is valuable, though a bit more detail about ordering or limit application would make it fully self-sufficient.

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 carry parameter meaning. It explains that 'query' consists of words matching against the URL path, which is the key semantic. However, it does not explicitly state that 'limit' controls the number of returned results, although the schema's default and min/max provide some structural, if not semantic, guidance.

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 ('Find'), a concrete resource ('pages on blbestate.com'), and a precise search mechanism ('by words in their URL path'). It also notes the output ('URLs with a match score'), making it readily distinguishable from siblings like estate_search or read_page.

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 clear context for when to use this tool: when searching site pages by URL-path words, as opposed to content or property searches. It does not name specific alternatives or explicitly say when not to use it, but the context is unambiguous enough for an agent to select it appropriately.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false. The description adds that the tool provides links to sitemap, docs, contact, and discovery documents, which is a mild behavioral detail not covered by annotations. However, it does not disclose additional behaviors like response format or whether the content is static, and it relies on annotations for the safety profile.

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 entire description is a single sentence that front-loads the core purpose ('What Black Label Real Estate is') and then lists the included link types. Every word contributes value, with no redundancy or filler.

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, read-only informational tool, the description adequately covers the tool's purpose and content. It does not specify the exact output format (e.g., text vs. HTML) or detail the structure of the links, but given the simplicity of the tool and the absence of an output schema, this is sufficient. A slightly richer description could mention the type of information returned, but it is not a critical gap.

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

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

The tool has zero parameters, so the input schema provides no semantics to clarify. The description correctly mentions nothing about parameters, and the baseline for zero-parameter tools is 4. There is nothing missing here.

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's purpose: it provides an overview of what Black Label Real Estate (blbestate.com) is, along with links to its sitemap, docs, contact, and discovery documents. This is a specific verb+resource that distinguishes it from sibling tools like estate_search and estate_owner, which focus on real estate data rather than site information.

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?

While the description implies the tool is for general site information (contrasting with sibling estate tools), it does not explicitly state when to use this tool versus alternatives or provide exclusions. The usage context is inferred from the tool's name and description rather than spelled out.

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