Elron Club Public Rentals

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

Annotations already declare it is non-read-only, idempotent, non-destructive, and closed-world. The description adds useful behavioral context by naming the verification steps—uploaded object, content signature, session ownership, expiry, and exact application version—before the protected document record is created. It does not describe failure modes or error behavior, but with annotations and an output schema present, this is still solid.

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 efficient sentence that front-loads the verification action and ends with the resulting record creation. There is no redundant or filler content.

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 description covers the purpose and some preconditions for a mutation tool with four required parameters, and the output schema can explain return values. However, it leaves a meaningful gap around parameter usage, especially idempotencyKey, and does not explain where the session/version values come from or what happens on verification failure.

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% across four required parameters, so the description must carry the semantic burden. It gives partial meaning by referring to 'exact application version' and 'session ownership, expiry', which likely correspond to expectedVersion, sessionToken, and uploadSessionId, but it never mentions idempotencyKey and does not clearly map concepts to parameter names.

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: verifying upload details and then creating a protected document record. It is clear this is the completion/finalization step for a signed application-document upload, though it does not explicitly distinguish itself from sibling tools such as applications.upload_document or applications.create_document_upload.

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

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

Usage is implied by 'Verify the uploaded object' and 'before creating the protected document record', suggesting this is called after an upload. However, it does not explicitly state when to use this tool versus create_document_upload, upload_document, or get_status, nor does it name alternatives or exclusions.

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

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

Annotations already declare non-read-only, idempotent, non-destructive, open-world, so the safety profile is covered. The description adds genuinely non-derivable behavior: a 15-minute expiry window and strict enforcement of exact size and content type, plus an email-verification prerequisite and version pinning. What is missing is the failure behavior on version conflict or expiry.

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

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

One dense sentence, front-loaded with the verb and resource, with no filler. The stacked 'exact-size and exact-content-type' phrasing is compact but slightly awkward; nothing is wasted, though nothing is unpacked either.

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

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

An output schema exists so return values need not be explained, and annotations cover the safety profile. But for a seven-parameter, all-required tool with no schema descriptions, the definition leaves the identity and role of sessionToken, contextKey, and idempotencyKey unexplained, and gives no guidance on retry or conflict handling.

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% across seven required parameters, so the description carries the burden and only partially meets it: it conveys that expectedVersion must be the exact current version, mimeType/sizeBytes must match exactly, and that a verified session is involved. It never maps these constraints to parameter names, and contextKey, fileName, and idempotencyKey semantics go unaddressed.

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?

Specific verb (Create) plus a precisely characterized resource (a signed upload form), with scoping qualifiers — 15-minute lifetime, exact size/content type, one email-verified application, current version. This implicitly separates it from applications.upload_document and complete_document_upload, though neither sibling is named, so the agent must still infer which step of the flow this is.

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 preconditions (email-verified application, exact current version, exact size and MIME type) hint strongly at when the tool is valid, but there is no explicit statement of when to use this versus applications.upload_document or complete_document_upload, and no stated two-step flow. Usage is inferable rather than instructed.

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, non-destructive and closed-world. The description adds real value beyond them: it discloses that it returns the customer's personal information (a privacy constraint on how the result may be handled) and that unverified, expired and revoked sessions are refused. It doesn't cover rate limits or what happens with a malformed token, but this is well beyond the annotation baseline.

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 tight sentences, front-loaded with what is returned, followed by the privacy constraint and the refusal conditions. No filler; each sentence carries distinct 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?

An output schema exists, so return-value detail is unnecessary. For a single-param read tool with full annotations, the description covers purpose, privacy handling and failure modes well. The only gap is how a session token is acquired or how sessions relate to applications, which would help an agent recover from a refusal.

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?

Only one parameter (sessionToken) and schema description coverage is 0%, so the schema says nothing about what a session token is or where it comes from. The description implies the token belongs to an email-verified session but doesn't explain its provenance, lifetime, or how to obtain it. It partially compensates but the gap remains.

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

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

States a specific verb (read) and resource (email-verified request session, its customer-editable fields and current version). The title and description align. It doesn't explicitly contrast with the mutation siblings like applications.update or applications.get_status, so it stops short of a 5.

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

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

Implicit guidance: use this to read draft/session state, and the refusal conditions (unverified, expired, revoked) tell the agent when the call will fail. But it never names alternatives such as applications.get_status or applications.update, leaving the agent to infer the boundary itself.

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, non-destructive behavior, so the safety profile is covered. The description adds important context beyond annotations: the returned URL contains a scoped credential and should not be shared or logged, and the document must belong to the email-verified session.

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

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

Three short sentences, front-loaded with the core action and followed by the security warning and parameter-source guidance. Every sentence contributes useful information with no repetition 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?

The tool is a read-only retrieval operation with annotations and an output schema, so return-format details are not required. The description covers the security-sensitive credential behavior and documentId sourcing, though it leaves sessionToken semantics under-explained.

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 where documentId comes from via applications.list_documents, but it does not explain the required sessionToken parameter beyond an implicit reference to the email-verified session.

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: return an authenticated binary-download URL for one document. It also scopes the operation to documents owned by the email-verified session, which distinguishes it from list/upload/remove document operations.

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 tells the agent to use documentId from applications.list_documents, which gives a clear call sequence. It does not state when not to use it or name alternatives for other document actions, but the retrieval use case is unambiguous.

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, non-destructive, and closed-world, so the safety profile is covered. The description adds one genuinely useful trait, 'privacy-minimized', hinting that personal data is redacted, but says nothing about token expiry, invalid-token errors, or polling behavior.

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

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

One sentence with zero filler, front-loading the verb, the returned content, and the scope. Nothing repeats or pads.

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?

Output schema and annotations carry the return shape and safety profile, so the description only needs purpose and scope, which it supplies. Minor gaps remain around token provenance and failure modes for an otherwise simple one-parameter read.

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 parameter burden. It does clarify that the single parameter is a scoped application session token (not an application ID), which is useful, but it does not explain validity constraints, lifetime, or how the token is obtained.

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

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

States a specific verb ('Read') and resource ('status and next actions') scoped to one application session. The scope as a single-session read makes it reasonably distinguishable, but it never contrasts itself with the sibling applications.get, which likely overlaps.

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 explicit when-to-use, when-not-to-use, or alternative routing is given against siblings like applications.get or applications.list_documents. The only usage signal is the implied 'one token at a time' scope, which an agent must infer.

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, non-destructive behavior, so the safety bar is met. The description adds genuinely new context: results are session-scoped and deliberately exclude storage keys and employee data, which tells the agent what it will and won't get back. It stops short of noting pagination or result limits.

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

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

Three short sentences with zero filler, leading with the operation and scope. Every sentence carries distinct information (scope, follow-up usage, output exclusions).

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

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

An output schema exists so return structure needn't be described, and the description appropriately focuses on what is omitted from results. For a single-parameter read tool with rich annotations, the only real gap is sessionToken sourcing and any result-size behavior.

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 one parameter at 0% schema description coverage, the description must compensate. It hints that sessionToken is an email-verified session token, but gives no format, source, or lifecycle detail for the value. The documentId reference is a return-field hint, not a parameter explanation.

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 (List) and resource (document metadata) with an explicit scope: 'owned by the email-verified request session'. This scope sentence distinguishes it from siblings like applications.get_document, which retrieves a single document by ID.

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

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

