Street.co.uk MCP by usefulapi

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

Adds substantive behavior beyond the annotations: email matching to an existing person or person creation, downstream agency automations that may email or assign the lead, and a duplicate-prevention mechanism via enquiry_identifier on retry. These are real side effects an agent must know about and are not derivable from the annotation flags.

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?

Front-loaded with the write mode and purpose, then the constraint sentence, then the retry rule, ending with the HTTP endpoint. Four sentences, each carrying distinct information, no repetition of schema 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?

For a 16-parameter write tool with no output schema, the description covers the critical decision rules and side effects. It stops short of saying what the call returns on success (presumably an enquiry id), which would help an agent chain into street_get_enquiry or follow-up calls.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds the crucial exclusivity rule across property_id / sales_applicant_id / lettings_applicant_id that the schema does not encode (no oneOf/anyOf present). It also explains the semantics of enquiry_identifier as a idempotency key rather than just an id field.

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?

Opens with an explicit mode marker and specific verb+resource: "WRITE: record a new inbound enquiry (a lead) in Street." This clearly separates it from the read-side siblings (street_get_enquiry, street_list_enquiries) and from the other create_* tools by naming the resource precisely.

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 a hard usage constraint that no sibling offers: the enquiry must be tied to exactly one of property_id / sales_applicant_id / lettings_applicant_id. It also states the retry protocol with enquiry_identifier. It does not explicitly say when to prefer this over, say, street_create_follow_up or street_create_note, but the resource naming makes that inferable.

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 write, non-idempotent, non-destructive and open-world, and the description usefully translates the idempotency hint into a concrete consequence ("calling it twice creates two follow-ups") plus the underlying POST endpoint. It adds no detail on authorization, error behavior, or what the call returns, so it stops short of full disclosure.

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 the write nature front-loaded and the idempotency caveat placed before the endpoint reference. No filler or redundant restatement of 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?

For a four-parameter create tool with full schema documentation and complete annotations, the description covers purpose, scope, and the key duplicate-creation hazard. The only gap is that, with no output schema, it does not indicate what the response contains (e.g. the created follow-up identifier).

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

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

Schema coverage is 100% and the description still adds light value by expanding the enum into readable record types, making clear that target_id refers to one of those records. No format or constraint details for due_date or note are added beyond the schema, so it stays near the baseline.

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 ("schedule a follow-up") and enumerates the record kinds it can attach to, which separates it from generic create tools like street_create_note or street_create_task. It never names a sibling explicitly, so differentiation is inferential 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?

The target_type list implies when this tool applies (property, applicants, sale, valuation), but there is no explicit guidance about when to choose a follow-up versus a task or note, and no prerequisites are stated. Usage is inferable from the enumeration but not 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 readOnlyHint=false, idempotentHint=false and destructiveHint=false, so the bar is lower, and the description still adds the consequence of the non-idempotency ('calling it twice logs two requests') plus the downstream workflow (staff convert it into a job). It does not cover authorization requirements or what the response contains, 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?

Three short sentences, front-loaded with the WRITE marker and the request-versus-job distinction, with the endpoint as a trailing implementation hint. No filler sentences.

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 six-parameter write tool with full schema coverage and no output schema, the description covers mode, idempotency and domain role adequately. The one remaining gap is that it never says what a successful call returns (presumably the created request with an ID), which matters for a create operation with no output schema.

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

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

Schema description coverage is 100% and every parameter carries its own description, enum, or format constraint, so the schema does the heavy lifting. The description adds no parameter-level meaning such as defaults for priority or reported_at, so baseline 3 applies.

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

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

States a concrete verb and resource ('log a maintenance request against a property') and immediately disambiguates the most likely confusion, that a request is not a job. An agent can distinguish this from the maintenance-job siblings 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?

The 'a request, not a job: Street staff turn it into a job' clause tells the agent which workflow stage this belongs to and implicitly routes job-level operations elsewhere. It stops short of naming an alternative tool or stating explicit exclusions, so it lands just below the top band.

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=false and idempotentHint=false, so restating non-idempotency is partly redundant — but the description adds the concrete consequence ("calling it twice adds two notes") plus a genuinely new trait: the note becomes staff-visible, which matters for what an agent chooses to write. No mention of permissions or the returned payload.

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; the WRITE marker and the resource are front-loaded, and each sentence carries distinct information (what, who sees it, repeat-call behaviour). Nothing is padded or repeated for its own sake.

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 5-parameter write tool with rich annotations and full schema coverage, the remaining gap is the response: there is no output schema and the description doesn't say whether a note id or the created note is returned. Otherwise an agent has enough 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 100%, so every parameter, including the author_id default and the target_type enum, is already documented in structured data. The description's parenthetical list of record kinds adds only marginal reinforcement, so baseline 3 applies.

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

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

Starts with an explicit verb and resource ("WRITE: add a note to one Street record") and enumerates the record kinds covered, which lets an agent separate it from neighbouring creators such as street_create_task, street_create_follow_up and street_create_enquiry 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?

The note's visibility ("visible to the agency's staff") gives useful context for choosing free-text notes over structured records, but the description never states when to prefer this over the sibling creators or what precondition (a valid target_type/target_id pair) is needed. 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 idempotentHint=false, but the description makes the consequence concrete ('calling it twice creates two tasks'), which is genuine added value for a mutation tool. It also discloses the underlying endpoint (POST /todos). It does not mention permission or auth requirements, and destructiveHint=false is simply consistent with the text rather than elaborated.

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 the write marker front-loaded, then the key non-idempotency warning, then the endpoint. Nothing is wasted and nothing important is 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?

For a mutation tool with no output schema, it covers the write semantics, idempotency behaviour, and endpoint, and annotations carry the safety profile. What is missing is minor: no mention of what the call returns or how failures on invalid user_id/task_type_id manifest.

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 100%, so all six parameters are already documented, including the street_list_users and street_list_task_types lookup hints. The description restates the optional user assignment and task type but adds no format or constraint detail beyond the schema, so baseline 3 applies.

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

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

States a specific verb and resource ('create a task (to-do) in Street') and scopes it with the optional assignment and task type. The resource is clearly distinct from siblings like street_create_note or street_create_follow_up, though it never names those alternatives 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?

No explicit when-to-use guidance or exclusion against sibling creation tools such as street_create_enquiry, street_create_follow_up, or street_create_note. Usage is only implied by the resource being created.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds that included records are requested via `include` and cites the underlying endpoint, but says nothing about not-found behavior or what an omitted `include` 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?

Two compact sentences with the core identity front-loaded and no filler. Every clause 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?

For a simple two-parameter read with full schema coverage and clear annotations, the description is nearly sufficient. Only minor gaps remain, such as error behavior for an invalid UUID, which are low-stakes for a read-only getter.

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 100% – both `branch_id` (with format/pattern and a pointer to street_list_branches) and `include` (with allowed enum values) are fully documented. The description restates the `include` concept but adds no syntax or behavior beyond the schema, so baseline 3 applies.

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

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

States a specific verb and resource ("One branch by UUID") and distinguishes itself from the list sibling by emphasizing a single record with an optional include. It does not explicitly name street_list_branches, but the singular/count distinction is unmistakable.

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 "by UUID" implies you need an id obtained elsewhere, and indeed the schema points to street_list_branches. However, no explicit when-to-use or when-not-to-use guidance is given, and no alternative is named in the description 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?

The annotations already declare that this is a read-only, open-world, non-destructive operation. The description adds the HTTP endpoint and notes that requested related records will be included, but it does not cover error behavior, permissions, or response details beyond include.

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

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

The description is two short sentences with no wasted text. It front-loads the primary purpose and then clarifies include behavior and the endpoint.

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

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

