Check classes, attendance, customers, memberships and invoices in TeamUp and register customers.
Scored across 20 tools
Tools target distinct resources and actions, but the set contains adjacent pairs like list_memberships vs list_customer_memberships and list_events vs list_attendances that could be confused if descriptions are skimmed. Descriptions clearly distinguish them, so ambiguity is low overall.
All 20 tools use the goteamup_ prefix followed by a consistent snake_case verb_noun pattern (get_, list_, create_, confirm_, log_, register_, unregister_). No mixed conventions or vague verbs.
20 tools is slightly above the ideal 3-15 range but reasonable given the breadth of the TeamUp domain (customers, memberships, events, invoices, CRM, venues, etc.). Each tool maps to a distinct endpoint or action, so the count is justified.
The surface covers many read operations and a few key actions (create customer, register/unregister, confirm attendance, log CRM), but lacks update/delete for customers and most create/update/delete for events, memberships, invoices, venues, etc. This is a notable gap for a business management API.
Confirm that a customer attended an event (check them in). Returns the updated attendance. TeamUp: POST /events/{id}/confirm_attendance.
| Name | Required | Description | Default |
|---|---|---|---|
| customer | Yes | The customer's numeric id. | |
| event_id | Yes | The event's numeric id. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the return value ('Returns the updated attendance'), which matters since there is no output schema. However it adds nothing about the destructiveHint=true annotation: whether an attendance record is created or overwritten, whether re-confirming is idempotent, or whether the action can be undone.
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 plus endpoint reference; the action is front-loaded. The REST endpoint notation is low-value for an agent but not enough to reduce this below 4.
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?
Covers purpose, the mutation, and the return shape, which is adequate for a 2-parameter tool. But with no output schema and an unexplained destructiveHint=true, the definition leaves an agent unsure what state change actually occurs.
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 are documented in the schema, so the baseline of 3 applies. The description only echoes the path template (/events/{id}/confirm_attendance) without adding format or constraint details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource+effect: confirming a customer's attendance at an event equals checking them in. This distinguishes it from goteamup_register_customer_for_event and goteamup_list_attendances, though it never names either sibling as the contrasting alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use guidance, no prerequisites, and no distinction from the closely related register/unregister tools or list_attendances. The check-in semantics are only implied by the parenthetical.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add a new customer to the business as staff. By default TeamUp emails them an invitation to claim the profile; set send_invitation_email=false to add them silently. TeamUp: POST /customers.
| Name | Required | Description | Default |
|---|---|---|---|
| No | Email address (used for the invitation). | ||
| last_name | Yes | Last name. | |
| first_name | Yes | First name. | |
| invitation_note | No | A personal note included in the invitation email. | |
| send_invitation_email | No | Send the invitation email (TeamUp default: true). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The only annotation is destructiveHint=true, so the description carries most of the burden and does add value: it discloses the outbound email side effect, that it is on by default, and how to suppress it. It is consistent with destructiveHint (record creation + external email). It stops short of saying what happens on duplicate emails, what permissions are needed, or what is 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?
Two short sentences plus the endpoint mapping; the default-vs-silent behavior is front-loaded and no sentence is padding. Efficient and easy to scan.
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 five-parameter create tool with no output schema and only a single annotation, the description covers the invitation behavior but says nothing about the result (e.g., whether the new customer id is returned), duplicate-email handling, or required permissions. Adequate to invoke, but not fully complete for an agent that needs to chain the created record into later calls.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with all five parameters documented in the schema, so the baseline is 3. The description restates the send_invitation_email toggle (already in the schema as 'TeamUp default: true') and links email to the invitation, adding only marginal meaning beyond structured 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 ('Add a new customer to the business as staff') plus the underlying endpoint (POST /customers), which is enough to distinguish it from goteamup_get_customer, goteamup_list_customers, and goteamup_register_customer_for_event without opening the schema. The 'as staff' qualifier even clarifies what kind of customer record is produced.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives clear operational context: by default an invitation email goes out, and setting send_invitation_email=false adds the customer silently. That is real when-to-use guidance for the tool's main branch point. It does not, however, say when to prefer this over siblings like goteamup_register_customer_for_event, nor note any prerequisites/exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show the API application this token belongs to and the businesses (providers) it can reach, with their numeric ids — a cheap way to confirm the token works and to find the value for GOTEAMUP_PROVIDER_ID. TeamUp: GET /auth/application.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
readOnlyHint=true already covers the safety profile, and the description adds useful behavioral context: it is a cheap call, it acts as a token validity check, and it returns provider ids used as configuration. It does not describe failure behavior (e.g. what an invalid token returns), which keeps it out of the top band.
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 with the return contents front-loaded, followed by the use cases and the endpoint. No filler and nothing 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?
For a zero-parameter, read-only lookup with no output schema, the description conveys what comes back (application, reachable businesses, their numeric ids) sufficiently for an agent to call and rely on it. A little more on error semantics would make it complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so the schema baseline is 4. The description appropriately focuses on the returned provider id rather than any input, and introduces no phantom parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Specific verb (show) plus a precise resource: the API application the token belongs to and the businesses/providers it can reach, including numeric ids. It is unmistakably distinct from the customer/event/invoice siblings, and it even cites the underlying endpoint (GET /auth/application).
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 two concrete reasons to call it: confirm the token works and discover the value for GOTEAMUP_PROVIDER_ID. It names no sibling alternative, but none exists for this purpose, so little is left to inference; only an explicit when-not clause is missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch one customer by id: name, email, family role, lead flag, CRM status, created date. Use expand for deferred fields, e.g. field_values,credit_balance,staff_assignments. TeamUp: GET /customers/{id}.
| Name | Required | Description | Default |
|---|---|---|---|
| expand | No | Comma-separated related fields to expand into full objects (dot-nested, max depth 4), e.g. customer,event.instructors. | |
| fields | No | Comma-separated fields to return (dot notation for nested), e.g. id,name,starts_at. | |
| customer_id | Yes | The customer's numeric id. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so safety is covered. The description adds genuinely non-obvious behavior: several fields are deferred and only materialize via expand (field_values, credit_balance, staff_assignments). It omits error/not-found behavior, but the key competence needed to call this correctly is disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three compact clauses with the core action front-loaded and no filler; the expand guidance and endpoint reference follow in dependency order. It is dense but 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 does the work of listing the return fields and explaining how to obtain deferred ones, which is sufficient for a single-resource read. It lacks any note on failure modes for a bad customer_id, the only clear remaining gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description earns above baseline by naming endpoint-specific expand targets that the schema's generic example (customer,event.instructors) does not convey, telling the agent which deferred customer fields are actually available here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Fetch one customer by id') and enumerates the returned fields, which immediately separates it from goteamup_list_customers and goteamup_get_customer_membership. The endpoint mapping ('GET /customers/{id}') confirms scope for an agent that knows the API.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The only explicit routing guidance is conditional field expansion ('Use expand for deferred fields'). Nothing states when to prefer this over goteamup_list_customers or goteamup_get_customer_membership, so tool selection is left to inference from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch one customer membership by id. Use expand=usage_summary,next_billing_date,shared_with for usage, next bill and sharing. TeamUp: GET /customer_memberships/{id}.
| Name | Required | Description | Default |
|---|---|---|---|
| expand | No | Comma-separated related fields to expand into full objects (dot-nested, max depth 4), e.g. customer,event.instructors. | |
| fields | No | Comma-separated fields to return (dot notation for nested), e.g. id,name,starts_at. | |
| customer_membership_id | Yes | The customer membership's numeric id. |
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. The description adds the underlying REST route (GET /customer_memberships/{id}) which helps the agent model the call, but says nothing about auth requirements, 404/not-found behavior, or response shape.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, zero waste, scope stated first and the concrete expand hints immediately after. The endpoint mapping is compact and earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-by-id tool with annotations already covering read-only safety, the description is nearly complete; the absence of an output schema is the only mild gap, since it never hints at what a fetched membership contains.
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 would be 3, but the description adds meaning beyond the schema by naming concrete expand values (usage_summary, next_billing_date, shared_with) and what each buys the caller. That is genuine added value over the generic comma-separated expand documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (Fetch), resource (customer membership) and scope (one, by id), which implicitly separates it from goteamup_list_customer_memberships. It does not explicitly name that sibling, so it falls just short of the top score.
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: fetch when you need a single membership by id. The only explicit direction concerns expand values, which is parameter guidance rather than a when-to-use/when-not-to-use statement or a sibling comparison.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch one class or appointment by id, including capacity, attending/waiting counts, registration open/close and late-cancel deadlines. TeamUp: GET /events/{id}.
| Name | Required | Description | Default |
|---|---|---|---|
| expand | No | Comma-separated related fields to expand into full objects (dot-nested, max depth 4), e.g. customer,event.instructors. | |
| fields | No | Comma-separated fields to return (dot notation for nested), e.g. id,name,starts_at. | |
| event_id | Yes | The event's numeric id. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, so safety is already covered, and the description goes further by disclosing the concrete contents of the response (capacity, attending/waiting counts, registration and cancel deadlines) plus the backing endpoint GET /events/{id}. It does not describe handling for a missing/invalid id, but the content disclosure is genuinely additive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tightly packed sentences: the outcome and its payload come first, the API mapping last. Every clause carries information and nothing is repeated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description takes on the burden of telling the agent what comes back, and it does so concretely. It is nearly complete for a single-resource read; the only gap is not hinting at how expand/fields alter the payload shape, which the schema does cover.
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 already fully documented with examples in the schema. The description only alludes to the id parameter and adds no syntax or format detail beyond that, so the baseline of 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 ('Fetch one class or appointment by id') and enumerates the returned data (capacity, attending/waiting counts, registration and late-cancel deadlines). This clearly separates it from the sibling goteamup_list_events, which returns many events.
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: 'by id' and 'one' suggest it is the single-record lookup counterpart to goteamup_list_events, but neither that sibling nor any when/when-not condition is named. No prerequisites (e.g. needing an id from a list call) are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch one invoice by id. Use expand=line_items,charges,discounts,taxes,applied_credits for the breakdown. TeamUp: GET /invoices/{id}.
| Name | Required | Description | Default |
|---|---|---|---|
| expand | No | Comma-separated related fields to expand into full objects (dot-nested, max depth 4), e.g. customer,event.instructors. | |
| fields | No | Comma-separated fields to return (dot notation for nested), e.g. id,name,starts_at. | |
| invoice_id | Yes | The invoice's numeric id. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
readOnlyHint=true already tells the agent this is a safe read, lowering the bar. The description adds the invoice-specific expansion targets, which is useful behavioral detail about how to get a full breakdown, but says nothing about permissions, rate limits, or error behavior for a missing id.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences: purpose first, then the highest-value parameter hint, then the underlying endpoint. No filler and nothing 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?
For a read-only single-resource fetch with no output schema and full schema coverage, the description covers purpose, key parameter usage, and the endpoint. It stops short of describing what the breakdown contains or pagination, but no essential calling information is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description goes beyond the schema's generic expand example by naming the five invoice-specific expansions (line_items, charges, discounts, taxes, applied_credits). That is concrete meaning the schema does not supply.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Fetch one invoice by id'), which unambiguously distinguishes it from the sibling goteamup_list_invoices. The endpoint hint (GET /invoices/{id}) reinforces scope without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives operational guidance for the expand parameter ('use expand=line_items,charges,... for the breakdown'), which is a real usage cue, but never states when to reach for this tool versus goteamup_list_invoices. Usage is implied rather than explicitly routed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List bookings: who is registered for, attended, no-showed or late-cancelled which event, and with which customer membership. Filter by customer, event, venue, offering type, status or event start window. Use expand=customer,event for names. TeamUp: GET /attendances.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number, starting at 1. | |
| sort | No | Ordering; '-' for descending. | |
| event | No | Only these event ids. | |
| venue | No | Only these venue ids. | |
| expand | No | Comma-separated related fields to expand into full objects (dot-nested, max depth 4), e.g. customer,event.instructors. | |
| fields | No | Comma-separated fields to return (dot notation for nested), e.g. id,name,starts_at. | |
| status | No | Attendance status; plans_to_attend = registered or waitlisted. | |
| customer | No | Only these customer ids. | |
| page_size | No | Results per page, 1-100 (default 100). | |
| offering_types | No | Only these offering type ids. | |
| event_starts_at_gte | No | Only attendances for events starting at or after (ISO 8601 timestamp, e.g. 2026-10-01T00:00:00Z). | |
| event_starts_at_lte | No | Only attendances for events starting at or before (ISO 8601 timestamp, e.g. 2026-10-01T00:00:00Z). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint=true annotation already establishes this as a non-mutating read, so the description only needs to add operational context. It contributes the expand advice and the filter surface, but says nothing about pagination behavior, result volume, or default page size despite being a list endpoint over potentially large booking sets.
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: purpose first, filters second, expand tip third, with the API route appended as a compact reference. No filler 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?
For a 12-parameter, zero-required read endpoint with no output schema and full schema coverage, the description covers identity, filterable dimensions and the key expand option. Only pagination/result-size behavior and any sibling routing guidance are absent, which is a minor gap given the readOnly annotation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so every one of the 12 parameters is already documented in the schema, including the status enum and sort options; this sets the baseline at 3. The description restates the filter families and gives one expand example, which is mildly reinforcing but adds no syntax or semantics 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?
The description states a specific verb and resource ('List bookings') and defines what a booking row contains: who is registered, attended, no-showed or late-cancelled, for which event, and with which customer membership. That roster semantics clearly separates it from siblings like goteamup_list_events or goteamup_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?
It enumerates the usable filter dimensions (customer, event, venue, offering type, status, event start window) and adds a concrete tip to pass expand=customer,event for names, which is actionable context. It stops short of stating when a different sibling (e.g. goteamup_get_event or goteamup_confirm_attendance) should be preferred instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List logged CRM interactions (calls, emails, meetings, contacted) with notes and who logged them, optionally for one customer. Requires a super_admin-level token. TeamUp: GET /crm/interactions.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number, starting at 1. | |
| expand | No | Comma-separated related fields to expand into full objects (dot-nested, max depth 4), e.g. customer,event.instructors. | |
| fields | No | Comma-separated fields to return (dot notation for nested), e.g. id,name,starts_at. | |
| customer | No | Only interactions for this customer id. | |
| page_size | No | Results per page, 1-100 (default 100). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the read safety profile is covered. The description adds genuinely useful context beyond that: the required super_admin-level token (an auth gating detail not in the annotations or schema) and the underlying endpoint. It stops short of describing pagination or return format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One tight sentence, front-loaded with the core purpose, then the auth prerequisite and endpoint. No redundant or filler content, though the trailing API reference is marginal value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only list tool with a fully documented schema and no output schema, the description covers purpose, the optional customer scope, and the super_admin auth requirement. Nothing essential 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 description coverage is 100%, so all five parameters (page, expand, fields, customer, page_size) are documented in the schema itself. The description only adds a plain-language gloss for the customer filter, which is the correct 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?
The description gives a specific verb+resource ('List logged CRM interactions') and even enumerates the interaction types (calls, emails, meetings, contacted) plus what fields come back (notes, logger). It implicitly contrasts with the sibling goteamup_log_crm_interaction via the List/Log verb, but never names or explicitly differentiates that alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It states a real prerequisite ('Requires a super_admin-level token') and hints at an optional filter usage ('optionally for one customer'), which is useful context. However it gives no explicit when-to-use/when-not guidance and does not point to the sibling log tool as the write counterpart.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List memberships held by customers — status (active, hold, complete, cancelled), start/expiration/renewal dates, billed price, active hold. Filter by customer, membership plan, type, status, dates or holds. TeamUp: GET /customer_memberships.
| Name | Required | Description | Default |
|---|---|---|---|
| ids | No | Only these customer membership ids. | |
| page | No | Page number, starting at 1. | |
| sort | No | Ordering; '-' for descending. | |
| expand | No | Comma-separated related fields to expand into full objects (dot-nested, max depth 4), e.g. customer,event.instructors. | |
| fields | No | Comma-separated fields to return (dot notation for nested), e.g. id,name,starts_at. | |
| status | No | Customer membership status. | |
| customer | No | Only these customer ids. | |
| page_size | No | Results per page, 1-100 (default 100). | |
| membership | No | Only these membership (plan) ids. | |
| start_date_gte | No | Start date on or after (date, YYYY-MM-DD). | |
| start_date_lte | No | Start date on or before (date, YYYY-MM-DD). | |
| has_active_hold | No | Only memberships with (true) or without (false) a current or upcoming hold. | |
| membership_type | No | Membership type. | |
| expiration_date_gte | No | Expiration date on or after (date, YYYY-MM-DD). | |
| expiration_date_lte | No | Expiration date on or before (date, YYYY-MM-DD). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already tells the agent this is a safe read, so the burden is lower. The description usefully discloses the returned data surface (status, start/expiration/renewal dates, billed price, active hold) and the backing endpoint GET /customer_memberships, but says nothing about pagination behavior or the default page size of 100 that the schema exposes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences that front-load the scope ('List memberships held by customers') followed by the filter dimensions. The trailing endpoint reference is mildly redundant but compact, and there is no filler prose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 15-parameter read-only list tool with no output schema, the description covers purpose, filterable axes, and the shape of the returned record, which is enough for an agent to call it correctly. Only pagination/sorting behavior is left entirely 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 every parameter including page, page_size, sort, expand and fields is already documented. The description only restates the filter categories at a high level and adds no syntax, formatting, or default-value detail beyond the schema, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('List memberships held by customers') and names the concrete data it returns (status, dates, billed price, hold). It does not explicitly distinguish itself from the sibling goteamup_list_memberships, which an agent could easily confuse with this tool, but the 'customer memberships' phrasing is reasonably precise.
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 the filtering dimensions (customer, plan, type, status, dates, holds), which implies when the tool is useful, but it never states when to use this versus goteamup_list_memberships or goteamup_get_customer_membership, nor any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search and list the business's customers (members and leads). Filter by free text (email and name), CRM status, active memberships, age or family. Deferred fields such as field_values, credit_balance or sms_account can be added with expand. TeamUp: GET /customers.
| Name | Required | Description | Default |
|---|---|---|---|
| ids | No | Only these customer ids. | |
| page | No | Page number, starting at 1. | |
| query | No | Free-text match against email and name. | |
| expand | No | Comma-separated related fields to expand into full objects (dot-nested, max depth 4), e.g. customer,event.instructors. | |
| family | No | Only customers in this family id. | |
| fields | No | Comma-separated fields to return (dot notation for nested), e.g. id,name,starts_at. | |
| status | No | CRM status slugs, as shown in a customer's `status` field; pass 'null' for customers without a status. | |
| age_gte | No | Minimum age in years. | |
| age_lte | No | Maximum age in years. | |
| deleted | No | Filter by deleted (true) or not deleted (false). | |
| page_size | No | Results per page, 1-100 (default 100). | |
| autocomplete | No | Prefix match from the start of email and name fields. | |
| active_memberships | No | Only customers holding one of these membership (plan) ids. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare readOnlyHint=true, so the description usefully adds that certain fields are deferred and must be pulled in via expand, naming concrete examples (field_values, credit_balance, sms_account). It omits pagination behavior, default page size, and what the response looks like, but the deferred-field disclosure is genuine value beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tightly written sentences that front-load the core purpose and then layer filters and expand. The trailing 'TeamUp: GET /customers.' is minor API-mapping context rather than 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 13-parameter, zero-required, no-output-schema list tool, the description covers the filter surface and the expand mechanism but says nothing about return shape, pagination defaults, or result limits. Adequate for invoking the tool, incomplete for predicting its output.
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 13 parameters with descriptions. The description's filter summary and expand note largely restate schema content without adding format or syntax detail (e.g., how 'null' status works or how dot-nesting is specified). 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 pair (search and list) plus the resource (customers), and clarifies scope with '(members and leads)' so the agent knows leads are included. It is clearly distinguishable from get_customer and list_customer_memberships by the free-text/filter framing, though it never names a sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The filtering vocabulary ('Filter by free text, CRM status, active memberships, age or family') implies when this tool is appropriate, but there is no explicit when-to-use guidance or statement of when to prefer get_customer or list_customer_memberships. Usage is inferable rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List scheduled sessions — classes and appointments — with start/end time, status, capacity, attending and waitlist counts, instructors, venue and offering type. Filter by time window, instructor, venue, offering type, status or occupancy. TeamUp: GET /events.
| Name | Required | Description | Default |
|---|---|---|---|
| ids | No | Only these event ids. | |
| page | No | Page number, starting at 1. | |
| sort | No | Ordering; '-' for descending. | |
| expand | No | Comma-separated related fields to expand into full objects (dot-nested, max depth 4), e.g. customer,event.instructors. | |
| fields | No | Comma-separated fields to return (dot notation for nested), e.g. id,name,starts_at. | |
| status | No | Event status. | |
| venues | No | Only events at these venue ids. | |
| page_size | No | Results per page, 1-100 (default 100). | |
| ends_at_gte | No | Only events ending at or after (ISO 8601 timestamp, e.g. 2026-10-01T00:00:00Z). | |
| ends_at_lte | No | Only events ending at or before (ISO 8601 timestamp, e.g. 2026-10-01T00:00:00Z). | |
| instructors | No | Only events taught by these instructor ids ('me' for your own). | |
| starts_at_gte | No | Only events starting at or after (ISO 8601 timestamp, e.g. 2026-10-01T00:00:00Z). | |
| starts_at_lte | No | Only events starting at or before (ISO 8601 timestamp, e.g. 2026-10-01T00:00:00Z). | |
| offering_types | No | Only events of these offering type (class type) ids. | |
| occupancy_status | No | Only events matching at least one of these occupancy states. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With readOnlyHint=true already declaring the safety profile, the description adds real value by disclosing the returned fields (capacity, attending and waitlist counts, instructors) that an agent cannot see without an output schema, plus the underlying API call ('TeamUp: GET /events'). It still omits pagination/sort defaults and any rate limits, so it is not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences with the payload described first and filters second; no filler. The field enumeration is dense but each item is informative, and the API endpoint tag is a compact addition.
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 read-only list tool with no output schema, the description supplies a useful summary of the returned shape and the filter surface, which is the main gap the schema cannot fill. Minor omissions (pagination defaults, sort direction semantics) already live in the schema, so coverage is adequate.
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 15 parameters (ids, page, sort, expand, fields, status, venues, time bounds, instructors, offering_types, occupancy_status) are already documented in the schema. The description restates the filter dimensions at a high level without adding format, syntax, or default-value 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?
Names a specific verb and resource ('List scheduled sessions — classes and appointments') and enumerates the payload it returns (times, status, capacity, counts, instructors, venue, offering type). An agent can distinguish it from goteamup_get_event 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 filter dimensions ('time window, instructor, venue, offering type, status or occupancy'), which implies the tool's use cases but does not state when to prefer it over alternatives such as goteamup_get_event or goteamup_list_attendances, nor any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the business's instructors (coaches, trainers) with name, bio and linked staff id. TeamUp: GET /instructors.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number, starting at 1. | |
| query | No | Free-text match on the instructor. | |
| expand | No | Comma-separated related fields to expand into full objects (dot-nested, max depth 4), e.g. customer,event.instructors. | |
| fields | No | Comma-separated fields to return (dot notation for nested), e.g. id,name,starts_at. | |
| page_size | No | Results per page, 1-100 (default 100). |
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 that results are scoped to 'the business's' instructors and enumerates returned fields, which is useful context, but says nothing about pagination defaults, result caps, or ordering.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short, front-loaded sentences with the verb and resource first and scope/returned fields second. The trailing 'TeamUp: GET /instructors' is traceability rather than instruction, but its cost is minimal.
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?
A five-parameter, zero-required read tool with fully described schema and no output schema. The description compensates for the missing output schema by naming the returned fields (name, bio, staff id), leaving little an agent needs before invoking it.
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, query, expand and fields are each documented in the schema. The description adds no parameter-level meaning beyond the field list it advertises, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('List the business's instructors') and clarifies the domain synonyms (coaches, trainers), so an agent knows what entity is returned. It does not explicitly differentiate itself from the many other goteamup_list_* siblings, but the resource noun is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied: this is the tool for enumerating instructors, with no explicit when-to-use, prerequisites, or pointer to an alternative. For a straightforward read-only list endpoint the implied usage is probably sufficient, but no routing guidance is offered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List invoices with status (open, paid, failed, voided, upcoming, …), due date, amount due, payer and receipt URL. Filter by status or a customer membership. TeamUp: GET /invoices.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number, starting at 1. | |
| sort | No | Ordering; '-' for descending. | |
| expand | No | Comma-separated related fields to expand into full objects (dot-nested, max depth 4), e.g. customer,event.instructors. | |
| fields | No | Comma-separated fields to return (dot notation for nested), e.g. id,name,starts_at. | |
| status | No | Invoice status. | |
| page_size | No | Results per page, 1-100 (default 100). | |
| customer_membership | No | Only invoices for this customer membership id. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint=true annotation already establishes this as a safe read. The description adds the underlying API mapping (GET /invoices) and the shape of returned invoice data, but says nothing about default ordering, default page size behavior, or result caps — all of which matter for a list 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?
Two compact sentences that front-load the resource and its returned fields, with the filter capability trailing. The trailing "TeamUp: GET /invoices" is mildly useful for API traceability and costs little.
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 key returned fields, which is the main gap it needs to fill. A read-only list tool with fully documented parameters needs little more; only pagination/ordering behavior is 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 every parameter is already documented in the schema. The description only restates the status and customer_membership filters and samples the status enum, adding no syntax or format detail beyond what is structured. 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 invoices") plus the scope of data returned (status, due date, amount due, payer, receipt URL) and the two supported filters. It is unambiguous about what the tool does, though it never names the sibling goteamup_get_invoice as the single-invoice counterpart.
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?
"Filter by status or a customer membership" implies when the filters are relevant, but there is no explicit when-to-use versus when-not, no guidance on choosing between this and goteamup_get_invoice, and no mention of pagination strategy for large result sets.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the membership products the business sells — packs, recurring and prepaid plans — with price, duration, allotment, active member count and visibility. TeamUp: GET /memberships.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number, starting at 1. | |
| expand | No | Comma-separated related fields to expand into full objects (dot-nested, max depth 4), e.g. customer,event.instructors. | |
| fields | No | Comma-separated fields to return (dot notation for nested), e.g. id,name,starts_at. | |
| for_sale | No | Only memberships currently for sale (true) or not (false). | |
| is_dropin | No | Filter drop-in memberships. | |
| page_size | No | Results per page, 1-100 (default 100). | |
| name_contains | No | Only memberships whose name contains this text. | |
| visible_to_customers | No | Filter by customer visibility. | |
| permits_registration_for_event | No | Only memberships that can be used to book this event id. |
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 structurally. The description adds value by enumerating the fields returned (price, duration, allotment, active member count, visibility), but says nothing about pagination behavior despite page/page_size existing, nor about auth or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence naming the resource and its returned attributes, plus a compact API endpoint reference. No filler; every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description usefully enumerates the returned fields, which is the key gap it must fill. Remaining omissions — pagination guidance and the distinction from customer-membership siblings — are modest but real for a 9-parameter list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all nine parameters are already documented in the schema, establishing a baseline of 3. The description's listed attributes (price, duration, allotment) describe output fields rather than the filter semantics of for_sale, is_dropin, permits_registration_for_event, etc., so it adds no parameter meaning 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 (List) and resource (memberships), and clarifies the resource as 'membership products the business sells — packs, recurring and prepaid plans', which implicitly separates it from the per-customer siblings goteamup_list_customer_memberships and goteamup_get_customer_membership. It does not explicitly name those alternatives, so it falls short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description never says when to reach for this tool versus goteamup_list_customer_memberships or goteamup_get_customer_membership, nor does it mention prerequisites or pagination workflow. Usage must be inferred entirely from the resource name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List offering types — the kinds of classes, appointments and courses the business runs — with schedule type, drop-in price, age limits, visibility and status. TeamUp: GET /offering_types.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number, starting at 1. | |
| sort | No | Ordering; '-' for descending. | |
| expand | No | Comma-separated related fields to expand into full objects (dot-nested, max depth 4), e.g. customer,event.instructors. | |
| fields | No | Comma-separated fields to return (dot notation for nested), e.g. id,name,starts_at. | |
| status | No | Offering type status. | |
| page_size | No | Results per page, 1-100 (default 100). | |
| name_contains | No | Only offering types whose name contains this text. | |
| has_active_sessions | No | Only offering types with upcoming active sessions. |
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 genuine value beyond that by disclosing the shape of the returned data (schedule type, drop-in price, age limits, visibility, status) despite there being no output schema. It does not mention pagination behavior, but the schema parameters cover that.
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: the verb and resource come first, the field inventory second, and the API mapping is a compact trailing tag. No sentence 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?
For a read-only list tool with 0 required parameters, full schema coverage and annotations carrying the safety profile, the description is nearly sufficient. The only gap is guidance on when to prefer this over related list tools, which would make it fully self-contained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all eight parameters — including the sort enum, expand, fields, status, page_size, name_contains and has_active_sessions — are already fully documented in the schema. The description adds no syntax or format detail beyond what the schema provides, 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 (offering types), then defines the resource in business terms — 'the kinds of classes, appointments and courses the business runs' — and enumerates the notable fields returned. No sibling tool covers this resource, so no differentiation is needed and the agent can select it unambiguously.
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 by the resource name; the description never states when to call this versus alternatives (e.g. list_events for actual sessions) or any prerequisites such as authentication scope. The GET endpoint hint gives provenance but not selection guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the business's venues (physical locations and online venues) with address, timezone and rooms. TeamUp: GET /venues.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number, starting at 1. | |
| expand | No | Comma-separated related fields to expand into full objects (dot-nested, max depth 4), e.g. customer,event.instructors. | |
| fields | No | Comma-separated fields to return (dot notation for nested), e.g. id,name,starts_at. | |
| status | No | Venue status. | |
| page_size | No | Results per page, 1-100 (default 100). | |
| has_active_sessions | No | Only venues with non-cancelled sessions. |
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 useful but modest context: the venue categories returned and the underlying TeamUp endpoint (GET /venues). It says nothing about pagination limits or the default page size, which is meaningful behavior for a list 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?
A single front-loaded sentence stating what is listed and what comes back, plus a short API cross-reference. Zero filler; 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?
There is no output schema, so the description usefully names the returned attributes (address, timezone, rooms) and even clarifies the venue types. It stops short of covering pagination/filter behavior, which is the remaining gap for a 6-parameter list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each of the six parameters (page, page_size, expand, fields, status, has_active_sessions) documented in the schema itself. The description adds no parameter-level 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 (List) and resource (the business's venues), and even disambiguates scope by clarifying that both physical locations and online venues count. An agent can distinguish it from list_events or list_instructors without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use, when-not-to-use, or alternative-tool guidance is given. The description never hints that the tool supports filtering (status active/archived, has_active_sessions) or pagination, so an agent gets no signal about how to use it beyond the obvious enumeration.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Record a call, email, meeting or contact with a customer or lead, with an optional note and call outcome. Requires a super_admin-level token. TeamUp: POST /crm/interactions.
| Name | Required | Description | Default |
|---|---|---|---|
| note | No | Free-text notes about the interaction. | |
| customer | Yes | The customer's numeric id. | |
| call_outcome | No | Outcome — only for interaction_type=Call. | |
| interaction_type | Yes | Kind of interaction. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only supply destructiveHint=true, so the description's addition of the required super_admin token level and the underlying POST /crm/interactions endpoint adds real behavioral context (mutation + privilege requirement). It does not address side effects on the customer record or whether the logged interaction can be amended/removed, keeping it 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, zero filler: the operation and its scope come first, the auth requirement and API endpoint follow. Every clause carries information an agent can act on.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a write tool with no output schema, the description covers operation, required privilege, and parameter conditionality, which is adequate. It stops short of describing what the mutation affects or returns implicitly (e.g., new interaction id), leaving a small gap against destructiveHint=true.
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 (including enum semantics) are already documented in the schema. The description's mentions of an optional note and call outcome restate the schema rather than adding syntax, format, or constraint detail, matching the baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Specific verb+resource: 'Record a call, email, meeting or contact' makes the write-side counterpart to goteamup_list_crm_interactions obvious, and the enumerated types mirror the interaction_type enum. It is clear what the tool does, though it never explicitly names the read sibling as the alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives one real usage constraint ('Requires a super_admin-level token') and a conditional rule ('call outcome — only for interaction_type=Call'), which is genuinely useful. However, there is no when-to-use vs alternatives guidance and no stated preconditions beyond auth, so it is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Register a customer for a class or appointment, optionally using a specific customer membership, or comped (free). Returns the attendance id. Undo with goteamup_unregister_customer_from_event. TeamUp: POST /events/{id}/register.
| Name | Required | Description | Default |
|---|---|---|---|
| comped | No | Book as comped (no membership use / charge). Default false. | |
| customer | Yes | The customer's numeric id. | |
| event_id | Yes | The event's numeric id. | |
| customer_membership | No | The customer membership id to book with (omit to let TeamUp choose). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare destructiveHint=true; the description goes beyond that by disclosing the return value ('Returns the attendance id') and the exact reversal tool, which matters for a mutating call. It still omits auth/permission requirements and what happens on duplicate registration or full capacity, so it is not fully transparent.
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 action and its variants, then the return value, then the undo route. No filler, and the API endpoint hint is compactly appended.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, but the description compensates by stating the returned attendance id, and all four parameters are covered by the schema. Missing only secondary behavioral detail (idempotency, capacity/failure behavior, auth), which is acceptable for a single-purpose booking call.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so every parameter is already documented (customer, event_id, customer_membership, comped). The description only restates the membership-or-comped choice at a high level and adds no format or edge-case detail, so the schema does the heavy lifting — baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource ('Register a customer for a class or appointment'), clarifies the optional mechanisms (specific membership or comped), and names the inverse sibling goteamup_unregister_customer_from_event, which no other tool covers. An agent can distinguish it from list/get/confirm tools without opening any schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly routes the agent to goteamup_unregister_customer_from_event as the undo path, and distinguishes the two booking modes (membership-backed vs comped/free). It does not state prerequisites such as the event needing capacity or the customer needing to exist, but the when-to-use context is otherwise clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Cancel a customer's booking for a class or appointment. is_late_cancel=true records it as a LATE cancel, which can trigger the business's penalty rules — leave it unset unless asked. The response says whether it counted as late. TeamUp: POST /events/{id}/unregister.
| Name | Required | Description | Default |
|---|---|---|---|
| customer | Yes | The customer's numeric id. | |
| event_id | Yes | The event's numeric id. | |
| is_late_cancel | No | Record as a late cancellation (may incur penalties). Omit unless explicitly requested. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare destructiveHint=true, so the description usefully adds that a late cancel 'can trigger the business's penalty rules' and that the response reports whether the cancel counted as late. This is real behavioral context beyond the safety hint, though it omits anything about permissions or irreversibility of the removal itself.
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 compact sentences: purpose first, then the risky parameter's caveat, then the response hint and endpoint. No filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 3-parameter destructive mutation with no output schema, the description covers purpose, the risky flag's consequence, and what the response conveys. It could say more about what the removal destroys (e.g. attendance/booking record) or required permissions, but it is largely sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description goes slightly beyond the schema by framing is_late_cancel as something that can trigger penalty rules and should be left unset by default, reinforcing the safe default rather than merely restating the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource ('Cancel a customer's booking for a class or appointment') and names the exact API operation (POST /events/{id}/unregister). It is immediately distinguishable from the inverse sibling goteamup_register_customer_for_event.
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 conditional guidance for is_late_cancel ('leave it unset unless asked') and describes the consequence of setting it. It doesn't explicitly name register_customer_for_event as the inverse alternative, but the context is clear enough for an agent to act on.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
goteamup_confirm_attendance1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"goteamup_create_customer1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"goteamup_get_authenticated_application1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"goteamup_get_customer1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"goteamup_get_customer_membership1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"goteamup_get_event1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"goteamup_get_invoice1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"goteamup_list_attendances1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"goteamup_list_crm_interactions1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"goteamup_list_customer_memberships1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"goteamup_list_customers1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"goteamup_list_events1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"goteamup_list_instructors1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"goteamup_list_invoices1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"goteamup_list_memberships1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"goteamup_list_offering_types1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"goteamup_list_venues1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"goteamup_log_crm_interaction1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"goteamup_register_customer_for_event1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"goteamup_unregister_customer_from_event1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"goteamup_confirm_attendancegoteamup_create_customergoteamup_get_authenticated_applicationgoteamup_get_customergoteamup_get_customer_membershipgoteamup_get_eventgoteamup_get_invoicegoteamup_list_attendancesgoteamup_list_crm_interactionsgoteamup_list_customer_membershipsgoteamup_list_customersgoteamup_list_eventsgoteamup_list_instructorsgoteamup_list_invoicesgoteamup_list_membershipsgoteamup_list_offering_typesgoteamup_list_venuesgoteamup_log_crm_interactiongoteamup_register_customer_for_eventgoteamup_unregister_customer_from_eventRead Mindbody classes, schedules, clients, staff and sales; book clients and appointments.
Look up Momence members, class schedules, bookings and memberships, and handle front-desk actions.
Check Bookeo availability and manage bookings, holds and customers; read payments.
Look up members, events, registrations, invoices and payments, and add contacts or check in guests.
Add one secure layer between your agents and this server.