listing

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

Discloses no account or prop_id needed, specifies the endpoint, and indicates the return format with is_active: true meaning covered. Adequate given no 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?

Extremely concise, front-loaded with purpose, and every sentence adds value. No wasted words.

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

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

For a simple tool with one parameter and an output schema, the description covers key aspects: purpose, usage timing, and return value indicator. Missing some details but overall complete enough.

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 already describes the state parameter. The description repeats schema info without adding additional meaning, so baseline 3 is appropriate.

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

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

The description clearly states the tool's verb ('check coverage') and resource ('state served by beycome MLS'), and distinguishes it from siblings as a discovery stage tool.

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?

Explicitly advises 'Use before listing to confirm beycome operates in the property's state' and explains consequences (listing flow does not apply if not covered). Lacks explicit when-not-to-use, but context is sufficient.

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 provided, so description carries full burden. Discloses slow performance and retry guidance, as well as stripped fields. Does not mention destructive behavior, but it's a GET endpoint, so okay.

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?

Description is mostly concise, front-loaded with purpose, and provides necessary details. Some minor redundancy (e.g., 'during discovery' twice) but overall efficient.

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 13 parameters, 1 required, and presence of output schema, the description covers purpose, usage context, performance, data omissions, and references sibling tool. No major 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 100% with detailed descriptions. Description adds a summary of filter categories but no extra meaning beyond what the schema provides. Baseline 3 is appropriate.

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

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

Description clearly states 'Discovery stage — sold comparable listings near a location (GET /comps)' and distinguishes from sibling 'beycome_estimate' by saying 'Use during discovery to support pricing alongside beycome_estimate'.

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?

Explicitly says 'Use during discovery to support pricing alongside beycome_estimate' and notes that no account or prop_id is needed. Also mentions retry behavior for slow endpoint. Does not explicitly exclude other use cases or alternatives, but context is clear.

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

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

No annotations provided, so description carries full burden. It states no account or prop_id needed, and returns both estimates plus pricing strategies. Lacks details on limitations or data freshness, but adequately discloses behavior for an estimation 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?

Three sentences, front-loaded with key information, no redundant or unnecessary words. Efficient and well-structured.

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 output schema exists, description efficiently covers return values (both estimates plus strategies), provides usage context, and fully documents parameters. No gaps for this tool's complexity.

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

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

Schema coverage is 100% with descriptions. Description adds value by providing an address format example and explaining unit handling preference (embedding in address string vs separate field), clarifying usage beyond schema.

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

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

The description clearly states it estimates a property's sale value using beycome CMA and Zillow Zestimate. It specifies the resource (property), verb (estimate), and scope (sale value), and distinguishes from siblings like beycome_rental_estimate.

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?

Explicitly says when to use: during discovery to set a list price. Provides pairing with beycome_comps and directs rental inquiries to beycome_rental_estimate, offering clear when-not-to-use guidance.

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 full behavioral burden. It states it's a token-scoped RESO list endpoint, implying read-only listing. However, it does not disclose potential edge cases (e.g., empty list, invalid token, pagination) or side effects, leaving some behavior uncovered.

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?

Description is concise with front-loaded purpose and clear use cases. A slight lack of structure (block text instead of bullets) but every sentence adds value, with no redundant phrasing.

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 complex workflow with many sibling tools, the description fully orients the agent by detailing integration points (after submission, for returning users) and linking to downstream tools. Output schema exists to cover return details, so no 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 only parameter, access_token, is described with specific provenance (from beycome_signin_verify or saved token), adding critical context beyond the schema's description. This helps the agent correctly provide the token.

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

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

Clearly states the tool retrieves the signed-in user's listings (GET /properties) and differentiates from siblings by specifying two main use cases: after property submission to find new listing, and for returning users to locate listings. This directly distinguishes it from tools like beycome_submit_property_link and beycome_questionnaire_link.

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?