For a simple two-parameter read tool with full schema coverage and annotations covering safety, the description is largely complete. It explains the single-enquiry retrieval and include behavior, though it could say more about the response shape if an agent were expected to rely solely on prose.

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 100%, so both parameters are already documented in the schema. The description reinforces the include behavior but does not add syntax, formatting, or other semantic detail beyond what the schema provides.

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

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

The description clearly states a specific resource and operation: retrieve one enquiry by UUID. It distinguishes the single-record nature from list tools through 'One enquiry' and mentions the optional related-record include, though it does not explicitly name a sibling alternative.

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 purpose of include for fetching related records, which is useful usage context. However, it gives no explicit guidance on when to use this tool versus street_list_enquiries or when to omit include.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds nothing beyond the raw endpoint: no mention of 404 behavior for unknown UUIDs, embedding cost, or what 'included' looks like on return.

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, zero padding, with the core purpose front-loaded before the endpoint reference. Nothing to trim.

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

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

For a simple two-parameter read tool with full schema coverage and existing read-only annotations, the description is nearly sufficient. A brief note about what the response contains (the included embeds) or missing-ID behavior would close the remaining gap.

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

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

Schema description coverage is 100% — both inspection_id (UUID pattern, sourced from street_list_inspections) and include (allowed enum values, maxItems 3) are fully documented in the schema. The description only restates the include behavior, so baseline 3 applies.

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

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

States a specific verb (get) and resource (one inspection) keyed by UUID, and mentions the include mechanism. It implicitly distinguishes itself from the many list_* siblings by emphasizing a single record, though it never names street_list_inspections as the alternative.

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

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

Usage is only implied: an agent infers this is the single-record counterpart to street_list_inspections. There is no explicit when-to-use/when-not or prerequisite statement in the description itself (the ID provenance hint lives in the schema, not the description).

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 readOnly/destructive annotations already establish this as a safe read, so the description only needs to add context. It does add that include controls embedding of related records, but says nothing about errors, missing-record behavior, or what 'included' contains beyond what the schema states.

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 what is returned, followed by a compact endpoint identifier. No filler and nothing redundant.

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 single-record read with full annotation coverage, complete parameter docs, and a sibling list tool, this is nearly sufficient. The only real gap is that with no output schema, the shape of the returned applicant and its 'included' array is 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 100%, so the schema already documents both parameters, including the id source and the allowed include values. The description's mention of include adds no meaning beyond 'related records you ask for in include,' so baseline 3 applies.

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

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

States a specific verb and resource ('One interested applicant by UUID') and includes the underlying endpoint GET /interested-applicants/{id}. The singular 'One ... by UUID' distinguishes it from street_list_interested_applicants, but it does nothing to differentiate from the other applicant-type getters (lettings/sales) that populate the sibling list.

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 UUID' suggests it is the follow-up to the list tool, and the schema's id description names street_list_interested_applicants as the source. The description itself states no when-to-use or when-not conditions and names no alternative.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds the concrete endpoint (GET /invoices/{id}) and that include controls embedded records, but says nothing about not-found behavior or response size.

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

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

A single tight sentence, front-loaded with the resource and scope. The trailing 'GET /invoices/{id}' is largely redundant with the tool's purpose but is short enough not to hurt.

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

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

For a simple two-parameter read tool with full schema coverage, the description is adequate but not complete: with no output schema, it never says what the returned invoice record looks like or how embedded records appear in 'included'.

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

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

Schema coverage is 100%, so both the UUID format/source and the include enum are fully documented in the schema. The description merely restates that include embeds related records, adding no format or constraint detail beyond structured fields.

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

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

States a specific verb and resource ('One invoice by UUID') and clarifies that related records come via include, which contrasts with the list siblings such as street_list_invoices. It stops short of naming any sibling explicitly, so it's clear but not maximally differentiating.

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: 'One invoice by UUID' suggests single-record retrieval as opposed to listing. There is no explicit when-to-use/when-not or prerequisite guidance, though the schema does point to street_list_invoices as the source of the ID.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so safety is covered. The description adds that related records are embedded in the response's `included` collection and names the underlying endpoint, which is modestly useful context. It doesn't describe error behavior for unknown UUIDs or what's returned when `include` is omitted.

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 resource and scope. No filler. Slightly terse, using telegraphic phrasing ('One landlord by UUID'), but every clause 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?

There's no output schema, so the description should carry more about the response shape; it only says the requested relations land in `included`. For a simple read-only getter this is close to adequate, but the return envelope (attributes vs. relationships) remains 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 100%, so both parameters are fully documented in the schema (including the enum list for `include`). The description only gestures at `include` ('records you ask for') without adding syntax or format details beyond what the schema already provides. Baseline 3 applies.

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

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

States a specific verb and resource (get one landlord by UUID) plus the include-embedding behavior, which distinguishes it from the list tool. It doesn't explicitly contrast with sibling getters, but the resource name does the work well enough.

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?

Implies usage via the 'landlord_id from street_list_landlords' path, but the description itself gives no explicit when-to-use or when-not-to-use guidance versus the list tool or other getters. The inclusion of `include` hints at fetching detail beyond the list, but this 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds that this is a GET endpoint and that include controls related records embedded in the response, but it does not discuss not-found behavior, permissions, or response structure beyond the include concept.

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

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

The description is two compact sentences, front-loads the core lookup behavior, and ends with the exact REST endpoint. There is no wasted wording.

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 low-complexity read-only GET tool with full schema descriptions and safety annotations, the description gives enough context to invoke it correctly. A bit more on return shape or not-found behavior would improve completeness, especially since there is no output schema.

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

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

Schema description coverage is 100%, so both parameters are already well documented in the schema, including the UUID format and the allowed include values. The description reinforces 'UUID' and 'include' but does not add syntax, defaults, or constraints beyond the schema.

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

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

The description states a specific resource and scope: one lettings applicant retrieved by UUID. It also clarifies that related records can be embedded via include, which distinguishes it from the list sibling street_list_lettings_applicants and from other applicant-related gets.

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 'by UUID' implies this tool is for direct lookup when the identifier is already known, but it does not explicitly say when to use this instead of list/search alternatives or how to obtain the UUID. No exclusions or alternatives are named in the description.

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 carry the safety profile (readOnlyHint=true, destructiveHint=false, openWorldHint=true), so the burden is lower. The description adds only that `include` embeds related records, and says nothing about not-found behavior, whether `cancelled` affects visibility, or response shape — modest added value beyond structured fields.

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

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

Two tight sentences with the cardinality constraint front-loaded and no filler text. The trailing raw endpoint is marginally useful for mapping but is the only slightly redundant element.

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?

A simple single-record read whose parameters are fully documented in the schema and whose safety profile is covered by annotations. Nothing essential is missing for correct invocation, though a note on missing/soft-deleted records would round it out.

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 100%, so baseline is 3; the schema already documents `include`, `cancelled`, and the UUID source. The description echoes the `include` concept ('the related records you ask for') without adding syntax or semantics beyond the schema.

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

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

States a specific verb ('GET ... by UUID') and resource ('lettings instruction'), plus the key differentiator that it returns a single record with an `include` expansion. It does not explicitly name street_list_lettings_instructions as the plural alternative, but 'One ... by UUID' makes the single-vs-list split obvious.

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: an agent can infer it should use this when it has a UUID and wants the expanded record. There is no explicit 'use this instead of X when...' routing or mention of prerequisites such as where the UUID comes from (the schema covers that, not the description).

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 safe read-only operation. The description adds that it uses GET and that included related records are requested via the include parameter, but it does not mention behavior for missing records, permissions, or response shape beyond the embedded includes.

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

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

