goteamup

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

Annotations already flag this as destructiveHint=true, so the agent knows it mutates state; the description adds the return value ('Returns the updated attendance') and the underlying endpoint, which is genuinely useful given there is no output schema. It stops short of explaining why a check-in is flagged destructive, whether it is reversible (e.g., via unregister), or any permission requirements.

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

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

Two clauses plus an endpoint reference, front-loaded with the action and its plain-language synonym. Every element earns its place; only the trailing API path is arguably redundant.

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

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

For a two-parameter mutation with no output schema, the description covers the action and the return value, but the destructiveHint is left unexplained and there is no note on prerequisites, idempotency, or reversibility. Adequate but with clear gaps for a write 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 100% - both event_id and customer are documented as numeric ids in the schema - so the description adds nothing about parameters. Baseline 3 applies when the schema carries the full parameter burden.

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 ('confirm that a customer attended an event') and even clarifies with the synonym 'check them in', so an agent immediately knows this marks attendance rather than merely reading it. It does not, however, explicitly contrast itself with the sibling tools register_customer_for_event or unregister_customer_from_event, which all touch the same event/customer pair.

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

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

There is no when-to-use guidance: nothing tells the agent that this applies after a customer attended (vs. registering them beforehand), nor when to prefer it over the similar-sounding register/unregister siblings. The parenthetical '(check them in)' implies context but does not state conditions or exclusions.

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

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

The only annotation is destructiveHint=true, which is a weak safety signal for an additive create. The description usefully discloses the side effect that an invitation email is sent by default and how to suppress it, plus the endpoint. It stops short of stating auth/permission needs or whether the created profile is immediately active.

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

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

Three short sentences, front-loaded with the core action, then the default behavior, then the endpoint. No filler; 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?

For a create tool with no output schema, the description covers the action, the primary side effect, and the opt-out. It leaves unspecified whether a customer identifier is returned and whether email is required for the invitation path, minor gaps given the rich 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 already 100%, so the schema documents each field. The description still adds interpretive value by explaining the default and the effect of send_invitation_email=false ("add them silently"), clarifying intent beyond the schema's terse "TeamUp default: true."

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

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

States a specific verb and resource ("Add a new customer"), reveals it is created "as staff," and even names the underlying endpoint (POST /customers). This is clearly distinguishable from siblings like get_customer and list_customers.

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

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

Explains the default behavior (invitation email sent) and how to override it (send_invitation_email=false for silent add), which is the key decision an agent faces when calling this tool. It does not, however, name sibling alternatives or state when this is preferable to register_customer_for_event.

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 signals a safe read, and the description adds useful context beyond the annotation: it defines what is returned (application + reachable businesses with numeric ids) and frames it as a cheap token-validity check. It stops short of documenting error/auth-failure behavior, which would earn 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?

A single dense sentence that front-loads the return content before the practical use cases, plus the underlying endpoint. Every clause earns its place and nothing is padded.

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

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

For a zero-argument, zero-output-schema tool, this covers everything the agent needs: what it returns, why to call it, and the underlying TeamUp endpoint. There is no meaningful 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?

The tool takes zero parameters, so the schema-baseline of 4 applies. There is nothing to disambiguate, and the description correctly implies no input is required.

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

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

The description states a specific verb ('Show') and resource ('the API application this token belongs to and the businesses (providers) it can reach'), with concrete outputs (numeric ids). No sibling tool does anything remotely similar, so the agent can distinguish it immediately.

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 when-to-use reasons: confirm the token works and find the value for GOTEAMUP_PROVIDER_ID. It doesn't name an alternative, but among the listed siblings there is no substitute for this introspection call, so guidance is effectively complete.

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

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

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds useful context about which fields are returned by default versus deferred (field_values, credit_balance, staff_assignments reachable via expand), but offers nothing on auth, rate limits, or error behavior.

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

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

Two tight sentences, front-loaded with the verb and resource, followed by the expand hint and the underlying endpoint. No filler, though the trailing 'TeamUp: GET /customers/{id}' is marginally redundant with 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 read-only single-resource fetch with annotation coverage, a fully described param schema, and no output schema, the definition is nearly complete. Enumerating the default returned fields compensates for the missing output schema, leaving only error/not-found behavior unaddressed.

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

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

