UniAffitti Room Finder

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

Annotations already declare the write nature (readOnlyHint=false), idempotency, and safe/non-destructive behavior, so the safety profile is covered. The description adds only the 'approved room' precondition and the auth scope, but leaves unclear what 'approved' means or what happens on a duplicate/already-favorited call.

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

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

A single, well-formed sentence with the action and target front-loaded and no redundant 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?

An output schema exists and annotations cover the safety profile, so return values need not be explained. However, the description omits error conditions, the meaning of 'approved', and param provenance, leaving meaningful gaps for a mutation tool.

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

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

Schema description coverage is 0% and the description adds no meaning beyond the schema's room_id (integer, minimum 1). It does not say where the room_id comes from (e.g., get_room_details or search_rooms), so it fails to compensate for the coverage gap.

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

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

States a specific verb and resource: 'Save an approved room to the authenticated user's favorites.' An agent can identify the operation clearly, but the description does not name how it differs from siblings like remove_favorite or list_my_favorites, so it stops short of full sibling differentiation.

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

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

There is no when-to-use or when-not-to-use guidance and no mention of alternatives such as remove_favorite (to undo) or list_my_favorites (to verify). The agent must infer the usage context entirely.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile needs no repeating. The description adds one genuine behavioral nugget — only 'public' listings are comparable — but says nothing about the 2–8 room bounds, error behavior for private/invalid IDs, or result ordering.

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

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

One sentence, verb-first, no filler, and the enumerated dimensions give the reader immediate value. Nothing to trim and nothing relevant 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?

An output schema exists, so return values need no explanation, and the listed dimensions roughly preview it. However, for a tool with two undocumented parameters and hard cardinality limits, the description omits constraints an agent must know to call it successfully.

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

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

Schema description coverage is 0% for two parameters, so the description must carry the burden and largely fails: room_ids is only obliquely implied by 'selected ... listings' and campus_id is never mentioned at all. Neither the minItems=2/maxItems=8 limits nor the campus scoping semantics are surfaced.

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 (compare) and resource (public room listings) and enumerates the compared dimensions. The 'side by side' framing implicitly separates it from single-room tools like get_room_details, but it never names an alternative, so sibling differentiation is inferred rather than explicit.

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

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

No when-to-use guidance, no stated prerequisites, and no mention of the practical constraints (min 2 / max 8 rooms, or how campus_id affects the comparison). The agent is left to infer the intended invocation context from the name alone.

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 the mutation/safety profile (readOnlyHint=false, destructiveHint=false, non-idempotent, openWorld). The description adds real context beyond that: the object is a draft, invisible until approved, stores full address and coordinates, leaves university/campus IDs unset, and carries a PII prohibition. It does not touch idempotency (duplicate drafts on re-call), which the annotation covers.

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

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

Three tight sentences, front-loaded with the create action and draft state, followed by storage behavior and the compliance constraint. No filler, though the PII sentence duplicates the schema's description-field note.

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

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

An output schema exists, so return values need not be explained, and the moderation/draft lifecycle is covered. However, for an 18-parameter create tool with low schema coverage, the description omits guidance on most inputs and on re-call/idempotency behavior, leaving a noticeable gap.

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

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

Schema description coverage is only 33% across 18 parameters (10 required, 3 enums), so the description must compensate heavily and does not. It speaks only to address_full, coordinates, and an out-of-schema note about university/campus IDs; price_currency, room_type, occupancy_status, property_type, and other required fields get no added meaning, and the PII advice for description merely repeats the schema.

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

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

The description names a specific verb (Create) and resource (a listing draft) and scopes it to a named workflow (UniAffitti moderation). No sibling tool creates listings, so it is unambiguously distinguishable from create_rental_request and the list/update 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 clarifies that the result is a non-public draft pending approval, which implies when this is appropriate, but it never states when to use this over an alternative or any prerequisite for calling it. With no explicit alternative named, usage must be inferred.

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

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

Annotations already declare the safety profile (readOnly=false, destructive=true, idempotent=false, openWorld=true), so the bar is lower. The description adds genuinely non-redundant behavior: the landlord is notified and the request persists in the account until its status changes, plus a PII prohibition. It stops short of describing failure behavior or rate limits.

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

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

Three sentences, front-loaded with the action, then behavior, then the safety constraint. Every sentence carries weight, though the PII sentence partially duplicates the schema's message description.

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

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

