officernd

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

Adds real context beyond the destructiveHint annotation: the required OAuth scope 'flex.collaboration.ticketComments.create', the endpoint, and the visibility rule for public vs member-attributed comments. It does not explain irreversibility or rate limits, but the annotations already carry the destructive signal.

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

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

Front-loaded with the WRITE marker and the core action, then constraints and auth. Four compact sentences with little waste, though the raw endpoint string adds marginal 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?

For a write tool with annotations and no output schema, the description covers action, scope, endpoint, and a key visibility constraint. Return behavior and error handling are omitted but are not essential for correct invocation.

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

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

Schema coverage is 100% so the baseline is 3, but the description adds a cross-parameter constraint tying 'member' to 'is_public' that the schema does not express. That is meaningful semantics beyond the field-level docs.

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 ('Post a comment on a helpdesk ticket') and the WRITE prefix immediately signals the operation class. It is clearly distinguishable from siblings like create_ticket or list_tickets.

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 a clear business rule for the operation ('comments attributed to members must be public') and marks it as a write, but never names a when-not condition or an alternative tool. There is no competing sibling for commenting, so context is adequate.

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 carry only destructiveHint=true, so the description does the heavy lifting and delivers: it declares a write, that charges accrue per the resource rate by default, that the member is notified unless silenced, and that the flex.space.bookings.create scope is required. It omits conflict/double-booking handling and rate limits, so not a full 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 tight sentences with the operation type front-loaded and no filler; each clause conveys either scope, behavior, or auth requirement.

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

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

For a 13-parameter mutation with no output schema and only a destructiveHint annotation, the description covers the essential behavior an agent needs: write semantics, default charging, notification, and required scope. Return shape is excusably absent given no output schema, though conflict/failure behavior is 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 description coverage is 100%, so every one of the 13 parameters is already documented in the schema, making 3 the baseline. The description clarifies the default charging model and reiterates the is_free/is_tentative/is_silent interplay, but adds little semantics beyond what the individual parameter descriptions already state.

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

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

Opens with a specific verb+resource ('WRITE. Book a resource (e.g. a meeting room) for a member and/or company'), immediately distinguishing it from read-side siblings like officernd_get_booking and officernd_list_bookings. The scope tag and REST endpoint (POST /bookings) pin down exactly which operation this is.

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

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

