Rex Software MCP by usefulapi

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

The readOnlyHint annotation already establishes this as a safe read operation. The description adds value by disclosing the return shape (id, name, email, phone) and the intended follow-up tool, which helps the agent understand the result without an output schema. It does not describe pagination or limit behavior, but the schema covers limit.

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

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

Two tightly written sentences: the first states what the tool returns and how to search, the second gives the immediate next action. The endpoint path is included without bloating the 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?

This is a simple two-parameter read tool with no output schema. The description covers purpose, returned fields, and the follow-up tool, giving the agent everything needed to invoke it correctly despite the absence of 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 description coverage is 100%, so both parameters are already documented in the schema. The description's '(part of) a name' adds a little intuition for search_string, but it does not add syntax, matching behavior, or other 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: 'Quick lookup of contacts by (part of) a name', and lists the returned fields. It is clear what the tool does, though it does not explicitly distinguish itself from the similarly named sibling rex_search_contacts.

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

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

It gives a useful next step ('Use the id with rex_get_contact') and implies this is for quick autocomplete-style lookup. However, it does not state when to use this instead of rex_search_contacts or other contact-related siblings, leaving the alternative choice 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?

readOnlyHint=true already covers the safety profile, and the description adds that matches are "best matches" (i.e. ranked) and that results carry a listing id plus address, which the absent output schema would otherwise leave unknown. It does not mention truncation/default result count behavior beyond what the schema says, so meaningful but not rich added context.

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

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

Two sentences, front-loaded with the purpose, then the follow-up action; every clause carries information. The trailing raw endpoint "POST /v1/rex/Listings/autocomplete" is largely noise for an agent invoking a tool and is the only wasted 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?

With only three simple flat parameters and no output schema, the description supplies what is needed: input semantics (partial address), result content (id + address) and the next call to make. Missing only explicit differentiation from the full search siblings.

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 limit, search_string and listing_states are all documented in the schema, and the description adds only the notion that search_string is a partial address. 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?

The description names a specific verb and resource ("quick lookup of listings by (part of) an address") and states the input shape (partial address), so the agent knows this is a prefix/partial matcher rather than a full search. It does not name the nearest sibling, rex_search_listings, so the boundary with it 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?

"Use the id with rex_get_listing" gives explicit downstream routing, which is useful workflow guidance. However, there is no statement of when to prefer this over rex_search_listings (the obvious alternative for listing search), so the agent must infer that this is for autocomplete-style partial input.

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=true. The description adds useful behavior beyond annotations by saying 'Not retried', stating it returns the new contact id, and giving the API endpoint; it does not explain why destructiveHint=true or permission requirements.

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 write operation, and every sentence adds actionable information. It avoids repeating schema details while still covering duplicate avoidance, retry behavior, return value, and 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 create mutation with full schema coverage and annotations, the description covers duplicate avoidance, retry risk, return value, and endpoint. It omits permissions/auth details and deeper duplicate-handling behavior, but no output schema exists and the key call guidance is present.

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

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

Schema description coverage is 100%, so the schema already documents all five parameters in detail. The description adds only high-level context that a name is required and optionally one email and one phone can be supplied; phone_type semantics remain with 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 starts with a specific verb and resource: 'create a new person contact in Rex'. It states the required name and optional one email/one phone, and names rex_autocomplete_contacts for duplicate checks, making it distinguishable from get/search 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?

It explicitly tells the agent to search first via rex_autocomplete_contacts to avoid duplicates. It does not give broader when-not-to-use guidance or mention other search/create alternatives, but the primary usage condition is clear.

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

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

Annotations already declare readOnlyHint=false and idempotentHint=false; the description adds genuinely new behavior: 'Not retried' (critical for a caller deciding whether to re-attempt) and 'Returns the new note id'. It does not explain what happens if both contact_ids and property_ids are omitted, which would be useful given the destructiveHint=true flag.

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

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

One front-loaded sentence with the operation class first, followed by the non-retry/return/endpoint facts. Every clause carries information; nothing is repeated from the schema.

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

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

With no output schema, the description helpfully states the return value ('the new note id'), and the non-retry note covers the main failure-handling question. It is slightly incomplete on the required-vs-optional targeting rule (whether a note with no contact or property is valid) for a 5-parameter mutation.

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

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

Schema coverage is 100%, so every parameter is already documented in the schema; the baseline of 3 applies. The description only reiterates that notes can target multiple contacts and/or properties, adding no format or constraint detail beyond the schema (e.g. the 20-item cap or note_type value-list lookup).

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 ('add a note') plus the exact resource scope ('to one or more contacts and/or properties'), which cleanly separates it from rex_get_note and rex_search_notes. The 'WRITE:' prefix makes the operation class immediately legible.

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

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

Provides concrete usage contexts ('after a call or an open home') that tell an agent when this tool is appropriate. It does not name a competing alternative or state exclusions (e.g. when to use search_notes instead), so it stops short of a full routing rule.

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

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

Goes beyond the annotations by disclosing that the call is not retried (so a failure is final), that it returns the new reminder id, and the underlying POST endpoint. It does not explain failure modes or what the destructiveHint=true means for a create operation, leaving a small 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?

