Move Studios Staff Ops

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

Annotations already convey the read/write and destructive nature, so the description adds useful behavioral context beyond them: it is a staff note, it is stored on the client's profile, pinning keeps it at the top, and it requires the 'client' scope. There is no contradiction with the annotations.

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

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

Two sentences carry the essential purpose, examples, pinning behavior, and auth scope with no filler. The most important information is front-loaded and every sentence adds 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 simple add-note operation, the description covers purpose and one behavioral nuance, but it leaves gaps in client identification semantics and does not mention what the tool returns. Given the 0% schema coverage and no output schema, an agent may still be unsure whether email, client_id, or both are needed.

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 should compensate, but it only explains the 'pinned' behavior ('Pin it to keep it at the top'). It does not clarify how text, email, or client_id relate to the target client or whether a client identifier is required beyond the schema's minimal 'text' requirement.

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

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

The description uses a specific verb and resource: 'Add a staff note to a client's MarianaTek profile,' and gives concrete examples (injury, preferences, conversation summary) that clarify what kind of content belongs. This clearly distinguishes it from sibling tools like get_client_notes or add_client_to_class.

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 provides clear context for when to use the tool via its examples and the phrase 'staff note,' and the required scope is stated. It does not explicitly name alternatives or exclusions, but the intended use case is unambiguous enough that an agent can select it appropriately.

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 mark this as a non-read-only, destructive operation, and the description adds meaningful behavioral detail: it automatically consumes the client's first available membership/credit unless overridden by payment_option_id, and it requires the 'book' scope. This explains the main side effects beyond the structured 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?

Two tight sentences front-load the main action, then provide the payment side effect and the required scope. There is no filler or repetition of schema details.

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

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

For a destructive booking action with six parameters and no output schema, the description covers the key side effect and auth requirement but omits error/waitlist edge behavior and does not disambiguate from sibling booking tools. It is adequate but not fully complete.

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

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

The description adds semantic value to payment_option_id by explaining it overrides the default first-available membership/credit selection. It also frames the waitlist flag with 'or its waitlist'. Schema coverage is only partial, so this extra explanation is useful, though spot_id's role is left to the schema.

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

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

The description states a specific action ('Book a client into a class session') and identifies the waitlist option, making the core purpose immediately clear. It does not explicitly distinguish this from siblings such as move_client_to_class or promote_from_waitlist, so it falls just short of full differentiation.

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

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

The description implies usage: book a client into a class or its waitlist, and it provides a conditional payment behavior ('unless payment_option_id is given') plus a required scope. However, it does not explicitly say when to use this instead of move_client_to_class, promote_from_waitlist, or remove_client_from_class.

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 mark the tool as destructive, and the description adds useful behavioral context by explaining the destructive action is removing store credit and that the operation requires the 'money' scope. It does not contradict the annotations and provides additional context beyond the structured fields.

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

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

Two compact sentences communicate action, sign convention, use case, alternative, and scope requirement. Every clause earns its place and the main action 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?

The description covers what the tool does, when to use it, the required scope, and the amount sign behavior. The main gap is the undocumented 'note' parameter and the absence of any return-value detail, but annotations cover the destructive safety profile, so the description is largely complete for a 3-parameter 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?

The description clarifies that positive amounts add credit and negative amounts remove credit, and 'client's account balance' gives context for client_id. However, the required 'note' parameter is completely undocumented, and schema description coverage is only 33%, so the description only partially compensates for the low 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?

The description uses a specific verb-resource pair: 'Add (positive) or remove (negative) store credit on a client's MarianaTek account balance.' It also explicitly distinguishes this from a card refund, making the tool's purpose and boundary clear even among many 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 gives explicit guidance: 'Use for goodwill credits or credit-based refunds instead of a card refund.' This tells an agent when to select this tool and when to consider an alternative, which is exactly what the dimension asks 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 signal a safe read operation, and the description adds meaningful context: it requires scope 'read,' operates on a Pacific date range, defaults to the last 7 days, and reports breakdowns and no-show counts. No contradiction with annotations exists.

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

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

A single dense sentence front-loads the core scope and then packs grouping, breakdown categories, and authorization scope without filler. Every clause contributes useful information.

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

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

The description is reasonably complete for a read-only report with optional parameters: it covers date range, grouping modes, breakdown dimensions, and no-show counts. There is no output schema, so the agent must infer exact response shape, but the listed categories provide adequate guidance for invocation.

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

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

Two of the three parameters are already documented in the schema with format and defaults. The description adds value by spelling out the group_by enum semantics ('grouped by class, instructor, or day') and the date-range defaults, but it does not substantially extend the schema's parameter 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 clearly identifies the resource (attendance for every class in a date range) and the aggregation dimensions (class, instructor, day), which distinguishes it from lower-level tools like get_class_roster. It lacks an explicit verb like 'Returns' or 'Gets,' but the intent is unmistakable.

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

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

Usage context is implied: this is the aggregate attendance reporting tool for a date range, not a per-class roster tool. However, the description does not explicitly name alternatives or state when not to use it, leaving some routing to the agent's 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?

Adds substantial context beyond the destructiveHint/readOnlyHint annotations: irreversibility and the required user confirmation, the side effect of cancelling every booking and returning membership/credit, default attendee notification, the $1 apology credit via emergency-cancel flow, and the required 'book' scope. This is exactly the behavioral detail annotations do not carry.

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 core action, followed by side effects and the irreversibility caution. The scope requirement tag is compact and useful; no filler or repetition.

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

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

For a destructive tool with no output schema, the description thoroughly covers what happens to bookings, credits, notifications, and the confirmation workflow. The only gap is that it does not state what a successful call returns, so an agent must infer how to confirm completion.

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 75%, so the schema already documents notify, apology_credit, and confirm_class_name. The description adds marginal context (the 'standard $1' credit and emergency-cancel flow) but does not document class_session_id, which lacks a schema description, so it stays at the baseline.

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

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

States a specific verb and resource: 'Cancel an entire class session in MarianaTek'. The word 'entire' plus 'every booking is cancelled' distinguishes it from per-client tools like remove_client_from_class and from cancel_membership, even though no sibling is named explicitly.

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

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