The description is two compact sentences with the primary operation front-loaded. Every sentence contributes useful information and there is no filler.

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

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

For a simple read-only tool with full schema coverage and clear annotations, the description covers the core behavior and include handling adequately. Minor omissions such as not-found behavior or response envelope details are not critical here.

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 100%, and the description adds little beyond noting that UUID identifies the offer and include controls related records. The schema already documents the UUID format, source, and allowed include values in detail, so baseline 3 is appropriate.

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

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

The description states a specific resource and retrieval mode: 'One lettings offer by UUID,' which clearly distinguishes a single-record fetch from list operations. It also names the endpoint. It does not explicitly name sibling alternatives such as street_list_lettings_offers, so it falls short of full sibling differentiation.

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

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

The UUID-based framing implies this is for retrieving a known lettings offer, while listing tools would be used to find one. However, there is no explicit when-to-use guidance, no exclusions, and no named alternative for discovery.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, openWorldHint=true, so the safety profile is covered. The description adds the REST endpoint and the notion that related records can be included, but never says which relations are available or what happens if include is omitted.

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 resource and scope. The 'GET /maintenance-jobs/{id}' tail is mildly redundant but a cheap, useful routing hint for an API-shaped toolset.

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

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

For a one-parameter read tool with full schema coverage and annotations, the core is covered. The unexplained 'include' reference is a real gap: an agent cannot tell how to request related records, or whether omitting it returns only the bare job.

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 has 100% schema coverage including the UUID format and its source (street_list_maintenance_jobs), so the description adds nothing there. Worse, it references an 'include' parameter that does not exist in the input schema, which could lead an agent to pass an invalid argument.

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+resource ('One maintenance job by UUID') and implicitly distinguishes from street_list_maintenance_jobs by singular vs. list. Sibling differentiation is present but by implication rather than explicit naming.

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

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

Usage is only implied: an agent can infer this is the fetch-single-after-listing call, and 'with the related records you ask for' hints at an expansion use case. No explicit when-to-use/when-not, and no reference to the list tool or id source (that only appears in the schema description).

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful context that include embeds related records in the response and that this maps to GET /people/{id}, but it does not mention permissions, errors, or pagination 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?

The description is two short sentences and front-loads the essential resource and lookup key. The HTTP endpoint detail is slightly redundant but still useful and not wasteful.

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-by-ID tool with full schema coverage and clear read-only annotations, the description gives enough to call it correctly. It does not need to explain return values because there is no output schema, though more detail on the included records might help.

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 100%, so the schema already documents person_id as a UUID from street_list_people and include as a constrained enum of ownedProperties and applicants. The description only restates the include purpose at a high level, so baseline 3 is appropriate.

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

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

The description states a specific resource (person), a specific lookup key (UUID), and the optional include behavior. It clearly distinguishes this from list endpoints, though it does not explicitly contrast with sibling get tools such as street_get_tenant or street_get_user.

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

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

There is no explicit guidance on when to use this tool versus street_list_people or the many other get tools. The only hint is that a UUID is required, which implicitly points to a known-ID lookup, but no alternatives or preconditions are stated.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, destructiveHint=false, so safety is covered. The description adds the concrete HTTP endpoint and clarifies that includes are embedded responses, which is useful operational context beyond the annotations; it stops short of noting response size or latency implications of a 29-item include list.

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, zero filler, with the core purpose first and the endpoint as a trailing anchor. Nothing could be trimmed without losing 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 two-parameter read tool with 100% schema coverage and no output schema, the definition covers purpose, the include mechanism, and the endpoint. The only gap is that nothing describes the shape of the returned payload (data vs. included arrays), which an agent might want to know when planning follow-on calls.

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

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

Schema coverage is 100% — both property_id and include are fully documented in the schema, including the full enum list. The description merely restates that include controls embedded records, adding no syntax or semantics beyond the schema, so the baseline 3 applies.

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

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

States a specific verb and resource ('One property by UUID') plus the domain-specific twist of embedded related records, and the HTTP route anchors the mental model. It doesn't explicitly name a sibling like street_list_properties as the collection counterpart, but the singular scope still separates it from the list tools.

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 'with the related records you ask for in include' implies how to use the optional param, and the schema's property_id description points to street_list_properties for obtaining IDs. There is no explicit when-to-use versus when-not or eligibility statement.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so safety is covered. The description adds the underlying HTTP endpoint and reiterates that include drives embedded related records, but says nothing about return shape, missing-record behavior, or whether includes add cost. Modest value beyond structured fields.

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

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

Two compact sentences with zero filler; the core behavior (single sale by UUID) is front-loaded and the include behavior and endpoint follow as supporting detail.

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?

A simple read tool with full annotation coverage, a fully documented 2-parameter schema and no output schema — the description gives enough to call it correctly. Only the response shape (what a returned sale/included payload looks like) is left unstated, which is minor here.

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 100% and the include enum is fully documented in the schema, so the description's mention of 'the related records you ask for in include' adds no new semantics. Baseline 3 applies when 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 ('One sale by UUID') and scopes it against the listing siblings implicitly via the UUID lookup. The REST path GET /sales/{id} reinforces it. It stops short of naming a specific sibling alternative, but an agent can tell this is a single-record fetch.

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

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

Usage is implied: use when you already have a sale UUID and optionally want related records embedded. It notes the UUID source indirectly (schema says 'from street_list_sales'), but the description itself offers no when-not conditions or explicit pointer to street_list_sales.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so safety and mutability are covered. The description adds that requested relations are embedded under 'included', which is useful behavioral context, but it omits error behavior (e.g., 404) and any pagination or size considerations for the include list.

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

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

Two short sentences with the key point (single applicant by UUID) front-loaded and the include behavior immediately after. The trailing 'GET /sales-applicants/{id}' is mildly redundant with the schema but harmless.

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 tool with full annotations and a fully documented two-parameter schema, the description covers the essentials: what is fetched and how relations are embedded. It could do more on failure modes or the shape of the response, but with no output schema and rich annotations the gap 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?

Schema description coverage is 100%, and the schema already enumerates all nine include values and explains that sales_applicant_id comes from street_list_sales_applicants. The description only restates that 'include' controls embedded related records, adding no syntax or format detail beyond the schema.

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

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

The description names a specific verb and resource ('One sales applicant by UUID') and scopes it to a single record, which implicitly contrasts with the sibling list tool street_list_sales_applicants. It stops short of naming that sibling explicitly, so an agent must infer the distinction.

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

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

The description makes clear this is a single-record fetch keyed by UUID and that related data comes through 'include', which implies the lookup-after-list workflow. It does not state when to prefer this over street_list_sales_applicants or what happens if the UUID is unknown.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds modest context: the GET endpoint and the fact that requested includes are embedded in an 'included' collection, which is useful given no output schema. It says nothing about errors, missing/cancelled records, or response shape beyond that.

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

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

Two short sentences, with the core capability front-loaded ahead of the endpoint detail. The trailing 'GET /sales-instructions/{id}' is mildly redundant with the prose but cheap and confirms read semantics.

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 get-by-id call the description is close to sufficient, especially since the 'included' payload is mentioned. However, with no output schema and no explanation of how the 'cancelled' filter changes results, an agent cannot fully predict what it will get back in edge cases.

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 100%, so the baseline is 3. The description echoes the 'include' parameter and confirms its purpose (embedding related records), but adds no new meaning for the 'cancelled' filter, whose enum semantics ('with' vs 'only') are only partially documented in the schema.

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

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

States a specific verb and resource: fetch a single sales instruction by UUID, which cleanly separates it from street_list_sales_instructions and the many other street_get_* entity tools. It never names a sibling explicitly, 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?