Front-loaded with 'WRITE:' and packed into one dense sentence plus two short fragments; every clause (linking options, default remindee, no retry, return value, endpoint) carries information an agent needs.

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

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

With 8 parameters and no output schema, the description supplies the key facts an agent needs (required vs optional linking, defaults, return value). It stops short of describing error behavior or what validation of the date/description fields will reject.

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; the description adds value by stating that links are optional and that reminder_type/remindee_user_id default when omitted. That default-behavior context is not 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+resource ('create a follow-up reminder (task)') with its scope: due date, optional links to contact/property/listing, and assignee. This clearly separates it from rex_search_reminders and rex_get_reminder, which read rather than create.

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

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

The description implies when to use it (you want a new reminder) and notes the default remindee when no user is supplied, but it never states when NOT to use it or points to an alternative. Usage is inferable rather than explicit.

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, so the description is not burdened with safety disclosure. It adds real context beyond that: the shape of each returned record, the warning that large services have hundreds of fields, and the endpoint backing it. It does not mention pagination or response size limits, which matters given the stated field 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?

Front-loads the return contents, then the when-to-call rule, then the sorting caveat. Every sentence carries decision-relevant information; the trailing endpoint paths are the least valuable, though still useful for debugging.

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 the return-shape burden and does so — field names, labels, types, and enum values are all covered. Combined with the match-filter guidance, nothing material is missing for a read-only discovery tool.

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

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

Schema coverage is 100%, so the baseline is 3. The description goes beyond the schema by explaining why include_order_by exists — order_by fields come from a separate model and their names can differ (name_last vs contact.name_last) — which is the key disambiguation an agent needs before passing that flag.

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 search field names a service accepts in criteria) and enumerates what each entry carries: label, type, enum value list. It also explicitly distinguishes this from the separate sortable-field list used by order_by, so it is not confused with that narrower 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?

Gives an explicit trigger: 'Call this before building criteria on a field you are not sure of,' plus the conditional 'set include_order_by' path for sorting. It does not name a sibling as the alternative for either case (e.g. what to call instead when you already know the fields), so it stops short of full when/when-not routing.

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

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

Annotations already declare readOnlyHint=true, so the safety profile is covered; the description adds value by enumerating what the response contains (date, state, agents, property, price expectations, commission estimate) in the absence of an output schema. It also discloses the underlying endpoint, though it says nothing about behavior when the id does not exist.

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 operation and scope, followed by the id source. Every clause carries information; nothing is repeated from the title or 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 single-parameter read tool with no output schema, the description covers purpose, input provenance, and a useful sketch of returned fields. Only missing pieces are failure behavior (unknown id) and any auth or rate considerations, which are 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?

The schema documents the single id parameter at 100% coverage, so the baseline is 3. The description earns an extra point by explaining where the id originates (search or autocomplete), which is provenance information the schema does not provide.

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 appraisal by id') and immediately differentiates scope from the plural search tool by emphasizing a single record. It also previews the returned fields, so an agent knows exactly what it gets. It stops short of naming rex_search_appraisals outright, relying on 'a search' to imply it.

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 id comes from a search or autocomplete' tells the agent the precondition for calling this tool and implicitly routes it to rex_search_appraisals / autocomplete when no id is held. There is no explicit when-not guidance or error/not-found behavior, but the usage 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?

readOnlyHint=true already declares the safety profile, so the description only needs to add context. It does add the shape of the returned record and the underlying endpoint (POST /v1/rex/Contacts/read), which is useful. However the important warning that the full record is large lives only in the schema's `fields` description, not here, and nothing is said about authorization or failure behavior for a missing id.

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: what comes back, then where the id comes from, followed by the raw endpoint. Zero filler and the core purpose is front-loaded in the first five words.

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

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

With only two well-documented parameters, a read-only annotation, and no output schema, the description is nearly sufficient — it enumerates return contents in place of a missing output schema. The one gap is that the payload-size caveat about omitting `fields` isn't echoed in the prose, where an agent would most likely see it.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds genuine meaning beyond the schema: the `id` value is not arbitrary — it must be obtained from a search or autocomplete call. That is actionable context not present in the schema's bare 'The contact id.' The optional `fields` projection is left entirely to the schema, hence not a 5.

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 resource ('One contact by id') and enumerates the returned data (names, emails, phones, addresses, tags, relationships, related properties and listings). It implicitly distinguishes itself from rex_search_contacts by returning a single record by id, but never names a sibling tool explicitly.

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

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

Gives a clear provenance rule — 'The id comes from a search or autocomplete' — which routes the agent to rex_search_contacts or rex_autocomplete_contacts before calling this. It lacks an explicit 'do not use this to find contacts by name' exclusion, so it stops short of full 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?

readOnlyHint=true already covers the safety profile, but the description adds real value by disclosing the payload contents (state, value, parties, close date) and the backing endpoint POST /v1/rex/Deals/read. This matters because there is no output schema, so field disclosure comes only from the description. It does not mention not-found/error 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 compact clauses with no filler; the resource and its scope lead, the return fields follow, and the provenance hint closes. Nothing is 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 one-parameter read tool with no output schema, the description covers what it returns, where the key comes from, and the underlying endpoint. Only failure modes and access restrictions are unaddressed, which is a minor gap.

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

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