It explains the downstream workflow ('Use documentId with applications.get_document or applications.remove_document'), which implies this is the entry point for discovery. However, it never states when to call this versus other listing/status siblings (e.g., applications.get_status) or any precondition for the session token beyond it being verified.

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 annotations already declare the operation destructive and idempotent, but the description adds useful state constraints: submitted requests are locked, and exact retries replay the receipt rather than repeating side effects. It does not explicitly mention the confirmed=true requirement, which is an important behavioral precondition for a destructive action.

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 front-load the core action and scope, then add the critical locked-state and idempotency rules. There is no 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 destructive 5-parameter mutation with an output schema, the description covers the key draft-state and retry behavior well. However, with zero schema parameter descriptions, it leaves important invocation details unexplained, especially the mandatory confirmed boolean and sessionToken.

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 documentId (from applications.list_documents) and expectedVersion ('current version'), and hints at retry/idempotency behavior, but it does not explain sessionToken or the required confirmed parameter.

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 precise verb and resource ('Remove one explicitly selected document') and scopes it to an editable, email-verified request draft. It clearly distinguishes this operation from listing documents by naming applications.list_documents as the source of documentId.

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

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

It states exactly when removal is allowed (editable, email-verified draft) and when it is not (submitted requests remain locked). It also points to applications.list_documents for obtaining the documentId, leaving little ambiguity about when to use this tool.

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 it is a non-destructive, idempotent, open-world mutation, so the safety profile is covered. The description adds real context beyond that: stage/selection rules are enforced server-side by the website service, and the selection is frozen once the request is submitted. It omits concurrency behavior despite requiring an expectedVersion token.

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 sentences, zero filler. The core action and the ID source are front-loaded, and the constraint sentence follows as the natural caveat.

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

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

