Read Hello Club members, events, bookings and transactions; add members and charges.
Scored across 14 tools
Each tool maps to a distinct resource plus action; get vs list pairs are unambiguous (e.g., get_member vs list_members, get_event vs list_events). No two tools overlap in purpose, so an agent can select reliably.
Every tool follows the same hello_club_verb_noun snake_case pattern (list_/get_/create_). The convention is uniform across all 14 tools with no deviations.
14 tools is well within the ideal 3-15 range and each earns its place covering members, events, transactions, bookings, check-ins, access logs and membership types. No redundant or filler tools.
The surface is heavily read-oriented with only two writes (create_member, create_transaction); there is no update or delete for members, transactions, events, bookings or membership types. Agents can read broadly but hit dead ends on modification workflows, making it a notably partial lifecycle.
WRITE: create a new member in the club (first and last name required; email, mobile, phone and gender optional). Creates a real member record in the club's database; it does not assign a membership or send an invoice. Not idempotent: calling twice creates two members, so search with hello_club_list_members first. POST /member.
| Name | Required | Description | Default |
|---|---|---|---|
| No | Email address. | ||
| phone | No | Other phone number. | |
| gender | No | Gender. | |
| mobile | No | Mobile phone number. | |
| last_name | Yes | Last name. | |
| first_name | Yes | First name. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false and idempotentHint=false, so the non-idempotency restatement adds little. The genuinely additive content is the side-effect boundary ('does not assign a membership or send an invoice') and the 'real member record' framing, which tells the agent the write is persistent and what it does not trigger.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the WRITE marker, then requirements, side-effect boundaries, the idempotency warning and the endpoint. Every clause carries distinct information and none is padding.
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 safety, side effects and duplicate risk well. It does not say what comes back from POST /member (e.g., the new member's identifier), which an agent chaining a follow-up get_member call would want, but that is a minor gap given annotations cover the safety profile.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and all six parameters are documented with types, lengths and an enum, so the schema carries the load. The description only restates which fields are required versus optional, adding no format or constraint 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 and resource ('WRITE: create a new member in the club') and immediately bounds the scope by saying it does not assign a membership or send an invoice. This lets an agent separate it from hello_club_create_transaction and membership-related siblings without opening a schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly directs the agent to call hello_club_list_members first to avoid duplicates, which is a concrete when-to-use instruction tied to the non-idempotent behavior. It stops short of naming when NOT to use it (e.g., for bulk import or for existing members), so it is strong but not exhaustive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
WRITE: create a financial transaction for a member (a charge, or a credit when is_credit is true), e.g. an invoice line or a manual adjustment. This changes the member's amount owing / account credit in the club's books and, with notify_by_email, emails the member. Not idempotent: calling twice creates two transactions. Confirm member, amount and type with the user first. POST /transaction.
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | Transaction date (default: now). | |
| type | Yes | Transaction type (use 'other' for a manual charge). | |
| amount | Yes | Amount in the club's currency, a positive number (tax inclusive). | |
| details | Yes | Description shown on the invoice. | |
| due_date | No | Payment due date. | |
| is_credit | No | True = a credit to the member instead of a charge (default false). | |
| member_id | Yes | Member the transaction is for. | |
| notify_by_email | No | Email the member about this transaction (default false). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already flag readOnly=false, destructive=true and idempotent=false, and the description adds genuinely new context on top: what actually changes (the member's amount owing / account credit in the club's books), the emailing side effect of notify_by_email, and the concrete consequence of non-idempotency ('calling twice creates two transactions'). It also surfaces the human-confirmation requirement, which no annotation conveys.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the operation verb and scope in the first clause, and each subsequent sentence adds distinct information (side effect, email, idempotency, confirmation, endpoint). The trailing 'POST /transaction.' is the only near-redundant element, but the rest is dense and waste-free.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive, non-idempotent write tool with no output schema and 8 parameters, the description covers the mutation's effects, the confirmation gate and non-idempotency, which is what an agent most needs. It stops short of telling the agent what is returned (e.g. whether a transaction ID comes back) so the agent can chain into get_transaction, which is the only notable 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%, including the is_credit, type, amount and notify_by_email definitions, so the schema already carries parameter meaning. The description restates is_credit's charge/credit duality and notify_by_email's email behavior but adds no new syntax, constraints or formats beyond what the schema documents - 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 ('create a financial transaction for a member') and immediately clarifies the two concrete variants: a charge, or a credit when is_credit is true, with examples (invoice line, manual adjustment). The 'WRITE:' prefix and the nature of the operation distinguish it cleanly from read siblings like hello_club_list_transactions and hello_club_get_transaction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives a clear precondition ('Confirm member, amount and type with the user first') and the context in which the tool applies (posting charges or credits to a member's account). It implies rather than states the split from read siblings - it never explicitly names list/get_transaction as the read-only alternatives - so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
One event by id: dates, recurrence, activity, area, organiser, capacity, attendance rules, questions. GET /event/{id}.
| Name | Required | Description | Default |
|---|---|---|---|
| event_id | Yes | Event id - find it with hello_club_list_events. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark this as a safe read (readOnlyHint=true, destructiveHint=false, openWorldHint=true). The description adds the endpoint and lists the returned fields, which is useful because there is no output schema, but it omits auth needs, error behavior, and any caveats for a missing event.
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 compact sentence front-loads the resource/cardinality and then lists the payload, followed by the HTTP endpoint. There is no filler and every clause contributes.
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 one-parameter read tool with annotations and no output schema, listing the returned fields and endpoint is largely sufficient. It could mention not-found behavior or auth, but 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 coverage is 100% and the single event_id parameter is fully documented in the schema, including how to obtain it. The description adds only "by id" and therefore meets the baseline without adding parameter syntax or format detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific retrieval action ("One event by id") and enumerates the event data returned, so the agent knows this is a single-record fetch rather than a list. It does not explicitly contrast with sibling hello_club_list_events, but the resource and cardinality are clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when an event id is known but gives no explicit when-to-use guidance, prerequisites, or alternatives. The schema's event_id note mentions hello_club_list_events, but the description itself does not route the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
One member by id: profile, contact details, roles, subscriptions, account credit, amount owing, custom fields. Password hashes and payment-provider data are not returned. GET /member/{id}.
| Name | Required | Description | Default |
|---|---|---|---|
| member_id | Yes | Hello Club member id (24 hex characters) - find it with hello_club_list_members. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnlyHint=true, destructiveHint=false), so the bar is lower. The description still adds real value by disclosing that password hashes and payment-provider data are excluded from the response, a data-exposure fact the annotations cannot express.
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 fragments: the highest-value content (what is returned) comes first, the exclusion note second, the endpoint last. Every clause carries information; there is no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-entity read with no output schema, enumerating the returned fields substitutes well for a return-value spec, and the exclusion clause covers the obvious privacy question. What is missing is any statement of error behavior for a bad or unknown member_id.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the single parameter is fully documented (24-hex pattern plus a pointer to hello_club_list_members for discovery). The description adds nothing about member_id beyond the schema, 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?
Names a specific verb and resource ('One member by id') and then enumerates the exact payload returned: profile, contact details, roles, subscriptions, credit, amount owing, custom fields. That enumeration makes it unmistakably distinct from hello_club_list_members and the other get_* siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied: 'one member by id' signals fetch-single, and the endpoint string GET /member/{id} confirms it. It never explicitly says when to use this instead of hello_club_list_members or what to do if the id is unknown (that routing hint lives only in the schema's parameter description, not the tool description).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
One membership type by id. GET /membership/{id}.
| Name | Required | Description | Default |
|---|---|---|---|
| membership_id | Yes | Membership type id. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds no behavioral context beyond that — no mention of what happens on a missing id, auth requirements, or error behavior. The restated 'GET /membership/{id}' is structural repetition, not added transparency.
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 fragments, front-loaded with the resource identity. It is efficient, though the trailing endpoint restatement is arguably redundant rather than earning 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 tool with full schema coverage, annotations and no output schema, the basics are covered. However, it does not describe the shape of the returned membership type or failure modes, leaving a small gap an agent would need to discover by calling.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the single membership_id param is fully documented with a pattern in the schema. The description adds no syntax or format detail beyond that, so the baseline 3 applies when the schema does all the work.
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 resource (membership type) and scope (one, by id), which distinguishes it from the sibling hello_club_list_membership_types. The verb is only implied via the name, but the singular 'one ... by id' makes the intent 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 'by id' phrasing implies usage (lookup of a single record), but there is no explicit when-to-use guidance and no alternative tool is named. The distinction from list_membership_types is left for the agent to infer.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
One transaction by id: member, type, amount, tax, details, dates, paid state. GET /transaction/{id}.
| Name | Required | Description | Default |
|---|---|---|---|
| transaction_id | Yes | Transaction id - find it with hello_club_list_transactions. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. With that lower bar, the description contributes the returned field set (member, type, amount, tax, details, dates, paid state), which is useful since there is no output schema, but it discloses nothing about permissions, rates, 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 compact clauses, with the identity/scope statement front-loaded and the HTTP path trailing as supplementary detail. No filler, though the raw endpoint string is of marginal value to an agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter read-only lookup this covers identity, scope and the returned fields, compensating for the absent output schema. It is missing only discovery guidance and any note on lookup failure, which keeps it short of a 5.
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?
Single parameter with 100% schema coverage, including a pattern and a pointer to hello_club_list_transactions for obtaining ids. The description's 'by id' adds nothing 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 (get) and resource (transaction) and pins the scope to a single record by id, which cleanly separates it from hello_club_list_transactions. It does not name the sibling alternative in the description text, so it stops short of full differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'by id' implies the fetch-a-known-entity use case, and the schema parameter points at hello_club_list_transactions for discovery of ids. No explicit when-to-use/when-not statement appears in the description itself.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List door / access-control logs in a date range: member, door, event, whether it was an override or an unknown person. GET /accessLog.
| Name | Required | Description | Default |
|---|---|---|---|
| door | No | Only entries for this door id. | |
| limit | No | Results per page, 1-100 (default 25). | |
| fields | No | Only return these fields of each item (e.g. ["id","firstName","lastName","email"]). Smaller replies are faster. | |
| offset | No | Number of results to skip (default 0). Pass the previous reply's next_offset. | |
| to_date | Yes | End of the range (required). | |
| event_id | No | Only entries for this event. | |
| from_date | Yes | Start of the range (required). | |
| member_id | No | Only entries of this member. | |
| is_unknown | No | Only unknown people (true). | |
| is_override | No | Only manual overrides (true). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description contributes the underlying endpoint (GET /accessLog) and the shape of a log entry, but says nothing about pagination behavior, result volume, or rate limits despite exposing limit/offset.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single compact sentence that front-loads the verb and resource and then enumerates the entry contents; the trailing 'GET /accessLog' is a small but useful anchor. The comma-delimited list is slightly dense but nothing is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 10-parameter read-only list tool with full schema coverage and safety annotations, the description supplies enough to call it correctly, and no output schema means return values need not be explained. Only the omission of pagination context is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so every filter (door, event_id, member_id, is_unknown, is_override, limit, offset, fields) is already documented. The description restates what the entries may contain but adds no format, syntax, or default details 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?
The description gives a specific verb and resource ('List door / access-control logs') plus the scope ('in a date range') and the content of each entry (member, door, event, override, unknown person), which clearly separates it from sibling list tools like list_check_ins or list_members. It stops short of explicitly naming or contrasting any 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 only implied by the phrase 'in a date range'; there is no statement of when to prefer this over list_check_ins or other log/listing tools, and no mention of prerequisites or when not to use it. An agent must infer the routing decision from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List resource bookings (courts, rooms, lanes): owner, activity, area, start/end, paid state, recurrence. Filter by date range, member, activity, mode, area, recurring, paid or removed. GET /booking.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Results per page, 1-100 (default 25). | |
| fields | No | Only return these fields of each item (e.g. ["id","firstName","lastName","email"]). Smaller replies are faster. | |
| offset | No | Number of results to skip (default 0). Pass the previous reply's next_offset. | |
| search | No | Free-text search. | |
| area_id | No | Only bookings of this area. | |
| is_paid | No | Only paid (true) or unpaid (false) bookings. | |
| mode_id | No | Only bookings of this mode. | |
| to_date | No | Bookings up to this date (use together with from_date). | |
| from_date | No | Bookings from this date on (use together with to_date). | |
| member_id | No | Only bookings that include this member. | |
| is_removed | No | Only removed (true) or active (false) bookings. | |
| activity_id | No | Only bookings of this activity. | |
| is_recurring | No | Only recurring bookings (true) or one-off bookings (false). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnlyHint=true, destructiveHint=false, openWorldHint=true), so the bar is lower. The description adds genuinely useful context beyond that: the shape of returned records (owner, activity, area, start/end, paid state, recurrence) and the fact that removed bookings can be surfaced via a filter. It does not discuss pagination behavior, which the schema partly covers.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two compact sentences plus the endpoint: the purpose and returned fields are front-loaded, then the filter surface, with no filler. Every clause carries content 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 13-parameter, no-required-param list tool with no output schema, the description compensates by describing the returned record fields and the available filters. It is slightly thin on pagination/response shape, though the schema's limit/offset/next_offset descriptions partially cover that.
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; the description mostly restates the filter dimensions (member, activity, area, mode, recurring, paid/removed) without adding syntax or semantics. Baseline 3 is appropriate 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 and resource ('List resource bookings') and immediately disambiguates what a booking is with '(courts, rooms, lanes)', distinguishing it from siblings like list_check_ins, list_access_logs, or list_events. It also enumerates the fields returned and pins the underlying endpoint (GET /booking), so an agent knows exactly what it is.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description says what can be filtered ('date range, member, activity, mode, area, recurring, paid or removed'), which implies the read/filter use case, but it never states when to reach for this tool versus list_check_ins or list_access_logs, nor any prerequisite. Usage is inferable but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List check-in logs (members arriving at the club): who, when, how (type). Filter by member or type, or only unknown people. GET /checkInLog.
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | Check-in type (as recorded by the club). | |
| limit | No | Results per page, 1-100 (default 25). | |
| fields | No | Only return these fields of each item (e.g. ["id","firstName","lastName","email"]). Smaller replies are faster. | |
| offset | No | Number of results to skip (default 0). Pass the previous reply's next_offset. | |
| search | No | Free-text search. | |
| member_id | No | Only check-ins of this member. | |
| is_unknown | No | Only check-ins of unknown people (true). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is fully covered without the description. The description adds the endpoint (GET /checkInLog) and the log content, but says nothing about pagination behavior, result ordering, or rate limits — useful context for a 7-param paged list, but not required given the annotation coverage.
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 plus the endpoint reference; the core purpose is front-loaded and every clause carries information (entity, meaning, return facets, filters). No filler or redundant restatement of the title.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only, filter-and-page list operation with a fully documented 7-param schema and no output schema, the description covers purpose, the main filters, and roughly what each record contains. The remaining gap is minor: no note on result ordering or how pagination should be driven across 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%, so every one of the 7 parameters is already documented in the schema with limits, defaults and patterns. The description only restates the filtering intent for member_id, type and is_unknown and adds no syntax, format or constraint detail 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?
Specific verb+resource ('List check-in logs') with a parenthetical clarifying what a check-in means (members arriving) and a hint of the returned shape (who, when, how). It is clear on its own, but among siblings it never distinguishes itself from the nearby hello_club_list_access_logs, which an agent could easily confuse it with.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It states what can be filtered ('by member or type, or only unknown people'), which implies the common usage patterns, and the raw GET endpoint hints at the underlying API semantics. However, it gives no when-to-use context, no prerequisites, and no guidance on when to prefer access logs or member endpoints over this one.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List who is signed up to events: member or guest, event, sign-up date, paid state, whether they attended. Filter by event, member or guest. GET /eventAttendee.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Results per page, 1-100 (default 25). | |
| fields | No | Only return these fields of each item (e.g. ["id","firstName","lastName","email"]). Smaller replies are faster. | |
| offset | No | Number of results to skip (default 0). Pass the previous reply's next_offset. | |
| event_id | No | Only attendees of this event. | |
| guest_id | No | Only attendances of this guest. | |
| member_id | No | Only attendances of this member. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds the set of returned attributes (paid state, attended), which is useful given no output schema, but discloses nothing about permissions, pagination behavior, 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?
Two tight sentences with the resource and returned fields front-loaded, followed by the filter axes. The trailing 'GET /eventAttendee' is mildly redundant with the endpoint context but harmless.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description usefully enumerates the fields an attendee record carries, and the schema covers pagination and filters. Complete enough to call correctly, though it omits any note on default ordering or result size.
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 limit, fields, offset and the three id filters. The description's 'filter by event, member or guest' merely restates the event_id/member_id/guest_id parameters without adding format or combination semantics; 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 who is signed up to events') and enumerates the returned data (member/guest, event, sign-up date, paid state, attendance). It is clearly distinct from list_check_ins and list_events, though it never names a 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?
'Filter by event, member or guest' gives the supported filtering axes, which implies usage, but there is no guidance on when to choose this over list_check_ins or get_event, and no 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 or search events and classes (sessions, courses, tournaments) with dates, activity, area, organiser, capacity and attendance rules. Filter by date range, recurring, hidden, public, has attendees, has spaces left, rule type, activity, area or organiser. GET /event.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Results per page, 1-100 (default 25). | |
| fields | No | Only return these fields of each item (e.g. ["id","firstName","lastName","email"]). Smaller replies are faster. | |
| offset | No | Number of results to skip (default 0). Pass the previous reply's next_offset. | |
| search | No | Free-text search. | |
| area_id | No | Only events in this area id. | |
| to_date | No | Events up to this date (use together with from_date). | |
| from_date | No | Events from this date on (use together with to_date). | |
| is_hidden | No | Only hidden events (true) or visible ones (false). | |
| is_public | No | Only public events (true) or member-only ones (false). | |
| rule_type | No | Only events with this attendance rule type. | |
| activity_id | No | Only events of this activity id. | |
| category_id | No | Only events in this category id. | |
| is_recurring | No | Only recurring events (true) or one-off events (false). | |
| organiser_id | No | Only events organised by this member id. | |
| has_attendees | No | Only events with at least one attendee. | |
| membership_id | No | Only events that can be attended with this membership type id. | |
| has_spaces_left | No | Only events that still have places left. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds the underlying endpoint ('GET /event') and the shape of returned content (dates, activity, area, organiser, capacity, attendance rules), but says nothing about pagination, result ordering, or rate limits beyond what the schema states.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two dense sentences with the purpose front-loaded and the filter inventory second; nothing is wasted. The long comma-separated filter clause is slightly list-like, but it is efficient 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 17-parameter read-only search tool with no output schema and full annotation coverage, the description supplies enough for an agent to understand scope and available filters. Only pagination and return-shape details are absent, and those are handled by 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% with 17 documented parameters, so the schema carries the parameter burden. The description's filter list largely restates those same parameters in prose and adds no extra syntax or semantics (e.g. how from_date/to_date combine, or how membership_id scoping works).
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 ('List or search') and resource ('events and classes'), and even disambiguates the domain by naming the subtypes (sessions, courses, tournaments). It never names a sibling tool, so the agent must infer that this is the plural/list counterpart to hello_club_get_event rather than being told.
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 every filter dimension available, which implicitly tells the agent this is the tool for filtered event discovery, but it offers no explicit when-to-use/when-not guidance and never points to alternatives such as hello_club_get_event for a single record or hello_club_list_event_attendees for attendance detail.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List or search the club's members (people and staff) with contact details, roles, memberships (subscriptions), account credit and amount owing. Filter by free text, gender, role, staff, money owing, account credit, current subscription state, ending subscriptions or a membership type. GET /member.
| Name | Required | Description | Default |
|---|---|---|---|
| role | No | Filter on role. | |
| limit | No | Results per page, 1-100 (default 25). | |
| fields | No | Only return these fields of each item (e.g. ["id","firstName","lastName","email"]). Smaller replies are faster. | |
| gender | No | Filter on gender. | |
| offset | No | Number of results to skip (default 0). Pass the previous reply's next_offset. | |
| search | No | Free-text search (name, email, member number...). | |
| is_staff | No | Only staff members (true) or only non-staff (false). | |
| membership_id | No | Membership type id (hello_club_list_membership_types), used together with one of the subscription filters. | |
| updated_since | No | Only members updated on or after this timestamp. | |
| has_money_owing | No | Only members with unpaid transactions (true) or without (false). | |
| signed_up_since | No | Sign-up date threshold. | |
| has_account_credit | No | Only members with account credit (true) or without (false). | |
| subscription_ended | No | Members whose subscription ended within the past hour/day/week/month/year. | |
| subscription_ending | No | Members whose subscription ends within the next hour/day/week/month/year. | |
| with_current_subscription | No | Only members with a current membership subscription. | |
| without_current_subscription | No | Only members without a current membership subscription. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is clear. The description adds the HTTP method (GET) and confirms return data, but does not disclose pagination behavior, rate limits, or authentication needs beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with purpose and filters in two tight sentences. The appended 'GET /member' is slightly redundant given annotations, but overall it is efficient and avoids 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?
With 16 parameters and no output schema, the description covers purpose and filters but omits key operational details: pagination (limit/offset), field selection (fields), and the fact that results are paginated (next_offset). This leaves gaps for effective 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 each parameter is fully documented in the schema. The description lists filter categories but adds no syntax, format, or inter-parameter nuance (e.g., how membership_id works with subscription filters) beyond the schema; baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb (list/search) and resource (club's members), and enumerates the return data (contact details, roles, memberships, etc.). It does not explicitly differentiate from siblings like hello_club_get_member or hello_club_list_transactions, but the purpose 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 implied: use this tool to list or search members with filtering. There is no explicit when-to-use vs alternatives (e.g., get_member for a single member) or guidance on when not to use it, leaving the agent to infer.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The membership types (plans) the club sells: name, fee, term, age limits, renewal rules and access. GET /membership.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds the endpoint and the shape of returned fields, but says nothing about pagination, result size, or whether the list is filtered by anything — modest added value on top of 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?
A single compact sentence that front-loads the resource and ends with the endpoint. Nothing wasted, though the field enumeration is a dense list rather than structured 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 zero-parameter, read-only list tool with no output schema, the description usefully enumerates the returned fields (name, fee, term, age limits, renewal rules, access), partially compensating for the missing output schema. Only pagination/ordering behavior is unaddressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so there is no parameter semantics burden; the baseline for a 0-param tool is 4. Nothing in the description misrepresents the (empty) input.
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 the specific resource ('membership types (plans) the club sells') and enumerates the fields it returns (name, fee, term, age limits, renewal rules, access), plus the underlying endpoint GET /membership. It is clearly a listing operation, but it does not explicitly distinguish itself from the sibling hello_club_get_membership_type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use guidance and no named alternative, despite a closely related sibling (hello_club_get_membership_type) that an agent could easily confuse with this one. The agent must infer that 'list' means 'all plans' versus the singular get.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the club's financial transactions (invoices, charges, credits): member, type, amount, tax, due and payment dates, paid state. Filter by member, type, paid, credit or a date range on date / dueDate / paymentDate. GET /transaction.
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | Transaction type. | |
| limit | No | Results per page, 1-100 (default 25). | |
| fields | No | Only return these fields of each item (e.g. ["id","firstName","lastName","email"]). Smaller replies are faster. | |
| offset | No | Number of results to skip (default 0). Pass the previous reply's next_offset. | |
| is_paid | No | Only paid (true) or unpaid (false) transactions. | |
| to_date | No | Up to this date (use together with from_date). | |
| from_date | No | From this date on (use together with to_date). | |
| is_credit | No | Only credit (true) or charge (false) transactions. | |
| member_id | No | Only transactions of this member. | |
| date_field | No | Which date from_date / to_date apply to (default date). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds the underlying endpoint ('GET /transaction') and confirms the filterable dimensions, but says nothing about pagination behavior (offset/next_offset), result caps, or ordering beyond what the schema already implies.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two dense sentences with no filler; the resource and its returned fields are front-loaded ahead of the filter list. Slightly list-heavy 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 usefully enumerates the fields a transaction returns, and annotations cover the safety profile; schema coverage is complete for all 10 params. What is missing is pagination/return-shape guidance (next_offset handling) for a list tool that can return many rows.
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 ten parameters are already documented in the schema, including the date_field enum that selects which date from_date/to_date apply to. The description restates the same filter set without adding format, default, or interaction detail beyond it, 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 club's financial transactions') and enumerates the record contents (invoices, charges, credits; member, type, amount, tax, dates, paid state). This clearly separates it from the singular hello_club_get_transaction and the mutating hello_club_create_transaction siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description tells the agent how to narrow results (filter by member, type, paid, credit, date range) which implies the tool's use case, but it never states when to prefer it over hello_club_get_transaction or hello_club_list_members, nor any exclusions or prerequisites. Usage is implied rather than guided.
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.
hello_club_create_memberhello_club_create_transactionhello_club_get_eventhello_club_get_memberhello_club_get_membership_typehello_club_get_transactionhello_club_list_access_logshello_club_list_bookingshello_club_list_check_inshello_club_list_event_attendeeshello_club_list_eventshello_club_list_membershello_club_list_membership_typeshello_club_list_transactionsRead Mindbody classes, schedules, clients, staff and sales; book clients and appointments.
Check classes, attendance, customers, memberships and invoices in TeamUp and register customers.
Read subscriptions, customers, charges, orders; skip charges, cancel or activate subscriptions.
Read ChurchSuite contacts, children, small groups, rotas, events and attendance; add contact notes.
Add one secure layer between your agents and this server.