The description implies when to use it (when the whole session must be cancelled) and provides workflow guidance, but it never names alternatives or states when-not conditions. The agent must infer the boundary against siblings such as cancel_membership and remove_client_from_class on its own.

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 destructiveHint annotation already flags this as destructive, and the description adds meaningful context: end_of_cycle stops future billing, immediate terminates access right away, and the operation requires the money scope. This gives the agent a clear picture of consequences and prerequisites beyond what annotations alone provide.

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. The core purpose is first, mode semantics follow, and the confirmation requirement and scope requirement are appended without redundancy. Every sentence adds information that is not already in the schema.

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

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

For a destructive operation with no output schema and a modest parameter set, the description covers the key behavioral details: modes, billing impact, scope requirement, and user confirmation. It could mention reversibility or refund implications, but the core information an agent needs to call this tool correctly is present.

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

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

Schema description coverage is 0%, so the description must compensate. It explains the mode enum and its default, which is valuable, but does not describe membership_id, reason, or note. Of the four parameters, only one receives meaningful semantic detail, leaving the required parameters underspecified.

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

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

Starts with 'Cancel a membership' – a specific verb and resource – then explains the two cancellation modes in concrete terms (end_of_cycle vs immediate). This clearly distinguishes it from sibling tools like freeze_membership or extend_membership and goes well beyond the title.

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 context for when to use each mode: end_of_cycle keeps service until the paid period ends, immediate terminates right now, and end_of_cycle is the default. It also instructs the agent to confirm with the user first. It does not explicitly name alternatives like 'use freeze_membership instead for temporary holds,' but the distinction is strong enough for an agent to make the right call in most cases.

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

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

Beyond the destructiveHint annotation, it discloses a critical safety behavior: expected_total must match the cart total to the cent or nothing is charged. It also flags the required money scope and prerequisite calls, giving the agent important operational context.

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

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

Three short sentences front-load the purpose and then deliver the safety and prerequisite guidance. No filler or redundant restating of the schema.

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

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

For a destructive financial action, the description covers the key safety guardrail, prerequisites, and scope. It does not mention success/error response behavior, but that is not required to invoke the tool correctly and there is no output schema.

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

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

The description adds meaning to expected_total by explaining it is 'what you told the client' and must match the cart total, which is not fully captured by the schema. It also connects client_id and product_id to the prerequisite list_products and get_client calls, though quantity and client_id remain somewhat implicit.

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

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

The description clearly states the action: selling a product and charging a client's saved card. This distinguishes it from siblings like refund_order or adjust_account_balance without ambiguity.

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 explicit prerequisites ('Run list_products and get_client first') and clear context for when to use it. It does not name alternatives or exclusions, but no close alternative exists among the listed siblings.

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

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

Annotations already signal a mutating, destructive operation, and the description confirms the state change. It adds the useful `[requires scope: book]` auth context, but it does not disclose reversibility, idempotency, or broader effects of the check-in.

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 filler. It states the action first and appends the scope requirement compactly.

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

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

For a simple two-parameter mutation, it covers the action, parameter mapping, and required scope. However, with destructiveHint=true and no output schema, it would benefit from noting whether check-in is reversible and what happens on repeated calls.

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

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

Schema description coverage is 0%, so the description carries the burden. It implicitly maps client_id to 'client' and class_session_id to 'class session,' which is helpful, but it does not explain the nature or format of the IDs beyond that.

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

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

The description uses a specific verb ('Mark') and resource ('a client ... for a class session'), with '(arrived)' clarifying the exact meaning of check-in. This clearly distinguishes it from sibling tools like add_client_to_class or remove_client_from_class.

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

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

It gives clear context for when to use the tool: when a client has arrived for a class session. It does not explicitly name alternatives or state exclusions, but the arrival context is enough to guide selection.

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

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

Annotations already flag this as non-read-only and destructive, and the description adds useful behavioral context: the operation fails on duplicate email and requires scope 'client'. This goes beyond the structural metadata, though it does not detail success response or side effects beyond creation.

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

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

A single tight sentence front-loads the action and resource, then adds the uniqueness failure and scope requirement. Every clause carries information and there is no filler.

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

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

For a 6-parameter creation tool with no output schema, the description is lean: it covers auth scope and duplicate-email failure but omits the success return shape and any guidance on optional fields. Annotations and the schema fill some gaps, but not all.

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

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

Schema description coverage is only 17% (birth_date YYYY-MM-DD), and the description adds little per-parameter meaning. It does clarify that email must be unique, but phone, marketing_opt_in, first_name, and last_name semantics remain undocumented except for the schema's own type/default info.

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 action ('create') and a precise resource ('brand-new client (customer account) in MarianaTek'), and adds a distinguishing constraint (fails if email already exists). It is clearly distinct from sibling tools like get_client, search_clients, and add_client_note.

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

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

The description implies usage by stating what it does, but it never says when to prefer this over alternatives or when not to use it. No explicit routing to search_clients or get_client for existing accounts, so an agent must infer the right context.

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 mark this as destructive and non-read-only, so the mutation safety profile is covered. The description adds valuable context beyond annotations: the date format and Pacific timezone, and the required money scope. It does not contradict the annotations.

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

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

Two sentences with no filler: action first, then example, then critical format and scope details. Every clause adds information the agent needs.

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

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

For a three-parameter mutation tool with annotations and no output schema, the description covers the core invocation requirements: what it does, when to use it, the date format, timezone, and required scope. It could be more complete on the note parameter, but overall it is well above the minimum viable definition.

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

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

With 0% schema description coverage, the description must compensate for parameter meaning. It does clarify new_end_date format and timezone, but membership_id and note receive no explanation beyond their names; note being required but unexplained is a notable gap.

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

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