Usage is only implied: 'by UUID' signals you must already have an identifier, and the schema notes the id comes from street_list_sales_instructions, but the description itself gives no when-to-use or when-not guidance. Nothing tells the agent when to prefer this over street_get_sale or street_get_lettings_instruction.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds that requested related records are embedded via include and names the underlying endpoint, but says nothing about error behavior for bad UUIDs or the shape/size of the embedded payload.

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, zero filler; the core behavior comes first and the endpoint is a compact supporting detail.

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

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

For a two-parameter read tool with full schema coverage and safety annotations, this is nearly complete; mentioning the "included" payload gives a hint about the response. It stops short of describing how embedded records are keyed or what happens with an unknown UUID, but nothing essential to invoking it 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 coverage is 100% — both parameters are documented in the schema, including the include enum and the UUID source hint. The description only restates the include behavior, adding essentially no semantics beyond the schema, so baseline 3 applies.

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

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

States a specific verb (get/return) and resource (one sales offer) plus the scoping key (UUID), and mentions the include-driven embedding. It doesn't name a sibling tool explicitly, but the singular-vs-list contrast with street_list_sales_offers is clear from the schema reference.

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?

Implies usage: fetch a single offer when you have its UUID (obtained from street_list_sales_offers). There is no explicit when-not guidance or statement about alternatives, but for a simple lookup tool the implied context 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 cover readOnlyHint, destructiveHint, and openWorldHint, so the safety profile is handled. The description adds genuinely new behavioral context by explaining that include embeds related records into the response's "included" collection, which tells the agent the call can fan out into a compound document. It does not cover error behavior for unknown UUIDs, but that is a minor gap given the annotation coverage.

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

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

Two short sentences, front-loaded with the resource and scope, then the endpoint. Nothing is redundant and no sentence fails to earn 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?

With no output schema, the description should hint at the shape of the return, and it does by naming the "included" collection for related records. Combined with a fully documented two-parameter schema and read-only annotations, this is close to complete, though a note on what happens with a missing or malformed UUID would close the last gap.

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

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

Schema description coverage is 100%, with the include enum fully enumerated in the schema itself, so the baseline is 3. The description restates that include selects related records but adds no depth on nesting semantics (e.g., property.owner), request cost, or default behavior when include is omitted.

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 (fetch one tenancy by UUID) plus the endpoint GET /tenancies/{id}. It implies the list counterpart via the schema reference to street_list_tenancies but never explicitly contrasts itself with street_get_tenant or street_list_tenancies, so sibling differentiation is left implicit.

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 tenancy_id parameter description points to street_list_tenancies as the source of IDs, which sketches a workflow. There is no statement of when to use this versus street_list_tenancies or street_get_tenant, and no guidance on when include is worth requesting.

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

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

Annotations already cover read-only, non-destructive, and open-world hints. The description adds that include embeds related records and notes the HTTP GET endpoint, but does not disclose error behavior or rate limits. Some added value beyond annotations, but not rich.

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 purpose. The trailing 'GET /tenants/{id}' is implementation detail that doesn't aid an agent, but overall compact.

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 tool with annotations covering safety and no output schema, the description provides enough to call it correctly. It states it returns one tenant with optional includes. Minor gap: no mention of what fields a tenant has, but that's acceptable.

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

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

Schema coverage is 100%, so the schema fully documents both parameters. The description merely restates that include controls related records, adding little beyond what the schema already says. Baseline 3 is appropriate.

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

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

States a specific verb (get) and resource (tenant by UUID) and implicitly distinguishes from list tools, but does not name sibling get tools like street_get_person. An agent can still identify it as the single-tenant fetch.

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 'by UUID' implies use when you have an identifier, but there is no explicit guidance on alternatives when you don't, such as street_list_tenants to find a UUID. No when-not-to-use 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 readOnlyHint=true, destructiveHint=false, openWorldHint=true, so the safety profile is covered. The description adds the endpoint and notes that requested relations arrive embedded, but says nothing about error behavior for unknown IDs or how the embedded records are shaped beyond the generic 'included' reference.

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

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

Two clipped sentences with zero filler; the core purpose and the include behavior are both front-loaded, and the endpoint is appended as a compact anchor.

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

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

For a two-parameter read tool with full schema coverage, no output schema, and complete annotation coverage, this is nearly sufficient. The only shortfall is that it does not describe what the returned record or its 'included' relations look like, forcing the agent to rely on the include enum wording.

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 100%, including the enum of allowed include values and the UUID format, so the baseline of 3 applies. The description restates that include controls embedded related records but adds no syntax, defaults, or cardinality detail beyond the schema.

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

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

States a specific verb and resource ('One user by UUID') plus the include mechanism, and the endpoint reference (GET /users/{id}) confirms single-record retrieval. It implicitly distinguishes itself from the many street_list_* siblings by fetching exactly one user, but never names a sibling 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?

Usage is only implied: 'One user by UUID' signals this is the single-record path versus a list, but the description never says when to prefer it over street_list_users or how to obtain the UUID. No exclusions or preconditions are stated.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so safety is covered. The description adds that related records are embedded via include and names the HTTP endpoint, but says nothing about not-found behavior, response shape, or what 'cancelled' does beyond the schema.

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

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

Two short sentences, front-loaded with the key fact (one valuation by UUID) and the include behavior, with no filler.

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

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

With no output schema, the description does not explain the returned valuation object or the shape of embedded 'included' records. Annotations and the fully documented schema carry most of the burden, making it adequate but not complete for a read tool without an output schema.

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

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

Schema coverage is 100%, so the schema already documents valuation_id, include, and cancelled. The description adds only a passing reference to include embedding related records; baseline 3 is appropriate.

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

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

States a specific verb and resource ('One valuation by UUID') and gives the underlying endpoint GET /valuations/{id}. This distinguishes it from the sibling list tool street_list_valuations, though it doesn't name that sibling 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?

Implies it is the single-record lookup for valuations and that related records are requested via include, but gives no explicit when-to-use/when-not guidance or named alternatives such as street_list_valuations.

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, destructiveHint=false and openWorldHint, so the safety profile is covered. The description adds that requested relations land in an 'included' section and names the underlying endpoint, but says nothing about not-found behavior or payload shape.

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, zero filler, and the core fact (single vendor by UUID) is front-loaded before the include caveat and the endpoint reference.

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

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

For a single-resource read with full schema coverage and readOnly annotations, this is nearly sufficient; the include-embedding behavior is surfaced. The only gap is that with no output schema, the caller gets no hint about the returned envelope beyond the word 'included'.

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 100% — both vendor_id (with a pointer to street_list_vendors) and the include enum are fully documented in the schema. The description only restates that include controls embedding, adding no format or nesting detail 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 states a specific verb and resource ('One vendor by UUID') plus the include mechanism, which implicitly separates it from street_list_vendors. It never names the sibling or explicitly contrasts the two, so a reader must infer the singular-vs-list distinction.

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

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

The phrase 'the related records you ask for in include' implies when include is relevant, but there is no explicit guidance on when to call this versus street_list_vendors, when to add includes versus making a second call, or any prerequisites beyond having an ID.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds the REST endpoint (GET /viewings/{id}) and the include-driven embedding behavior, but says nothing about auth requirements, the cancelled-filter default, or error behavior for unknown UUIDs.

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 purpose and the include expansion, with the endpoint appended as compact technical context. Every clause 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?

