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

Annotations already declare readOnlyHint=true, and the description is consistent with that (GET-only). It adds genuine behavioral context beyond the annotation: pagination semantics (paginate=true follows Limit/Offset pages), the PascalCase query-param convention, and that maxPages applies only with paginate. Error handling and rate-limit behavior are not 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?

Front-loaded with the escape-hatch purpose, then progressively narrows to path examples, param naming, and pagination. Dense but every clause earns its place and nothing is repeated from the schema.

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

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

For a raw passthrough GET with no output schema, the description gives enough to invoke it correctly: path format, param convention, and pagination behavior. Minor residual gap on error/response shape, acceptable given it is a generic forwarding 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?

With 60% schema coverage, the description compensates well: it explains that query params are PascalCase (StartDate, ClientId, Limit), that m_... member tokens are accepted as values, and that paginate pairs with maxPages. It gives syntax/format guidance the schema omits for the 'params' and 'paginate' fields.

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

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

States a specific verb and resource ('GET any Mindbody Public API v6 path with query params') and frames itself as the raw 'escape hatch' covering ~150 read operations. This explicitly distinguishes it from the typed per-resource siblings like mbo_get_client or mbo_get_staff.

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?

'Escape hatch' strongly implies fallback usage when no typed endpoint exists, and it tells the agent to set paginate=true specifically for list endpoints. It stops short of explicitly naming the sibling tools to prefer first or stating when NOT to use it.

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

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

readOnlyHint=true already establishes this as a safe read, yet the description adds real behavioral context: the classification is derived from contracts rather than stored, the set of possible verdicts, and the non-obvious edge case that one-time setup fees do not count as proof of payment. It does not disclose auth requirements or failure behavior for an unknown clientId, so it stops short of a 5.

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

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

Two sentences, front-loaded with the derivation and the enumeration of buckets, then the one rule that prevents a misclassification. No filler or restated boilerplate; the edge-case clause earns its place.

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

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

With no output schema, the description correctly carries the return-value burden by naming all bucket values plus join/churn lifecycle dates, and the read-only annotation covers safety. Gaps remain only around clientId semantics and what happens for a client with no contracts, which is minor given the tool's simplicity.

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 50% — siteId is documented in the schema, but clientId is bare. The description adds no parameter guidance at all (no site scoping note, no clientId format or lookup hint), so it fails to compensate for the undocumented half. Below the baseline 3 that high schema coverage would earn.

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 (buckets a client) plus the resource (payment status derived from contracts), and enumerates the exact output classes (paying | pastDue | onHold | promo | comp | none) with lifecycle dates. The 'Derived tool' framing distinguishes it from siblings like mbo_get_client_contracts, which return raw contracts rather than a classification.

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 'Derived tool' label and the explicit bucket list make the intended use case clear: call this when you want a payment classification rather than raw contract data. The rule that 'paying' requires a recurring NormalAutoPay > 0 tells the agent when the 'paying' verdict applies. However, it never explicitly names an alternative (e.g., mbo_get_client_contracts) or states 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, so the safe-read profile is covered. The description adds domain context about return semantics (TotalSignedIn is real attendance vs TotalBooked, cancellation status included), which is genuinely useful, but it discloses nothing about pagination behavior (despite maxPages existing in the schema), rate limits, or auth requirements.

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

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

One sentence, front-loaded with the route and resource, followed by the field inventory. Dense but no filler, and the most decision-relevant cue (date range, attendance metric) comes before the long field list.

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

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

With no output schema, the description steps in to sketch the return payload (staff, description, booking/attendance counts, waitlist, capacity, cancellation status), which is the right compensation. It is still thin on pagination and timezone/date-boundary behavior, but no critical invocation detail is missing.

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

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

Schema description coverage is 83% (siteId, dates, maxPages page size, staffIds all documented), so the schema carries most of the load. The description adds no parameter syntax or format detail beyond it, which matches the baseline 3 for a high-coverage 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 gives a specific verb+resource (GET /class/classes → the session schedule for a date range) and enumerates the returned fields, so an agent knows this is the class-session listing tool. However, it never distinguishes itself from the sibling mbo_get_class_visits, which a caller could easily confuse with a session-schedule endpoint.

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

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

The parenthetical 'use this for show-rate math' hints at a use case, implying the tool's role in attendance analytics. But there is no explicit when-to-use, when-not-to-use, or alternative routing guidance against siblings like mbo_get_class_visits or mbo_get_class_visits.

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?