The description uses a specific verb ('Push') with a clear resource ('a membership's end date later'), immediately identifying the operation. It also distinguishes itself from siblings like freeze_membership and cancel_membership by focusing on extending the end date, with a concrete goodwill-days example.

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 goodwill-days-after-cancelled-class example gives a clear real-world context for when this tool is appropriate. It does not explicitly name alternatives or say when not to use it, but the purpose and example make the primary use case unmistakable.

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

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

The annotations already flag the tool as mutating and destructive, and the description adds useful behavioral context: billing and usage pause until the reactivation date, dates are Pacific, and the operation requires the money scope. It does not contradict the annotations.

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

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

The description is one efficient sentence plus a scope note. It front-loads the action and effect, then gives the essential date format and authorization requirement without fluff.

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

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

The description covers the core contract: what freezing does, when it ends, date formatting, and required scope. With no output schema, it doesn't describe the return value, and the note parameter is left unexplained, but the operation is simple enough that the definition is largely sufficient.

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 only 25%, so the description partially compensates by explaining the date format/timezone and the start-to-reactivation date semantics. However, it does not explicitly document membership_id or note, leaving gaps for the required identifier and the optional note parameter.

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

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

The description uses a specific verb ('Freeze') and resource ('a membership') and clearly defines the operation as a temporary pause from a start date until a reactivation date. The phrase 'billing and usage pause' distinguishes it from cancel_membership, extend_membership, and unfreeze_membership.

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

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

The description implies a temporary-pause use case, but it does not explicitly state when to use this tool versus alternatives. It does not mention unfreeze_membership as the matching resume action or cancel_membership for permanent removal.

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 mark this as read-only and non-destructive. The description adds useful behavioral context beyond annotations by stating the required auth scope ('requires scope: read') and enumerating the returned fields, which helps the agent understand what the operation exposes without any side effects.

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

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

The description is a single front-loaded sentence that names the resource, the output contents, and the required scope. Every phrase earns its place, with no vague filler or restating of the tool name.

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

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

For a simple single-parameter read tool with annotations covering safety, the description provides enough context: the exact resource, the output fields, and the auth requirement. The main gap is not explaining how to source class_session_id or distinguishing from attendance_report, but the tool is simple enough that this is a minor omission.

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

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

Schema coverage is 0%, so the description carries the burden of explaining class_session_id, but it only says 'one class session' without clarifying what the ID is, where it comes from, or how to obtain it. The property name is somewhat self-explanatory, but the description does not meaningfully compensate for the missing schema documentation.

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

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

The description clearly states the resource ('one class session') and the exact information returned (attendee name, email, status, check-in time, membership type). This distinguishes it from siblings like list_classes, get_waitlist, and get_spot_map without needing to open schemas.

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 'one class session' implies this is for a single-session roster rather than broader scheduling or reporting tools, but there is no explicit guidance about when to prefer this over attendance_report, get_waitlist, or check_in_client. Usage context is implied 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?

Annotations already mark the tool as read-only and non-destructive, reducing the need for the description to cover safety. The description adds useful behavior beyond those annotations: it requires the 'read' scope and states that saved cards are returned masked, which is important privacy context. It does not fully describe error or edge-case behavior, but the annotation coverage lowers the bar.

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

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

The description is a single front-loaded sentence: 'Full profile for one client' immediately communicates the core purpose, followed by a compact colon-separated list of contents and a brief scope note. Every part earns its place and there is 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?

The description gives a solid list of return contents and mentions the required scope, which is meaningful. However, it fails to explain how to identify the target client via the two optional-looking parameters, and there is no output schema to fill that gap. An agent cannot be fully confident about whether to supply email, client_id, or both, making this minimally viable but incomplete.

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

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

Schema description coverage is 0%, so the description carries the burden of explaining the parameters. It never mentions email or client_id, nor does it clarify whether one, both, or neither is expected, especially since the schema lists no required parameters. The parameter names are self-explanatory, which prevents a score of 1, but the description adds no real guidance.

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

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

The description clearly states the tool returns a 'Full profile for one client' and itemizes the exact data included: contact info, memberships, account balance, saved cards, reservations, and attendance. This distinguishes it from sibling tools like search_clients (searching), get_client_notes (specific note data), and get_membership (single membership).

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

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

The description implies when to use it: when you need a complete profile for a single, known client rather than search results or a narrow sub-resource. It states the read scope requirement, giving useful context. However, it does not explicitly name alternatives or say when not to use it, 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 mark this as read-only and non-destructive. The description adds useful behavioral context beyond annotations by specifying newest-first ordering, tag inclusion, and the required 'read' scope.

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 concise sentence that communicates the resource, ordering, additional returned data, and scope requirement with 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 simple read-only tool, the description covers the main result content and order. However, it omits parameter selection details and any sense of the return structure, which is more impactful given there is no output schema.

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

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

Schema description coverage is 0%, and the description does not explain the two parameters. It does not clarify whether email, client_id, or both are needed, how they relate, or any format requirements. The description adds almost no value for parameter understanding.

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

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

The description clearly identifies the resource: staff notes on a client's MarianaTek profile, with newest-first ordering and tags included. It is distinct from sibling tools like get_client or add_client_note, though it does not explicitly state how it differs 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?

The description implies the tool is for retrieving staff notes and tags for a client, which gives reasonable usage context. However, it does not provide explicit when-to-use guidance or mention alternatives such as get_client or add_client_note.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context by enumerating what kinds of transactions are included and noting the required read scope, which goes beyond the annotations.

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

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

The description is one focused sentence that front-loads the resource and content, followed by a compact scope requirement. There is no filler or repetition of the title.

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

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

Given three undocumented parameters, no output schema, and no required fields, the description is too thin. It omits how the client is identified, whether limit controls pagination or response size, and what happens when neither identifier is supplied.

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

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

Schema description coverage is 0%, so the description carries the burden of explaining parameters, but it mentions none of email, client_id, or limit. An agent cannot tell whether email and client_id are alternatives, required, or how limit 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 names a clear resource ('class-credit transactions' and 'account-balance history') with specific included item types, so an agent can tell what the tool returns. It does not explicitly contrast it with a sibling like adjust_account_balance or get_reservation_history, but the read/history framing is unambiguous.

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

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

The description implies the tool is for reading a client's credit and store-balance history, and the '[requires scope: read]' note gives an access condition. It does not state when to prefer this over alternatives such as get_reservation_history or get_client, and it offers no exclusions.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description adds context beyond them: timezone, default date range, booked counts in the result, and the required read scope. No contradiction with 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?

One dense, front-loaded sentence conveys the core behavior, defaults, timezone, and output content, followed by a short scope note. No filler or repetition.

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

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

For a read-only schedule lookup with one required parameter, the description covers purpose, date defaults, timezone, and output content. It lacks exact date-format/boundary details, but these are minor given the schema and annotations.

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 only documents 'instructor' with 'First or last name'; date_to and date_from are bare strings. The description partially compensates by indicating they form a Pacific date range with a 7-day default, but it omits date format and boundary inclusivity.

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 ('get') and resource ('schedule'), then further specifies it returns classes one instructor teaches, filtered by a Pacific date range, with booked counts. This clear scope distinguishes it from sibling tools such as list_classes or get_class_roster.

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 provides useful operational context: Pacific date range, default next 7 days, and required read scope. However, it does not explicitly say when to use this tool over sibling alternatives or 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description aligns with those. It adds value beyond annotations by specifying the live nature of the data, enumerating returned fields, and disclosing the 'read' scope requirement. This is meaningful context without contradicting any structured metadata.

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, information-dense sentence with no filler. Each element earns its place: the object type, the field list, the ID source, and the scope requirement. It is well-structured and immediately front-loads the core purpose.

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

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

For a simple single-parameter read tool with no output schema, the description supplies everything needed: what the tool returns, how to obtain the identifier, and the required permission. The absence of an output schema is mitigated by the explicit field list in the description. There are no material gaps for an agent to resolve before invoking the 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 schema has one required parameter, membership_id, with no textual description in the schema (0% coverage). The description compensates by explaining where the ID comes from ('membership ids come from get_client'), which is the key semantic detail an agent needs. The single parameter's meaning is otherwise entirely inferable from its name.

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 opens with 'Live details for one membership instance', a specific verb-resource pairing that states exactly what the tool returns. The parenthetical list (status, dates, next charge, freeze, cancellation) further defines scope and clearly separates it from sibling mutation tools like cancel_membership, freeze_membership, and extend_membership.

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 provides clear contextual guidance by noting that membership ids come from get_client, establishing a prerequisite workflow. It also states the required scope ('read'), which helps the agent know when authorization is sufficient. It does not explicitly name alternatives, but the tool's read-only purpose is unambiguous given the sibling set.

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

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

The annotations already set readOnlyHint=true and destructiveHint=false. The description adds context beyond that by noting the data is live and that read scope is required, plus enumerating the kinds of historical data returned. No contradiction with annotations.

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

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

The description is a single sentence with no filler, front-loading the core purpose ('Live order details') before the data contents and scope requirement. Every clause adds 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 simple single-parameter getter with no output schema, the description covers the key return fields and a specific downstream use case. It does not mention error behavior or how to obtain order_id, but those are not necessary given the low complexity and schema-required parameter.

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 one required parameter, order_id, with 0% schema description coverage, so the description should compensate. It does not explicitly explain order_id semantics, but the name is self-explanatory and the phrase 'from MarianaTek' implies the ID is the MarianaTek order identifier. This is adequate but not enriched.

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

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

The description clearly states the tool returns live order details with specific contents (refundability, items with item_id, payments, prior refunds). It distinguishes itself from siblings like list_client_orders by focusing on a single order's detailed record rather than a listing.

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 'items with item_id (needed for partial refunds)' provides a concrete use case: call this tool before refund_order to retrieve item identifiers for partial refunds. It also indicates live data is available, but it does not explicitly contrast with list_client_orders or other siblings.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds useful context by specifying the auth requirement ('requires scope: read') and clarifying that it only lists membership/credit payment options rather than performing a charge. No contradiction with annotations.

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

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

The description is only two sentences and front-loaded: the core purpose appears first, followed by a workflow hint and the scope requirement. Every sentence earns its place and there is no filler.

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

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

For a simple read-only getter with two obvious parameters, the description is complete enough. It explains the output domain (membership/credits), the intended workflow position before add_client_to_class, and the required scope. No output schema exists, but the return concept is adequately conveyed.

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 does not compensate by explaining client_id or class_session_id beyond the property names themselves. It reuses the ideas of 'client' and 'specific class' but does not describe how to obtain the IDs, accepted formats, or any additional parameter semantics. The meaningful parameter burden falls almost entirely on the schema names.

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

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

The description clearly states what the tool returns: 'ways a client can pay for a specific class (membership, credits).' It also distinguishes itself by positioning it in the add_client_to_class workflow, so an agent can tell it apart from payment-processing siblings like charge_client.

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 an explicit when-to-use instruction: 'Use before add_client_to_class when you want to pick a specific option.' This strongly guides the agent, though it does not mention alternative tools for situations where payment should actually be processed rather than just queried.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds value beyond this by specifying the summarized output categories and the required 'read' scope, giving the agent a clearer picture of what the call returns and what permissions are needed.

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

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

The description is compact and front-loaded with the most important behavioral detail. The additional usage hint and scope note earn their place, though the wording is slightly general and could be tightened.

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 and low schema coverage, the description leaves critical invocation details unresolved, particularly how the client is identified and what the response shape looks like. It is adequate for understanding the purpose but incomplete for confident invocation.

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

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

Schema description coverage is only 25%, so the description needed to compensate, but it provides no parameter semantics at all. It does not clarify the relationship between email and client_id, the meaning of limit, or which identifier should be used for lookups.

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

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

The description clearly identifies the resource ('a client's booking history') and the specific data elements returned (counts of attended, late/penalty cancels, no-shows, graced cancels). It is distinct enough from siblings like attendance_report, though it does not explicitly name an alternative.

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

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

The phrase 'Use it to decide on fee waivers' provides a concrete decision-making context, which is helpful for an agent deciding when to call this tool. It does not state exclusions or explicitly contrast with sibling tools, so it misses the top score.

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 provide readOnlyHint=true and destructiveHint=false. The description adds the auth scope requirement and clarifies the returned content, but does not disclose extra behavioral details such as how free spots are represented or whether ordering is guaranteed.

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 focused sentence that front-loads the core function and output fields. No filler or redundant restatement of the tool name.

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

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

For a simple read-only lookup with one parameter, the description covers the essential output (spot number, occupant, free spots) and the scope requirement. Without an output schema, a bit more detail about how free spots are represented would make it fully complete.

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

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

There is one parameter, class_session_id, with 0% schema description coverage. The description says the tool is 'for a class session', which reinforces the parameter's purpose, but it does not add format, source, or validation details beyond the parameter name.

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

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

The description clearly states the verb-resource relationship: it gets a Reformer/spot layout for a class session, specifying spot number, occupant, and free spots. It is distinct from siblings like get_class_roster, though it does not explicitly name that alternative.

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

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

Usage is implied: use this when you need spot-level layout or free-spot information for a class session. However, it does not explicitly say when to prefer this over get_class_roster or other class-related tools.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description adds useful context: it requires 'scope: read' and specifies the output content (ordered waitlist, booked count, capacity). This provides transparency beyond the structured annotations without contradicting them.

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 that immediately states the action and resource, then adds ordering and count details, followed by the scope requirement. Every element earns its place and there is 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?

For a simple, read-only, one-parameter tool, the description covers the essential behavioral and output expectations: ordered waitlist, booked count, and capacity. The lack of an output schema is compensated by describing what the tool returns, and the annotations cover safety. No critical information 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?

The input schema has one required parameter, class_session_id, with 0% schema description coverage. The description mentions 'a class session' and thereby links the parameter to the tool's purpose, but it does not explain the ID format or how to obtain it. The parameter is self-describing enough for a basic call, but the description adds only minimal semantic value.

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 ('List'), a clear resource ('the waitlist for a class session'), and adds detail about ordering and included counts. It is easily distinguishable from siblings like get_class_roster or promote_from_waitlist because it specifically targets the waitlist with capacity and booked count.

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 clearly implies when to use this tool: when you need the ordered waitlist plus booked count and capacity for a class session. It does not explicitly contrast it with alternatives such as get_class_roster, but the context is clear enough that an agent can select it appropriately.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description adds meaningful behavior beyond that: Pacific-time date handling, default-to-today behavior, booked counts, and the required 'read' scope. This gives an agent useful non-obvious context without contradicting the annotations.

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

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

The description is a single tight sentence that front-loads the action, resource, and scope, then appends the most important context (default today, filters, read scope). No filler or repetition of schema details.

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

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

For a simple optional-parameter list tool, the description plus schema covers how to call it: date range, timezone, defaults, filters, and scope. Since there is no output schema, the description's mention of 'booked counts' provides some return expectation, but exact output fields, ordering, or pagination are not disclosed, leaving minor completeness gaps.

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

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

Schema description coverage is 100%, so each parameter is already well-documented in the schema. The description adds date-range and filter meaning but does not substantially enhance parameter understanding beyond what the schema provides; 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 clearly states a specific verb ('List') and resource ('class sessions') with date range, booked counts, and filter options. It is obviously a read/list operation and inherently distinguishable from tools like get_class_roster or get_instructor_schedule, though it does not name those alternatives explicitly.

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

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

The description provides clear context: date range defaulting to today, Pacific time, and optional filters for instructor or class name. However, it does not explicitly state when to use this tool instead of related ones like get_instructor_schedule, get_class_roster, or attendance_report, leaving the comparison to inference.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds useful behavioral context by noting the data comes from the synced orders table and represents recent orders, implicitly warning that it is not live data. This goes beyond the annotations.

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

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

The description is two sentences plus a scope note, with no filler. The core scoping statement and the get_order alternative are front-loaded and every sentence adds 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 list tool with no output schema and 0% parameter coverage, the description leaves key invocation details unstated: how to identify the client, whether email or client_id is preferred, ordering, and pagination behavior. The synced-data caveat and get_order pointer help but are not enough to make the tool safely callable.

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 does not explain email, client_id, or limit semantics. It only says 'for a client,' leaving ambiguous whether email, client_id, or both are expected, and it does not clarify requiredness despite no parameters being marked 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 clearly states the action and resource: list recent orders for a client, sourced from the synced orders table. It also distinguishes itself from get_order by indicating that get_order is for live refund eligibility, so an agent can tell these tools apart.

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 a concrete routing cue: use get_order when live refund eligibility is needed, implying this tool is for synced recent order history. It does not exhaustively list when not to use the tool, but the primary alternative is named with a clear condition.

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

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

The annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds useful context about the instructor data included and the read scope requirement, but it does not clarify whether inactive instructors are excluded by default or mention response shape or pagination behavior.

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

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

The description is a single, front-loaded sentence with no redundant filler. It packs useful detail into a compact form, though the trailing list of time windows is slightly dense.

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

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

For a simple read-only list tool with one optional parameter, the description covers the main returned data and the required scope. However, the meaning of include_inactive is left ambiguous, and without an output schema the description should at least clarify the default filtering behavior to be fully complete.

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

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

Schema description coverage is 0%, so the description carries the burden of explaining the include_inactive parameter. It mentions 'active flag' but never explains how include_inactive affects the result set. The parameter name gives some hint, but the description does not compensate for the missing schema description.

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

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

The description clearly states the resource being listed (instructors) and enumerates the data included: contact info, active flag, and class history. It is distinct enough as a list tool, but it does not explicitly distinguish itself from the sibling get_instructor_schedule, 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 guidance on when to use this tool versus alternatives like get_instructor_schedule or list_classes. The description implies a broad instructor overview but does not state when it should be preferred or explicitly call out sibling tools.

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

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

Beyond the readOnlyHint and destructiveHint annotations, the description adds operational context by noting that only sellable products are returned and that scope 'read' is required. This is useful auth-related behavioral disclosure that the annotations do not provide.

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, tightly packed with relevant information: product scope, price inclusion, cross-tool usage, and permission requirement. There is no filler or redundant restating of the tool name.

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

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

The description provides enough context for a basic list call, and annotations cover the safety profile. However, with no output schema and no parameter descriptions, the agent is left to guess the meaning of 'query' and the exact response shape. It is adequate but not complete.

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

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

Schema description coverage is 0%, so the description must compensate for both parameters. It does not explain what 'query' filters on or how 'include_inactive' behaves, aside from the indirect implication that products may be inactive by default. The child_product_id mention relates to output usage, not the request parameters.

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

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

The description clearly identifies the tool as listing sellable products and enumerates the categories (memberships, class packs, retail) with prices. This is a specific verb+resource combination that distinguishes it from sibling tools like list_classes or search_clients.

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 a concrete downstream usage directive: 'Use child_product_id with charge_client.' This tells an agent how the list results can be applied, though it does not explicitly state when not to use this tool or name alternatives.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds valuable behavioral context: the data domain, the existence of system tags that cannot be assigned manually, and the required 'read' scope. This goes beyond the structured annotations without contradicting them.

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

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

The description is two short sentences with no wasted words. The key content (available tags) is front-loaded, and the system-tag caveat and scope requirement are appended clearly. Every sentence adds 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 zero-parameter read-only list, the description is fairly complete, but since there is no output schema, it could clarify whether system tags are included in the response and how to distinguish them. It also leaves the connection to set_client_tag implicit rather than explicit, which would help an agent understand the tool's role in a workflow.

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

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

The tool has zero parameters, and the schema coverage is 100%. The baseline for no-parameter tools is 4, and the description appropriately focuses on the output rather than parameter details.

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 identifies the resource ('client tags in MarianaTek') and gives examples, making the tool's purpose clear. However, it lacks an explicit verb like 'List' or 'Returns' within the description itself, relying on the title and name for the action. It hints at differentiation from tag assignment by mentioning manual assignability, but does not name a sibling.

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 statement 'System tags cannot be assigned manually' implies that this tool is relevant when preparing to assign tags, but it does not explicitly say 'Use this before set_client_tag' or provide any when-not-to-use guidance. No alternative tool is named, so the usage context 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 cover idempotency and non-destructiveness. The description adds that login creates a prerequisite session and that role-based access follows, but it does not disclose session lifetime, token behavior, or failure modes. No contradiction with annotations exists.

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

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

Two tightly written sentences front-load the core purpose and prerequisite. Every sentence earns its place: credential entry, required-first-step, and role-based access. No unnecessary detail or repetition.

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

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

For a simple two-parameter login tool, the description covers the essential operational context: when to use it, what credentials are needed, and how authorization works. The lack of output schema is acceptable since the main effect is creating a session for subsequent calls.

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

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

Schema description coverage is 0%, so the description must compensate. It names 'dashboard email and password', which adds slight context beyond bare property names, but it does not clarify email format, password handling, or expected values. Minimal compensation is present.

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

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

The description states a specific action ('Sign in') with a specific resource ('Move Studios dashboard') and required credentials. It also distinguishes login from session-management siblings like logout and whoami by framing it as the required first step.

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 explicitly says login is required before using any other tool, which gives clear when-to-use guidance. It also notes that dashboard role determines tool access, providing useful context, though it does not discuss edge cases like re-authentication or failed logins.

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 indicate the operation is not read-only and not destructive. The description adds useful scoping by stating this affects only the current MCP session, but it does not disclose side effects such as invalidated authentication or behavior when called without an active session.

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

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

The description is a single short sentence with no filler or redundant restatement of the title. The action and its scope are front-loaded and immediately readable.

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 tool with no output schema, the description conveys the core action and scope, which is largely sufficient for invocation. It leaves minor gaps around post-conditions and error behavior, but the low complexity makes the definition acceptable.

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

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

The tool has zero parameters and the schema coverage is complete, so there are no parameter semantics for the description to clarify. The baseline for parameterless tools applies and no additional parameter explanation is needed.

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 ('Sign out') and a specific scope ('this MCP session'), so the action is unmistakable. It does not explicitly compare with sibling tools like login or whoami, but the semantics are distinct enough to prevent selection errors.

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 intended usage is implied: call logout when the current MCP session should end. However, the description gives no explicit guidance about prerequisites, when not to call it, or how it relates to login/whoami, leaving the usage context mostly implicit.

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

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

Annotations already indicate destructiveHint=true, and the description adds the required scope ('requires scope: book') and clarifies that the client must already be booked. This is useful behavioral context beyond the structured fields, though it does not detail consequences like freeing the previous spot or failing if the target is occupied.

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

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

The description is two short, purposeful sentences plus a scope note. It front-loads the core action and immediately provides the essential preparation step without 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?

For a small mutation tool with three parameters and no output schema, the description covers the action, the scope requirement, and how to find valid spot values. It could mention what happens on invalid input or whether a confirmation object is returned, but the essential call context is present.

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

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

Schema description coverage is only 33% (only 'spot' is documented). The description helps by explaining how to obtain spot ids and identify free spots, but client_id and class_session_id are left to inference from 'booked client' and 'same class.' This partially compensates for the low schema coverage but does not fully document each parameter.

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

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

The description clearly states the action ('Move'), the resource ('a booked client'), and the target ('a different reformer/spot in the same class'). This distinguishes it from the sibling move_client_to_class by explicitly limiting the move to within the same class.

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 concrete guidance on how to prepare for the call: 'Use get_spot_map to see spot ids and which are free.' It does not explicitly mention alternatives or when not to use the tool, but the 'same class' qualifier implies the boundary versus moving clients between classes.

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

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

Beyond the destructiveHint annotation, the description discloses the exact side-effect order: the original class is cancelled first, and the new class is booked using membership/credits. It also states the required scope ('book'), giving the agent useful operational context.

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

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

The entire description is one well-structured sentence that front-loads the core purpose and then adds behavioral detail in a parenthetical. The scope requirement is appended cleanly. There is no waste.

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

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

The description is complete enough for an agent to call the tool correctly, explaining the operation, the sequence, the credit dependency, and the required scope. It does not mention failure behavior, such as what happens if the second booking fails after the first is cancelled, but this is a minor gap.

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

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

With 0% schema description coverage, the description carries the semantic load. It maps the parameters clearly: moving a client from one class session (from_class_session_id) to another (to_class_session_id), and identifies that client_id refers to the client being moved.

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

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

The description states a specific action: moving a client from one class session to another, and clearly describes the mechanism ('cancels the first, then books the second'). This distinguishes it from related tools like add_client_to_class, remove_client_from_class, and cancel_class.

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

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

The description implies the correct scenario for use, but it does not explicitly mention when not to use it or name alternatives like add_client_to_class or remove_client_from_class. A capable agent can infer the use case, but it lacks explicit routing guidance.

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

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

Beyond the annotations (destructiveHint=true, readOnlyHint=false), the description discloses what gets destroyed (the waitlist spot), the side effect (consuming membership/credits), the failure mode ('Fails cleanly if the class is full'), the overbook exception, and the required scope ('book'). This is rich behavioral context that substantially exceeds the binary annotation flags.

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

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

Two sentences with zero wasted words: the core action is front-loaded, followed by the destructive mechanic, the failure condition, and the scope requirement. Every clause adds operational 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?

With no output schema and empty parameter descriptions, the description carries the full burden, and it covers the success flow, the failure condition, and the overbook escape hatch well. Remaining gaps are the meaning of spot_id, the behavior when a client lacks available membership/credits, and the return value, which are moderate rather than critical omissions.

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, but of the four parameters it only clarifies allow_overbook ('unless allow_overbook is true'). spot_id — the most ambiguous parameter — is never explicitly tied to the waitlist spot that the description mentions removing, and client_id/class_session_id receive no semantic context beyond their obvious names.

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

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

The description uses a specific verb ('Move'), a specific resource ('a waitlisted client into the class'), and states the exact mechanics ('removes their waitlist spot, then books them with their available membership/credits'). This clearly differentiates it from siblings like add_client_to_class or move_client_to_class, which lack the waitlist-promotion semantics.

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 context of use is clear: a waitlisted client is being converted into a confirmed booking, which implies the appropriate moment to invoke this tool. However, it does not explicitly name alternatives or state when not to use it (e.g., 'for a client not on the waitlist, use add_client_to_class'), leaving sibling differentiation 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?

The annotations already indicate destructiveness, and the description adds meaningful behavioral detail: money returns to the original payment source, memberships/packs are terminated on refund unless refund_without_termination is true, and the required scope is [money]. These are exactly the side effects an agent needs before invoking a destructive refund.

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: main action, full-vs-partial scope, and the critical membership-termination caveat. No filler, and the most decision-relevant details are 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?

For a destructive six-parameter refund tool with no output schema, the description covers the core behavior, the main conditional (item_ids), and the biggest side effect (termination). It doesn't describe response shape or restock/note/reason semantics, but the parameter names are mostly self-explanatory and the required order_id is obvious.

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%, and the description does partially compensate by explaining item_ids ('from get_order') and refund_without_termination's effect on membership/pack termination. Other parameters like note, reason, restock, and order_id rely on their names or schema-only descriptions, so compensation is incomplete.

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

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

The description clearly states a specific action — refund an order to the original payment source — and adds key scoping: the whole order is refunded unless item_ids are provided. It doesn't explicitly name or contrast a sibling tool such as cancel_membership, 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?

It provides useful conditional usage context: full refund by default, partial refund only when item_ids are supplied, and termination can be suppressed with refund_without_termination. However, it doesn't state when to choose this tool over alternatives like cancel_membership or charge_client, leaving alternative routing implicit.

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

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

Annotations already indicate destructiveHint=true, and the description adds useful behavioral context: MarianaTek's late-cancel policy applies and membership/credit is returned per that policy. It also discloses the required scope 'book'. This goes beyond the annotations by explaining the consequence of the cancellation, though it remains somewhat vague about the exact policy conditions.

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

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

The description is two sentences with no filler. It front-loads the core purpose, then adds the policy consequence and required scope. Every word contributes useful information.

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

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

The description covers purpose, policy, and scope, which are important for a destructive action. However, with three parameters and only 33% schema coverage, the lack of parameter-level guidance creates a meaningful gap. There is also no mention of what happens on success or failure, and no guidance about the optional reservation_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 description coverage is only 33%, with only reservation_id documented in the schema. The description mentions 'client' and 'class session' but does not explain the parameters, the optional nature of reservation_id, or how it interacts with class_session_id. Given low schema coverage, the description fails to compensate for the missing parameter 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 clearly states a specific action: cancel a client's reservation for a class session. This distinguishes it from siblings like add_client_to_class, move_client_to_class, and cancel_class, since it focuses on removing an individual client's reservation rather than altering or canceling the class itself.

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 provides no when-to-use guidance or exclusions. It does not mention alternatives such as move_client_spot or add_client_to_class, nor does it indicate scenarios where this tool should or should not be used.

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 mark this as read-only and non-destructive. The description adds value by stating the returned fields and the required 'read' scope, giving the agent useful context about authentication and output without contradicting the annotations.

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

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

Three short sentences, each earning its place: what the tool does, what it returns, and how to use the result. The most important information is front-loaded and there is no redundancy.

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

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

For a simple read-only search tool with two parameters and no output schema, the description covers core behavior, return values, and scope requirements. It is slightly incomplete in not addressing limit semantics or when to choose get_client instead, but these are minor 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?

The description adds meaning to the query parameter ('name or email') but the schema already covers that, and the limit parameter is only documented with a type and default. With 50% schema coverage, the description partially compensates but does not explain limit behavior or constraints.

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

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

The description states a specific verb ('Find'), a clear resource ('clients'), and the search criteria ('by name or email'). It also names the return fields and explains the downstream use of client_id, which makes the tool's purpose unmistakable and distinct from siblings like create_client or get_client.

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 clearly implies this tool is for finding clients when you have a name or email fragment, and it tells the agent to use the resulting client_id in other tools. It does not explicitly contrast with get_client for when an exact client_id is already known, which would be the natural alternative.

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

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

Annotations already signal a non-read-only, destructive side-effect operation. The description adds useful behavior beyond annotations: replies default to the logged-in staff member unless reply_to is set, the email is plain-text, and the scope requirement is disclosed. It does not detail irreversibility or potential charges, but the main behavioral traits are covered.

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 plus a scope note convey all essential information. There is no filler, and the most important behavior 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?

The description covers recipient resolution, reply behavior, plain-text format, and scope requirements, which is enough for an agent to invoke the tool correctly. The only notable gap is the lack of any mention of return values or failure modes, but there is no output schema and the operation is straightforward.

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%, so the description partially compensates by explaining that client_id and to are alternative recipient routes and that reply_to changes the default reply behavior. Subject is left undescribed, though its purpose is self-evident. Overall, the description adds meaning beyond the raw 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 uses a clear verb and resource: it sends a plain-text email from Move Studios to a client or any address. It also distinguishes itself from sibling communication tools like send_sms by specifying the email medium and recipient options.

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 clear context for when to use the tool: when emailing a client by client_id or an arbitrary address. It does not explicitly state when not to use it or mention alternatives like send_sms, but the context is strong enough that an agent can select it correctly.

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

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

Beyond the annotations, the description discloses the opt-in gate, the message-source behavior (profile mobile number), and the required scope. It does not describe what happens on failure or the cost of sending, but the annotations already flag the operation as non-read-only and destructive, so the added context is above the baseline.

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

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

The description is two tight sentences with the primary action front-loaded. The opt-in condition and scope requirement each add necessary behavior without verbose framing or redundant restatement of the title.

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

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

The description conveys the core behavior, opt-in guardrail, and scope requirement, which is adequate for a simple SMS tool. However, with four parameters and no output schema, it leaves a meaningful gap around how the agent should populate email versus client_id and whether at least one identifier is required.

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 50% schema coverage, the description compensates only partially: it explains that the recipient's mobile number comes from the MarianaTek profile and clarifies override_opt_in's effect, but it does not disambiguate the email and client_id parameters or state how the client is identified. The schema covers message and override_opt_in, while the description adds only modest meaning to the identifier fields.

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

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

The description opens with a specific action and resource: 'Text a client via Twilio using the mobile number on their MarianaTek profile.' This clearly distinguishes send_sms from send_email and other client-related tools. The opt-in caveat and scope note add precision without blurring the purpose.

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 opt-in condition ('Only sends if the client has opted in to transactional SMS unless override_opt_in is true') gives useful context for when the tool will act, but there is no explicit when-to-use versus send_email or any exclusion guidance. The usage is implied from the SMS-specific wording rather than stated as a decision 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 mark this as non-read-only and destructive, and the description's 'Change' is consistent with that. It adds the useful scope requirement ('requires scope: book'), but it does not disclose side effects of lowering capacity, such as impact on existing enrollments or waitlist, nor whether changes are reversible. With annotations covering the basic mutation signal, this is acceptable but not rich.

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

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

The description is one tight sentence with the core action front-loaded and the scope requirement appended. Every word earns its place; no redundant restating of the title or field types.

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

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

For a simple three-parameter mutation with no output schema, the description plus annotations cover the main intent and access requirement. However, it leaves the return value and consequences of reducing capacity/waitlist limits to inference, which is a noticeable gap for a destructive operation.

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. It clarifies that capacity and waitlist_capacity are the modifiable fields and can be changed individually or together ('and/or'), but it does not explain class_session_id semantics or constraints/limits. The schema only provides names and types, so the description adds some but not complete 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 states a specific action ('Change') on a specific resource ('a class session's capacity and/or waitlist capacity'), which is precise and distinct from sibling tools like cancel_class or move_client_to_class. It clearly tells an agent what the tool does.

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

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

The description makes it obvious this tool is for adjusting capacity/waitlist settings, and the '[requires scope: book]' note adds an access prerequisite. It does not name alternatives or explicit when-not-to-use cases, but no sibling tool offers the same capacity-setting function, so this is adequate context.

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 indicate this is a mutating/destructive operation (readOnlyHint=false, destructiveHint=true). The description adds useful context: it operates on manual tags by name and requires client scope. There is no contradiction with the annotations.

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

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

One tight sentence conveys the action, the object, the by-name behavior, and examples, plus a scope requirement. There is no filler or 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?

With no output schema, sparse parameter documentation, and a destructive hint, the description should clarify client identification and expected results. It leaves the role of email/client_id unexplained, so an agent cannot reliably know how to target the client.

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 'tag' is described. The description reinforces the tag semantics and the add/remove action, but it never explains how the client is identified via 'email' or 'client_id', which is critical for correct invocation.

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 opens with a specific verb and resource: 'Add or remove a manual tag (by name) on a client'. The examples 'VIP' and 'Extra Care' make the purpose immediately concrete, and 'manual tag by name' differentiates it from siblings like list_tags.

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 clear operating context: add or remove a manual tag by name, with a permission prerequisite ('requires scope: client'). It does not explicitly name alternatives or exclusions, but the action is straightforward and distinct enough from sibling tools.

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 mark the operation as destructive and not read-only. The description adds the immediate timing ('today'), the outcome ('membership resumes'), and a money scope requirement, but does not disclose error behavior for non-frozen memberships or any side effects on billing.

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 short sentence with the core action, timing, and scope requirement; no filler. The additional '[requires scope: money]' is useful and 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?

For a one-parameter destructive mutation, the description gives the action, timing, and auth requirement, but omits return/error behavior and the precondition that the membership must currently be frozen (beyond the word 'active'). It is adequate but not complete for an agent with no output schema.

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

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

Schema coverage is 0% and the description never explains membership_id. The parameter name and the phrase 'the membership' make the meaning inferable, but the description adds no semantic detail about format, source, or validity conditions.

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 the action ('end an active freeze') and the resource ('the membership'), and states the result ('resumes'). This clearly distinguishes it from siblings like freeze_membership, cancel_membership, or extend_membership.

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

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

The description implies the tool is for memberships currently in an active freeze, but it never explicitly says when to prefer this over freeze_membership or cancel_membership. No alternative or exclusion is mentioned, so usage guidance is only implicit.

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

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

Annotations already indicate readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds meaningful behavioral context beyond annotations by specifying exactly what will be reported (roles, scopes, tools), which is especially valuable given there is no output schema to convey return contents.

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 ('Show who is logged in on this session') and then appends the key detail fields. Every word earns its place; there is no filler or redundant restating of the tool name.

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

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

For a simple, zero-parameter, read-only whoami tool, the description is complete: it states the identity scope (current session), the output categories (roles, scopes, usable tools), and annotations cover side-effect safety. There is no output schema, but the description sufficiently describes what the agent can expect to learn from the call.

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 has zero parameters, so parameter semantics are trivially complete. The baseline for 0-parameter tools is 4, and the description does not need to add anything about parameters since none exist and schema 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?

The description uses a specific verb ('Show') with a clear resource ('who is logged in on this session') and enumerates the exact information returned: roles, scopes, and usable tools. This differentiates it from sibling auth tools like login and logout by focusing on the current session rather than authentication actions.

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

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

The description implies when to use the tool: whenever the agent needs to know the current user's identity, permissions, roles, or available tools. It does not explicitly name alternatives or exclusions, but for a zero-parameter, read-only introspection tool with no closely overlapping siblings, the context is sufficiently clear.

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