An output schema exists, so return values need not be explained, and annotations cover the destructive/open-world profile. The description covers notification and persistence, leaving only edge cases (failure, duplicate requests, approval-state enforcement) unspecified for a mutation tool.

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

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

Schema coverage is 50% (only message and start_date are documented in-schema). The description reiterates that message is optional with the same PII warning already in the schema, and ties room_id to an approved available room, but says nothing extra about start_date or duration_months semantics. Baseline 3 is appropriate.

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

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

States a specific verb+resource ('Create and send a rental request') and narrows the scope to 'an approved available room' under the authenticated UniAffitti account. It does not name the closest sibling (send_room_message) to explain the difference, so an agent must infer the distinction from the resource noun.

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

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

The phrase 'for an approved available room' is an implicit precondition that constrains when the tool is valid, which is useful. However, there is no explicit when/when-not guidance and no routing to alternatives such as send_room_message or update_rental_request_status.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so safety is fully covered by structured data. The description adds one useful piece of context — the links target the 'full UniAffitti web app' (as opposed to an API or mobile surface) — but says nothing about whether sign-in is required for the links to resolve.

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

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

A single sentence with zero filler, and the verb and destination are front-loaded before the enumeration of link categories. Nothing could be trimmed without losing information.

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

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

An output schema exists, so the description need not explain return values, and it correctly spends its words on scope instead. For a zero-param read tool this is nearly complete; the only omission is whether the links are absolute or require an authenticated session.

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 per the rubric the baseline is 4. There is no parameter surface for the description to clarify or for it to neglect.

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 ('Return') and resource ('deep links') and enumerates exactly which app areas are covered (account, listing creation, messages, requests, favorites). It is unambiguous what comes back, though it never distinguishes itself from structurally similar siblings like get_my_profile or list_my_messages, which cover the same domains with data rather than links.

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

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

No when-to-use guidance and no exclusions. The critical ambiguity — this returns URLs to web pages, while get_my_profile / list_my_messages / list_my_requests return the underlying data — is left for the agent to infer, which is exactly the confusion that most needs resolving here.

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

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds the 'data-only' framing (no side effects) and the UI-driven invocation model, but says nothing about result ordering or what happens when messages_limit truncates the output.

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

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

Two tight sentences, front-loaded with the action and resource before the invocation context. No filler, though it is thin enough that a few more decisive details could have been added at no structural cost.

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

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

An output schema exists, so return values need no explanation, and the read-only safety profile is covered by annotations. For a 2-parameter read tool the description is nearly complete, with the only meaningful gap being ordering/limit behavior for messages_limit.

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 50%: conversation_id is documented in the schema, while messages_limit carries only a default/min/max with no description. The phrase 'recent messages' hints at recency ordering but does not explain that messages_limit caps how many are returned, so the description does not fully compensate for the gap.

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

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

States a specific verb and resource: 'Load the recent messages for one authenticated UniAffitti conversation.' The 'one ... conversation' scoping implicitly separates it from the list_my_messages sibling, though that sibling is never named, so it stops short of explicit differentiation.

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

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

Gives a usage context ('intended to be called by the messages UI after the user selects a conversation'), which implies the trigger condition. It never states when not to use it or names the alternative for browsing conversations, so guidance is implied 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/idempotentHint/non-destructive, so the safety profile is covered. The description adds genuinely new behavioral context: it may initiate an OAuth connection as a side effect, and it explicitly scopes the returned data for privacy. There is mild tension worth noting — an OAuth handshake with an external provider versus openWorldHint=false — but this is not a clear contradiction of any stated 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 sentences, both front-loaded: the first establishes the trigger condition and the OAuth behavior, the second enumerates the returned and withheld fields. No filler, and every clause 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?