With only readOnlyHint=true in annotations, the description carries the behavioral burden and does so well: it discloses that the v6 endpoint accepts only a singular ClassId, that the tool fans out one request per session with bounded concurrency of 5, that Service.Name flags intro-offer/first-timer members, and that member ids return as m_... tokens. These are non-obvious operational and output-shape facts not derivable from schema or 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 tight sentences with the core purpose front-loaded, followed by the batching constraint and the output-token note. Each sentence carries information, though the final member-id token sentence is slightly peripheral and could be dropped without loss to core selection.

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

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

With no output schema, the description does explain the returned row content and the m_... id token format, which is the key return-value context an agent needs. It leaves pagination/partial-failure behavior across the concurrent requests unstated, a minor gap for a read-only fan-out tool whose safety profile is already covered by 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?

Schema description coverage is 100%, so all three parameters are already documented in the schema (including that classIds come from mbo_get_classes and the maxItems of 50). The description adds the fan-out/per-request behavior behind classIds, but does not elaborate on lastModifiedDate or siteId beyond what the schema states, so the baseline 3 is appropriate.

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

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

States a specific resource (session roster rows) and enumerates what the rows contain (booked/signed in, late cancels, service used), scoped to "specific sessions". It implicitly distinguishes itself from the sibling mbo_get_client_visits by being session-scoped rather than client-scoped, but it never names an alternative to sharpen the contrast.

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 indicates the tool operates on a set of sessions and the schema points classIds back to mbo_get_classes, so the usage context is implied. However, there is no explicit when-to-use/when-not guidance versus mbo_get_client_visits or mbo_get_classes, leaving the agent to infer the 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?

readOnlyHint=true already tells the agent this is a safe read, so the bar is lower. The description adds useful context by disclosing that the payload is a composite spanning profile, icon, services, contracts, and balances, but says nothing about auth requirements, rate limits, or payload size/pagination for a heavy aggregate call.

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

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

A single front-loaded sentence that leads with the endpoint and then lists the returned facets. No filler, no repetition of schema or 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?

There is no output schema, so the description carries the burden of describing the return payload, and it does so by enumerating the record's sections. What is missing is any note on the aggregate call's cost, latency, or whether the listed sections can be partial/empty.

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

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

Schema description coverage is 100% and both parameters (siteId, clientId) are self-documented, including the m_... token form. The description adds no parameter-level detail, so the baseline 3 applies.

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

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

Names a specific verb+resource (GET /client/clientcompleteinfo) and enumerates the record's contents (profile, membership icon, services, contracts, balances), which implicitly separates it from the narrower siblings mbo_get_client_services and mbo_get_client_contracts by promising everything 'in a single call.' It stops short of explicitly naming those siblings, so it is clear but not fully differentiated.

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 'in a single call' implies this is the aggregate lookup to prefer over the per-section tools, but no explicit when-to-use or prerequisite guidance is given. Nothing tells the agent it must first run mbo_search_clients to obtain a clientId, even though the sibling set makes that workflow likely.

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

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

Annotations already establish this as a safe read (readOnlyHint=true), so the safety bar is met. The description adds genuine value beyond that by naming the response envelope key and the fields returned (AutopayStatus, NormalAutoPay, Start/End/TerminationDate), though it says nothing about pagination or auth requirements.

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

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

Three tight, front-loaded fragments: endpoint and resource first, return shape second, sibling routing last. No padding and every clause carries information.

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

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

With no output schema, the description usefully documents the response envelope and fields, which is the critical missing piece for an agent. Coverage is strong for a two-param read tool; only the undocumented clientId semantics leave a small gap.

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

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

With only 50% schema coverage, the description is expected to compensate, but it never mentions clientId or siteId. The one documented parameter (siteId) is explained only in the schema, so the description adds no parameter meaning whatsoever.

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

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