Provides explicit scenarios for when to use the tool (after submission, for returning users) and references sibling tools for next steps (questionnaire_link, messages, showings, offers). Lacks explicit when-not-to-use guidance, but the context is clear enough 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?

No annotations provided, so description covers all behavioral aspects: read-only, token requirement, list non-pagination rationale, soft-deleted message behavior, response structure (bare array under `data`), and 401 error handling. Very transparent.

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

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

The description is fairly long but well-structured, front-loading the main purpose. It includes some minor extraneous detail (e.g., field list), but these are helpful for the agent. Could be slightly more concise but still efficient.

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?

Despite having an output schema, the description covers return structure, error handling, authentication flow, and links to sibling tools. The agent has all necessary context to use the tool correctly.

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

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

Schema coverage is 100%, baseline 3. Description adds value by explaining the effect of omitting vs passing `thread`, the source of `access_token`, and the fields in list rows. This goes beyond the schema's basic descriptions.

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 reads owner's buyer/inquiry messages (GET /messages). It distinguishes two modes (list vs thread) and differentiates from sibling tool `beycome_reply_message` for replying. The verb 'read' and resource 'messages' are specific and 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?

Explicitly explains when to omit or pass `thread`, and directs users to `beycome_reply_message` for answering messages. Also guides re-authentication on 401. Provides clear context for using this tool over alternatives.

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

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

With no annotations, the description fully discloses behavioral traits: read-only, paginated (20 per page), returns full offer records, no server-side filter, and no response actions. No contradictions.

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 detailed but each sentence contributes useful information. It is front-loaded with the core purpose and structured logically. Minor redundancy could be trimmed, but overall effective.

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 output schema exists, the description adequately covers usage context, pagination, filtering limitations, and what is not included. It is complete for a tool with only two parameters.

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%, but the description adds value by explaining how page is used (paginated list, 20 per page) and the purpose of access_token. It goes beyond the basic schema definitions.

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 is for retrieving offers on the owner's listings post-publish, specifying the HTTP method and endpoint. It distinguishes from siblings by emphasizing its post-publish stage and read-only nature.

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?

Provides clear context: used once a listing is live, requires access_token, pagination details, and lack of server-side prop_id filter. It implicitly suggests when to use (post-publish) and notes that responding to offers is not exposed, though explicit when-not-to-use is missing.

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 provided, but description fully discloses behavior: returns an expiring link, no login step, browser actions required, 48-hour processing. No contradictions with missing 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?

Well-structured with clear sections (prerequisites, workflow, failure modes). Slightly verbose but each sentence contributes to clarity; could be tightened slightly.

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

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

Covers all aspects: purpose, prerequisites, return value, user actions, timeline, and error handling. No gaps given lack of annotations and presence of output schema.

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

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

Schema coverage is 100%, so baseline is 3. The description adds value by specifying the source of access_token (from beycome_signin_verify or saved token), enhancing parameter understanding beyond schema.

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

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

The description clearly states the verb ('mint'), resource ('pre-authorized link to the MLS questionnaire form'), and method (POST). It distinguishes from sibling tools like beycome_submit_property_link by specifying context.

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?

Explicitly states prerequisites (PAID listing, premium active, Flat/Yes) and failure modes (403, 422, 401). References related tool (beycome_submit_property_link) and explains when to use.

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 discloses important behavioral traits: no account or prop_id needed, the tool returns `rentEstimate`, `rentEstimateRange`, and `sources` with URLs stripped. It also warns that an unrecognized address returns `success: true` with a generic market-average rent, and advises checking source titles before trusting the number.

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 concise, well-structured with line breaks, and front-loads the core purpose and usage. Every sentence adds necessary information, and there is no repetition or fluff.

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 presence of an output schema, the description sufficiently explains the return values and adds the critical caveat about address recognition. However, it does not cover error conditions other than the unrecognized address case, leaving a minor 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 input schema has 100% description coverage, so the schema already documents the parameters. The description adds value by reinforcing that no account or prop_id is needed and that the tool is appropriate for addresses with a unit number. However, it does not add significant new syntax details beyond the schema.

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

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