With no output schema, the description leaves the response shape only implicitly defined by the word 'include' (the schema mentions embedding into 'included'). For a simple read tool that may suffice, but it does not mention the default cancelled behavior or that missing UUIDs may return an error.

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 100%, so the schema already documents viewing_id, include, and cancelled in detail. The description only adds a one-line restatement of the include mechanism, which is a baseline contribution given the rich schema.

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

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

States a specific verb and resource ('One viewing by UUID') and references the include expansion, which distinguishes it from street_list_viewings. It does not explicitly name the list sibling, so sibling differentiation is only implied by 'One'.

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

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

The description implies usage for fetching a single viewing when you have its UUID, and the schema notes the ID comes from street_list_viewings. There is no explicit when-to-use vs. when-not or pointer to alternatives for resolving an ID.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true and destructiveHint=false, so safety is covered. The description adds the ordering behavior ('Newest first as Street orders them'), which the annotations do not convey. It stays silent on the deleted-record dimension (trashed), which is the one behavioral aspect an agent might get wrong, so it does not go much beyond what's structured.

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, front-loaded clauses: purpose, definition, ordering/paging. Nothing is wasted, though the trailing 'GET /areas.' is redundant with the tool name and could be dropped.

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 list endpoint with a fully described schema and no output schema, the description supplies the essentials: what an area is, ordering, and pagination. It could say more about what each returned area contains, but nothing needed to invoke it correctly 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 coverage is 100%, so all three parameters, including the trashed enum, are fully documented in the schema. The description restates page and page_size usage but adds no semantics beyond them and omits trashed entirely, so the baseline of 3 is correct.

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 the verb and resource ('List areas') and parenthetically defines what an area is — the names used to match applicants and properties — which is genuinely informative beyond the sibling list_* pattern. It does not need to differentiate against a direct alternative because no other area-listing tool exists among the siblings.

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

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

Usage is implied by the read-only list nature and the pagination instructions ('page with page and page_size'), but there is no explicit when-to-use or when-not-to-use guidance. Given the sibling set contains only 'get' tools plus other unrelated list families, the absence of exclusions is a minor gap.

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 safety profile (readOnly, non-destructive, openWorld), so the description earns credit for adding non-inferable behavior: the newest-first ordering 'as Street orders them' and how pagination works with page/page_size. It omits that include triggers side-loaded records in an 'included' block, which is the one meaningful behavioral 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?

Three tight sentences, front-loaded with what the tool returns, followed by ordering and paging, ending with the underlying endpoint. No filler or 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?

For a read-only list tool with full schema coverage and no output schema, the description covers return fields, sort order, and pagination sufficiently to invoke correctly. It stops short of explaining the include/trashed side-loading semantics, which is the only notable omission.

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 100%, so all four parameters are already documented in structured form; this sets the baseline at 3. The description reinforces page/page_size usage but adds nothing about include or trashed beyond what the schema states.

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 ('List branches') and enumerates the returned fields (name, address, contact details), so an agent knows exactly what comes back. No explicit sibling differentiation, though the resource noun already disambiguates it from the other list_* tools.

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

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

Usage is implied rather than stated: the description says how to page and what order results come in, but never says when to use this versus street_get_branch for a single record. Adequate for an obvious list-vs-get split, but no explicit routing 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 readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds the default sort ('Newest first as Street orders them') and pagination mechanics plus the field shape of a lead, but says nothing about the deleted-record behaviour or result volume, which are real behavioural concerns for a paged list.

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 purpose and resource definition before ordering and paging details. Only 'page with page and page_size' is close to restating the schema, but it functions as usage guidance.

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 read-only, 10-optional-parameter list tool with no output schema, the definition covers purpose, ordering, paging and record shape. It leaves out any mention of the filtering power (branch, created/updated ranges, email, phone) and the deleted-record mode, but those are fully documented in the schema, so nothing critical 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 100%, so all ten parameters are documented in the schema itself, including the 'trashed' semantics and the sync hint on updated_from. The description only restates page/page_size, adding no semantics the schema lacks; baseline 3 applies.

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

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

States a specific verb (List) and resource (enquiries), and defines the resource inline as 'inbound leads: who, which property, message, source', which separates it from unrelated list_* siblings such as street_list_tasks or street_list_invoices. It does not explicitly phrase the contrast with street_get_enquiry (single record), though 'List' carries that distinction.

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

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

Gives concrete pagination guidance ('page with page and page_size'), but never says when to reach for this tool versus street_get_enquiry or the other list endpoints, and does not surface the filter dimensions (branch, date ranges, email/phone) that determine whether it fits a given query.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds genuinely new behavior: results come back newest-first in Street's fixed order (with no sort parameter visible in the schema), and pagination is the only navigation mechanism — useful for an agent planning a paging loop.

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 what is returned and the ordering, then pagination. The trailing 'GET /follow-ups' is marginal value but costs almost nothing.

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 an 11-parameter tool with no output schema, the description covers return shape and ordering but silently omits the substantial filtering surface (branch, trashed, created/updated ranges, subject). An agent reading only the description would not know it can filter at all, though the schema compensates.

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 100%, so all 11 parameters are self-documenting; baseline 3 applies. The description echoes page/page_size and hints at the related-record dimension covered by subject/include, but adds no syntax or default detail beyond the schema.

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

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

States a specific verb and resource ('List follow-ups') and enumerates the payload contents (due date, note, and the related property/applicant/sale/valuation), which separates it from list tools for those other resources. It does not explicitly contrast itself with siblings like street_list_tasks, but the resource 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 implied via pagination guidance ('page with page and page_size') and ordering, but there is no statement of when to reach for this versus street_list_tasks or a get-by-id tool, and no exclusions. An agent can infer the use case but gets no routing help.

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

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

Annotations already cover read-only, open-world, and non-destructive behavior. The description adds useful behavioral context: default ordering ('Newest first as Street orders them'), pagination via page and page_size, and that it maps to GET /inspections.

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 short, front-loaded with the core operation and fields, and then adds ordering, pagination, and endpoint context without unnecessary repetition. Every clause contributes useful information.

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

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

For a nine-parameter list tool with no output schema, the description gives enough orientation: listed fields, default ordering, pagination, and endpoint. The schema covers filters and enums, though the description could say more about return pagination metadata or filtering scope.

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 100%, so the schema already documents the nine parameters thoroughly. The description only mentions page and page_size and does not add format, defaults, or filtering semantics beyond what the schema provides.

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

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

The description states a specific verb and resource: 'List property inspections', and names the fields surfaced (due date, booked date, inspector, status). This clearly separates it from the singular 'street_get_inspection' sibling while remaining precise.

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 listing purpose and pagination guidance are clear, but the description does not explicitly say when to use this tool versus alternatives such as 'street_get_inspection' or other list tools. Usage is mostly implied by the tool name and operation.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered and the description's job is to add listing behavior. It does add two useful traits beyond annotations: the sort order ('Newest first as Street orders them') and the pagination contract, plus the underlying endpoint. It doesn't describe the 'included' side-loading result, but the core behavior is 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 definition and scoping before the pagination mechanics; nothing is padded. Minor awkwardness in 'Newest first as Street orders them' is the only friction.

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 read-only list tool with full schema coverage and no output schema, ordering, pagination, and endpoint are all covered, which is what an agent needs to call it correctly. The remaining gap is that the sibling distinction (lettings/sales/interested applicant lists) is never resolved.

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 100%, so all four parameters are already documented in the schema, including the property UUID filter and the include enum. The description echoes page/page_size but says nothing about the 'property' or 'include' parameters, so it adds no meaning beyond the schema. Baseline 3 is correct.

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?