Schema description coverage is 100%, so all three parameters are already documented; baseline is 3. The description adds marginal value by naming concrete expand targets (field_values, credit_balance, staff_assignments) as deferred fields, but no syntax or format details 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?

Specific verb (Fetch) plus resource scope (one customer by id), and it enumerates the key returned fields (name, email, family role, lead flag, CRM status, created date). It is clearly distinguishable from the sibling goteamup_list_customers (one vs many).

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

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

It gives a conditional instruction for 'expand' to retrieve deferred fields, which is useful actionable guidance. However, it never states when to prefer this tool over goteamup_list_customers or goteamup_get_customer_membership, so the alternative-selection guidance is only implied.

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

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

readOnlyHint=true already tells the agent this is a safe, non-mutating read, so the burden is lower. The description adds the endpoint and the expand hint but says nothing about error behavior for a missing id or what the returned object contains. Adequate but thin beyond the annotation.

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

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

Two short sentences, front-loaded with the core action and followed by the one actionable hint. 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?

For a single-resource read with no output schema, the description covers the identifier, the expand mechanism, and the backing endpoint well enough to call it correctly. It could mention that a nonexistent id returns an error, but nothing essential is missing.

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

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

Schema coverage is 100%, so the baseline is 3, and the description genuinely adds value by naming concrete expand values (usage_summary, next_billing_date, shared_with) that the schema only illustrates generically. It does not document the 'fields' parameter, so it stops short of a 5.

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

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

The description states a specific verb and resource ('Fetch one customer membership by id') and even cites the underlying HTTP endpoint. The word 'one' plus the required id parameter cleanly distinguishes it from the sibling goteamup_list_customer_memberships.

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 specific expand values ('for usage, next bill and sharing'), which is useful, but never states when to use this tool versus the list variant or what happens when the id is unknown. Usage is implied by 'by id' rather than explicitly contrasted with 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, so the safety profile is covered. The description adds real behavioral context by enumerating what the record contains — capacity, attending/waiting counts, registration and late-cancel deadlines — and by mapping to the underlying GET /events/{id} endpoint.

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 plus an endpoint reference, front-loaded with the verb and resource. Every clause earns its place by telling the agent what the returned record includes.

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 partially compensates by listing the notable returned fields, and the schema fully covers the inputs. It does not specify error behavior for an unknown id, which is a minor residual gap.

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

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

Schema description coverage is 100%, so event_id, expand, and fields are all documented in the schema itself. The description adds nothing about expand/fields syntax, so the baseline 3 applies.

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

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

States a specific verb ('Fetch') and resource ('one class or appointment by id'), and the phrase 'by id' immediately separates it from the sibling goteamup_list_events. The included resource detail (capacity, counts, deadlines) sharpens the purpose beyond a tautology.

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

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

Usage is implied by 'by id' — fetch one entity when you have its id rather than listing. However, no sibling alternative (e.g. goteamup_list_events) is named and no exclusions or prerequisites are given, so the agent must infer when this is preferred.

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

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

readOnlyHint=true already tells the agent this is a safe non-mutating read, so the description carries a lower burden. It adds the endpoint path but discloses nothing beyond annotations such as error behavior for missing ids or whether expansions affect payload size.

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

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

Three short sentences, front-loaded with the core action, followed by the most actionable parameter tip and the endpoint. No filler.

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

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

For a read-only single-resource fetch with no output schema, the description covers purpose, the id requirement, and the useful expand set. It could note return shape or not-found behavior, but nothing critical for correct invocation 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 100%, so the baseline is 3, but the description adds genuine value by naming the concrete invoice-specific expand values (line_items, charges, discounts, taxes, applied_credits) that the generic schema example does not provide.

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

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

States a specific verb and resource with scope ('Fetch one invoice by id'), which cleanly distinguishes it from the sibling goteamup_list_invoices. The API endpoint reference reinforces the exact resource addressed.

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

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