States a specific verb+resource ('a client's contracts'), names the exact endpoint, and discloses the return structure ('array is under `Contracts`') and key fields. It also distinguishes itself from the sibling mbo_classify_client_payment by scoping that tool to the derived verdict.

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

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

Explicitly routes the agent to mbo_classify_client_payment when a paying/promo/comp verdict is needed, which is clear alternative guidance. It does not, however, state when to prefer this over mbo_get_client or mbo_get_client_services, leaving part of the routing to inference.

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

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

readOnlyHint=true already establishes this is a safe read. The description adds useful return-content context (Current flags, remaining counts, expirations) but says nothing about pagination, rate limits, or whether non-current services are included.

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

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

One sentence, endpoint front-loaded, and every clause earns its place by naming the returned data. No filler.

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

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

With no output schema, the description helpfully enumerates return fields, but it leaves the required clientId parameter completely undescribed and gives no filtering or scoping behavior. Adequate but with a clear gap on the one mandatory 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?

Schema coverage is only 50%: siteId is documented in the schema, but the required clientId has no description anywhere. The description mentions no parameters at all, so it fails to compensate for the documented gap.

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

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

States a specific verb+resource: a client's purchased services, then enumerates the returned fields (memberships, class packs, intro offers, Current flags, remaining counts, expiration dates). This implicitly separates it from siblings like mbo_get_client_contracts and mbo_get_services, 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?

No guidance on when to use this versus mbo_get_services (site catalog) or mbo_get_client_contracts. Usage is only inferable from the resource name, with no exclusions or prerequisites given.

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

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

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds only the endpoint and the date-range scoping; it says nothing about pagination behavior (maxPages is capped at 50) or the volume/format of results returned.

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

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

A single front-loaded sentence with the endpoint first and the scope second; no filler. Very terse, but every clause carries meaning.

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

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

For a read-only list tool with no output schema and strong schema coverage, the description is minimally sufficient, but an agent gets no hint about result volume, pagination defaults, or how this differs from the class-visit sibling.

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 80%, so the schema already documents siteId, startDate/endDate formats, and maxPages page size. The description's 'date range' phrasing adds nothing beyond the required clientId plus date parameters already described in the schema.

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

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

States a specific verb+resource: retrieving a client's visit history (class check-ins) over a date range, and names the underlying endpoint. It is distinguishable from mbo_get_class_visits by being client-scoped, though the description never explicitly contrasts the two 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?

No when-to-use guidance, no prerequisites, and no mention of alternative siblings like mbo_get_class_visits for looking at visits from the class side. The date-range phrase implies context but gives no selection criteria.

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

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

Annotations already establish this as a safe read (readOnlyHint=true), so the safety burden is lifted. The description adds a genuinely valuable behavioral note — 'Dates are site-local' — but omits other traits that matter for a paginated query, such as what maxPages defaulting to 3 implies about truncated results or the shape of returned records.

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 with the endpoint and scope front-loaded and no filler. It is appropriately sized for the amount of information provided, though it is telegraphic rather than structured.

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

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

For a read-only range query with full schema coverage and a safety annotation, the essentials are present. With no output schema, the description could have said something about the returned transaction fields or pagination limits, so an agent may not realize results can be truncated at maxPages.

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

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

Schema coverage is 100%, so baseline is 3. The description exceeds that by adding timezone semantics for the date parameters ('site-local') that the schema's 'YYYY-MM-DD (inclusive)' text does not convey — a common source of date-boundary errors.

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

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

The description names a specific verb and resource ('GET /sale/sales — sales transactions') and scopes it to a datetime range, so the agent knows exactly what is returned. It adds the distinguishing qualifier 'refund/purchase source of truth,' but does not name or contrast any sibling tool (e.g., mbo_api_get) 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?

Calling itself 'the refund/purchase source of truth' implies this is the authoritative tool for transaction/refund data, which is useful context. However, there is no explicit when-to-use/when-not guidance and no alternative tool is named, so usage remains 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?

readOnlyHint already marks this as a safe read, and the description goes further by disclosing a 12-hour per-site cache and the meaning of `complete: false` (page cap hit before all rows returned). That truncation/caching disclosure is real operational context an agent needs when reasoning about stale or partial data. It stops short of auth or rate-limit details, so not a 5.

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

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

One dense, front-loaded sentence: endpoint, resource, returned fields, caching, then the pagination caveat. Nothing is wasted and the most important routing information leads. Slightly packed with clauses, but every one 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?

With no output schema, the description compensates by naming the key return fields and, importantly, the `complete` truncation flag. Combined with readOnlyHint and full schema coverage for the sole parameter, an agent has enough to call and interpret this correctly; only auth/error behavior is unaddressed.

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

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

There is a single parameter (siteId) with 100% schema description coverage including the sandbox value, so the schema already carries the semantics. The description only alludes to it via 'per site' and adds no format or default guidance beyond the schema.

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

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

States a concrete verb+resource ('GET /sale/services — purchasable services/pricing options') and enumerates the returned fields (ProductId, Price, program linkage), so the agent knows exactly what comes back. It does not explicitly distinguish itself from the sibling mbo_get_client_services, but the 'price list for a site' framing implies the difference.

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

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

Usage is only implied: fetch the site's purchasable services. There is no when-to-use/when-not-to-use statement and no sibling (e.g. mbo_get_client_services) is named as an alternative, so the agent must infer the distinction between site-level pricing and client-level services.

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

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

readOnlyHint=true already establishes the safety profile, and 'reference data' is consistent with that. The description adds that these are site-scoped static lists, but says nothing about pagination, auth requirements, or volume of results for a tool with no output schema.

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

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

A single front-loaded sentence with no filler; the resource list is the operative content. Slightly dense as a comma list, but nothing wasteful.

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

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

With no output schema, the description carries responsibility for conveying what comes back, and listing the entity types does that at a high level. It stops short of describing return shape or differences between resources, leaving the agent to discover them.

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%: siteId is documented in the schema, while resource is an enum with no schema description. The description partially compensates by enumerating the same enum values and adding '(name/timezone)' detail for the sites resource, but it adds little beyond the enum itself.

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 resource domain concretely ('Site-level reference data') and enumerates the six entity types returned, so an agent knows this is a read-only lookup of Mindbody reference entities. It doesn't explicitly contrast itself with siblings like mbo_get_services or mbo_api_get, so the distinction must be inferred.

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 statement of when to call this versus mbo_api_get or the entity-specific siblings (mbo_get_services, mbo_get_classes), and no prerequisites or selection guidance beyond the resource enum itself. Usage is only implied by the title and the list of resources.

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

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

Annotations already declare readOnlyHint=true, and the description adds genuinely useful behavior beyond that: contact details are stripped and names reduced to initials by the PII mask. This tells the agent the returned data is transformed, which is important context it could not get from annotations. It does not, however, disclose pagination behavior despite the maxPages parameter.

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

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

Two tight sentences with the endpoint and scope front-loaded, followed by the masking note. No filler, though the raw endpoint prefix is slightly redundant with 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?

For a simple two-parameter read-only tool, purpose plus the PII transformation is largely sufficient. Without an output schema the description could say a bit more about return shape and pagination, but the key behavioral caveat is covered.

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% (siteId documented, maxPages not), which is borderline. The phrase 'at a site' reinforces the role of siteId but adds no format or syntax detail, and maxPages is left undocumented in both schema and description. A 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 gives a specific resource ('staff at a site') and the underlying endpoint GET /staff/staff, which lets an agent distinguish it from sibling client/sales/service tools. The verb is only implicit (GET) and the leading endpoint string is somewhat redundant, but the scope is clear.

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

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

No when-to-use guidance, no prerequisites, and no mention of alternatives such as the generic mbo_api_get sibling. Usage is only implied by the resource name.

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

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

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds value beyond that: it discloses the shape of the returned records (contact info, MembershipIcon, status) and a pagination/scoping tactic for bulk scans, which is more than the annotation conveys.

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, no filler, and the primary capability (search by text or ClientId) is front-loaded ahead of the secondary bulk-scan tip. Every clause earns its place.

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

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

For a 6-parameter, no-output-schema tool, the description covers purpose, both access modes, the return payload, and a bulk-scan workflow. The one gap is that it never points to mbo_get_client for single-record retrieval, but nothing the agent needs to invoke the tool correctly is missing.

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

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

Schema coverage is high (83%) and the schema already documents each parameter, so the baseline is 3. The description goes slightly further by explaining how two parameters interact for bulk scans, adding operational meaning that the per-field schema text does not supply on its own.

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

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

The description states a specific verb and resource ('Search Mindbody members') and covers both modes of operation: free-text search and direct ClientId retrieval. It also names the return payload ('raw MBO client records'), which distinguishes it from the single-record sibling mbo_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?

It tells the agent when to use each mode (text search vs. fetching specific ClientIds) and adds a concrete bulk-scan recipe ('set includeProspects=false and raise maxPages'). It stops short of explicitly naming mbo_get_client as the alternative for single-record lookups, so routing guidance is clear but not exhaustive.

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