Schema coverage is 100% and the id parameter is documented there, so the baseline is 3. The description goes one step further by explaining where the id originates (a prior search or autocomplete), which the schema does not convey.

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 deal by id") and enumerates the returned fields (state, value, parties, expected close date). It implicitly distinguishes itself from the many rex_search_* siblings by being a single-record fetch keyed on id, though it never names rex_search_deals explicitly.

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

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

"The id comes from a search or autocomplete" makes the prerequisite workflow explicit, telling the agent it must first run a lookup rather than guess an id. It stops short of naming rex_search_deals as the alternative or stating any when-not conditions.

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, so the safety profile is covered. The description adds useful context by listing returned fields and noting the endpoint, but it does not describe not-found behavior, auth, or other operational traits.

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?

Very compact and front-loaded: it states the core operation first, then the returned fields, then the id source and endpoint. No wasted text.

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

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

With no output schema, listing the returned data fields is valuable and helps the agent understand what to expect. Minor gaps remain around error behavior and exact response shape, but the definition is sufficient for a simple one-parameter read tool.

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

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

Schema coverage is 100% and the single id parameter is already documented. The description adds meaning by explaining where the id should come from: a search or autocomplete.

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 combination: retrieve one lead by id. It also names the key fields returned and distinguishes this from search-style sibling tools by emphasizing a single lead by id.

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

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

Explains that the id comes from a search or autocomplete, giving clear context for when this tool is appropriate. It does not explicitly name the alternative search tool or state exclusions, but the intended usage is clear.

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

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

Annotations already declare readOnlyHint=true, so safety is covered; the description adds that the full record is large and that fields narrows the response, plus discloses the POST /v1/rex/Listings/read endpoint. No mention of permissions or error behavior, but little more is needed for a read tool.

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

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

Two compact sentences, front-loaded with the resource and payload, followed by id provenance and the endpoint. 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 usefully enumerates the returned sections. It does not describe pagination or size mitigations beyond the fields hint, but for a single-record read it is nearly complete.

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

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

Schema coverage is 100% and the fields parameter is already documented in-schema including the 'omit for whole record' caveat. The description only adds provenance for the id, which is useful but slight; 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+resource ('One listing by id') and enumerates the payload (state, price, agents, property attributes, images, contacts, events). It is clearly distinguishable from the search/autocomplete siblings.

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

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

'The id comes from a search or autocomplete' implicitly points the agent at rex_search_listings / rex_autocomplete_listings as the prerequisite step. There is no explicit 'do not use for lookup by name' exclusion, but the context is clear.

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

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

The readOnlyHint annotation already establishes that this is a safe read operation. The description adds meaningful behavioral context by listing what the response contains and explaining where the required id originates, which helps an agent understand the expected call pattern.

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 language. The key information, what the tool returns and where the id comes from, is front-loaded and immediately actionable.

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

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

For a simple single-parameter read tool with no output schema, the description is complete enough: it identifies the resource, the return contents, the id source, and the underlying endpoint. An agent has what it needs to invoke the tool correctly.

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

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

Schema coverage is 100%, so the single id parameter is fully documented in the schema. The description adds provenance by stating that the id comes from search or autocomplete, giving the agent practical guidance beyond the schema's type and range constraints.

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

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

The description states a specific resource and access pattern: one note by id, including the returned fields (text, type, linked contacts and properties). It distinguishes itself from search/list tools by emphasizing a single note retrieved by id, 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 implies when to use the tool by saying the id comes from a search or autocomplete, which gives useful context. However, it does not explicitly name alternatives such as rex_search_notes or state when not to use this tool, leaving usage guidance mostly 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?

readOnlyHint=true already covers the safety profile, and the description adds genuinely new behavioral detail: the payload includes nested related data (owners, history), and the underlying endpoint is POST /v1/rex/Properties/read. It does not say what happens for an unknown id or whether access is scoped, which keeps it below 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 clauses with the resource and id provenance front-loaded and the endpoint last. The nested parenthetical listing returned sections is dense but every element carries information; nothing is padded.

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

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

With no output schema, the description correctly carries the burden of telling the agent what comes back (address, attributes, features, owners, history) and that the full record is large. Missing only failure/not-found semantics and permission scoping for a read of a single 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 coverage is 100%, so the baseline is 3; the description earns an extra point by explaining where the required `id` originates (search or autocomplete), which the schema only calls 'The property id.' The `fields` parameter's large-record tradeoff is already fully 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+resource ('One property by id') and enumerates what the record contains (address, attributes, features, owners, history), which clearly separates it from the search/autocomplete siblings. It stops short of naming the sibling that produces the id, but the singular-by-id framing makes the distinction 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?

'The id comes from a search or autocomplete' tells the agent the prerequisite step and steers it to the right family of tools before calling this one. No explicit when-not or cost/volume exclusion is given, so it is clear context rather than full 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?