Gives a practical hint about which expand values are useful for invoices, but never states when to use this single-fetch tool versus goteamup_list_invoices or other lookups. Usage is only implied by the word 'one'.

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, so the description only needs to add beyond that. It adds useful context that status values include registration, attendance, no-show and late-cancel states and that expansion is available, but says nothing about pagination limits or result volume, even though the tool returns a paginated list.

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

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

Three tight sentences, front-loaded with what a booking record is before listing filters. The middle clause ('who is registered for, attended, no-showed or late-cancelled which event') is slightly convoluted but still compact and information-dense rather than padded.

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

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

For a 12-param read-only list tool with no output schema and full schema coverage, the description supplies the conceptual framing (what a booking is), the filter vocabulary, and the expand tip. The main omission is any hint about pagination behavior or typical result size, but the schema covers the page/page_size mechanics.

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

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

Schema description coverage is 100%, so every one of the 12 parameters is already documented in the schema. The description slightly reinforces the filterable fields and highlights the expand convention, but adds no syntax or format detail beyond what the schema provides, so baseline 3 applies.

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

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

States a specific verb and resource ('List bookings') and immediately enumerates what each record contains: attendance status, event, and customer membership. This is clearly distinguishable from siblings like goteamup_get_event or goteamup_list_events, which return event data rather than per-customer attendance records.

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 explicit filter axes (customer, event, venue, offering type, status, event start window) and a concrete tip to use expand=customer,event for names, which is actionable invocation guidance. However, it never states when to prefer this over alternatives such as goteamup_get_customer_membership or per-event lookups, leaving 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 covers the safety profile, so the bar is lower, and the description adds real context beyond it: an authorization requirement (super_admin-level token) and the shape of the payload (notes, who logged them). It does not mention pagination behavior or result ordering, but the auth disclosure is the kind of pre-flight constraint an agent needs.

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

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

Two short sentences, front-loaded with the resource and its contents, then the two practical constraints (filter, auth). Slightly redundant to repeat 'TeamUp: GET /crm/interactions' since the name already implies it, but nothing wastes meaning.

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

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

With no output schema, the description carries return-value burden and does so by naming the interaction types and the included metadata. Combined with the auth requirement and the fully covered input schema, an agent has enough to call it correctly; only pagination/ordering semantics are left unstated.

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

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

Schema description coverage is 100%, so page, page_size, expand and fields are already fully documented with formats and bounds. The description's only parameter-level addition is glossing the customer filter, which merely restates the schema's own text. Baseline 3 is correct when the schema does the heavy lifting.

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

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

States a specific verb (List) and resource (logged CRM interactions) and even enumerates the interaction types (calls, emails, meetings, contacted), so the agent knows exactly what comes back. It does not explicitly name the write counterpart (goteamup_log_crm_interaction), but 'logged' plus the list verb clearly separates reads from that 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?

Adds one useful usage cue — 'optionally for one customer' — signaling the customer filter is the only narrowable dimension. However it gives no explicit when-to-use vs the log_crm_interaction sibling or other list tools, and the super_admin prerequisite is stated only as a requirement, not a decision rule. Implied usage only.

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

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

readOnlyHint=true already establishes this as a safe read, so the bar is lower. The description adds the underlying endpoint (GET /customer_memberships) and the returned field set (status, dates, billed price, active hold), which is useful context, but says nothing about pagination behavior or how the default 100-per-page interacts with filtering.

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

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

Two compact sentences front-load the returned fields and filter options, then close with the API endpoint. No filler, though the parenthetical status enumeration duplicates the schema enum rather than adding value.

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

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

For a rich 15-parameter read tool with full schema coverage and no output schema, the description covers what is returned (statuses, dates, billed price, hold state) and what can be filtered. It is close to complete; only pagination/return-shape behavior is left to the schema.

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

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

Schema description coverage is 100%, so the schema already documents all 15 parameters, including the status enum and date bounds. The description's filter list ('customer, membership plan, type, status, dates or holds') only restates those parameters at a higher level without adding format or constraint detail, so the baseline 3 applies.

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

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