The description clearly states the tool estimates monthly rent for a property, using the verb 'estimate' and the resource 'monthly RENT'. It explicitly distinguishes itself from the sibling `beycome_estimate` by specifying it is for rental inquiries or properties with a unit number, while `beycome_estimate` is for sale-price estimates.

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 explicit usage guidelines: use this tool ONLY for rental inquiries or properties with a unit number, and for sale-price estimates use `beycome_estimate`. It also includes a caveat about how to handle unrecognized addresses, guiding the agent on when the result may not be trustworthy.

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 description carries full burden. It fully discloses that sends are final (live send), queues email notifications, and that the tool automatically corrects the user's draft before sending. Lists all error responses with causes and status codes.

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?

Long but well-structured: starts with purpose, then behavioral caveat, then instruction to improve draft, then parameter hints, then error handling. Every sentence is informative; no fluff. Could be slightly more concise but still effective.

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 5 parameters, no annotations, and an output schema (not shown but referenced), the description covers all necessary context: input derivation from sibling tool, success response shape, and full error mapping. Complete for a mutation tool.

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

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

Schema coverage is 100% with good parameter descriptions. Description adds extra value: clarifies thread usage, advises on subject omission, explains how to derive to_user_id, and specifies access token source. Goes beyond schema.

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

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

The description clearly states the tool replies to buyer/inquiry messages via POST /messages/reply, distinguishing it from siblings like beycome_messages which list conversations. It specifies the stage (post-publish) and action (sends real message and queues notification).

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?

Provides explicit guidance: use for threaded replies (pass thread verbatim, omit subject), how to find to_user_id via beycome_messages, and always improve the drafted reply. Lacks explicit when-not-to-use, but context from siblings makes it clear.

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

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

With no annotations, the description discloses key behaviors: response mixes all event kinds with a type field, no server-side type filter, and default date range applied. Could mention authentication details, but access_token is in schema.

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?

Description is a single paragraph with clear, logical flow. No wasted words, but slight redundancy (e.g., 'Used once a listing is live' and later 'prop_id filters to one listing...'). Still effective and front-loaded.

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

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

Given an output schema exists, the description adequately covers behavior (mixed types, defaults). No mention of error handling or rate limits, but these are often out of scope. Sufficient for a list-style tool with good schema 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 coverage is 100%, baseline 3. Description adds meaning beyond schema: explains default values, format (YYYY-MM-DD), constraint (to_date on or after from_date), and prop_id filtering behavior. This enhances parameter understanding.

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 retrieves a calendar of showings, open houses, and offer deadlines via GET /calendar/events, using a specific verb and resource. It distinguishes from siblings like beycome_offers by noting it returns all event types.

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?

Provides explicit usage context: 'Used once a listing is live.' Explains default date range behavior (today to +90 days) and when to omit prop_id for all listings. Advises client-side filtering when user asks for one event kind.

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 fully discloses behavioral traits: passwordless authentication, 6-digit code sent via email and SMS, 30-minute validity, re-invalidation on re-run, and HTTP response nuances (e.g., 2xx on auth failures). This exceeds typical transparency.

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 well-structured with the action stated first, followed by key behavioral notes and response handling. It is longer but every sentence adds value; minor redundancy could be trimmed but overall it is efficient for the complexity.

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

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

Given the tool's complexity (multiple response cases, rate limits, code expiration) and the presence of an output schema, the description fully explains the behavior, response interpretation, and error handling. An agent can correctly invoke and handle this tool without additional information.

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 only parameter 'email' is already described in the schema as 'User email address.' The description adds behavioral context (email is used to send a code and check existence) but does not add new technical constraints or format details beyond the schema. Schema coverage is 100%, so baseline 3 is appropriate.

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

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