readOnlyHint=true already establishes this as a safe read, so the description only needs to add context; it does add the id-precondition and the returned field set. It says nothing about behavior for an invalid/missing id or what the response envelope looks like. Useful but not rich beyond the annotation.

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

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

Two short sentences, the resource and return shape front-loaded, no filler. The trailing endpoint string is mildly noisy but negligible.

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, the description plus readOnlyHint covers what an agent needs: what it fetches, which fields return, and where the id originates. No output schema exists, but the field enumeration substitutes adequately.

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 single param is already documented. The description still adds value by stating the id's provenance (search or autocomplete), which is not in the schema and tells the agent where a valid value must come from.

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 reminder by id') and enumerates the returned fields (description, date, remindee, completion state, linked records), so an agent knows exactly what it gets. It does not explicitly name rex_search_reminders as the alternative, but the id-provenance sentence implies the split.

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 id comes from a search or autocomplete' tells the agent this is a follow-up call and points at the sibling family that produces ids. No explicit when-not or fallback behavior is given, which keeps it short of a 5.

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

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

readOnlyHint=true already covers safety, so the description's value-add is the enumeration of returned fields (property, tenants, lease dates, rent) — meaningful because there is no output schema. The endpoint note clarifies that a "read" is performed via POST, which prevents a wrong assumption about the HTTP verb. No mention of permissions or error cases, keeping it below 5.

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

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

Two short sentences, front-loaded with the resource and its payload. The trailing endpoint path is the only element of marginal use to an agent, slightly diluting otherwise tight phrasing.

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

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

A single-parameter read tool with no output schema is adequately covered: input provenance and returned fields are both stated. Nothing critical is missing for correct invocation, though auth or not-found behavior 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?

With one parameter at 100% schema coverage, the schema already defines id as a positive integer. The description adds provenance the schema cannot express: the id must originate from a search or autocomplete call, which guides correct value sourcing. That is genuine additive meaning above 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+resource: fetch one tenancy by id, and enumerates the payload it covers (property, tenants, lease dates, rent). This cleanly separates it from rex_search_tenancies, which returns many. It stops just short of naming the sibling outright, but the single-record scope 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?

"The id comes from a search or autocomplete" tells the agent where to get the required input, implicitly routing to rex_search_tenancies / rex_autocomplete_* when no id is on hand. The prerequisite (must already have an id) is clear, though there is no explicit "do not use for listing" exclusion.

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?

readOnlyHint=true already tells the agent this is a safe, non-mutating read, so the description needn't re-litigate safety. It adds the underlying endpoint (POST /v1/rex/UserProfile/read) and the field set, but says nothing about what happens if no account is signed in, auth failure modes, or whether the response is cached.

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

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

Three short fragments, front-loaded with the identity/scope and followed by the returned fields, then the usage cue and endpoint. No filler or restatement of the title beyond what adds meaning.

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 the burden of describing the return payload and does so by enumerating the six fields. It's nearly complete for a zero-param read; minor gaps are behavioral edge cases (unauthenticated state, error responses) that an agent might still want.

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

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

The tool takes zero parameters, so there is no parameter semantics to document and the baseline of 4 applies. The description correctly implies no input is needed by framing this as an identity lookup.

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 resource (the signed-in Rex user) and enumerates exactly what it returns: user id, name, email, ownership flag, position and default office. This cleanly separates it from the sibling rex_search_users, which searches arbitrary users rather than resolving the current identity.

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?

"Good first call" gives concrete, actionable sequencing guidance — an agent knows to invoke this during bootstrap before user-scoped calls. It stops short of explicit exclusions (e.g., 'use rex_search_users to look up other users'), so it earns a 4 rather than a 5.

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

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

Consistent with readOnlyHint=true, and it goes beyond the annotation by disclosing the underlying endpoint (POST /v1/rex/SystemValues/getCategoryValues) and the shape of what comes back (id and label pairs) in the absence of an output schema. It omits edge behavior such as error handling for an invalid list_name or whether results are ordered/paginated.

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

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

Three short sentences with zero waste: purpose first, then the practical payoff of the ids, then the raw endpoint for traceability. Nothing is buried or repeated.

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-only lookup with no output schema, the description covers what it returns (id and label), the source of the argument, and why the result matters. Only failure modes and result ordering are left unaddressed.

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

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

Schema coverage is 100% and the single parameter is already documented as the list name sourced from rex_list_value_lists. The description adds a concrete example value (property_category) but does not explain the allowed pattern or what happens with a malformed name, so it stays at 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: retrieves the allowed values (id and label) of a single Rex value list, with a concrete example (property_category). It is distinguishable from rex_list_value_lists as the expansion step, but the description never names that sibling explicitly, relying on the schema's 'from rex_list_value_lists' note to disambiguate.

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 ids are what writes and criteria expect' implies the downstream use case (fetching valid ids before writing or filtering) but gives no explicit when-to-use/when-not, no mention of rex_list_value_lists as the prerequisite/alternative path, and no guidance on what to do with an unrecognized list_name.

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, so the safety profile is covered. The description adds that results are scoped to the signed-in user and names the backing endpoint, but says nothing about auth requirements, error behavior, or ordering. Note the POST endpoint is disclosed despite the read-only annotation – this is not a contradiction, since many read operations use POST, but it is worth flagging for an agent that infers semantics from the verb.

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: what it returns, how it's used, and the endpoint. Front-loaded with the payload shape and free of filler. Every sentence adds something.

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 the return contract and does so adequately by naming account_id and name. For a simple zero-param read tool with a readOnlyHint annotation, only minor things (pagination, empty-result behavior) are unstated.

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?