States a specific verb and resource ('List memberships held by customers') with clear scope. It implies a distinction from plan-level listings, but never names the sibling tools goteamup_list_memberships or goteamup_get_customer_membership, so differentiation depends on inference.

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 enumerates filterable dimensions (customer, membership plan, type, status, dates, holds), which implies the contexts in which the tool is useful, but it gives no explicit when-to-use, when-not, or alternative-tool guidance.

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

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

readOnlyHint=true already establishes that this is a safe read, and the description usefully discloses that some fields (field_values, credit_balance, sms_account) are deferred and require expand. It does not, however, mention pagination behavior, defaults, or result volume despite being a list endpoint with page/page_size.

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: purpose, filter inventory, and the expand caveat, front-loaded with the core purpose. Efficient, though the endpoint reference (TeamUp: GET /customers) is of limited value to an agent choosing a tool.

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

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

For a 13-parameter read-only list tool with a full schema and no output schema, the description covers purpose, filter taxonomy, and deferred fields adequately. The notable omission is pagination behavior, which the agent must infer from the schema alone.

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 13 parameters are already documented in the schema, setting the baseline at 3. The description's mapping of filters to categories and its note on expand adds only marginal value beyond what the schema already states.

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 combination (search and list) and resource (business's customers, clarifying members and leads), plus enumerates the filter dimensions. An agent can easily distinguish this from the singular get_customer or the write-oriented create_customer 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?

Usage is implied by the 'search and list' framing and the filter inventory, but it never states when to prefer this over get_customer (single lookup) or how it relates to siblings like list_customer_memberships. No explicit when-not guidance is 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 the underlying endpoint (TeamUp: GET /events) and the shape of returned data, which is useful context, but says nothing about pagination behavior, default page size, or how expand/fields affect the payload — details that matter for a 15-parameter list tool.

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

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

Two sentences, no filler, with the core purpose and return fields front-loaded. The second sentence is a dense enumeration of filter dimensions, which is slightly hard to scan but still earns its space.

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 15-parameter, zero-required read tool with no output schema, the description usefully previews the returned fields and the filter surface, and annotations cover safety. It stops short of explaining pagination defaults or expand/fields interplay, but that gap is modest given the thorough schema.

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

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

Schema description coverage is 100%, so every parameter (ids, page, sort, expand, fields, status, venues, instructors, starts/ends bounds, occupancy_status, page_size) is already documented in the schema. The description merely restates the filter categories without adding format, default, or interaction semantics beyond what is structured.

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

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

States a specific verb (list) and resource (scheduled sessions — classes and appointments), and enumerates the returned fields (time, status, capacity, counts, instructors, venue). An agent can distinguish it from the sibling goteamup_get_event (single event) and goteamup_list_attendances without opening either schema.

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

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

The second sentence lists the filterable dimensions (time window, instructor, venue, offering type, status, occupancy), which implies when the tool is useful, but it never states when to prefer it over goteamup_get_event or goteamup_list_attendances, nor mentions exclusions or prerequisites. Usage is implied rather than prescribed.

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

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

readOnlyHint=true already tells the agent this is a safe read. The description adds the returned field set (name, bio, linked staff id), which is modest but real added value; it says nothing about pagination behavior or scoping beyond what annotations and schema 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?

Two short sentences, front-loaded with the resource and return shape, with the upstream endpoint noted compactly. 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 read-only list tool with fully documented params and an existing readOnlyHint, the description covers purpose and returned fields adequately. Only minor gaps remain, such as pagination expectations, but nothing critical is missing for correct invocation.

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

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

Schema description coverage is 100%, so page, query, expand, fields and page_size are all documented in the schema itself. The description adds no syntax or format detail beyond that, which is the expected baseline when the schema does the heavy lifting.

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

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

States a specific verb (List) and resource (business's instructors), and clarifies the domain synonyms (coaches, trainers) plus the fields returned. No sibling tool covers instructors, so differentiation 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 gives no when-to-use guidance, prerequisites, or alternatives. Listing is implied by the verb, but there is no statement about when this is the right call versus, say, goteamup_get_authenticated_application or other lookups.

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

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

The readOnlyHint annotation already establishes this as a safe read, so the bar is lower. The description adds worthwhile context by listing the returned fields (status, due date, amount due, payer, receipt URL) and the upstream endpoint, but says nothing about pagination behavior despite page/page_size parameters.

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

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

One dense sentence plus an endpoint reference, front-loaded on the resource and returned data. No filler, though the field enumeration is slightly list-heavy for a tool whose return shape could be inferred.

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's field listing usefully covers what comes back, and all seven optional params are covered by the schema. Missing only pagination guidance and an explicit pointer to the single-invoice 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 100%, so every parameter is already documented in the schema. The description only echoes the status values (with a truncated list versus the schema's full enum) and the membership filter, adding no syntax or format detail 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 specific verb+resource ('List invoices') and enumerates the returned fields and supported filters, which is more than a restatement of the name. It implies but never explicitly says how it differs from the singular goteamup_get_invoice sibling, 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?

The description tells the agent the two filter dimensions (status, customer membership), which implies when the tool is useful, but offers no when-not conditions, prerequisites, or named alternative such as get_invoice for a single record.

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

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

Annotations already declare readOnlyHint=true, so the safety profile is covered by structured data. The description still adds value by naming the fields the listing returns (price, duration, allotment, active member count, visibility) and by clarifying these are sellable products, not customer subscriptions. It stops short of mentioning pagination behavior, which the schema covers instead.

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

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

One dense sentence front-loads the resource, its subtypes and its returned fields, followed by a short API endpoint reference. Zero filler; 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 enumerates the returned fields, and the schema fully covers all 9 filter/pagination parameters. The only real gap is the absence of usage routing against the closely named sibling list_customer_memberships, which would matter for an agent choosing between the two.

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

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

Schema description coverage is 100% and every one of the 9 parameters is documented in the schema itself, including the expand/fields syntax and the for_sale, is_dropin and permits_registration_for_event filters. The description adds no parameter semantics beyond that, so the baseline 3 applies.

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

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

States a specific verb ('List') and resource ('the membership products the business sells') and enumerates the subtypes — packs, recurring and prepaid plans — plus the fields returned. An agent can infer this is the product catalog rather than a customer's owned memberships, but the description never explicitly contrasts itself with goteamup_list_customer_memberships, so sibling differentiation is left implicit.

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

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

There is no when-to-use or when-not-to-use guidance and no mention of the obvious alternative (goteamup_list_customer_memberships) or of the filter conditions under which this tool is preferred. The agent must infer usage purely from the resource noun.

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

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

Annotations already declare readOnlyHint=true, so the safe-read nature is covered. The description adds the returned attribute set (schedule type, price, age limits, visibility, status) and the underlying endpoint, which is useful context but says nothing about pagination defaults or result volume.

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

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

One dense sentence that front-loads the entity and its definition, followed by the attribute set and endpoint mapping. Nothing is wasted and nothing is buried.

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 partially compensates by enumerating what each offering type record contains. It does not cover pagination behavior or the default page_size, but for an optional-filter list endpoint this is close to 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 description coverage is 100% with all 8 parameters documented in the schema, so the baseline is 3. The description's field list describes returned data rather than adding meaning to filters like name_contains, status, or has_active_sessions.

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 and resource ('List offering types') and immediately defines the domain term for an agent unfamiliar with TeamUp ('the kinds of classes, appointments and courses the business runs'). This disambiguates it from siblings like list_events and list_memberships.

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

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

Usage is implied by the nature of a catalog-listing tool, but there is no explicit when-to-use, when-not-to-use, or pointer to an alternative when the agent actually needs session instances (list_events) rather than the offering definitions.

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 scope context (includes online venues, returns address/timezone/rooms) but says nothing about pagination behavior (default page size 100, max 100) or how many venues to expect, which matters for a paginated list.

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

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

Two short sentences, front-loaded with the action and scope; the trailing "TeamUp: GET /venues" is mildly useful for mapping to the underlying API but is otherwise redundant.

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

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

With no output schema, the description compensates by naming the key returned attributes (address, timezone, rooms) and the venue kinds covered. It is close to complete for a read-only list tool whose parameters are fully documented in the schema, though pagination semantics are not mentioned.

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 page, page_size, fields, expand, status and has_active_sessions are fully documented in the schema. The description contributes no additional parameter meaning, so the baseline 3 applies.

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

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

States a specific verb+resource ("List the business's venues") and scopes it by clarifying that both physical locations and online venues are included, plus the returned attributes. It is unambiguous among siblings, though it does not explicitly name a contrasting tool.

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 explicit when-to-use or when-not-to-use guidance is given; the tool's role is only implied by its name and the parenthetical scope. For a straightforward list-all endpoint this is adequate but leaves the agent to infer that it is the entry point for discovering venue IDs.

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 only declare destructiveHint=true, and the description adds genuine value beyond that by disclosing the super_admin token requirement. However, it says nothing about side effects (record visibility, whether an existing interaction is overwritten) or the response shape for what is a write operation.

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

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

Two tight sentences, front-loaded with the action and resource, with optional fields and the auth prerequisite following. The trailing 'TeamUp: POST /crm/interactions' is marginally useful endpoint metadata but borders on 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 four-parameter write tool with no output schema and only a destructiveHint annotation, the description covers the action, the optional fields, the interaction vocabulary, and the token requirement. It is nearly sufficient; only side-effect and response behavior are left unstated.

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

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

Schema description coverage is 100%, so all four parameters (customer, interaction_type, note, call_outcome) are already fully documented in the schema, including the enum values and the 'only for interaction_type=Call' constraint. The description merely summarizes note and call outcome, adding no syntax or format detail 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?

Specific verb ('Record') and resource ('call, email, meeting or contact with a customer or lead'), with the optional fields named. It is clearly distinguishable from the sibling goteamup_list_crm_interactions by verb contrast, though it never names that sibling explicitly.

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

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

The description states a prerequisite ('Requires a super_admin-level token'), which is useful context, but it gives no explicit when-to-use/when-not guidance or comparison to alternatives such as the list or create_customer tools. Usage is only implied by the verb.

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 flags this as a mutating operation, and the description adds value beyond it: it discloses the returned attendance id, the reversal path, and the underlying TeamUp endpoint. It still doesn't say what a failed/duplicate booking does or whether a membership gets consumed/charged explicitly, but the coverage is solid.

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

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

A single tight sentence covering purpose, options, return value, undo tool, and endpoint — front-loaded and waste-free. The endpoint tail is slightly extraneous for an agent but harmless.

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

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

For a 4-param mutation tool with no output schema, the description covers what matters: what it does, the two booking modes, and the returned id. Prerequisite/auth conditions and duplicate-booking behavior are the only meaningful 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 coverage is 100%, so all four parameters already carry descriptions including the 'omit to let TeamUp choose' behavior for customer_membership. The description only restates the comped/membership semantics rather than adding syntax or constraints beyond the schema, so baseline 3 applies.

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

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

States a specific verb+resource ('Register a customer for a class or appointment') and clarifies the two booking modes (membership-backed vs comped). It also names the undo counterpart, goteamup_unregister_customer_from_event, so an agent can tell the two apart without opening 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?

Explains what the optional paths mean (use a specific membership, or book comped/free) and points to the undo tool. It does not, however, state prerequisites (e.g., that the customer must already exist or the event must be bookable) or when to prefer this over sibling listing/attendance 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?

Adds useful behavioral context beyond annotations: destructive/side-effect warning about penalty triggers from late cancel, plus note that the response indicates whether it counted as late. Annotations already mark destructiveHint=true, but description enriches with consequence awareness.

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: purpose, key parameter caveat, return value hint, API path. Front-loaded. 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?

For a 3-param mutation with annotations covering destructiveness and full schema coverage, this is complete. Minor gap: no output schema, but description notes the response reports late-cancel status, so the agent knows what to check.

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 parameters are already documented. The description echoes and contextualizes is_late_cancel with consequence framing, but adds no syntax or format detail. 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?

Clear specific verb+resource: 'Cancel a customer's booking for a class or appointment.' Distinguishes from sibling goteamup_register_customer_for_event by directly opposing it, and the API endpoint reference (POST /events/{id}/unregister) anchors it.

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

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

Provides a clear conditional instruction for is_late_cancel ('leave it unset unless asked'). No explicit when-not to use the tool itself or alternatives, but context is strong enough to route correctly.

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