The description explicitly states 'send a one-time sign-in code' and identifies the endpoint. It distinguishes this tool from 'beycome_signin_verify' which exchanges the code for a token, making the purpose clear and unique among siblings.

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 detailed when-to-use and when-not-to-use guidance: use for starting sign-in, if email not found use signup instead, and outlines steps based on response. It also mentions rate limits, explicitly warning against looping or automatic retries.

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 provided, so description carries full burden. Discloses key behaviors: token long-lived, response success field is data.success, code expires in 30 minutes, and imperative to persist token. Lacks explicit statement about side effects but given authentication context, it's adequate.

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?

Description is relatively long but well-organized with clear sections. Front-loaded with core purpose and followed by usage details. Every sentence adds value; no 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?

Given the output schema exists, description properly explains return fields (access_token, expires_in) and error handling. Also covers token persistence, multi-account disambiguation, and session reuse. Thoroughly completes the context for the tool's role in the authentication flow.

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%, baseline 3. Description adds meaning by specifying code is 6-digit and obtained via email/SMS, and mentions 30-minute expiry, which is valuable context beyond the schema fields.

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

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

Clearly states the tool exchanges a one-time code for an access token, and positions it as the gateway to the listing flow. Distinguishes from siblings like beycome_signin_start and beycome_signup by specifying it is called after those.

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?

Explicitly says when to call (after signin_start or signup), what input to provide (6-digit code), and how to handle errors (wrong/expired code). Gives detailed next steps based on user state and warns about rate limits on retries.

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 provided, so description carries full burden. It discloses that registration sends a sign-in code automatically, doubles as signin-start if email exists, and returns validation errors. Lacks mention of rate limits or authentication needs, but sufficient for a registration 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?

Concise and well-structured single paragraph. Front-loaded with purpose, each sentence adds value without fluff.

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?

Comprehensive for a signup tool: explains the full flow, error handling, sibling differentiation, and edge cases. Output schema exists, so return values are covered.

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

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

Schema coverage is 100%, so baseline is 3. Description adds minor value by noting required params (firstname, phone) and stating 'No prop_id needed,' but does not elaborate on each parameter beyond 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?

Clearly states it registers a new user via POST /auth/register. Distinguishes from siblings by explicitly saying not to call beycome_signin_start after signup.

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?

Explicitly says 'Use when the owner has no account yet.' Provides step-by-step flow: email code sent, next step is beycome_signin_verify, and warns against calling beycome_signin_start. Also covers edge case where email already registered.

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

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

No annotations exist, so the description fully discloses behavior: it returns a pre-authorized URL expiring in 7 days, the listing is created in the browser, and failure modes (401 for bad tokens) are listed. It also warns about the package parameter being a preset index, not a payPremiumOpt reference.

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 detailed but well-structured, with key information front-loaded (purpose, prerequisites). It uses clear paragraphs and warning notes. While slightly lengthy, every sentence adds value for a complex tool, so it is appropriately sized.

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

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

Given the tool's complexity and that an output schema exists, the description covers all necessary aspects: workflow, parameter details, failure modes, post-call actions, and even script for the agent. It is fully complete for an AI agent to use correctly.

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

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

Schema coverage is 100%, but the description adds significant value: for 'package', it explains the mapping from index to price and warns against misuse; for 'list_address', it advises to always pass it; for 'access_token', it specifies the source. This exceeds what the schema alone provides.

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: 'mint a pre-authorized link to the submit-property page' for listing creation. It distinguishes itself from siblings by noting it's the only way to create a listing and directs the agent to subsequent tools like beycome_get_my_listings and beycome_questionnaire_link.

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

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

The description explicitly tells when to use the tool: 'Call AFTER signing in (beycome_signin_verify).' It provides a complete workflow: call this, present the link, user fills out, then call beycome_get_my_listings. It also states there is no in-chat alternative, giving clear usage context.

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