Zero parameters, so nothing needs explaining beyond the absence of filtering. The description correctly implies no inputs are required. Baseline 4 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 the specific resource and its shape: 'The Rex agency accounts (account_id and name) this user can sign in to.' An agent immediately knows it returns a list of accounts for the authenticated user. No sibling tool lists accounts, so no sibling differentiation is needed, though a leading verb ('List...') would make it crisper.

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 real operational context: 'A user with several accounts picks one with the Account id field when connecting,' which tells the agent both when this tool is relevant (multi-account users) and what downstream value the result feeds. It stops short of stating prerequisites or what to do when only one account exists.

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, so the safety profile is covered; the description adds the genuinely useful behavioral detail that only names are returned, which prevents an agent from expecting ids/values. The endpoint string (POST /v1/rex/SystemValues/getValueCategories) is slightly at odds with the read-only nature of the call, but the annotation resolves that and nothing in the prose contradicts it.

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 plus the endpoint: what it returns, what it's for, and what to do next, in that order. No filler and nothing an agent must read past to reach the actionable 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 no-param, read-only catalog lookup with no output schema, the description supplies enough: the shape of the return (names), their purpose, and the next call. It could say whether the list is fixed or user-configurable and whether results are ordered, but that is a minor 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?

The tool takes zero parameters, so the baseline is 4 and there is nothing for the description to compensate for. No misleading param hints are given.

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

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

Specific verb+resource ("The names of Rex's value lists") with a parenthetical that defines what a value list is (allowed ids for note types, reminder types, lead sources, property categories), which an agent would otherwise not know. It also clarifies the return is names only, not the values themselves, and points at rex_get_value_list as the consumer.

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

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

Explicitly states the follow-on action ("Use a name with rex_get_value_list"), giving a clear discover-then-fetch workflow. It stops short of stating when not to call it or how it relates to the sibling rex_get_value_list's own input shape, so it's clear context without full 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, so the safety profile is clear. The description adds useful behavior beyond annotations: filters combine with AND, results are paged via offset/limit, and next_offset indicates continuation.

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 front-loaded and appropriately sized, covering purpose, filtering, paging, and useful fields in a compact form. The trailing endpoint reference is minor implementation detail that slightly dilutes conciseness but does not harm usability.

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 a rich parameter schema and readOnly annotation, the description provides enough context to call the tool correctly: what activities are, how filters combine, and how paging works. It does not detail result fields, but no output schema exists and the search purpose is clear.

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 all parameters. The description adds activity-specific field examples (parent_object_type, parent_object_id, type_id, system_ctime, system_created_user_id) and clarifies next_offset continuity, giving extra semantic value 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 verb and resource: searching activities, with a parenthetical defining activities as the log of calls, emails, and other actions on records. This clearly distinguishes it from sibling search tools such as appointments, contacts, and listings.

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

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

The description implies when to use the tool by defining activities and search behavior, but it does not explicitly state when to use it versus alternatives like rex_search_appointments or rex_describe_search_fields. No exclusions or routing guidance are provided.

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, so the description is free to spend its words on the pagination contract (offset/limit with next_offset as the continuation token) and the AND-only combination rule, which the annotations do not cover. It stops short of describing result row shape or behaviour on invalid field names.

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 resource and its clarification, then pagination, then field discovery. Every sentence carries a distinct fact and nothing repeats the schema verbatim.

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 five-parameter nested search tool with no output schema, the description covers the mutation/safety stance (via annotations), the AND semantics, the paging loop including how to continue, and where to get valid field names. An agent can construct a correct call and page through results without guessing.

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 genuinely new parameter-level guidance: which service to pass to rex_describe_search_fields to discover legal `criteria.name` values and the fact that searchable fields mirror Reminders (reminder_date, remindee_user_id, contact_id, property_id, listing_id). That is information absent from 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 (Search) and resource (appointments) and clarifies the ambiguous term as "calendar items such as inspections and meetings", which an agent could not infer from the name alone. It does not, however, explicitly distinguish itself from near neighbours like rex_search_reminders or rex_search_activities, so the sibling boundary is only implied.

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 clear operational context: filters combine with AND, results are paged, and field names must come from rex_describe_search_fields with service Appointments. It does not state when to prefer this over rex_search_reminders or rex_search_activities, so there is no explicit exclusion or alternative routing.

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

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

readOnlyHint=true already covers the safety profile, and the description goes beyond it by disclosing that criteria are ANDed (only `in` gives OR), that results are paged, and where to resume via next_offset. It omits anything about result volume, default paging behavior interaction, or the shape of returned appraisal records, but the added semantics are genuinely useful.

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

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