An output schema exists, so return values need no explanation, and the context/precondition story is well told. But for a mutation with five required parameters including an optimistic-concurrency token and a confirmation flag, the description leaves an agent without guidance on sourcing expectedVersion or the meaning of 'confirmed'.

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 carries the full burden, yet it explains only rentalId's provenance. The four other required parameters – sessionToken, expectedVersion (where to obtain the current version), idempotencyKey, and the const true 'confirmed' double-confirm flag – get no explanation anywhere.

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 ('Select a published apartment by rentalId') plus the scope ('within the customer's verified, editable inquiry context'). It ties itself to rentals.search as the ID source, though it never distinguishes itself from the other applications.* mutators (update, start, submit) a sibling-aware agent might confuse it with.

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?

Preconditions are explicit: the apartment must be published, rentalId must come from rentals.search, and the inquiry must be verified and editable. The exclusion is also stated – 'submitted requests cannot change apartments' – which tells the agent when NOT to call. No alternative tool is named for swapping a selection, so it falls just short of a 5.

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 mutation, idempotency and non-destructiveness, so the bar is lower. The description adds real value beyond them: it clarifies that each boolean is the customer's actual choice (not a default) and explicitly states the operation neither submits a Request nor signs a contract, scoping its 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?

Two sentences, zero waste, with the core action and the key exclusion front-loaded. Every clause 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?

An output schema exists so return values needn't be explained. But for a 7-required-parameter mutation at 0% schema description coverage, the description omits how expectedVersion or idempotencyKey govern the call, leaving an agent to infer concurrency and retry behavior from parameter names alone.

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 parameter meaning. It explains the semantics of the three consent booleans ('each boolean is the customer's actual choice') but says nothing about sessionToken, expectedVersion, idempotencyKey, or the const-true confirmed flag, leaving half the parameters undocumented.

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

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

States a specific verb and resource ('Record ... consent choices') with a clear scope ('on an editable draft'). The line 'this does not submit a Request or sign a contract' functionally separates it from applications.submit, though no sibling is named explicitly, keeping it just short of a 5.

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

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

'On an editable draft' and 'this does not submit a Request or sign a contract' give a when-not boundary, and 'verified customer' implies a prerequisite. However, no alternative tool is named and there is no explicit statement of when this step should be performed in the application flow.

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 mutability, idempotency, and closed-world scope, but the description adds real value beyond them: duplicate-safe reuse semantics, the consent requirement, and the side effect that an email verification is sent while the URL is never returned. It does not explain what happens on the reuse path (e.g., whether an existing workspace is returned unchanged) or failure modes for stale consent.

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 front-loaded sentences: the identity/scope first, prerequisites second, side effects and limitations last. No filler, and each sentence contributes distinct operational 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 mutating, multi-parameter tool with an output schema (so return values need not be described), the description covers scope, consent, idempotency, and the email-verification side effect. It omits the natural next step in the flow (e.g., the follow-up submit call) and the meaning of the journey choice, which would complete the picture for an agent coordinating the workflow.

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 0% schema description coverage across 12 parameters, the description must carry semantics, and it does explain the most bespoke ones: idempotencyKey (duplicate-safety) and the privacy consent fields (must be current). It says nothing about journey (INQUIRY vs APPLICATION), desiredDurationMonths, requestedParkingCount, or locale, so the compensation is only partial.

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

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

The description names a specific verb pair ('create or reuse') and resource ('duplicate-safe applicant workspace for one published rental'), which is far more informative than the bare tool name. It does not explicitly contrast itself with siblings like applications.submit or applications.update, so it lands just short of the top score.

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?

Prerequisites are stated ('one published rental', explicit current privacy consent, idempotency key), which implies when the tool is callable. However, there is no explicit guidance on when to use this versus applications.update, applications.submit, or applications.get_status, and no exclusion conditions are given.

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

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

Annotations already declare readOnly=false, idempotent=true, non-destructive, so the safety profile is covered. The description usefully adds prerequisites (email verification, explicit consent) but does not explain the concurrency behavior implied by expectedVersion (conflict/failure outcome) or what submit does to the application state afterward.

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 dense sentence that front-loads the core action and then lists requirements. No wasted clauses, though the packing of four distinct prerequisites into one sentence slightly hurts scannability.

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?

Output schema exists so return values needn't be explained, and annotations cover safety/idempotency. However, for a mutation with a version-guard the absence of conflict/failure semantics and of sessionToken provenance leaves a meaningful gap 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 description coverage is 0%, so the description must carry parameter meaning. It explains expectedVersion ('exact version'), the two consents, and the idempotency key, but never mentions sessionToken or consentVersion, so two of six parameters get no semantic help beyond the schema's const/pattern constraints.

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 ('Submit one complete email-verified application for review') with strong qualifying adjectives that separate it from siblings like applications.update or applications.set_consents. It doesn't explicitly name an alternative, but the intent is 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?

Usage is only implied: 'complete... application for review' suggests this is the final submission step after documents/consents are set. There is no explicit when-to-use vs. when-to-use-instead guidance (e.g., 'use set_consents first, then submit'), leaving the agent to infer the workflow order.

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?

Adds substantial context beyond annotations: expectedVersion is an optimistic-concurrency token, idempotency keys are durable, insurance choice is optional and never activates cover, referral consent must be explicit, and a household edit without insuranceSelection silently clears existing sharing permission. That last point is a data-losing side effect worth flagging against destructiveHint=false, but the description discloses it rather than hiding it, so this is a tension rather than a contradiction.

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 front-loaded sentences with no filler; the concurrency/idempotency contract comes first and the caveats follow. Slightly dense and telegraphic ('bounded applicant, tenancy, billing and manual insurance-offer selection'), but every sentence carries 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?

Given 45 parameters and a mutation tool, the description covers the critical invariants (version, idempotency, insurance optionality, clearing behavior) and an output schema exists so return values need not be described. What is missing is the general update semantics: whether omitted fields are left untouched or cleared (only the insurance case is stated), and how tenantProfiles/companyTenantSigners arrays merge with existing records.

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% across 45 parameters, so the description must compensate and it only partly does: it explains semantics for the three required parameters (version, session token, idempotency key) and for insuranceSelection, plus category labels for the rest. The remaining ~40 fields (tenantPartyMode, parkingInterest, companyTenant* fields, etc.) get no meaning beyond their names.

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 (update) and resource (a verified Elron Club application) and names the data domains in scope: applicant, tenancy, billing and insurance-offer selection, tied to one email-verified session. It is clearly differentiated from creation/read siblings by the 'verified'/'exact current version' framing, though it never names an alternative tool 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?

Prerequisites for invoking are spelled out (email-verified session, exact current version, durable idempotency key), which is real guidance. But it never says when to prefer this over applications.set_consents or applications.submit, even though the description touches on consents-adjacent behavior (referral permission) that a sibling owns; the agent has to infer 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?

Annotations already declare readOnly=false, idempotent=true, destructive=false and openWorld=false, so the bar is lower; the description still adds real context: files are 'bounded', the target application must be email-verified, and the version must match exactly, implying conflict behavior. It stops short of stating what a version mismatch or idempotent replay actually returns.

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

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

A single front-loaded sentence with no filler, stating resource before constraints. It is densely packed with qualifiers, which slightly hurts scannability but nothing is wasted.

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

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

Output schema and annotations relieve it of covering returns and safety, and the description flags the version and idempotency risks. However, for an 8-required-parameter mutation with 0% schema descriptions, the missing explanation of contextKey and sessionToken leaves an agent guessing how to target the application at all.

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% across 8 required parameters, so the description must carry the load, but it only gestures at expectedVersion, idempotencyKey, mimeType and size. The two most opaque parameters, contextKey and sessionToken, plus contentBase64 encoding and fileName rules, get no explanation beyond their names.

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?

Specific verb+resource ('Upload ... document to ... application') with concrete constraints: one file, allowed formats, exact version, idempotency key. It does not differentiate itself from the closely named siblings applications.create_document_upload and applications.complete_document_upload, leaving the agent to infer the place in the upload lifecycle.

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?

Preconditions are implied ('email-verified application', 'exact version'), which hints at when this call is valid, but no alternative is named and no explicit when-not guidance is given, even though create_document_upload and complete_document_upload are obvious candidates to route against.

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 destructiveHint=true and idempotentHint=true, so the safety profile is structured. The description adds genuine context by bounding the destruction (cancels inquiry arrangements, not contracts or tenancies) and naming the alternative channel. It stops short of saying whether withdrawal is reversible, what state the application ends in, or how the destructive action interacts with the confirmed flag.

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 sentences with no filler and the action front-loaded, which is good. But the prose is weighed down by internal jargon ("the owning inquiry," "owns the journey") that obscures more than it conveys, so the compactness comes partly at the cost of clarity.

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

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

An output schema exists, so return values need not be described, and the destructive scope is covered. The gap is operational: a five-parameter destructive mutation with a version guard and idempotency key is called without any explanation of versioning, retry semantics, or what the confirmation flag enforces. An agent could invoke it and hit version conflicts or mis-set confirmed without warning.

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% across five parameters, and the description says nothing about any of them. The concurrency token (expectedVersion, a date-time), idempotencyKey, sessionToken and the const-constrained confirmed flag are completely undocumented; the schema gives only types and a maxLength. With zero coverage the description was required 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 gestures at the action ("Record the customer's explicit loss of interest... and cancel its arrangements") rather than plainly stating "withdraw this application." The phrase "owning inquiry" and the title's "viewing inquiry" blur the line against the sibling viewings.cancel, which is the exact distinction an agent most needs. It does carve out an explicit negative scope ("cannot cancel a contract or tenancy").

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

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

It gives one concrete exclusion: once a Request owns the journey, contact the team instead. That is real routing guidance, but it names no sibling tool (viewings.cancel, viewings.decline_proposals, applications.update) and states no precondition for the normal case. Usage is implied 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.

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

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description does add real value beyond them: the output is privacy-minimized (redacted) and the call is gated on a conversion state. It stops short of saying what failure looks like when the gate isn't met, which is the one behavior an agent most 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?

A single front-loaded sentence with the action first and no filler. It is efficient, though a portion of its brevity comes from compressing meaning into opaque internal terms rather than genuinely economical 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?

An output schema exists, so return values need not be explained. But for a tool whose sole required parameter is undescribed, and whose gating condition is stated in terms an agent cannot act on, the definition is not sufficient to invoke it confidently.

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

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

With one required parameter (sessionToken) and 0% schema description coverage, the description carries the full burden and says nothing about it — not where the token comes from, its lifetime, or what scope it must represent. This leaves the only input undocumented in both schema and prose.

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 verb+resource pair ('Return a ... booking confirmation') is identifiable, but 'privacy-minimized' and 'authoritative Stay workflow' are internal jargon that an outside agent cannot decode. Nothing distinguishes it from siblings such as reservations.get_status or payments.get_status, which also deal with post-booking state.

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 clause 'only after the request has converted into the authoritative Stay workflow' implies a precondition but never states it operationally (what 'converted' means, what happens if it hasn't, or which sibling to call instead). No alternatives are named among the 26 siblings.

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

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

Goes meaningfully beyond annotations: discloses the side effect that an existing receipt email may be sent, the token-only constraint for resident support, and the retry contract for idempotencyKey, which complements idempotentHint=true. It stops short of stating what a successful submission produces or what happens if a token is invalid or expired.

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?

Four tight sentences with no filler, and the highest-value constraint (idempotencyKey reuse on retry) is placed last as an explicit warning. Slightly dense sentence-packing in the second sentence costs it a point.

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

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

An output schema exists, so return values needn't be explained, and the side-effect and retry behavior are covered. But for a 13-parameter, 6-required mutation with zero schema descriptions, the absence of per-category field requirements leaves an agent guessing at 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 description coverage is 0% across 13 parameters, so the description must carry the burden and does not. It adds meaning only for category, idempotencyKey and photoUploadTokens; name, email, message, confirmed, locale, companyName, apartmentCount, desiredMoveInDate and apartmentOfInterest are entirely unexplained, and there is no guidance on which fields each category requires.

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?

Specific verb ('Send') plus four precisely named request types that map one-to-one onto the category enum. It also disambiguates from the sibling contact.upload_photo by explaining that tokens come from there, so an agent can route without opening either schema.

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 four enumerated categories give clear selection context, and the resident-support clause implies a boundary (photo tokens only, no tenancy record access). However, it never states what to do instead when a request falls outside this public intake, e.g. which sibling handles applications or viewings flows.

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 flag this as a write operation with idempotency and open-world behavior, and the description adds material context they don't carry: the sanitizer strips metadata, the returned token is single-use and expires in 30 minutes, URL/storage-key inputs are refused, and retries must reuse the same key. That is exactly the kind of operational detail an agent needs before calling a mutation 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?

Four sentences, each carrying a distinct constraint, front-loaded with the core action and the hard limits. No filler and no restating 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 write tool with five required parameters, the description covers format, size, sanitization, token lifetime, and retry policy, and an output schema exists so return values need no explanation. The unanswered `confirmed` flag and unexplained fileName keep it from being 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?

With 0% schema description coverage, the description must compensate and largely does: it explains the base64 content format, the JPEG/PNG restriction, the 5 MiB ceiling, and the retry semantics of idempotencyKey. It leaves two gaps, though: fileName is never discussed, and the required `confirmed: true` flag is never explained, so the agent cannot tell what it is attesting to.

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?

A specific verb and resource ('Upload one ... support photo') with hard scope limits (JPEG/PNG, 5 MiB, base64) are stated in the first sentence. It also positions itself relative to the sibling contact.submit by naming the token that tool consumes, so an agent can distinguish it from applications.upload_document.

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

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

It gives clear operating context: the photo must be customer-approved, arbitrary URLs and storage keys are rejected, and the idempotencyKey must stay stable across retries. It implies the follow-on step (contact.submit) without explicitly stating when to prefer it over upload alternatives like applications.upload_document.

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, non-destructive, and closed-world, so the safety profile is covered. The description adds genuinely new context: the URL is gated on signer-invitation email matching the verified session, and verification/review/signature are explicitly not performed here. It does not say what is returned when the condition fails, which is the remaining gap.

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

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

Two tight sentences with no waste, and the gating condition is front-loaded before the scope disclaimer. Every clause carries information the agent needs.

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

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

An output schema exists, so return-value shape need not be explained, and the description covers the security precondition and the tool's boundary. The one missing piece is behavior on a failed match (error vs. empty result), which an agent calling this would want to know.

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 single required 'sessionToken' has no documented meaning in the schema. The description partially compensates by tying it to an 'email-verified application session', but it never states the token's origin, format, or failure mode when expired or mismatched.

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

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

The description names a specific verb and resource ('Return a secure signing URL') and scopes it to an email-matched, verified application session. It is unambiguous about what the tool produces, though it never names or contrasts a sibling, which is acceptable given no sibling in the list overlaps with this function.

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 email-match condition is a success precondition rather than a statement of when to call the tool versus something else. An agent can infer this is the step after human verification and review, but no alternative paths or exclusions are stated, so usage is implied rather than guided.

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 establish readOnly/idempotent/non-destructive, and the description still adds substantial context: content parity with the public site, a special-case return shape for the after-hours-emergencies article (Europe/Zurich schedule status, observation time, published schedule, Swiss emergency numbers), interpretation caveats, and explicit negative disclosure of what is NOT returned (credentials, staff notes, case data).

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

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

Purpose is front-loaded in the first sentence and no sentence is pure filler. The after-hours sentence is very dense and the two policy-style caveats are borderline, but they do inform how an agent should present the returned content rather than being repetition.

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

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

An output schema exists and annotations are rich, so return values and safety are adequately covered, and the special-case return is even explained. The remaining gap is parameters: with 0% schema coverage, the agent gets no guidance on what articleId accepts or how locale behaves, which is the one thing needed to call this 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 carry parameter meaning, and it does not. 'Localized' only hints at the locale parameter without naming it or its de/en values, and 'after-hours-emergencies' hints at an articleId value but never documents the articleId format, length limits, or the de default.

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 ('Read ... article') and adds a meaningful guarantee: the content is the same approved localized article served on the public website, including related answers and next steps. It never names help.search, so the get-vs-search distinction is left implicit, which keeps it out of the top band.

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

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

There is no statement of when to call this versus help.search, and no mention that an articleId must already be known. The only implicit signal is that the tool takes a specific article ('after-hours-emergencies'), which an agent could infer means 'use search first', but the description never says so.

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/non-destructive/closed-world, and the description adds meaningful scope boundaries: the corpus is 'approved' (curated) content only, it excludes personal tenancy data and live pricing, and results are IDs plus canonical links. It does not describe pagination behavior or how locale affects results, which keeps it below the top score.

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, zero filler: purpose first, return shape second, routing/exclusions last. Every clause carries distinct information and the most decision-relevant content is 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?

Annotations and the output schema cover safety and return values, and sibling routing is complete, but with 0% schema description coverage the definition leaves the agent without guidance on category selection or paging (limit 1-30, offset to 1000). Adequate overall, yet not fully self-sufficient for 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 description coverage is 0% across five parameters, so the description must compensate and mostly doesn't: only the DE/EN axis is implied via 'DE/EN guidance'. The query, category enum values, limit range and offset/paging semantics are never explained in prose, leaving the agent to read raw schema types alone.

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 concrete verb+resource ('Search ... Help Center guidance') and pins the content domain and audiences ('approved general DE/EN guidance for applicants, residents and coworking guests'). It also names the return shape (article IDs and canonical links), which separates it cleanly from sibling help.get.

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 routes three adjacent needs elsewhere: emergency guidance and office-hours status go to help.get with articleId after-hours-emergencies, apartment availability/prices go to rentals tools, and personal tenancy details require the resident's portal. Both when-to-use and when-not-to-use are stated with named 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 establish read-only, idempotent, non-destructive behavior. The description adds meaningful semantic context beyond them: legal documents are information rather than acceptance of terms, and personal facts are out of scope. There is no contradiction with the 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?

Three short sentences, front-loaded with purpose; each sentence adds a distinct scope or boundary clarification. No sentence is redundant or wasted.

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

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

For a simple read-only tool with rich annotations and an output schema, the description is largely complete for selection: it covers scope, language and a key exclusion. It leaves individual topic mapping and help-tool alternatives implicit, so it is not 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 description coverage is 0%, so the description must carry parameter meaning. It explains locale as English/German and groups topics into company, corporate-housing, contact and legal, but it does not account for all seven enum values (e.g., home, about) or mention the default locale.

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

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

The description names a specific verb and resource: 'Read the current English or German company, corporate-housing, contact or legal information.' It covers most topic categories, though it does not mention 'home' or 'about' or distinguish this from help.get/help.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?

It states the public-information scope and explicitly redirects personal tenancy facts to the resident portal, which is a useful exclusion. It does not name a sibling tool alternative for general help, so it falls short of full when/when-not/alternatives 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?

Beyond the annotations (idempotentHint/destructiveHint/readOnlyHint), the description adds real behavioral context: preconditions (email-verified draft, explicit customer confirmation), dedup semantics ('Existing inquiries are reused'), and an irreversible outcome ('Submitted requests cannot switch back'). It does not mention auth/expiry of the session token or failure modes.

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

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

Three tight sentences, front-loaded with the action and state transition, with no filler. The phrase 'using its current version' is slightly cryptic about what 'version' refers to, a minor clarity cost rather than padding.

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

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

An output schema exists so return values need no explanation, and the preconditions and irreversibility are covered. However, for a four-parameter, fully-required mutation with zero schema descriptions, the auth/session parameter and the idempotency key still have no explanatory home.

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 carries the burden. It glosses two of four params — 'using its current version' (expectedVersion) and 'explicit customer confirmation' (confirmed) — but leaves idempotencyKey and sessionToken entirely unaddressed; idempotency is at least implied by the annotations.

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?

Names a specific verb and resource ('Activate the email-verified draft as a viewing inquiry'), not a restatement of the tool name. The state transition (draft -> inquiry) is clear and the note about submitted requests clarifies the lifecycle boundary. It stops short of naming a sibling tool to contrast against, which keeps it at 4.

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 draft must be email-verified and the customer must explicitly confirm, and 'submitted requests cannot switch back to an inquiry' is a when-not condition. No alternatives are named (e.g., when to prefer a viewing request or an application submit path), so the agent must infer the 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?

Annotations already declare readOnly, idempotent, non-destructive, closed-world, so the description needn't restate safety. It adds domain-specific behavioral facts: only published roles are readable, and the tool never sends an application or makes a hiring decision — a meaningful guardrail given the many applications.* siblings. Locale behavior (which language content is returned) is not disclosed.

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, front-loaded with the core action, then the disambiguating guardrail. No filler and nothing repeated from schema or 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?

With an output schema present, return values need no explanation, and annotations cover the safety profile. The remaining gap is only the locale parameter's effect; otherwise the description gives an agent everything needed 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?

Schema description coverage is 0%, so the description must carry parameter meaning. It adds real value by telling the agent where jobId comes from (jobs.search), but says nothing about the 'locale' enum (de/en, default de) or that it governs the language of the returned role text — half the parameters remain unilluminated.

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

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

States a specific verb ('Read one published role') plus the returned content ('email application instructions') and the identifying parameter source ('jobId from jobs.search'). This clearly separates it from jobs.search (listing) and the applications.* siblings (applying).

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 phrase 'using jobId from jobs.search' establishes the prerequisite workflow — search first, then read the single role — and the negative clause steers agents away from using it as an apply endpoint. No explicit 'when not to use' beyond that, but the routing 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?

Annotations already declare read-only, idempotent, closed-world, non-destructive behavior, so the safety profile is covered. The description adds genuine non-structured context: results are limited to published openings, the return is a set of jobId slugs, and recruitment happens through an email application handoff rather than in-portal.

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 compact sentences, front-loaded with the action and resource, then the follow-up dependency. Every clause earns its place by adding scope or chaining 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?

An output schema exists and annotations are rich, so return values and safety need not be explained. However, for a search tool the description leaves the query semantics and locale behavior entirely unaddressed, which is the main thing an agent would need clarified 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?

Schema description coverage is 0%, so the description carries the full burden for the two parameters, but it says nothing about what 'query' matches (title, keyword, location?) or what 'locale' controls beyond the enum/default in the schema. Only the word 'Search' implies a query, leaving meaningful 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?

States a specific verb and resource ('Search the published elron club job openings') and explicitly names the sibling it feeds into ('Returns jobId slugs for jobs.get'). An agent can distinguish this lookup tool from jobs.get without opening either schema.

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 chaining statement ('Returns jobId slugs for jobs.get') tells the agent this is the entry point that precedes a detail fetch, which is clear usage context. It stops short of naming when NOT to use it, and no alternative search path is mentioned.

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, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description's added value is the 'published' qualifier, telling the agent only published locations/media/slugs are returned, which is real behavioral context beyond annotations. It stops short of saying what happens for an unpublished or unknown locationId, which is the remaining gap.

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 sentences, front-loaded with what is returned and followed by identifier provenance and a sibling disclaimer. Every clause carries information an agent needs; nothing is padded.

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

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

With an output schema present the return shape needn't be explained, and annotations cover the safety contract, so the description only needs purpose, identifier source, and scope. Those are all present; the only omission is the effect of the locale parameter and error behavior for unpublished IDs.

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 parameter meaning; it does this well for locationId by naming its source (locations.search) and length-bounded string type. However, the locale parameter (enum de/en, default de) is never mentioned, so the agent gets no explanation that it controls the language of the returned content.

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 a precisely enumerated resource set: published building and neighborhood information, media, and apartment slugs. It also implicitly delimits scope against siblings by noting where pricing and rental details live (rentals.get) and where the identifier comes from (locations.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?

Gives the prerequisite for calling it ('using locationId from locations.search') and an explicit routing alternative for the adjacent need ('Published rental details and pricing remain available through rentals.get'). An agent can decide between locations.get, locations.search, and rentals.get without opening another schema.

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, non-destructive and closed-world, so the safety profile is covered. The description adds genuinely new context beyond them: results are limited to published/public locations and private property identifiers are excluded, which tells the agent what will and will not come back.

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

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

Two tight sentences: purpose and matching facets first, then the return contract and follow-up tool. Nothing is repeated from the schema or annotations and no sentence is padding.

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

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

With annotations and an output schema already covering safety and payload shape, the description only needs to convey what is searched and what is returned, which it does, including the public-only guarantee. The remaining gap is the lack of any hint about paging or the query string's free-text nature.

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 carries the full burden for four parameters, yet it never names 'query' or explains how city/region/name map onto it (single string? free text?). Limit, offset and locale are not mentioned at all, leaving pagination and language behavior entirely to structural inference.

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 ('Find published apartment buildings') with the searchable facets (city, region, name) and scopes the result to public data only. It also explicitly separates itself from the sibling locations.get by naming it as the follow-up consumer of the returned locationId slugs.

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 workflow ('returns locationId slugs for locations.get') implies when to call it, but there is no explicit when-not guidance or comparison against adjacent discovery tools such as regions.list or rentals.search. The agent can infer the sequence but must guess the boundaries.

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, closed-world and non-destructive, so the safety profile is covered. The description earns credit by disclosing a non-obvious return-value guarantee: an action URL is emitted only from an exact, unexpired provider session and is never fabricated. It doesn't cover expiry behavior or what an absent session yields, which keeps it below 5.

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

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

Two sentences, front-loaded with the core behavior and followed by the one caveat worth knowing. The phrasing 'payment truth' is jargon but costs little space; nothing is padded.

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

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

An output schema exists, so return values need not be enumerated, and the description still flags the most consequential output nuance (the guarded action URL). For a one-parameter idempotent read, the remaining gap is the unnamed sessionToken semantics, which is modest.

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 single parameter sessionToken has 0% schema description coverage, so the burden falls on the description. It adds a partial hint that the token scopes the application, but never explains token origin, expiry handling, or what an invalid/expired token returns.

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: return due and received payment status for the scoped application, which is more precise than the bare name payments.get_status. It does not distinguish itself from the several get_status siblings (applications, reservations, viewings), relying on the namespace to do that work.

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

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

There is no statement of when to call this, when not to, or what alternative exists. An agent must infer from the name alone that this is the tool for checking whether a first payment has been received or is still due.

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?

Goes well beyond the annotations by disclosing the anti-enumeration design: the same generic acknowledgement is always returned and nothing about tenancy existence, identity, codes or links leaks. That is exactly the behavioral context an agent needs before calling. It stops short of stating error behavior for invalid/unregistered emails or any rate limiting, which for an open-world, non-read-only tool would be useful.

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

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

Two tight sentences: the action and its target come first, the privacy/return guarantee second. No filler and nothing buried.

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

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

An output schema exists so return values need no explanation, and the description covers the tool's key risk surface (indistinguishable responses, no data leakage). The remaining gap is input-side: with 0% schema coverage, the required confirmation flag and idempotency key are left unexplained.

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 four parameters exist, only one of which ('email') is indirectly implied by 'the customer's own address'. Nothing explains the purpose or expected value of 'confirmed', 'idempotencyKey', or 'locale', so the agent gets no help on three of four required-or-optional inputs.

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: request the existing resident-portal access email for the customer's own address. It is unambiguous and clearly distinct from every sibling (application, booking, payment, viewing tools), none of which touch portal access recovery.

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 establishes the scope — the customer's own address only — and explicitly hands off identity verification and personal tenant actions to the private resident portal. That is a clear when-not boundary, though it names no alternative tool or precondition workflow (e.g. what a customer without an existing account should do).

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 the write/idempotent/non-destructive profile, and the description adds meaningful context on top: atomicity, the 30-minute expiry, request ownership of the hold, and the explicit non-effects (no contract, no payment). It does not disclose what happens on a stale quote version or whether an acceptance can be undone, which are the remaining behavioral gaps.

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

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

Two tight sentences: the action and its precondition first, then the exclusions. Every clause carries information an agent needs before invoking.

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

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

With a rich annotation set and an output schema present, the description needn't explain returns; it covers preconditions, side effects, hold duration, and non-effects. What's missing is failure behavior on version mismatch or an already-held quote, which matters for a concurrency-guarded mutation.

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 the burden. It conveys the confirmation gate (acceptanceConfirmed) and hints at version pinning via "one exact active quote," but never explains expectedQuoteVersion's conflict semantics, nor the roles of sessionToken or idempotencyKey, leaving three of five required params uninterpreted.

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 (accept) and resource (one exact active quote) plus the atomic side effect (claiming a 30-minute availability hold). This is clearly distinguishable from quotes.get, quotes.create, and contracts.get_signing_link without opening any schema.

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?

Gives an explicit precondition ("with explicit customer confirmation") and negative boundaries ("does not create or sign a contract and does not authorize payment"), which steers the agent away from contract and payment siblings. It stops short of naming a specific alternative tool to use when those conditions aren't met.

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 the safety profile (non-read-only, idempotent, non-destructive, closed-world), so the bar is lower. The description adds real value beyond them: the 24-hour expiry window, the four precondition gates, and the fact that inventory is not held. It doesn't say what happens to the quote on expiry or what state the application must be in afterward.

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

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

Three short sentences, zero filler, front-loaded with the action and its output. Each sentence carries distinct information: the operation, the precondition set, and the inventory caveat.

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

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

An output schema exists so return values need no explanation, and the preconditions are well covered. But for a three-parameter mutation with 0% schema coverage, the description leaves the concurrency and idempotency contracts entirely unaddressed, which is a meaningful gap before calling a version-guarded write.

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 all three required parameters (sessionToken, idempotencyKey, expectedApplicationVersion) are completely undocumented in the schema. The description names none of them and never explains that expectedApplicationVersion is an optimistic-concurrency guard or that idempotencyKey suppresses duplicate quote creation, which are exactly the semantics an agent most needs.

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?

Uses a specific verb and outcome: snapshot approved request terms into a 24-hour quote, and states the object created is a quote with a bounded lifetime. It doesn't explicitly distinguish itself from quotes.get or quotes.accept, so the reader must infer lifecycle position, but the creation semantics are 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?

Gates are stated concretely: the application must be submitted, internally approved, due-diligence positive, and solvency passed. 'This does not hold inventory' is a genuine exclusion that prevents a wrong assumption. It stops short of naming a fallback tool (e.g. applications.submit) when a precondition is unmet.

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, non-destructive and closed-world, so the safety profile is covered. The description adds real value beyond that: the response is 'privacy-minimized' (fields are redacted), the expiry/availability-hold state is 'live' (computed at read time rather than stored), and access requires the application session that owns the quote — an authorization constraint the annotations do not express.

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

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

A single front-loaded sentence that packs verb, resource, returned state and auth scope with no filler. It is dense but readable; the only slight cost is that 'privacy-minimized' and 'availability-hold' are domain jargon an agent must infer meaning from.

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

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

An output schema exists, so return shape need not be described, and annotations cover the safety profile. The description supplies the two things structured fields cannot: the response is redacted and time-sensitive, and the session token must own the quote. Only error/expired-quote behavior is left unaddressed, which is a minor gap for a single-record read.

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 the burden for both parameters. It does partially: 'quote' implies quoteId and 'the application session that owns it' explains the role of sessionToken as an ownership/authorization credential, not just an opaque token. However, neither parameter's format, length bounds, or failure mode on a non-owning session is clarified beyond that.

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 ('Read') and a precisely scoped resource ('one privacy-minimized quote and its live expiry/availability-hold state'), so an agent can distinguish it from quotes.create and quotes.accept without opening the schema. It stops short of naming those siblings explicitly, so the differentiation is implicit rather than stated.

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

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

Usage is implied rather than stated: fetch a single quote by identity, within the owning application session. There is no explicit 'use this when...' guidance, no when-not condition (e.g., for listing or creating quotes), and no mention of what happens if the quote has expired. The owning-session phrase does hint at a prerequisite, which lifts it above a bare 2.

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, destructiveHint=false and openWorldHint=false, so safety is fully covered. The description adds the useful constraint that only *published* regions are returned, but says nothing about how locale affects the returned content or ordering, which is the main behavioral question for this 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, no filler, with the tool's scope stated first and the sibling redirection second. Nothing is redundant with the schema or 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?

An output schema exists, so return structure needn't be explained, and the description characterizes the content (regions, local facts, canonical pages). The only material gap is the unstated effect of the locale parameter on the returned content language.

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?

There is one optional parameter (locale) with 0% schema description coverage; only the enum de/en and default de are given structurally. The description never mentions that content language can be selected, so the agent must infer the parameter's effect entirely from the enum values.

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 set: reading published Swiss regions, local facts and canonical region pages. It's clearly a read-only reference/content tool, distinguishable from the transactional siblings, though the phrase 'elron club regions' in the title is never explained in the description.

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 routes the agent elsewhere for a common adjacent need: 'Use rentals.search for current inventory and availability.' That gives a clear when-not, but there's no positive trigger statement (e.g., when a user asks about a region or local area) and no mention of other reference siblings like locations.get or information.get.

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, non-destructive, closed-world, so the description doesn't need to prove safety. What it adds is the 'published' qualifier (a point-in-time public state, not internal inventory) and the explicit no-hold guarantee, but nothing on staleness, timezone, or rate limits. Useful reinforcement rather than new behavioral depth.

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, both earning their place: the first states what is returned, the second removes the most likely misreading. Front-loaded with zero preamble.

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

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

With an output schema present, the description needn't explain return values, and it covers scope, single-rental targeting, and the no-hold caveat. Minor gaps remain around whether 'availability' accounts for partial periods or locale-dependent output, but nothing essential for a correct call is missing.

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 has to carry parameter meaning. 'for one rental' correctly conveys that rentalId targets a single record, but the locale parameter (enum de/en, default de) is never mentioned or explained. Partial compensation is the right level 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?

Names a specific verb ('check') and a precisely scoped resource: the current published availability state and earliest date for a single rental. This clearly separates it from rentals.get (full record), rentals.get_pricing, and viewings.propose_availability, which an agent can distinguish without opening the schema.

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?

'This does not create a hold or reservation' is a genuine exclusion that steers an agent away from treating the result as a booking step. No alternative tool is named for the case where the caller actually wants to hold dates, so it stops short of full when/when-not 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?

Annotations already declare readOnlyHint, idempotentHint, openWorldHint=false, and destructiveHint=false. The description adds scope that annotations cannot: results are localized, limited to published rentals, and filtered to be 'customer-safe' (i.e., internal fields removed). It does not say what happens when rentalId refers to an unpublished or missing listing.

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

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

A single front-loaded sentence with the verb and scope first, followed by the payload list. The list is dense but every item adds discriminating information about what the record contains; nothing is padding.

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

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

With a full output schema and four annotations, the description need not explain return shape, and it doesn't waste words doing so. However, for a detail-fetch tool it omits the two facts an agent most needs beyond the schema: behavior on unknown/unpublished ids and the default locale.

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 carries more weight than usual. It does explain the effect of the two parameters indirectly — 'localized' accounts for locale, and 'published rental' constrains what rentalId must reference — but gives no format, example, or validity rule for rentalId, and never mentions the 'de' default.

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: 'Return localized customer-safe apartment details' for a published rental. The enumerated payload (pricing, availability, deposit, terms, links) makes clear this is the aggregate detail endpoint rather than a narrow lookup, though it never names the sibling tools rentals.get_pricing or rentals.check_availability that overlap its stated content.

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

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

Usage is only implied by the shape of the tool: fetch the full published detail record for a rental. There is no explicit 'use this when…' or 'use rentals.get_pricing instead for…', which matters here because the description itself advertises duration pricing and verified availability — content the sibling tools also supply. An agent must infer the routing rule.

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

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety bar is low. The description nonetheless adds real behavioral value beyond them: the pricing is "current published" (not a snapshot of historical or negotiated rates) and is explicitly non-binding until a quote or hold is issued, which is exactly the caveat an agent needs before quoting numbers to a user.

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 sentences, zero filler, with the returned dimensions front-loaded and the caveat placed last where it reads as a qualifier rather than a distraction. Every clause 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?

An output schema exists and annotations fully cover the safety profile, so return-value and permission explanation are correctly omitted. However, with a localized pricing tool the total silence on locale and on what a rentalId refers to leaves a gap the description should have closed.

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% for both parameters, so the description carries the full burden and fails it: rentalId (required) is never mentioned, and the locale enum with its "de" default is completely unexplained — an agent cannot tell from this text that pricing output is localized or that locale is even an accepted input.

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

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

Specific verb (Return) plus resource (current published monthly pricing) with the full set of dimensions covered: duration, parking, deposit, inclusions, payment method, minimum-stay terms. It implicitly separates itself from quote-issuing siblings by noting pricing is informational until a quote or hold exists, though it never names quotes.create/quotes.get directly, so it falls short of a 5.

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

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

"Pricing is informational until a quote or hold is issued" hints that this is the browse-before-committing tool and that quotes.create is the next step, but it never states an explicit when-to-use rule or names the alternative tool. Usage is implied rather than prescribed.

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 the read-only, idempotent, closed-world safety profile, so the description only needs to add operational context. It does: results are 'compact' (truncated records), the shortlist defaults to 10 available/upcoming rentals, and complete data lives behind rentals.get. It stops short of describing pagination fields or ordering, which the schema only partially hints at.

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 sentences, both front-loaded with the highest-value information: what the result is, then what it covers, then the escape hatch to rentals.get. No filler or restated title text.

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

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

With an output schema present, return-value description is unnecessary, and all 11 optional parameters are schema-documented. The description is nearly complete for a zero-required-param search tool, missing only ordering/ranking semantics for the shortlist, which matters when 50+ matches exist.

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 91%, so the schema already documents every parameter including enums and formats. The description adds only a high-level naming of the facets (location, availability, capacity, rooms, duration, monthly rent) without syntax or constraint detail, so this is a baseline-3 case where the schema does the heavy lifting.

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 ('Return a compact, actionable shortlist of published furnished apartments') and enumerates the filter facets it operates on. It also signals the boundary with the sibling rentals.get ('for complete details'), so an agent can distinguish search from detail retrieval without opening either schema.

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 routes the agent to rentals.get when full details are needed and discloses the default behavior of 10 available-or-upcoming results. It gives clear usage context but does not name exclusions or alternatives such as rentals.check_availability or rentals.get_pricing, which are also plausible siblings for availability/pricing questions.

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, non-destructive and closed-world, so the safety profile is covered. The description adds one genuinely useful behavioral fact—that the returned data is 'privacy-minimized'—but does not explain what that minimization means concretely, nor anything about session lifetime or failure modes.

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

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

A single compact sentence with the read scope front-loaded and no filler. The enumerated state list is dense but earns its place by telling the agent what progression stages are surfaced.

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

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

With a rich annotation set and an output schema, most structured information is already carried elsewhere, and the description needn't explain return values. However, in a sibling cluster containing four other '*get_status' tools, the missing routing guidance and session-token provenance leave a real gap for an agent choosing between them.

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% for the single required 'sessionToken'. The phrase 'for one application session' implies the token identifies the session being inspected, but the description never explains where the token comes from, its lifetime, or what happens if it is stale.

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

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

States a specific verb (Read) and a specific resource (the progression state for one application session), and even enumerates the state families it covers (hold, contract, signature, payment, reservation, confirmation). It is clear what the tool returns, but it never distinguishes itself from siblings such as applications.get_status or payments.get_status, which read overlapping state.

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 only usage signal is the scoping phrase 'for one application session'. There is no statement of when to call this versus applications.get_status, payments.get_status, or viewings.get_status, and no prerequisites or exclusions are given.

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

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

With destructiveHint and idempotentHint already declared, the description usefully adds that the call only applies to future confirmed appointments (scope bound) and that it may send the existing cancellation communication (external side effect). It does not say whether cancellation is reversible or what happens to downstream state, but the annotation covers 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?

Two compact sentences with the action first and prerequisites after. The middle sentence is slightly list-like and could read more smoothly, but no sentence is wasted.

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

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

An output schema exists, so return values need not be explained. For a destructive open-world mutation, the description covers scope, prerequisites, and the communication side effect; the only real shortfall is not unpacking the required idempotencyKey/note 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 description coverage is 0%, so the description carries the full burden, yet it only glosses expectedVersion ('current request version') and confirmed ('explicit confirmation'). It refers to 'appointmentId or proposalId' rather than the actual target/targetId fields, and never mentions sessionToken, idempotencyKey, or note, leaving a meaningful mapping gap for a 7-parameter 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?

States a specific verb and resource ('Cancel a future confirmed appointment or withdraw the customer's own pending proposal'), covering both modes the enum encodes. It does not explicitly name or contrast with nearby siblings such as viewings.decline_proposals or viewings.respond_to_proposal, so an agent must infer the routing.

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?

Gives concrete prerequisites: identifiers come from viewings.get_details, the current request version is required, and explicit confirmation is needed. It stops short of stating when not to use this versus decline_proposals or respond_to_proposal, so the exclusion case is left implicit.

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?

Beyond the annotations, the description adds important behavioral details: the operation is version-bound, customer-confirmed, and selectively changes only the chosen proposals while preserving later offers. This gives the agent crucial context about confirmation requirements and partial mutation semantics.

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

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

Two tight sentences, front-loaded with the core action and followed by the key preservation caveat. Every phrase adds value with no 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?

Given the 5 required parameters, annotations, and an output schema, the description covers the essential workflow and behavioral constraints. It falls slightly short by omitting any explanation of sessionToken or idempotencyKey semantics, which is important at 0% 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?

With 0% schema description coverage, the description must compensate. It explains 'version-bound' (expectedVersion), 'customer-confirmed' (confirmed), and 'one or more exact ... proposals from viewings.get_details' (proposalIds), but does not clarify the roles of sessionToken or idempotencyKey. Partial compensation yields a baseline score of 3.

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 ('Decline') and resource ('pending elron club proposals from viewings.get_details') and explicitly distinguishes the scope by noting that only selected proposals are changed while later offers are preserved. This differentiates it from related sibling tools like viewings.respond_to_proposal and viewings.cancel.

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

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

It clearly states the context: declining exact pending proposals obtained from viewings.get_details, and clarifies the effect on later offers. However, it does not explicitly name alternative tools or when not to use this one, leaving some inference to the agent.

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 annotations already establish that this is a read-only, idempotent, non-destructive operation. The description adds meaningful context by disclosing that internal notes and unreleased or revoked contact details are excluded, which helps the agent understand the visibility boundary.

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 returned resource types before detailing exclusions. It contains no obvious filler, though the second sentence is dense.

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

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

An output schema exists, annotations cover safety traits, and the description explains the content scope and filtering boundaries. The main remaining gap is the lack of any explanation of the sessionToken parameter, but otherwise the definition is sufficient for 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?

The schema has zero description coverage for the single required sessionToken parameter, and the description does not explain the token's role, format, or constraints beyond the phrase 'session-owned'. It therefore does not compensate for the schema 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 uses a specific verb, 'Read', and names the resource types returned: proposals, availability windows, appointments, and feedback versions. It clearly scopes the data to the customer's session, though it does not explicitly distinguish itself from sibling tools such as viewings.get_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 explains what data is returned but gives no explicit guidance on when to use this tool versus alternatives like viewings.get_status or viewings.get_details. Usage is only implied by the content list.

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=false, so the safety profile is covered. The description still adds real value beyond them: 'customer-safe' signals that internal data is redacted and 'email-verified application session' signals an authorization/scoping requirement. It does not cover behavior for invalid or expired tokens, which keeps it from a 5.

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

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

One front-loaded sentence with no filler; the scope qualifier ('one email-verified application session') comes immediately after the resource. Nothing is redundant with the schema or 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?

An output schema exists, so return-value documentation is unnecessary, and the description covers resource, scope, and safety posture. The remaining gap is operational: no mention of error or expiry behavior for the token in a tool whose only input is that token.

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 single parameter is undocumented in the schema. The description partially compensates by characterizing the session as 'email-verified' and 'application' scoped, but it does not explain the sessionToken's format, origin, or what happens if it is stale.

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

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

States a specific verb ('Read') and resource ('viewing proposals and confirmed viewing state'), scoped to one session. It clearly reads as the read counterpart to the sibling write tools viewings.propose_availability and viewings.respond_to_proposal, though it never names those siblings 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 phrase 'for one email-verified application session' implies when it applies, but there is no explicit when-to-use guidance, no stated preconditions for obtaining the sessionToken, and no reference to alternatives like viewings.propose_availability when the agent actually wants to act rather than read.

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 idempotentHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds genuinely new context: it operates on a verified session, requires an exact version (optimistic concurrency), and explicitly notes that Request approval and legal gates remain in force — i.e., this action does not bypass downstream checks.

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 sentences, no filler, with the core action front-loaded and the constraint/guarantee detail second. The second sentence is dense but each clause carries distinct 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?

An output schema exists, so return values need not be explained, and annotations cover the mutation/idempotency profile. What is missing is failure behavior (stale expectedVersion) and the meaning of the mandatory 'confirmed' flag, so it is strong but not fully complete for a 4-required-param mutation.

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 gives intent for three of four parameters (verified session, exact version, stable idempotency key), which is real value over the bare schema, but it says nothing about the required 'confirmed' flag (const true) or what a version mismatch means, leaving a 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?

States a specific verb (record) and a specific decision (customer's explicit choice to continue without a viewing), which is a distinct outcome from siblings like viewings.decline_proposals or viewings.respond_after_viewing. It does not explicitly name a contrasting sibling, so it stops short of a 5.

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

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

The phrase 'continue the rental journey without a viewing' implies the scenario, but the description never says when to choose this over requesting a viewing, contacting the customer, or responding after a viewing. Usage is inferable but not stated, so this is minimum-viable 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?

Annotations already declare idempotent=true, destructive=false, readOnly=false, so the safety profile is covered; the description adds real context beyond them — bounded 1-5 future slots, an email-verification precondition, and optimistic concurrency via expectedVersion. It still omits what happens on a version mismatch and what replaceProposalIds removes, which is the main behavioral gap for a mutation 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?

A single dense sentence with the action front-loaded and every qualifier carrying information about a constraint. Nothing is padded or repeated from the schema.

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

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

An output schema exists, so return values need not be explained, but for a five-parameter mutation with 0% schema coverage the description should account for replaceProposalIds and the conflict behavior on stale version. As written, an agent could call it correctly only by guessing at those two aspects.

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 carries the full burden. It explains the slots count bound, expectedVersion ('exact version'), and the nature of idempotencyKey ('durable'), but never mentions sessionToken or replaceProposalIds, leaving two of five parameters with no meaning beyond their type.

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 (propose viewing slots) plus hard scope (one to five, future, bounded, from an email-verified application). An agent can tell this is the tenant-side proposal action rather than a landlord-side one, though no sibling such as viewings.set_availability or viewings.respond_to_proposal is named to sharpen the contrast.

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?

Preconditions are embedded ('email-verified application', 'at its exact version'), which implies when the call is legal, but there is no explicit when-to-use versus viewings.set_availability, viewings.respond_to_proposal, or viewings.cancel, and no stated exclusions or failure conditions.

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