It states a specific verb and resource ('List interested applicants') and even defines the term in parentheses ('applicants who showed interest in a property'), so the domain object is unambiguous. What it does not do is distinguish this from the very similarly named siblings street_list_lettings_applicants and street_list_sales_applicants, leaving an agent to guess which list it actually wants.

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: pagination mechanics are given ('page with page and page_size'), which tells an agent how to iterate but not when to pick this tool over street_get_interested_applicant or the lettings/sales applicant lists. No preconditions or exclusions are stated.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds ordering semantics ('newest first as Street orders them') that the schema does not, which is genuine value, but says nothing about the response envelope (e.g. the 'included' collection the include param populates) or result size 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 dense sentences with no filler, front-loading what the resource is before pagination mechanics. The parenthetical list is compressed to the point of being terse but still parseable.

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

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

With no output schema, the description carries some burden for describing what comes back, and it only gestures at this via 'property, owner, line items' embedding. The GET /invoices hint and ordering note help, but the agent must infer response structure and filter-combination 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?

Schema coverage is 100%, so all six parameters — including page, page_size, paid, voided, include, invoice_type — are already documented in the schema. The description restates a subset (page/page_size, property/owner/line items, paid/voided) without adding format or interaction details, and omits invoice_type entirely. Baseline 3 applies.

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

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

States a specific verb and resource ('List invoices') and scopes it to client accounting with the embedded relations and state fields it exposes. It is distinguishable from the sibling street_get_invoice (single record), though it never names that sibling 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?

Usage is implied rather than stated: 'Newest first ... page with page and page_size' tells the agent how to paginate but not when to prefer this over street_get_invoice or how to combine filters. No exclusions or alternative-selection guidance 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 readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds ordering behavior ('Newest first as Street orders them') and pagination mechanics, which is useful. It does not mention rate limits, auth, response format, or that dates can filter by creation/update, leaving the description only modestly additive over annotations.

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

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

The description is two compact sentences with no filler, and it front-loads the resource definition followed by ordering and pagination. The trailing 'GET /landlords' is mildly redundant but useful for API-aware agents. Overall it is efficient and well-structured.

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

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

With 13 optional parameters fully covered by the schema, no output schema, and annotations that already signal a safe read, the description only needs to establish purpose, ordering, and pagination. It does that. It could go further by hinting at the landlord record shape or the available filters (address, status, dates) to help an agent choose parameters, but nothing critical 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 100%, so every parameter is already documented in the schema. The description mentions page and page_size but adds no syntax, default, or filtering semantics beyond what the schema provides. Baseline 3 is correct when 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?

The description gives a specific verb ('List') and resource ('landlords') and adds a clarifying parenthetical that landlords are people letting a property. That definition helps distinguish the tool from the generic people endpoints. It does not explicitly name or differentiate against siblings such as street_list_people or street_get_landlord, 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?

Usage is implied by the list framing, and the description adds pagination guidance ('page with page and page_size'). However, it gives no explicit when-to-use versus alternatives, no exclusions, and no mention of when a single landlord lookup (street_get_landlord) or a broader people listing would be preferable. This is adequate but thin for a 13-parameter sibling-rich 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 readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds genuinely useful behaviour not in annotations: result ordering ("Newest first as Street orders them") and the pagination mechanism, though it omits the next_page contract used by the paging flow and says nothing about the embedded "included" payload produced by the include parameter.

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 identity of the resource, then ordering and paging. The trailing "GET /lettings-applicants" is the only near-redundant element, though it is informative for API-oriented agents.

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 17-parameter, zero-required list endpoint with full schema coverage and no output schema, the description covers purpose, ordering and pagination adequately. The remaining gaps are modest: it does not mention the include parameter's effect on the response shape (the "included" array) or the trashed filter, which are the two parameters that most change what comes back.

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

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

Schema description coverage is 100% across all 17 parameters, so the schema already explains page, page_size, include, trashed, date ranges and follow-up filters. The description's parenthetical echoes only a subset (budget, bedrooms, areas, furnished, lead rating) and adds no syntax or constraint detail, so it neither compensates for nor improves on the schema.

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

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

States a specific verb and resource ("List lettings applicants") and clarifies what a lettings applicant is with the parenthetical "prospective tenants: budget, bedrooms, areas, furnished, lead rating", which makes it identifiable apart from the many other list_* tools. It does not explicitly differentiate itself from the nearest siblings street_get_lettings_applicant or street_list_interested_applicants, 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?

Usage is implied rather than stated: the filtering parenthetical and the paging sentence tell an agent what this tool is good for, but there is no explicit "use this when" nor any named alternative such as street_list_interested_applicants or street_get_lettings_applicant for single-record retrieval.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful ordering and pagination context, but does not disclose auth requirements, rate limits, or deeper response 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?

The description is short and front-loaded: resource definition, ordering, pagination, then endpoint. There is no filler, though it could omit the redundant endpoint mention if space mattered.

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 read-only list tool with full parameter schema coverage and rich annotations, the description is adequate: it defines the resource and covers ordering and pagination. It does not explain the return envelope or included-record structure, which matters somewhat because there is no output schema.

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

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

Schema description coverage is 100%, so all eight parameters are already documented in the input schema. The description mentions page and page_size, but adds no syntax or filtering semantics beyond what the schema provides; this is the expected baseline when 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?

The description names a specific verb and resource ("List lettings instructions") and defines the domain term as "an agreement to let: property, owner." It does not explicitly distinguish this from the sibling get_lettings_instruction or street_list_sales_instructions, but the resource is still clear.

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 ordering and pagination behavior ("Newest first... page with page and page_size"), which implies this is the list endpoint for browsing lettings instructions. However, it gives no explicit when-to-use guidance versus get_lettings_instruction or the sales-instructions sibling.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so safety is covered. The description adds genuine value by disclosing result ordering ('newest first as Street orders them') and the paging model, but says nothing about filtering interactions, total counts, or the upstream endpoint's rate/limit 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?

Three short, front-loaded sentences with no filler: purpose and returned fields first, then ordering, then pagination, then the endpoint. Slightly terse rather than padded, so it earns its length.

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 10-parameter, all-optional list tool with no output schema, the ordering and pagination notes are the essential missing pieces and they are present. However, the description does not help an agent reason about the rich filter surface (status, include, trashed, date windows) or about what the paged response shape looks like, leaving meaningful gaps.

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

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

Schema description coverage is 100%, so every one of the 10 parameters is already documented in the schema, including status enum values, the include list, trashed modes and date ranges. The description only restates page/page_size and does not enrich filter semantics, so baseline 3 applies.

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

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

States a specific verb and resource ('List lettings offers') and enumerates the fields returned (rent, applicant, property, status), so an agent knows exactly what data comes back. It is distinguishable from street_get_lettings_offer by the plural/list framing, but it never explicitly contrasts with street_list_sales_offers or the single-offer getter.

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

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

The description implies a browse/paginate use case ('page with page and page_size') but gives no explicit when-to-use versus street_get_lettings_offer or how it relates to street_list_lettings_instructions/applicants. Usage must be inferred from the tool name and the field 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=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds two genuinely useful behaviors beyond that: results come newest-first and are paginated. It stays silent on other behavioral traits such as deleted-record handling (the trashed parameter) and what the response envelope looks like.

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 compact clauses, front-loaded with the identity and read-only nature, then ordering, then pagination. Every sentence carries information and 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?

For a 13-parameter, annotation-covered list tool with full schema coverage and no output schema, the description covers identity, safety posture, ordering, and paging — enough to call it correctly. Missing only a note on the trashed/soft-delete option and the included-records behavior, which are lower priority given the schema.

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

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

Schema description coverage is 100%, so all 13 parameters are already documented in the schema; the description only names page/page_size paging and gestures at property/status/assignee/dates. It adds no filtering semantics, defaults, or enum guidance beyond what the schema already provides, which is baseline 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?