Two sentences, front-loaded with purpose, followed by operational constraints — no filler. The trailing "Useful fields" list is compressed to bare names, which is efficient but slightly raw.

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 five parameters, nested criteria objects, and no output schema, the description covers the essential mechanics: how filters combine, how paging continues, where field names come from, and which fields matter. The returned record shape is not described, though rex_get_appraisal partially covers that 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 coverage is 100%, so the baseline is 3; the description largely restates the schema's AND-combination rule and the next_offset paging hint. Its one real addition is the list of useful field names (appraisal_date, agent_id, pipeline_stage_id, price_asking, etc.) that an agent can feed into criteria.name, which is helpful but not elaborated into syntax.

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 domain term ("listing presentations / market appraisals"), which an agent could not infer from the name alone. It doesn't explicitly route to rex_get_appraisal for single-record fetches, so differentiation from siblings is implied 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 AND-combination rule and the paging contract (offset/limit with next_offset) tell the agent how to drive the tool, and it defers field-name discovery to rex_describe_search_fields. However, there is no explicit when-to-use/when-not, and no mention of rex_get_appraisal as the alternative for retrieving one appraisal by 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, so the safety profile is covered. The description adds useful behavior beyond annotations: AND semantics for criteria, pagination via offset/limit and next_offset, and the prerequisite to discover searchable fields via rex_describe_search_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?

The description is compact and front-loaded, starting with the core purpose and then covering filtering, paging, field discovery, and the endpoint. Every sentence carries useful operational context without unnecessary 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?

Given the nested criteria and order_by schema, the description supplies enough operational context to call the tool correctly, including AND filtering, pagination, and field discovery. It does not describe the returned campaign record structure beyond next_offset, which is a minor gap for a search 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 description coverage is 100%, so the schema already documents limit, offset, criteria, order_by, and search_state in detail. The description reinforces filtering and pagination semantics but adds little parameter-level information 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: search campaigns, specifically nurture and marketing campaigns with their members. This clearly distinguishes it from the many other rex_search_* sibling tools by resource domain.

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

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

It gives clear usage context by explaining that filters combine with AND and that paging uses offset/limit with next_offset. It also tells the agent to call rex_describe_search_fields with service Campaigns for searchable fields, but it does not explicitly state when not to use this tool versus alternatives.

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

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

The readOnlyHint annotation already establishes that this is a safe read operation. The description adds useful behavioral context beyond annotations: criteria are AND-combined, pagination uses offset/limit, and next_offset indicates where to continue.

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 front-loaded with purpose, filtering behavior, and the key alternative. The field list and endpoint are somewhat extra but still useful; overall it is appropriately sized and structured.

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

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

Given the rich schema and readOnly annotation, the description covers the main call behavior: filtering, paging, useful fields, and an alternative tool. It does not fully describe the response shape beyond next_offset, but it is complete enough for an agent to invoke the tool correctly.

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

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

Schema description coverage is 100%, so the schema already documents limit, offset, criteria, order_by, and search_state in detail. The description reinforces AND logic and pagination but adds little parameter meaning 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: search contacts, explicitly covering people and companies. It also names the sibling rex_autocomplete_contacts for a narrower name lookup, so the agent can distinguish this tool from alternatives.

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 that criteria combine with AND and that results are paged with offset/limit and next_offset. It also gives an explicit alternative condition: to find someone by name, use rex_autocomplete_contacts instead.

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, so the description doesn't need to re-establish safety. It adds real behavioral detail beyond annotations: AND semantics for criteria, offset/limit paging, and that next_offset from the prior reply says where to resume.

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

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

Four compact clauses, front-loaded with purpose, then filtering, paging, and field examples. Every sentence earns its place, though the 'Useful fields' enumeration is a loose list without explaining how those fields are used in criteria.

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, paged search tool with no output schema, the description covers the essentials: how filters combine, how paging works, and where continuation comes from. It leaves the exact response shape unstated, but the next_offset reference gives enough to iterate correctly.

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

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

Schema coverage is 100%, so every parameter is already documented in detail, including the criteria shape, AND semantics, and order_by guidance. The description's 'Useful fields' list adds concrete example field names but largely restates constraints the schema already carries, 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 ('Search deals') and clarifies scope with '(the sales pipeline)', which distinguishes it from get_deal-style retrieval. It does not distinguish itself from the many other rex_search_* siblings, but the resource name alone is unambiguous.

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

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

Usage is only implied by the tool name and the mention of paging via next_offset. There is no explicit statement of when to use this instead of rex_get_deal or rex_describe_search_fields, nor any exclusion about what cannot be searched.

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 readOnlyHint annotation already covers the safety profile. The description adds useful behavioral context by noting AND-combined filters and offset/limit paging with next_offset, but it does not discuss permissions, rate limits, or the returned record 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?