The description gives conditional context ('unless is_free or is_tentative is set...', 'unless is_silent') which implies when certain behaviors apply, but never states when to choose this tool over siblings or any prerequisites beyond the scope. Usage is inferred rather than directed.

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 are sparse (only destructiveHint=true and a title), so the description usefully adds 'WRITE', the required OAuth scope, and the backing endpoint. It does not disclose what the call returns (the new member's _id) despite there being no output schema, nor any failure/duplicate-handling behavior, leaving real behavioral gaps.

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

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

Three short sentences, front-loaded with the 'WRITE' marker and scope requirement before the resource description. Every clause carries information; no filler or repetition of the schema.

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

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

For an 11-parameter creation tool with a nested custom-properties object and no output schema, the description is adequate on the write/scope side but silent on the return payload and on the meaning of the surprising destructiveHint=true annotation. An agent can call it, but cannot anticipate the response.

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

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

Schema description coverage is 100%, with all 11 parameters including the nested properties object documented in the schema itself, so the baseline is 3. The description only restates the location/company relationship already evident from the schema, adding no new syntactic or format detail.

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: 'Add a new member (person) to a location, optionally attached to a company.' An agent knows exactly what is created and the two key attachment dimensions. It stops short of naming its closest sibling (officernd_update_member) for contrast, so it lands at 4 rather than 5.

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

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

Provides the prerequisite scope ('flex.community.members.create') and states that company attachment is optional, which is usable context. However, there is no guidance on when to prefer this over officernd_update_member or officernd_list_members, and no exclusions — usage is implied rather than specified.

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?

Leads with 'WRITE.' which is consistent with destructiveHint=true, and adds context annotations don't carry: the required OAuth scope and the underlying POST /tickets endpoint. It stops short of saying whether the ticket can be edited/deleted afterward or what the response returns.

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

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

Four very short sentences, front-loaded with the WRITE marker, scope, and endpoint; no filler and each clause carries information.

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

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

For a 7-parameter, 5-required mutation tool with no output schema, the description covers the write semantics, auth scope, endpoint, and the source of the enumerated id parameters. It is adequate; only return/error behavior is unaddressed, which is minor 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, but the description adds real value by explaining that type, priority, and severity are ticket-option _ids obtained from officernd_list_ticket_options, giving cross-tool provenance the schema alone does not.

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

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

States a specific verb and resource ('Open a helpdesk ticket') plus the actor ('on behalf of a member'), which cleanly separates it from create_booking, create_member, and add_ticket_comment among siblings.

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

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

Gives a clear precondition (needs scope flex.collaboration.tickets.create) and routes the agent to officernd_list_ticket_options for the option _ids, but does not state when to choose this over other ticket-related tools or any 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?

readOnlyHint=true already covers the safety profile, but the description goes further by enumerating the returned fields, which matters because there is no output schema, and by mapping to the underlying REST call (GET /bookings/{bookingId}). It does not mention not-found/error behavior, 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?

Two compact clauses with the purpose front-loaded, followed by the payload scope and the API mapping. Nothing is padded and 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 single-parameter read tool with no output schema, the description compensates well by listing what the returned booking contains. The only gap is operational behavior on an unknown/invalid booking _id, which an agent might want before calling.

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 booking_id parameter is documented as 'The booking _id.' The description's 'by _id' only echoes the schema, adding no format, sourcing, or validation detail beyond it — the baseline 3 for full schema coverage.

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

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

States a specific verb and resource ('Fetch one booking by _id') and the word 'one' cleanly separates it from the sibling list tools (officernd_list_bookings, officernd_list_booking_occurrences) that return multiple records. It also enumerates the payload contents (resource, member/company, times, recurrence, fees, extras, visitors, status), so the agent knows exactly what it is retrieving.

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 never states when to use this tool versus the list tools, nor any prerequisite (e.g. needing a valid booking _id from a prior list call). Usage is only inferable from the tool name and the phrase '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 real value by naming the fields the response carries (contact, company, location, status, billing, custom properties), which matters because there is no output schema.

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

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

One sentence, front-loaded with the verb and lookup key, followed by the payload summary and the underlying API route. No wasted words.

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

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

For a one-parameter read-only fetch with no output schema, the description covers the lookup key and the shape of the returned record. Only missing element is what happens on a not-found or invalid id.

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 member_id parameter is already documented in the schema. 'Fetch one member by _id' merely restates that, adding no format or sourcing detail, so the baseline 3 applies.

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

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

States a specific verb (Fetch) and resource (one member) qualified by lookup key (_id), and enumerates the returned data domains. Singular 'one member' cleanly separates it from the sibling list_members.

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 word 'one' versus the list sibling, but there is no explicit when-to-use condition, no statement about what to do when the member is unknown, and no guidance favoring this over officernd_list_members with a filter.

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 the safety profile, so the description only needs to add context — and it does, by naming the exact fields returned (name, slug, region) and framing the call as a lightweight connectivity check. It stops short of noting auth/token failure behavior, which would be the natural additional detail for a setup-verification 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?

Three short sentences, front-loaded with what is fetched and what comes back, then the use case, then the underlying endpoint. Nothing is redundant and the endpoint reference aids traceability 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?

For a parameterless read with no output schema, the description compensates by listing the returned fields and the call's purpose. Nothing else is required for an agent to invoke 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?

With zero parameters the baseline is 4. The description adds a genuinely useful implication — the org is derived from the supplied credentials, not passed in (the endpoint's {orgSlug} is resolved internally) — which preempts an agent searching for an org parameter that does not exist.

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 (Fetch) and resource (the OfficeRnD organization tied to the current credentials) and enumerates the returned fields — name, slug, region. It is trivially distinguishable from siblings like get_member or get_booking, which are also reads but of different 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?

'A cheap way to confirm the setup works' gives a concrete when-to-use scenario, which is a real usage signal rather than filler. No explicit when-not or named alternative is offered, but for a credential-scoped org lookup there is no competing sibling to route against.

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

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

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds genuinely new behavior beyond that: recurring series are expanded into individual occurrences, and the query window is capped at one year unless pagination is used. It stops short of describing pagination mechanics or result ordering, which keeps it out of the top score.

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

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

Three short sentences, front-loaded with the core purpose and scope before the usage hint and the API mapping. Nothing is padded, though the trailing 'OfficeRnD: GET /bookings/occurrences' endpoint line is redundant for an agent choosing a tool.

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

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

For an 11-parameter read-only list tool with no output schema, the description covers purpose, expansion semantics, use case and the window cap. It does not mention pagination response fields or result ordering, but the cursor parameters in the schema and the readOnlyHint annotation fill most of the remaining gaps.

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

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

Schema description coverage is 100% across all 11 parameters, so the schema already carries the burden of explaining from/to, limit, cursors, filters and their formats. The description adds only the aggregate window-length rule, not per-parameter meaning, so the baseline 3 is appropriate.

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

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

The description states a precise verb and resource ('List every individual booking occurrence') and immediately clarifies scope: one-off bookings plus each expanded instance of recurring series. That expansion semantics is exactly what separates it from a plain bookings listing, so an agent can distinguish it from siblings like officernd_list_bookings 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?

It gives a clear use context ('The right tool for calendars, room availability and utilisation') plus an operational rule ('Without pagination the window may be at most 1 year'). It does not, however, explicitly contrast itself with officernd_list_bookings or officernd_get_booking, so the routing guidance stops short of the top band.

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

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

Annotations already declare readOnlyHint=true, so the safety profile is covered by structured data. The description adds genuine behavioral context beyond that: the de-duplicated result grain (recurring series collapse to their first instance), which materially changes how an agent should interpret the response. It does not discuss pagination behavior or the cursor round-trip, which are only implied by the schema.

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

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

Front-loaded with the highest-value information (the result grain) and finished in three short sentences with no padding. The trailing 'OfficeRnD: GET /bookings' endpoint note is low-value for an agent but costs only a few tokens.

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

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

All 12 parameters are optional and fully described in the schema, and there is no output schema, so the description only needs to disambiguate the tool and explain the result grain — which it does. It could say slightly more about pagination behavior given the two cursor parameters, but nothing essential is missing.

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

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

Schema description coverage is 100%, so every one of the 12 parameters is already documented in the schema, including the ISO 8601 format and cursor semantics. The description restates the filter dimensions but adds no syntax or behavior beyond the schema, so the baseline 3 is correct.

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

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

States a specific verb and resource ('List bookings') and immediately pins down the result grain: one entry per one-off booking and one per recurring series, first instance only. That grain definition is what separates it from officernd_list_booking_occurrences, so an agent can pick between them without opening either schema.

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

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

Names the alternative tool explicitly ('For every individual occurrence in a date window use officernd_list_booking_occurrences') along with the condition that selects it. It also enumerates the filter axes (member, company, location, resource, series start window, status), so the agent knows what this tool is for.

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 safe-read nature is covered. The description adds value by enumerating what a check-in record contains, but says nothing about pagination semantics or result volume beyond what the schema cursor params imply.

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

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

A single compact sentence front-loads the resource and its payload, then adds the use case and API endpoint. No wasted words.

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

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

For a read-only list endpoint with fully documented parameters and no output schema, the definition covers purpose, content, and use case adequately. Only pagination behavior and return shape are left implicit, 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 description coverage is 100%, so all eight parameters (limit, member, company, location, cursors, time bounds) are already documented in the schema. The description adds no additional syntax or format guidance, so the baseline 3 applies.

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

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

States a specific verb+resource ('List member check-ins') and clarifies the returned content (who was on site, when, via which booking or pass), which distinguishes it from siblings like list_bookings or list_members. An agent can identify the tool's scope without opening the schema.

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

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

The phrase 'useful for occupancy and attendance' implies the use case but gives no explicit when-to-use vs alternatives or exclusions (e.g., when to prefer list_bookings). Usage is inferred rather than stated.

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

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

readOnlyHint=true already tells the agent this is a safe read. The description adds the backing endpoint (GET /companies) and the domain meaning of the resource, but says nothing about pagination behavior, default page size, or result ordering beyond what the schema already documents.

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, front-loaded with the action and resource before the filter list. The parenthetical domain gloss earns its place; the trailing endpoint reference is borderline but harmless.

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

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

With no output schema, the description could hint at return shape, and it omits pagination guidance despite cursor parameters. However, the fully documented schema covers parameters and safety is covered by annotations, so the definition is adequate if not rich.

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 all 9 parameters are documented in the schema. The description only restates a subset of filters (name/_id, location, status), so it adds no meaning beyond the structured definitions; baseline 3 applies.

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

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

States a specific verb and resource ('List companies') and adds domain clarification that companies are 'teams/tenants renting space'. It does not distinguish itself from sibling list tools such as officernd_list_members, but the resource is unambiguous.

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

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

It names the available filters (name/_id, location, status), which implies the retrieval contexts the tool serves, but there is no explicit when-to-use/when-not guidance and no routing to a sibling like officernd_list_members or officernd_get_organization.

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 return-content context by listing totals, dates, notice period, status, and lifecycle stage, though it does not discuss pagination behavior or authentication 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 a single front-loaded sentence with no wasted words. The parenthetical definition, example use case, and endpoint all contribute directly to understanding the tool.

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 9-parameter filtered list tool with no output schema, the description gives enough return-field and usage context for an agent to understand the tool. It leaves pagination and rate-limit behavior implicit, but those are partially covered by the schema's cursor and limit parameters.

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

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

The schema has 100% description coverage for all 9 optional parameters, including sort, limit, cursor, stage, status, company, location, and modified_since. The description adds no parameter syntax or filtering guidance beyond what the schema already provides, so the baseline of 3 is appropriate.

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

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

States a specific verb and resource ('List contracts') and immediately defines what a contract is ('agreements for plans and resources'), which separates it from sibling list tools such as memberships. It also names the data dimensions returned and the underlying OfficeRnD endpoint.

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 a clear usage example: 'find contracts up for renewal or serving notice.' This gives concrete context for when the tool is useful, though it does not name alternative tools or state when not to use it.

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 read, so the description's marginal burden is lower. It adds the returned field set and the REST endpoint, but says nothing about pagination behavior or ordering even though the tool is cursor-paginated per the schema.

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

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

Two tight sentences: the returned fields and scope come first, then the downstream dependency, then the endpoint. Nothing is padded or 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?

With no output schema, the description usefully enumerates the returned fields (address, timezone, open/public flags), and the annotations cover safety. Cursor-based paging semantics live only in the schema, which is a minor gap for a 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 100% and every parameter (name, limit, is_open, is_public, cursors) is documented in the schema itself. The description adds no parameter-level meaning beyond that, so the baseline 3 applies.

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

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

States a specific verb and resource ('List the organization's locations'), clarifies the domain entity in parentheses (coworking spaces/buildings), and enumerates the returned fields. It also cites the upstream API endpoint, so an agent can distinguish it from the other list_* siblings without opening any schema.

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

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

Explicitly tells the agent why it matters: location ids are required by most other filters and by officernd_create_member, which is a strong chaining/prerequisite cue. It stops short of any when-not or exclusion guidance, but the positive routing guidance 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=true annotation already establishes this is a safe read, so the description needs to add behavioral context and does not: it never mentions pagination behavior, cursor semantics, ordering, or result-set size limits. The only addition is the underlying 'GET /members' endpoint, which is of marginal value to an agent.

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 with no filler; the core purpose and the filter dimensions are front-loaded before the trailing endpoint reference.

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

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

For a 13-parameter list tool with no output schema, the definition leaves the agent guessing about the response shape and pagination workflow (it never signals that results are paged via cursor_next/cursor_prev). The schema covers inputs well, but the description does not close the remaining behavioral gap.

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

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

Schema description coverage is 100%, with every one of the 13 parameters documented including formats (ISO 8601, cursor fields, the <field>:asc|desc sort pattern). The description's filter list simply restates a subset of that schema, so the baseline 3 applies.

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

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

The description states a specific verb and resource ('List members (people) of the workspace') and enumerates the filterable dimensions, so the agent knows exactly what the tool returns. It does not distinguish itself from the sibling get_member (single-record fetch) or explain the list-vs-get boundary, so it stops short of a 5.

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

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

There is no when-to-use guidance: nothing says to prefer officernd_list_members over officernd_get_member when an email is known, nor when to fall back to officernd_list_companies. The filter enumeration implies bulk/search usage but no alternative or exclusion is named.

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 useful context by enumerating the returned fields (plan, price, discount, dates, calculated status) and the underlying GET endpoint, but says nothing about pagination behavior or rate limits beyond what the schema's cursor params imply.

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

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

Two tight sentences that front-load the verb and resource, with the parenthetical definition and endpoint reference compact. Minor redundancy in citing the raw endpoint, but no wasted prose.

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

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

For a read-only list tool with full schema coverage and annotations carrying the safety profile, the definition is largely sufficient, and it helpfully names the returned fields in the absence of an output schema. It could still say more about paging and result shape.

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

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

Schema description coverage is 100%, so all nine parameters are already documented in the schema. The description adds no syntax, format, or filtering semantics beyond what the schema provides, making the baseline 3 appropriate.

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

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

States a specific verb ('List') and resource ('memberships'), and clarifies the concept as 'recurring plans sold to members/companies' plus the fields returned. It does not, however, differentiate itself from near-siblings like officernd_list_contracts, which an agent could easily confuse it with.

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

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

No when-to-use guidance and no alternatives named. With siblings such as list_contracts and list_members in the same domain, the description gives the agent no basis for choosing between them.

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 valuable non-annotation context: the returned fields (totals, paid/pending amounts, due dates, status) are disclosed despite there being no output schema. It does not mention auth needs, rate limits, or pagination semantics beyond cursor params in the schema.

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

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

Two dense but front-loaded sentences with no wasted filler; the document scope comes first, filters second. The trailing 'OfficeRnD: GET /payments' is a minor endpoint breadcrumb that earns little but does no harm.

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 14-parameter read-only list tool with no output schema, the description covers the resource scope and the returned field set, which is what an agent needs to select and interpret it. Pagination and cursor behavior are delegated to well-documented schema fields, so nothing critical is missing.

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

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

Schema description coverage is 100%, so all 14 parameters are already documented. The description names the filterable fields and adds an example ('overdue invoices') that maps the date filters to a real scenario, but adds no syntax or format detail beyond the schema. 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 ('List') and resource ('billing documents — invoices, credit notes, overpayments'), enumerating the document types so it is clearly distinguishable from siblings like list_contracts or list_memberships. An agent knows exactly what set of records this returns.

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 usage context by enumerating filterable dimensions and an example use case ('overdue invoices'), which tells the agent when this tool is appropriate. It stops short of naming alternatives or when-not-to-use conditions, but no sibling overlaps this billing-document resource.

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 substance by enumerating the resource attributes available (capacity, price, rate, floor, amenities) and the OfficeRnD endpoint. It does not discuss pagination semantics beyond what the schema's cursor params imply, but the added context is meaningful.

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

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

Two tight sentences with the resource scope and purpose front-loaded and the downstream consumer linkage second. No filler.

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

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

For a 6-parameter, all-optional list tool whose schema is fully documented, the description covers purpose, scope and use case. With no output schema, a brief note on pagination or result shape would make it fully self-contained, but nothing essential is missing.

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

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

Schema description coverage is 100%, including type enums and cursor semantics, so the schema carries the parameter burden. The description's enumeration of attributes refers to returned resource fields rather than input parameters, so it adds little parameter-level 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?

Specific verb (list) plus concrete resource scope (meeting rooms, desks, hot desks, private offices) and the attributes returned. It explicitly ties itself to officernd_create_booking as the consumer of the resource _ids, so an agent can place it against siblings 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?

It gives a clear usage condition — fetch resource _ids before calling officernd_create_booking — which is genuine routing guidance. It doesn't state when not to use it or name an alternative list tool, so it falls 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 only declare readOnlyHint=true, and the description adds substantive context beyond that: the exact shape of returned records and the underlying endpoint (GET /ticket-options). It does not discuss pagination semantics or whether options are organization-wide or location-scoped, keeping it out of 5 territory.

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

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

One dense sentence stating purpose, return fields and the downstream dependency, plus a short endpoint reference. Nothing is redundant and the most decision-relevant information (what you get, why you need it) is front-loaded.

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

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

With no output schema, the description usefully names the returned fields, and the schema fully covers the paging controls, so an agent can call this correctly. The one unaddressed nuance is scope (global vs. per-location/per-organization options), which prevents a perfect score.

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?

All three parameters (limit, cursor_next, cursor_prev) are fully documented in the schema with descriptions and bounds, so the description carries no additional parameter burden. Baseline 3 is appropriate when schema description coverage is 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 and resource ('List the helpdesk ticket options') and enumerates exactly what is returned — configured types, priorities and severities with _id, category and label. This is clearly distinguishable from the sibling officernd_list_tickets, which lists actual tickets rather than configuration values.

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

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

Explicitly routes the agent: 'Their _ids are required by officernd_create_ticket,' which tells the caller when this must be invoked ahead of ticket creation. It stops short of stating any exclusions or contrasting conditions for the other list_* siblings, so 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?

Annotations already declare readOnlyHint=true, and the description reinforces this with the GET /tickets endpoint and by listing returned ticket fields. It does not add pagination behavior, default page-size details, sorting, or filtering context beyond what the schema already 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?

A single sentence plus a short endpoint reference with no filler. The resource and purpose are front-loaded, and every element contributes to identifying the tool.

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, so enumerating the main returned fields (subject, message, status, priority, severity, assignee) is valuable. Pagination is handled by the schema and read-only safety by annotations, making the definition nearly complete, though it could mention that results are paginated.

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 limit, cursor_next, and cursor_prev parameters are already fully documented in the schema. The description adds no parameter-specific meaning and only names returned fields, so the baseline of 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 (List) and resource (helpdesk tickets / member requests/issues), and enumerates the main fields returned. It is clear on its own but does not explicitly distinguish itself from sibling tools like officernd_create_ticket or officernd_add_ticket_comment.

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 guidance or mention of alternatives such as officernd_create_ticket, officernd_add_ticket_comment, or officernd_list_ticket_options. The list verb implies the use case, but no explicit context or exclusions are given.

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

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

Annotations carry only destructiveHint=true, so the description usefully adds that this is a WRITE, requires scope flex.community.members.update, and that `tags` replaces the entire tag list (the concrete destructive behavior). It stops short of describing return shape, error behavior, or reversibility, so it is strong but not exhaustive.

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?

Compact single paragraph, front-loaded with the WRITE marker, followed by affected fields, semantics, scope, and endpoint in priority order. The field enumeration partially duplicates the schema, a minor redundancy, but nothing else 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 9-parameter mutation with a nested `properties` object, minimal annotations, and no output schema, the description covers the essentials: mutation nature, partial-update rule, destructive tag behavior, auth scope, and the underlying API call. It does not address the nested custom-properties object or failure modes, which is the only real gap.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds meaningful semantics beyond the schema with the partial-update rule ("only the fields you pass are changed") and the tag-replacement warning, but the field list itself merely restates schema property names.

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

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

Opens with a specific verb+resource ("WRITE. Update a member") and enumerates the exact updatable fields, which distinguishes it cleanly from create_member, get_member and list_members without opening any schema. An agent can tell instantly what this tool mutates.

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 supplies partial-update semantics ("Only the fields you pass are changed") and the required scope, which implies how to call it. However, it never states when to reach for this versus create_member or a bulk/membership tool, nor any when-not conditions, so usage is only implied.

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