Houses With Land

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

With no annotations, the description does add two pieces of real behavioral context: a Bearer token is required, and results are scoped to the caller's private board. It says nothing about ordering, size limits, pagination, or what happens on an empty board, which is left entirely undisclosed for a zero-annotation tool.

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, the resource statement first and the auth prerequisite second, with no filler or repetition of the tool name.

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 with no output schema and no nested structures, the definition covers what it does and the auth requirement. The main remaining gap is the shape of the returned list, though with no parameters there is little an agent can get wrong before invoking it.

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 no parameters, so the baseline is 4. The description correctly implies no filtering or scoping inputs are needed because the board is implicitly the caller's own.

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?

'List the caller's private saved-homes board' pairs a specific verb with a specific resource and scopes it to the caller, which separates it from search_homes or get_home. It stops short of naming a sibling, so an agent must infer the boundary itself.

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 caller's private saved-homes board' suggests retrieving your own saved items rather than searching or fetching a single home. There is no explicit when-to-use statement, no mention of when board_save or board_update would be preferred, and no note on empty-board behavior.

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 Bearer token requirement, but does not say whether re-saving the same property is idempotent, what happens if the home is unavailable or already on the board, or what a successful response 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?

Two short sentences with the action front-loaded and no filler. The auth sentence is the only part that could arguably live in structured metadata, but it is still useful given the absence of annotations.

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

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

For a single-parameter mutation tool with no annotations and no output schema, the description covers the action and auth but omits duplicate-handling behavior, failure modes, and confirmation of what changes on the board. Adequate but with clear gaps.

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. "An available home" implies property_id must reference an existing, available listing, which adds a little meaning, but nothing is said about identifier format, source, or error conditions for invalid ids.

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 ("Save an available home to the caller's board"), which is clearly a write operation distinct from board_list and board_update. The word "available" adds a scope qualifier, but it is not defined, leaving a small ambiguity.

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

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

No guidance on when to choose this over siblings such as board_update or get_home, and no statement of when not to use it. The only conditional information is the auth prerequisite ("Requires Bearer token"), which is a requirement rather than usage routing.

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 usefully discloses that this is a mutation, that a Bearer token is required, and that notes are private. However, it does not explain whether notes replace or append to existing text, how notes are cleared or preserved, or whether stage transitions have restrictions.

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-loads the tool's purpose before authentication and valid-stage details. Each part supports selection or invocation without unnecessary prose.

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?

Together with the schema, the description is sufficient for basic selection and invocation of this small three-parameter tool. Important gaps remain for a mutation with no annotations or output schema, particularly that stage is required even for a notes-only edit, how to preserve the current stage, and what the update returns.

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 description only partially compensates by explaining the stage workflow and the privacy of notes. It merely repeats the stage enum already present in the schema, provides no explanation of saved_id, and omits useful notes semantics such as the 2000-character limit.

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 two specific operations on a saved-home board entry: moving it between stages and editing private notes. This clearly distinguishes it from board_save, which saves a home, and board_list, which retrieves entries.

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 stated operations provide clear when-to-use context: choose this tool to change an existing saved home's stage or notes. It does not explicitly exclude alternatives or explain that board_save should be used for initially saving a home.

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 burden and does disclose meaningful behavior: it is a logged-out (unauthenticated, read-only) call, it only resolves rights-cleared published homes, and it returns a save link among other fields. It stops short of describing error shape or what happens for an unpublished or non-existent id beyond implying non-resolution.

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 fragments, front-loaded with the resource and payload, with no padding. The telegraphic style ("Logged-out.") is efficient but slightly clipped, and the field list could be tied more clearly to return values.

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 lookup with no output schema, the description compensates well by enumerating the returned fields and stating the visibility gate. A note on failure behavior for invalid or unpublished ids would make it fully complete.

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

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

Schema coverage is 100% and the single property_id parameter is already documented with type, minimum, and the /homes/slug-1 example, so the schema does the heavy lifting. The description adds no additional meaning about the id beyond what is structured, so baseline 3 applies.

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

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

"Full public detail for one home" states a specific resource (home), scope (single, full public detail), and enumerates the payload (price, land, source, evidence, save link). It implicitly contrasts with the sibling search_homes but never names it, so an agent must infer the single-vs-list distinction.

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?

"Only rights-cleared published homes resolve" is a useful precondition that tells the agent when this call will fail, and "Logged-out" signals no auth is required. However, there is no explicit guidance on choosing this over search_homes or board_save, and no mention of how to obtain a valid property_id first.

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 must carry behavioral disclosure. It usefully states that only source-checked answers are filled in and that missing coverage is reported as unassessed, never asserted, but it does not cover read-only status, error behavior, or authentication needs.

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

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

Two tightly written sentences with no filler, front-loading the scope and then the answer-handling rule. Every sentence adds useful information.

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 tool with no annotations and no output schema, the description explains the output behavior reasonably well: 20 questions, source-checked answers, and unassessed gaps. It remains incomplete on input semantics and operational details, so an agent cannot fully infer usage.

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 one required property_id with 0% description coverage, and the description only implies 'one home' without naming or explaining the identifier. It does not compensate for the missing schema 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 identifies a specific resource: 20 rural buyer due-diligence questions for one home, with source-checked answers. It is more specific than a generic home lookup, though it uses a noun phrase rather than an explicit action verb.

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 guidance or comparison to siblings such as get_home or search_homes. The phrase 'for one home' implies a single-property lookup, but the agent must infer when this tool is preferred.

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

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

No annotations exist, so the description carries the full behavioral burden. It does disclose auth state and inventory scope, which is genuinely useful, but it says nothing about result size limits (the schema caps limit at 24 with a default of 10), ordering, pagination, or what a result record contains. For a search endpoint with no annotations and no output schema, that leaves the agent guessing about the shape and volume 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?

Three short fragments, front-loaded with the core action, with zero filler. The final sentence is arguably wasted space since it references a route the agent cannot inspect, but the overall economy is good.

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?

Eight parameters, none required, no annotations, no output schema, and only 25% schema coverage — this is a case where the description should do more. It omits return shape, default result count, and the semantics of most filters, so an agent can construct a call but cannot predict what it gets back.

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 only 25%: just q and region are documented, while kind (which has an odd empty-string enum member), limit, min_price, max_price, min_bedrooms and min_plot_acres are bare. The description adds no parameter meaning at all — 'same filters as /for-sale/' is a pointer to unavailable information, not an explanation. With low coverage the description needed to compensate and does not.

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

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

The description gives a specific verb and resource ('Search currently available houses with land') and adds a meaningful scope qualifier (land-bearing properties only). It is distinguishable from get_home (single-property lookup) and the board_* tools, though it never names a sibling. The '/for-sale/' reference is opaque to an agent that cannot see that route.

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?

'Logged-out' signals an important precondition: this is callable without authentication, which is useful routing context. However, there is no explicit guidance on when to prefer this over get_home for a specific listing, nor any exclusion or fallback. Usage is implied rather than stated.

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