The description is short and front-loads the purpose, filter behavior, and paging. The list of useful fields and the trailing POST endpoint are somewhat implementation-focused, but they do not make it bloated.

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 search tool with a rich input schema, the description covers the essential query behavior: filtering, paging, and example fields. The lack of output schema is partly offset by the next_offset paging hint, though the returned record structure is not described.

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 parameter meanings are already well documented in the schema. The description reinforces AND filter behavior and paging with next_offset, and lists example lead fields, but it adds little beyond the structured 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 verb and resource, 'Search leads', and clarifies that leads are enquiries from portals, the website, and email. It does not explicitly distinguish this search tool from siblings such as rex_get_lead or rex_describe_search_fields, 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 search-oriented name and the mention of filter and paging mechanics. However, the description does not say when to use this tool instead of rex_get_lead, rex_search_contacts, or rex_describe_search_fields, and it gives no explicit 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, so safety is covered. The description adds real behavioral detail beyond that: filters combine with AND (only 'in' gives OR, per schema), results are paged, and next_offset indicates continuation. No auth, rate-limit, or result-shape caveats, but for a read-only search this is solid.

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

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

Three short sentences, front-loaded with what the tool does and the key AND/paging semantics. The trailing POST path is minor low-value detail but takes only a clause.

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?

No output schema exists, and the description partially compensates by naming next_offset as the pagination cursor in the reply. With 0 required params, 5 fully documented parameters, and a mutation-free profile, an agent has enough to call this correctly; the actual row shape remains undisclosed.

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 AND-combination semantics, paging defaults, and order_by guidance, so the schema carries the load. The description restates the AND rule and paging hint but adds no new meaning (e.g., criteria/limit interaction or recommended filter patterns).

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 glosses the resource domain ('listing events (open homes and inspections)'), which is genuinely clarifying. It does not distinguish itself from the nearest sibling, rex_search_appointments, which could plausibly cover inspections, so it stops short of 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 a concrete prerequisite workflow: call rex_describe_search_fields with service ListingEvents before building criteria, and use next_offset to continue paging. It does not say when to prefer this over rex_search_appointments or other search siblings, so no exclusions are covered.

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, so the safety profile is covered. The description adds genuinely non-obvious behavior: criteria combine with AND unless the `in` type is used, results are paged with offset/limit, and next_offset indicates continuation. It omits anything about result caps or what the record payload looks like, keeping it below 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?

Front-loaded with the verb and resource, then pagination, then the field crib sheet, then the alternative tool. A single dense paragraph with no filler, though the inline field enumeration is longer than strictly necessary.

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?

Five parameters with nested criteria/order_by objects and no output schema, so the description carries real burden — and it does cover filter semantics, paging continuation, and where field names come from (rex_describe_search_fields). The absence of any description of returned listing shape or result-size limits leaves a small 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 coverage is 100%, so baseline is 3; the description earns above that by explaining the AND-conjunction model, the OR exception via `in`, and by naming concrete useful field paths (system_listing_state, adr_postcode, attr_bedrooms) with an example value. It does not restate limit/offset bounds, which the schema already handles.

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

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

States a specific verb and resource ("Search listings (properties for sale or rent)") and immediately names the sibling that serves a narrower purpose, rex_autocomplete_listings. An agent can distinguish this from rex_search_properties and the autocomplete tools without opening a schema.

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

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

Explicitly routes address lookups to rex_autocomplete_listings and defines the AND combination semantics for filters. It stops short of saying when to prefer this over rex_search_properties or how to choose search_state, so it is clear context rather than full 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, so safety is covered. The description adds meaningful behavioral context: criteria combine with AND, results are paged, next_offset indicates continuation, and field discovery requires rex_describe_search_fields. It does not describe auth, rate limits, or detailed return shape, but with the read-only annotation present the added context is solid.

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

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

The description is short, front-loaded with the tool's purpose, and moves efficiently through filtering semantics, paging, useful fields, field discovery, and the endpoint. No sentence is wasted.

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

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

For a read-only search tool with full schema coverage and annotations, the description covers the essential purpose, filtering, paging, and field-discovery workflow. It does not explain the response item shape beyond paging, and no output schema exists, but the core calling guidance is complete enough.

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

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

Schema description coverage is 100%, so the schema already documents limit, offset, criteria, order_by, and search_state thoroughly. The description mostly restates schema-level semantics such as AND-combined filters and offset/limit paging; its main extra value is naming useful fields and pointing to rex_describe_search_fields, which the schema also does.

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

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

The description gives a specific verb and resource: 'Search notes recorded against contacts and properties.' This clearly distinguishes it from note-fetching and note-creation tools, and from the many sibling search tools that target other resources.

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 mechanism for filtering and paging, names rex_describe_search_fields for discovering related contact and property fields, and gives useful field examples. It does not explicitly say when to use this instead of rex_get_note for a known note or other sibling searches, but the resource scope is clear.

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

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

Annotations only declare readOnlyHint=true, so the description adds value by disclosing the AND-only filter semantics, the offset/limit paging model, and specifically that next_offset indicates where to continue — information not present in the annotations and important because there is no output schema. Missing: any note on result size caps or what happens with 30+ criteria, though the schema covers those bounds.

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 purpose and the entity definition, then filter semantics, then paging, then example fields. Dense and mostly waste-free; the trailing POST endpoint adds little for an agent choosing a tool but is 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?