An output schema exists, so return format need not be explained; the description nonetheless usefully summarizes the returned and non-returned fields as a privacy contract. For a zero-parameter read tool this is close to complete, though it says nothing about what happens if the OAuth connection fails or is declined.

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 per the rubric the baseline is 4. The description reinforces this by confirming the tool operates purely on the authenticated user's own profile with no filtering inputs required.

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 (returns) and resource (the authenticated user's profile) and enumerates the exact fields returned plus a secondary behavior (starting OAuth connection). It distinguishes the tool's scope from risky siblings by listing what it deliberately never returns (phone, photos, account IDs, credentials). It does not, however, contrast itself with close siblings like get_account_links, 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?

It gives an explicit trigger condition: 'When the user asks to access or connect UniAffitti, call this tool.' That is a concrete when-to-use rule rather than an inference. It names no alternatives or exclusions (e.g., when get_account_links would be preferred), so it stops short of a 5.

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

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

Annotations already declare readOnly, idempotent, non-destructive, open-world, so the safety profile is covered. The description adds genuinely new context: results are public-only, restricted to 'approved' rooms, and landlord trust info is deliberately 'limited', which tells the agent what it will and won't get back.

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

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

A single front-loaded sentence that lists the returned content with zero filler. Every clause earns its place.

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

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

An output schema exists, so return values need not be re-explained, yet the description usefully previews them. Annotations cover safety. The only omission is behavior on failure (missing or unapproved room_id), which keeps it short of a 5.

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?

One parameter at 0% schema description coverage; the description never mentions room_id or its semantics. However, the name is self-explanatory and the schema constrains it to an integer >= 1, so the gap is minor rather than damaging.

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 ('Return public details for one approved room') and enumerates the payload (description, media, features, trust info). It implies single-record retrieval, distinguishing it from search_rooms, but never names or contrasts the sibling explicitly.

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

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

Usage is only implied — an agent infers you call this with a room_id when you need one room's detail page. There is no statement of when to prefer it over search_rooms or compare_rooms, and no prerequisites or exclusions.

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

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint, so safety is covered. The description adds two useful facts: the list is scoped to the authenticated user and only 'available' rooms appear — implying unavailable saved favorites are excluded. It says nothing about ordering, paging, or result 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?

A single front-loaded sentence with no filler. Every word carries meaning, and the scoping terms (authenticated user, saved, available) come before any trailing 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?

With an output schema present, return values need not be described, and zero parameters removes schema risk. The remaining question — what 'available' filters out and how the list is ordered — is a minor gap for a simple zero-arg list 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?

The tool takes zero parameters, so there is nothing for the description to explain; baseline 4 applies. No syntax or filter options are implied that the schema would need to document.

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

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

States a specific verb (List) and resource (the authenticated user's saved available rooms), which is unambiguous. It does not explicitly contrast with siblings like add_favorite or remove_favorite, but the verb makes the read-vs-mutate 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?

No statement of when to use this over alternatives, no preconditions, no mention of paging or filtering behavior. The agent must infer usage from the name alone.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint=false and destructiveHint=false, so the safety profile is fully covered. The description adds two useful facts beyond that: the result is scoped to the authenticated user (auth requirement) and includes moderation status. It does not add anything about ordering, pagination, or result volume.

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

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

A single sentence with zero padding, front-loading the action and scope. Nothing could be removed without losing 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?

For a zero-parameter read tool with a rich annotation set and an output schema covering return values, the description is essentially sufficient: it says whose data and what extra field comes back. Only minor omissions (result scope/volume, ordering) remain.

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 disambiguate. Schema coverage is also 100%.

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

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

States a specific verb (List) and resource (listings) restricted to the authenticated user, plus the extra payload detail 'moderation status'. The 'own' scoping implicitly separates it from search_rooms or get_room_details, though it does not name any sibling explicitly.

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

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

No when-to-use, prerequisites, or alternative-tool guidance is given. The scope 'authenticated user's own listings' hints at the use case, but the agent must infer it against siblings like search_rooms or list_my_favorites with no stated rule.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds useful mode context ('fast conversation summaries' vs 'complete recent messages' and web-app parity), but does not address truncation behavior, auth failure, or rate limits.

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

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

Two compact sentences with the dual-mode distinction front-loaded and no padding. It is dense but every clause carries information, though the clause ordering mixes scope and mode slightly.

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

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

An output schema exists, so return-value detail is not required. The description covers the mode split but leaves the limit/messages_limit and unread_only semantics unexplained, which is a meaningful gap for a 4-parameter list 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 description coverage is only 25%; only conversation_id is documented in the schema. The description does not explain limit versus messages_limit (the distinction an agent most needs), nor unread_only, so three parameters remain ambiguous.

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

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

States a specific verb (read) and resource (authenticated user's UniAffitti conversations) and clarifies the dual-mode behavior: summaries without conversation_id, full messages with it. It does not, however, distinguish itself from the sibling get_my_conversation_messages, which appears to cover the same with-id case.

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?

Clearly explains the two calling modes and what each returns, so an agent knows which parameters select which behavior. It stops short of naming an alternative tool or stating exclusions, leaving the overlap with get_my_conversation_messages unresolved.

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, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered structurally. The description contributes the authenticated-user scoping, which is useful, but says nothing about ordering, pagination, or result volume.

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

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

A single short sentence with the scope constraint front-loaded and no wasted words. It is efficient, though perhaps too terse for the parameter it leaves unexplained.

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

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

An output schema exists, so return values need not be described, and annotations cover the safety profile. What remains unaddressed is the semantics of the direction filter and any limits or ordering on results, leaving the definition adequate but with clear gaps.

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

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

Schema description coverage is 0%, so the description must carry the parameter burden, yet it only echoes the sent/received notions and never explains the 'all' value, the default, or what direction filtering actually changes. One documented enum exists in the schema but the description adds no real meaning on top of it.

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

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

States a specific verb (List) and resource (rental requests) with the scope qualifier 'sent or received by the authenticated user', which tells an agent exactly what set is returned. It does not, however, differentiate itself from similar 'my' siblings (list_my_favorites, list_my_listings) beyond the resource noun.

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

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

No when-to-use guidance, no mention of alternatives such as create_rental_request or update_rental_request_status, and no conditions under which a different tool should be chosen. Usage is only inferable from the resource 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 readOnly, idempotent, non-destructive, and closed-world behavior, so the safety profile is covered. The description does add two useful behavioral facts beyond that — results are paginated and the catalog is not capped at 500 records — but the '500 records' reference is unexplained and no other behavior (auth, response shape) is disclosed.

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

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

Two short sentences, with the core purpose front-loaded — that part is efficient. However, the second sentence about the 500-record cap appears with no antecedent or rationale, reading as an unexplained aside that weakens structure rather than adding value.

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

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

An output schema exists, so return values need not be explained, and annotations cover safety; that lowers the burden. Still, for a tool whose name says 'search metadata' and whose siblings overlap heavily, the description should clarify the relationship to search_universities and list_university_campuses — that gap remains 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 50%: university_query and university_country_code are documented in-schema, while university_limit and university_offset have only defaults/bounds. The phrase 'paginated slice' hints at limit/offset semantics but does not add format, default, or interaction detail beyond what the schema already states, so this sits at the baseline.

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

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

The description gives a verb (list) and resources (university catalog, campuses, feature filters), but it conflates three different things and never explains what 'search metadata' in the tool name refers to. With siblings like search_universities and list_university_campuses present, an agent cannot confidently tell this tool apart from them.

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

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

No when-to-use guidance is given. The description does not state whether this is the discovery/prep step before search_rooms, or how it relates to search_universities or list_university_campuses, leaving the agent to guess which sibling to call.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is fully covered elsewhere. The description adds one behavioral fact: only active campuses are returned, implying inactive ones are filtered out. It does not cover ordering, pagination, or what happens for an invalid university_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?

One sentence, front-loaded with the action and scope, with the purpose clause placed last. Every word earns its place.

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

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

An output schema exists, so return values need not be explained, and the tool is a simple single-param read. The only gap is that the description does not say where university_id comes from, which for a low-coverage schema would be helpful.

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

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

Schema coverage is 0% for the single required university_id, so the description must compensate. It does convey that the parameter selects a university (implying the ID originates from search_universities), but adds no detail on ID format or validation beyond the schema's integer/minimum=1 constraint.

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

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

States a specific verb (List) and resource (campuses) with a clear scope qualifier ('active', 'for a selected university'). It is distinguishable from siblings like search_universities, though it does not explicitly contrast with any of them.

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 trailing clause 'so the user can refine the room search' implies the workflow position (after picking a university, before searching rooms), but no alternatives are named and no when-not-to-use condition is given. Usage must be inferred from the purpose clause.

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

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

Annotations already declare readOnly, idempotent, open-world, non-destructive, so the safety profile is covered. The description adds that only 'public, approved' listings are considered and that content is user-submitted (a reliability caveat), which is real value, but it omits how scoring/ranking works and any ordering or result-count behavior.

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

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

Two sentences with no filler, and the core purpose is front-loaded. The user-submitted caveat is placed at the end, which is appropriate.

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

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

An output schema exists so return values need no explanation, and annotations cover safety. However, for an 8-parameter tool with 13% schema coverage, the description leaves several parameters and the sibling-choice question unaddressed, making it only minimally complete.

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

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

Schema description coverage is only 13%, so the schema does little lifting. The description loosely maps to some parameters (budget=max_budget, campus distance=max_distance_km, room type=preferred_room_type) but ignores query, limit, campus_id, available_from, and the nested features object, so the gap is only partly filled.

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 pair (find and score) and resource (public, approved room listings) with the scoring dimensions called out. It is clear what the tool returns, though it never explicitly distinguishes itself from the sibling search_rooms or compare_rooms.

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

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

The description gives no when-to-use guidance and never names an alternative, despite siblings like search_rooms and compare_rooms that an agent must choose between. Usage is only implied by the tool 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 destructiveHint=true, idempotentHint=true, and readOnlyHint=false, so the safety profile is covered. The description adds 'authenticated user's', implying an auth requirement, but says nothing about behavior when the room isn't favorited or what the response contains beyond what annotations supply.

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

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

A single front-loaded sentence with no filler, appropriate for a one-parameter tool. It is efficient but perhaps slightly under-specified rather than erring on the side of completeness.

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

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

Output schema exists, so return values needn't be described, and annotations cover the mutation/idempotency profile. For a simple one-parameter tool the description is nearly sufficient, with only the parameter format and any error behavior left implicit.

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

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

Schema description coverage is 0%, so the description must compensate for the single room_id parameter. It does not — it never explains the identifier format or constraints beyond what the bare integer schema already shows, leaving the parameter semantics thin.

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 ('Remove a room') plus scope ('from the authenticated user's favorites'), which cleanly distinguishes it from add_favorite and list_my_favorites. It stops short of explicitly naming the sibling alternative, but the operation is unambiguous.

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

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

Usage is implied by the inverse of add_favorite and the 'authenticated user's favorites' scope, so an agent can infer when to call it. However, there is no explicit when-to-use, no exclusion conditions, and no named alternative, leaving the routing 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 readOnly, idempotent, openWorld, and non-destructive, so the safety profile is covered. The description adds that results carry country and university counts, which is useful return-content context, but it says nothing about pagination despite limit/offset parameters existing.

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

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

A single front-loaded sentence with no filler. It is tight, but the compression comes at the cost of omitting routing and parameter detail rather than by economizing on redundancy.

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

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

An output schema exists, so return values need not be restated, and annotations cover safety. However, for a four-parameter search tool inside a 21-tool family with zero schema documentation, the description leaves both filtering semantics and sibling choice unresolved.

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

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

Schema description coverage is 0% across four parameters (query, limit, offset, country_code), so the description must compensate and largely does not. "Country and university counts" faintly suggests a country dimension, but no parameter's meaning, matching behavior, or default handling is clarified.

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 ("Search cities") with a stated data scope: the active university catalog and public room listings. It implicitly separates itself from search_universities and search_rooms by naming the entity it returns and where it draws from, though it never names those siblings directly.

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

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

The only usage cue is the trailing "for assisted room search," which implies a discovery step before a room search but states no when/when-not condition or alternative. With search_rooms, search_universities, and list_search_metadata available, an agent gets no routing help.

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

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

Annotations already establish readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds real value by scoping results to 'approved, available' rooms and disclosing that content is user-submitted ('public listing content submitted by UniAffitti users'), but it says nothing about pagination behavior despite limit/offset parameters.

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

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

Two tight sentences with zero waste. The filterable dimensions are front-loaded and the provenance note about user-submitted content follows immediately. Nothing is padded.

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

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

An output schema exists, so return-value detail is not required, and the read-only annotations cover the safety dimension. However, for a 14-parameter tool with only 29% schema coverage and no usage guidance, the description leaves meaningful gaps in how to drive the filters correctly, making it only adequate rather than complete.

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

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

Schema description coverage is low (29%), with only city, query, country_code, and available_from documented in the schema. The description partially compensates by grouping the filterable dimensions (budget, type, university, campus, distance, features), which maps to max/min_price, room_type, university_id, campus_id, max_distance_km, and features, but it adds no format or syntax detail, leaving the 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?

The description states a specific verb (Search) and resource (student rooms) and enumerates the filterable dimensions: budget, type, university, campus, distance, and features. It is clear on its own, but it never names or contrasts itself with close siblings like rank_room_matches, compare_rooms, or get_room_details, so an agent cannot tell from the description alone which one to reach for.

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

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

There is no when-to-use or when-not-to-use guidance. The description implies a general browse/search entry point, but it does not mention alternatives (rank_room_matches, compare_rooms, get_room_details) or prerequisites, leaving the agent to infer routing from the name alone.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=false, idempotentHint=true, destructiveHint=false, so safety profile is clear. The description adds that it's 'active' records only and supports pagination/total count, which is useful context. However, it doesn't describe return format details or rate limits, so it's modest value on top of annotations.

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

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

A single, well-structured sentence that front-loads the core action and scope. No wasted words.

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

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

Has an output schema, so return values needn't be explained. However, the description omits parameter semantics entirely and provides no usage guidance for a search tool with multiple optional filters. Given the 0% schema coverage, this is a notable gap.

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

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

Schema description coverage is 0%, meaning the 5 parameters (city, country_code, limit, offset, query) are entirely undocumented in the schema. The description mentions 'pagination and total count', hinting at limit/offset, but provides no meaning for city, country_code, or query. With low coverage, the description should compensate but largely fails to do so.

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 clear verb (Search) and resource (universities), and specifies scope (complete active UniAffitti university catalog worldwide). Distinguishes itself from siblings implicitly via the 'universities' resource, though it doesn't explicitly contrast with search_cities or list_university_campuses.

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

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

No indication of when to use this tool versus alternatives like list_university_campuses or search_cities. The description doesn't mention filters (city, country_code, query) as usage conditions. An agent must infer usage entirely from the name and sibling list.

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

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

Annotations already declare readOnly=false, destructive=true and non-idempotent, so the safety profile is covered. The description adds real value beyond them: the message is permanently stored, the landlord is notified, it cannot be recalled, and sensitive data types are prohibited.

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

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

Three sentences, front-loaded with the action and recipient, then consequences, then the data-handling rule. Minor redundancy: the PII prohibition duplicates verbatim text already in the message parameter's schema description.

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

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

With an output schema present, return values need not be described, and annotations cover the destructive/non-idempotent profile. The description supplies the consequential details an agent needs (permanence, notification, no recall) but leaves room_id validity only loosely implied.

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 50% and room_id carries no schema description, so the description's 'approved available room' constraint is the only hint about valid room_id values, partially compensating. The PII warning merely repeats the message parameter's own schema description, adding no new meaning.

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 ('Send and permanently store a message') plus the exact recipient ('the landlord of an approved available room') and the acting identity ('authenticated UniAffitti account'). It is unambiguous versus read-oriented siblings like get_my_conversation_messages or list_my_messages, though it never names an alternative directly.

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 scoping phrase 'approved available room' and the note that messages 'cannot be recalled with this tool,' which hints at deliberation before calling. There is no explicit when-to-use/when-not guidance or named alternative for messaging versus requesting or favoriting.

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 destructive=true, idempotent=false and openWorld=true, but the description adds real value beyond them: authorization depends on the caller's role, accepting has a side effect on the room ('marks the room as rented'), and other participants may be notified. It does not say whether transitions can be reversed or which transitions are legal from a given state.

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 operation and its allowed target states come first, and the consequential behavior (room marked rented, notifications) follows. No filler or repetition.

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

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

With an output schema present, return values need no explanation, and the destructive/non-idempotent nature is covered by annotations plus the side-effect and notification notes. The remaining gap is the conditional available_from requirement and the legal transition rules, which an agent would want before mutating state.

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 33%, with only available_from documented. The description restates the enum values already in the schema and never mentions available_from or that it is conditionally required when accepting, so it does not compensate for the coverage gap beyond what the schema already conveys.

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 ('Change a rental request') and enumerates the valid target statuses, which cleanly separates it from siblings like create_rental_request and list_my_requests. It stops short of naming any sibling explicitly, so differentiation is inferred 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?

'According to the authenticated user's role' signals a permission constraint on who may perform which transition, which is useful context. However, it never states when to prefer this tool over alternatives or when a transition is disallowed, leaving usage guidance implied rather than explicit.

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