States a specific verb and resource ('List maintenance jobs') plus the endpoint GET /maintenance-jobs, so the read/list nature is unambiguous. It does not explicitly distinguish itself from the single-record sibling street_get_maintenance_job, but the 'list' vs 'get' naming and the pagination hint make the scope clear.

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: 'page with page and page_size' tells the agent how to iterate, but there is no statement of when to prefer this over street_get_maintenance_job or when the filtered list is inappropriate. No exclusions or alternative routing 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 readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds genuinely new behaviour: results are newest-first per Street's ordering, and results are paged. It omits return-shape details (the presence of a next_page cursor that the schema references) and says nothing about how trashed/include affect results.

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?

Roughly two sentences plus an endpoint, with the identity of the resource and the ordering constraint front-loaded. The trailing 'GET /people' is mild filler for an agent but harmless and confirms scope.

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?

There is no output schema, and the description does not describe the response envelope (data plus included plus next_page) that the pagination advice implicitly depends on. For a zero-required-parameter list tool with 11 optional filters, a reader of the description alone would not know filtering is possible.

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 100%, so every parameter is already documented in the schema; the baseline is 3. The description only reinforces page/page_size and adds no semantics for the filter, date-range, trashed or include parameters that drive most real queries.

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+resource and disambiguates 'people' as contacts with the fields they carry, which is more than the title offers. It does not, however, distinguish itself from near-neighbours like street_get_person (single record) or street_list_tenants/landlords, so an agent must infer that this is the generic unpinned list.

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

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

The description gives concrete procedural guidance for pagination (page/page_size) and states the sort order, which is real usage help. It never says when to prefer this over street_get_person or the typed list siblings, and never mentions that the 11 filter parameters exist, so the choice between list tools 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds ordering ('Newest first as Street orders them'), pagination mechanics, and a summary of returned fields, which is genuinely useful, but it says nothing about deleted/archived handling beyond what the trashed/include_archived params hint at, nor about result caps or empty-set 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?

Two tight sentences, front-loaded with the resource and its contents, followed by ordering/pagination. The trailing 'GET /properties' is mild redundancy but not costly.

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

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

With no output schema, the description's one-clause summary of returned fields (address, status, price, bedrooms, owner link) is valuable, but for a 21-parameter tool with rich filters and an embed mechanism ('include' → 'included') the description is thin. It does not explain that related records are returned in an 'included' block, which is a structural aspect an agent would want when combining list and get results.

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 100%, so all 21 parameters are already documented in the schema, and the description only echoes page/page_size. With the schema doing the heavy lifting, baseline 3 is appropriate; the description adds no filter semantics (status, include, price ranges) beyond what the schema provides.

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

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

States a specific verb (list) and resource (properties) and clarifies the scope covers both sales and lettings listings, plus the headline fields returned. It does not explicitly distinguish itself from street_get_property or the sibling list tools, so differentiation is only implied by the plural resource.

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?

Offers pagination guidance ('page with page and page_size') and notes the newest-first ordering, which is the kind of context an agent needs when iterating. However it never says when to prefer this over street_get_property for a single record, nor when to use the type-specific list tools (street_list_sales, street_list_lettings_instructions, etc.), leaving the routing decision to inference.

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

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

Annotations already declare this as a non-destructive read operation (readOnlyHint=true, destructiveHint=false, openWorldHint=true). The description adds useful behavior beyond the annotations by stating the default ordering ('Newest first as Street orders them'), pagination controls, and the endpoint ('GET /sales'), but it does not disclose auth requirements, rate limits, or detailed return/pagination metadata 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?

The description is compact and front-loaded: it identifies the resource, defines the sale record, then states ordering/pagination and endpoint. It is appropriately sized, though the 'GET /sales' fragment is marginally redundant for an MCP tool invocation.

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 tool with ten optional parameters and no output schema, the description adequately covers identity, default ordering, and pagination. However, it does not mention the available filtering/embedding capabilities or clarify when to select this tool over sibling sales-related list/get tools, leaving some contextual gaps.

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

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

Schema description coverage is 100%, so all ten parameters are already documented in the schema. The description mentions only page and page_size, adding no meaning beyond the schema for branch, status, include, trashed, or date filters; baseline 3 is appropriate when the schema carries parameter semantics.

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

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

The description gives a specific verb ('List') and resource ('sales'), and clarifies what a sale is by naming its progression fields: agreed price, buyer, vendor, solicitors, status. It is clear enough to distinguish a sale record from unrelated resources, but it does not explicitly distinguish this list endpoint from close siblings such as street_list_sales_offers, street_list_sales_instructions, or street_get_sale.

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 ordering and pagination ('Newest first as Street orders them; page with page and page_size') but gives no explicit guidance on when to use this tool versus sibling list/get tools. An agent must infer the use case from the resource name alone, with no stated 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 readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered; the description usefully adds that results are returned newest-first in Street's own order and that paging is required for the full set. It stays silent on softer behaviors such as whether filters are ANDed or how soft-deleted records are treated, but the added ordering and paging notes clear the lowered bar.

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 clauses with the purpose, facet summary, and ordering/paging guidance packed in the first two sentences – front-loaded and waste-free. The trailing 'GET /sales-applicants' is transport detail that adds little for an agent but costs only a few tokens.

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 an 18-parameter tool with no output schema, the description covers purpose, ordering, and paging, which is the minimum an agent needs. It omits anything about how the many filters combine, what the 'include' embedding does to the response shape, or what a page payload looks like, leaving meaningful gaps for a tool of this complexity.

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

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

Schema description coverage is 100% across 18 parameters, so the description is not required to document them. The parenthetical facet list ('budget, bedrooms, areas, buying and financial position, lead rating') orients an agent to which filter axes exist, but adds no format or constraint detail beyond the schema, so it sits at the baseline.

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 ('List sales applicants') and summarizes the facets the records carry (budget, bedrooms, areas, buying/financial position, lead rating), so an agent knows this is the collection endpoint. It does not name the sibling single-record call (street_get_sales_applicant) or contrast with street_list_lettings_applicants, leaving that differentiation to the names alone.

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

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

Gives explicit paging mechanics ('page with page and page_size') and states the default ordering, which is actionable context. However, it never says when to use this list versus street_get_sales_applicant, nor how filters should be combined, so usage is largely implied.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so safety is covered. The description contributes the otherwise-unstated result ordering (newest first) and the pagination protocol, but says nothing about embedding behavior of `include`, default filtering, or result volume.

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 purpose and terminated with the endpoint; nothing is redundant or 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?

For an 8-parameter, no-output-schema list endpoint the parameter surface is fully documented in the schema and annotations carry the safety profile, so the description is nearly sufficient; only the shape of the returned list and the included-side-loading are not sketched.

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 100% and every parameter is documented in-schema, so the baseline is 3. The description only repeats page/page_size and ordering, adding no semantics the schema lacks for include, trashed, or the date filters.

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 and even glosses the domain term ('an agreement to sell: property, owner, fees'), which helps an agent unfamiliar with 'sales instruction'. It does not explicitly say to use street_get_sales_instruction for a single record, so sibling differentiation is left to the 'list' prefix.

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?

'Newest first as Street orders them; page with page and page_size' gives ordering and pagination mechanics, but there is no statement of when to choose this over street_list_sales or street_get_sales_instruction, nor any when-not 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 readOnly, openWorld, and non-destructive, so the safety profile is covered. The description adds useful sort-order behavior ('Newest first as Street orders them') but says nothing about pagination limits or the shape of 'included'/trashed results beyond what the schema states.

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 purpose and followed by ordering and pagination notes. Efficient with no wasted phrasing, though it could pack field/ordering details slightly tighter.

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 10 optional filters and no output schema, the description carries some return-shape burden, which it partially meets by listing returned fields and ordering. It omits mention of filters like branch, status, include, and trashed, but the rich schema covers those, so gaps are 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?