Five parameters, nested criteria objects, no output schema and no destructive behavior — the description covers purpose, filter logic, pagination continuation, and where field names come from, which is everything an agent needs 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 coverage is 100%, so the baseline is 3; the description earns above that by listing concrete useful field names (property.system_search_key, property.adr_postcode, property.attr_bedrooms, etc.) that are not enumerated anywhere in the schema, and by clarifying the criteria AND-combination and next_offset continuation 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?

States a specific verb+resource and immediately disambiguates the entity: properties are 'the physical addresses behind listings, appraisals and tenancies', which separates it from rex_search_listings and rex_search_appraisals without opening either schema. The endpoint reference (POST /v1/rex/Properties/search) confirms the 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?

Explains how to query (criteria combine with AND, only the 'in' type gives OR) and points to rex_describe_search_fields as the prerequisite for field names, which is real usage guidance. However, it never states when to use this tool rather than rex_search_listings or rex_get_property for a single record — the alternative routing is left 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 readOnlyHint=true, and the description adds real context beyond that: AND-only filter semantics, offset/limit paging with next_offset, the null-completion indicator for open reminders, and the underlying POST endpoint. Return shape is only partially described, but it goes meaningfully beyond the annotation.

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 purpose and scope, then paging, then field names. It is dense but nearly every clause carries information; the long field list is slightly list-heavy but still relevant.

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 five-parameter, nested-criteria search with no output schema, the description covers filtering semantics, paging and continuation, and the notion of open versus completed records. It stops short of sketching the result shape (e.g., that results contain reminder objects), but overall it is sufficient to call the tool correctly.

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

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

Schema coverage is 100%, so the baseline is 3; the description earns a step up by listing the practically useful field names (reminder_date, contact_id, priority_id, etc.) and clarifying that next_offset drives continuation. It does not add operator syntax detail, but it usefully concentrates which criteria fields matter.

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

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

States a specific verb and resource (search reminders) and adds scope detail (linked to contacts, properties, listings; includes tasks). It is clearly distinct from rex_get_reminder or rex_create_reminder, though it never names the sibling 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?

Explains that criteria combine with AND and how paging works, and notes that open reminders have a null system_completed_time, which is useful context. It does not say when to use this search versus rex_get_reminder, nor does it state that rex_describe_search_fields should be consulted first (that hint lives only in the schema).

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

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

Annotations already declare readOnlyHint=true, so the safety profile is covered; the description adds genuinely new context: criteria combine with AND (only `in` gives OR) and results are paged with next_offset telling you where to continue. It also lists commonly useful return fields, which matters because no output schema exists. Rate limits, maximum criteria/limit behavior and error semantics are not covered, keeping it below 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 compact sentences plus the endpoint, front-loaded with the resource definition, then filter semantics, then paging and useful fields. Every clause carries information an agent needs to construct a call.

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 five-parameter tool with a nested criteria array and no output schema, the description supplies the return-shape hints (next_offset, useful fields) and AND semantics that the schema alone would not make obvious. Gaps remain around whether criteria may be omitted entirely and what the default result ordering is.

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 still earns a bump by naming the useful fields an agent can search on (id, property_id, system_record_state, lease_current_expiry, crt.contact_id) and by explaining next_offset as the continuation token, neither of which the schema states. It stays silent on order_by and search_state, which the schema handles alone.

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

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

States a specific verb and resource ('Search tenancies') and adds a clarifying gloss ('property management leases') that disambiguates the domain term. It does not explicitly contrast with rex_get_tenancy or the other rex_search_* tools, so sibling differentiation is left to naming convention.

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 'Search' plus the routing hint that field names come from rex_describe_search_fields (mentioned in the schema too). There is no explicit statement of when to use this versus rex_get_tenancy for a single lease, and no exclusions or prerequisites such as account scoping.

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 only declare readOnlyHint=true; the description adds real behavioral context: filters combine with AND, results are paged via offset/limit, and next_offset indicates where to continue. That paging contract is the key non-obvious behavior. It stops short of describing what the response objects contain beyond the id.

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?

Five short sentences, front-loaded with the core purpose, then paging, then field hints and the endpoint. Nothing is padding; even the endpoint line is a compact operational 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 parameterless-required, nested-criteria search tool with no output schema, the description covers scope, filter semantics, paging and field discovery. The main gap is the response shape — it is unclear whether 'Useful fields' are searchable inputs or returned attributes, which an agent must know 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 baseline is 3. The description still adds value by naming concrete searchable fields (first_name, last_name, email, status, user_group_id) and clarifying the offset/limit/next_offset paging loop, though the AND-combination rule largely duplicates the schema's criteria description.

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 with scope: 'Search the users (staff) of the agency account.' It is unambiguously distinct from the many other rex_search_* siblings (contacts, listings, deals) and adds that returned user ids serve as agent/assignee/remindee ids elsewhere, which tells an agent exactly what this tool yields.

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 line 'User ids are used elsewhere as agent, assignee and remindee ids' gives a concrete when-to-use signal, and pointing at rex_describe_search_fields implies the field-discovery prerequisite. However, it never states when NOT to use it (e.g. vs rex_get_user_profile for a single user, or rex_autocomplete_contacts), so there is no explicit alternative routing.

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