Schema description coverage is 100%, so every parameter is already documented in the schema. The description only echoes pagination via page/page_size and adds no syntax or semantics beyond the schema, making the baseline 3 appropriate.

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

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

States a specific verb+resource ('List sales offers') and enumerates the returned fields (amount, applicant, property, status), clearly distinguishing it from the singular sibling street_get_sales_offer. It does not explicitly name that sibling or contrast scope, keeping it at 4 rather than 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?

Gives concrete operational guidance: newest-first ordering and pagination via page/page_size. It does not say when to prefer the get/list alternatives or note exclusions, so it stops short of explicit when/when-not 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 readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds ordering ('Newest first as Street orders them'), pagination guidance, and the endpoint, but does not disclose auth needs, rate limits, or other behavioral constraints.

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

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

The description is two compact sentences, front-loaded with the resource and result content, followed by ordering and pagination guidance. Every clause carries useful information and there is no filler.

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

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

Given 11 optional parameters with full schema coverage, the schema already explains filters, date ranges, trashed behavior, and inclusion options. The description supplies result shape, ordering, pagination guidance, and endpoint, which is sufficient; the only minor gap is that it does not summarize the available filters, but those are well documented in the schema.

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

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

Schema description coverage is 100%, so all 11 parameters are already documented in the schema. The description only mentions page and page_size, adding no meaningful semantics beyond the schema's own parameter descriptions; this matches the baseline of 3 when 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?

The description gives a specific verb and resource ('List tasks') and clarifies that tasks are to-dos with title, due date, assignee, and related record. It also states ordering and the underlying endpoint, though it does not explicitly distinguish this from sibling tools such as street_list_task_types or street_create_task.

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 pagination mechanics ('page with page and page_size') and ordering, which is useful context. However, it does not say when to use this tool versus alternatives, nor does it provide exclusions or preconditions.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is carried structurally. The description adds genuinely non-schema information: result ordering ("Newest first as Street orders them"), pagination behavior, and the underlying endpoint. It does not explain what fields come back or whether trashed records are excluded by default, which keeps it short of 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?

Two compact sentences, front-loaded with the purpose and definition, then pagination, then the endpoint. Nothing is redundant with the schema and nothing wastes tokens.

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 read-only list endpoint with full parameter coverage and clear annotations, this gives the agent what it needs to invoke correctly, including ordering and paging semantics. The only real gap is that no output schema exists and the description doesn't hint at the shape of a task type record.

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 100%, so every parameter is already documented in the schema, and the description only echoes page/page_size at a high level. The date-range and trashed filters go unmentioned in prose, but with full schema coverage the baseline of 3 is appropriate rather than a penalty.

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 ("List task types") and immediately disambiguates it from the sibling street_list_tasks by defining a task type as "the categories a task can have". It also ties the resource to its practical use ("use an id as task_type_id when creating a task"), so an agent knows exactly what it is looking at.

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

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

The parenthetical makes the when-to-use case explicit: call this to obtain a task_type_id before calling street_create_task. That is real routing guidance to a sibling, though it does not state exclusions (e.g., that this is not how you list actual tasks) or address the trashed/date-filter cases.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds the ordering guarantee and the paging model, which are genuinely useful, but says nothing about how the `include` embedding or `trashed` behavior affects the response shape.

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 clauses with no padding: what it returns, how it orders, how to page. Front-loaded with the resource and its payload. The trailing 'GET /tenancies' is mild redundancy but harmless.

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 read-only list endpoint with a fully documented schema this is close to sufficient, but the omission of `include` is notable: embedding property.owner, tenants or inspections materially changes the response and the agent has to discover it from the schema alone. No output schema exists, so some mention of the `included` sidecar would have helped.

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 100%, so all eight parameters are already documented in the schema, including the next_page convention and the trashed semantics. The description merely repeats page/page_size, adding no format or interaction detail beyond the schema, which is the baseline for full coverage.

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 ('List tenancies') and enumerates the fields returned (property, tenants, owner, rent, dates), which separates it from street_get_tenancy (single record) and street_list_tenants (different resource). It stops short of explicitly naming those siblings as alternatives, so the distinction is inferable 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?

Pagination guidance ('page with page and page_size') tells the agent how to iterate, and 'newest first as Street orders them' sets expectations about result order. There is no statement of when to reach for this tool versus street_get_tenancy or the other list_* endpoints.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds genuine value beyond that by disclosing sort order ("Newest first as Street orders them") and the backing endpoint. It says nothing about pagination metadata, rate limits, or how large result sets behave, which for an open-world list call 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?

Three short clauses, front-loaded with the verb and resource, then ordering/pagination, then the endpoint. No filler. It is arguably too terse for a 12-parameter tool, but nothing written 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?

With 12 optional filters and no output schema, the description should ideally say what a tenant record looks like and how the 'included' side-loads appear in the response. It covers ordering and paging but leaves the return shape and the tenant/people distinction unaddressed; the rich schema compensates for the filter side but not the response side.

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 100%, so all 12 parameters (including the include embedding, trashed semantics, and date-range filters) are already documented in the schema. The description only echoes page and page_size, adding nothing the schema lacks. Baseline 3 applies when the schema carries the load.

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 ("List tenants") and reveals the underlying endpoint (GET /tenants), which makes the operation unambiguous. However, it does nothing to distinguish this from close siblings such as street_list_people or street_get_tenant, so an agent must infer the tenant-vs-person-vs-tenancy boundary on its own.

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 sentence about page/page_size is parameter guidance, not when-to-use guidance. There is no statement about when to pick this over street_list_people or street_get_tenant, and no mention of when the richer filters (email_address, person_status, trashed) are appropriate. Only ordering and pagination context is given.

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

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

Annotations already cover read-only and non-destructive semantics, so the burden is lower, yet the description still adds a genuine behavioral trait not in the schema: default ordering ('Newest first as Street orders them') and the paging pattern via page/page_size. It stops short of describing the response envelope (data/included/next_page) or soft-delete visibility, which the schema covers separately.

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 that front-load the resource definition before ordering and paging details. 'As Street orders them' is slightly soft language and the trailing 'GET /users' is mild redundancy, but there is no 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?

For a paginated list tool with full schema coverage and no output schema, the description supplies the ordering and paging contract an agent needs to iterate pages. The shape of the response (array vs. included/next_page) is assumed rather than stated, which is the only real gap.

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

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

Schema description coverage is 100%, so all eight parameters are already documented, including trashed, include, and the created/updated range filters. The description only echoes page and page_size, adding nothing about the filter parameters; baseline 3 applies.

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

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

States a specific verb and resource and disambiguates the vague term 'users' by parenthesizing 'the agency's staff' and enumerating returned attributes (name, job title, contact details, deactivated state). It doesn't explicitly contrast itself with the sibling street_get_user, but the list-vs-get distinction is unambiguous from the wording.

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

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

The description implies usage ('List users', with paging guidance) but never says when to prefer this over street_get_user or how to narrow via the date filters. No exclusions or prerequisites are stated; the agent must infer that this is the browse-all path.

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

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

Annotations already cover read-only, non-destructive and open-world behavior, so the description adds ordering ('newest first as Street orders them') and paging mechanics. It says nothing about default exclusions (trashed/cancelled rows are dropped by default) or the 'include' embedding side effect, which are the behavioral traits an agent most needs flagged here.

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