Server Quality Checklist

Tool Scores

• signupgenius_list_created_expiredB
  3/5.0
  Behavior4/5

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

  The description adds useful behavioral disclosure beyond the readOnlyHint annotation by stating that v3 returns active and expired records together, and that client-side filtering on enddate is necessary. This is valuable because it warns the agent that the tool does not actually return only expired signups despite the name.

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

  Conciseness5/5

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

  The description is a single concise sentence that is front-loaded with the alias relationship and then explains the v3 behavior and filtering requirement. Every phrase carries meaningful information, with no wasted words.

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

  Completeness2/5

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

  Although there are no parameters and a readOnly annotation, the description is incomplete because it never explicitly states what the tool returns. It relies on the agent already knowing what signupgenius_list_created_active does, and there is no output schema to fall back on. The agent is left without a clear understanding of the list structure or return behavior.

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

  Parameters4/5

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

  The input schema has zero parameters, so per the rubric the baseline is 4. The description does not need to add parameter details because there are none to explain.

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

  Purpose2/5

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

  The description does not clearly state what the tool does. It calls it an 'alias of signupgenius_list_created_active', which is ambiguous and does not differentiate it from other siblings. The name implies it lists expired created signups, but the description says v3 returns active + expired together, making the purpose confusing rather than specific.

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

  Usage Guidelines2/5

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

  There is no guidance on when to use this tool versus alternatives such as signupgenius_list_created_active or signupgenius_list_created_all. The only operational note is 'Filter on enddate client-side', which is a filtering instruction rather than a usage guideline.

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

• signupgenius_list_signedupforA
  3.5/5.0
  Behavior3/5

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

  The readOnlyHint annotation already marks the tool as read-only, and the description aligns with that by saying 'List'. The additional phrase 'personally signed up for' adds slight contextual scope but no deeper behavioral traits such as return format, pagination, or authentication requirements. This is consistent with the annotations and adds only marginal value.

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

  Conciseness5/5

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

  The description is a single, concise sentence that is front-loaded with the action. It contains no redundant or filler content, making it appropriately sized for a zero-parameter tool.

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

  Completeness4/5

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

  For a zero-parameter, read-only listing tool with no output schema, the description is largely complete. It clearly states what the tool returns. However, it does not clarify the difference from the legacy 'get_my_signups' sibling, leaving a small ambiguity in context.

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

  Parameters4/5

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

  The input schema is empty, so there are no parameters to describe. The baseline for zero parameters is 4, and the description correctly makes no claim about parameters. No additional semantic information is needed.

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

  Purpose4/5

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

  The description uses a specific verb ('List') and resource ('sign-ups the user has personally signed up for'), clearly indicating the tool's function. It differentiates from related sibling tools like signupgenius_list_invited and signupgenius_list_created by specifying the user's own sign-ups, but does not explicitly distinguish from the similar signupgenius_legacy_get_my_signups.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives. There is no mention of prerequisites, use cases, or exclusions. Given the presence of several similar list tools, the lack of usage direction is a notable gap.

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

• signupgenius_list_created_activeA
  3.6/5.0
  Behavior4/5

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

  The description adds useful behavioral context beyond the readOnlyHint annotation by revealing that session mode returns the full list instead of just active ones, and suggests client-side filtering. This discloses an unexpected behavior and helps the agent avoid misinterpreting the tool's name.

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

  Conciseness5/5

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

  The description is two sentences: the first states the core purpose, the second provides a necessary caveat. It is concise, front-loaded, and contains no filler.

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

  Completeness3/5

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

  The description explains session mode behavior but is silent on non-session mode and how this tool differs from siblings like list_created_all and list_created_expired. Without an output schema, the return format is unspecified, leaving the agent with incomplete context for correct usage.

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

  Parameters4/5

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

  The input schema is empty (0 parameters), so the description has no parameter details to add. Per the baseline for 0 params, a score of 4 is appropriate.

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

  Purpose3/5

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

  The description clearly states the tool lists sign-ups created by the authenticated user, but the 'active' aspect is ambiguous: it says 'In session mode this returns the full list (active + expired)', which contradicts the tool's name suggesting an active-only filter. It doesn't clearly distinguish from sibling tools like list_created_all or list_created_expired.

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

  Usage Guidelines3/5

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

  The description gives a usage hint for session mode (returns full list, filter client-side for active), but it doesn't explicitly say when to choose this tool over alternatives like list_created_all or list_created_expired. The guidance 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.

• signupgenius_get_group_memberA
  3.9/5.0
  Behavior4/5

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

  The annotation already provides readOnlyHint=true, but the description adds useful behavioral context: data availability is conditioned on whether the member provided it via a sign-up. This warns the agent that fields may be absent or missing, which goes beyond the annotation. It does not contradict the read-only annotation.

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

  Conciseness5/5

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

  The description is a single concise sentence, front-loaded with the verb and resource, followed by clarifying detail. It contains no filler or redundant information, making it easy to parse quickly.

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

  Completeness4/5

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

  For a simple read-only operation with no output schema, the description adequately covers the function and return fields. It notes the condition for data availability. However, it could be slightly more explicit about edge cases (e.g., what happens if the member did not provide the info), so it stops short of a perfect score.

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

  Parameters2/5

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

  The schema documents memberId with a description, but groupId has no description. The description text does not clarify groupId or add any parameter meaning beyond the schema, so it fails to compensate for the 50% coverage gap. It mentions return fields, but not the parameters themselves.

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

  Purpose5/5

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

  The description clearly states the tool's function: retrieving detailed info for a group member, listing specific fields (address, phone, email). The verb 'Get' plus resource 'group member' distinguishes it from siblings like list_group_members, which lists members, and get_profile, which targets a different entity. The condition 'when the member has provided it via a sign-up' further scopes the operation.

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

  Usage Guidelines3/5

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

  The description implies usage: use this when you need detailed contact info for a single member, especially if they provided it via a sign-up. However, it does not explicitly name alternatives or state when not to use it, such as comparing with signupgenius_list_group_members for a list of members. This is only implicit guidance, not explicit differentiation.

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

• signupgenius_list_invitedA
  4/5.0
  Behavior3/5

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

  Annotations already indicate readOnlyHint=true, and the description's 'List' is consistent with that. However, the description adds no extra behavioral context (e.g., whether only pending invitations are listed, return format, or other nuances). It does not contradict annotations, but provides no additional transparency beyond them.

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

  Conciseness5/5

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

  The description is a single, clear sentence that immediately states the purpose. It is front-loaded and contains no unnecessary words or filler. Every word earns its place.

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

  Completeness4/5

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

  Given the simple nature of the tool (no parameters, no output schema), the description is adequate. It clearly defines what the tool lists. The only minor gap is not clarifying the distinction from similar sibling tools, but that is more of a usage guideline issue. The core function is sufficiently described.

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

  Parameters4/5

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

  The tool takes zero parameters, so the schema fully covers them (100% coverage). The baseline for zero parameters is 4, and the description does not need to explain parameter semantics since there are none. No additional meaning is required.

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

  Purpose5/5

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

  The description clearly states the verb ('List') and the resource ('sign-ups the user has been invited to'). This directly distinguishes it from sibling tools like 'signupgenius_list_signedupfor' (sign-ups the user registered for) and 'signupgenius_list_created_active' (sign-ups the user created).

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

  Usage Guidelines3/5

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

  While the meaning implies when to use it (when the user wants to see invitations), there is no explicit guidance on when not to use it or which alternative to choose. Given the close sibling 'signupgenius_list_signedupfor', the usage context is only implied rather than clearly differentiated.

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

• signupgenius_report_availableA
  4/5.0
  Behavior4/5

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

  Beyond the readOnlyHint annotation, the description discloses important behavioral traits: it requires a Pro subscription with a user key and does not support session mode. This is valuable operational context that the annotation does not convey. It does not contradict the read-only hint and adds meaningful constraints for the agent to consider before invocation.

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

  Conciseness5/5

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

  The description is a single concise sentence, front-loaded with the primary purpose ('restricted to slots that are still open/empty') followed by the key requirement. It contains no fluff or redundancy, making it easy to parse quickly.

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

  Completeness4/5

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

  Given the tool's simplicity (single parameter, read-only, no output schema), the description provides sufficient information: what it does and the required auth setup. It does not explain the return format, but the absence of an output schema and the straightforward nature of a report tool make this acceptable. The description is complete enough for the agent to understand the tool's role.

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

  Parameters3/5

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

  Schema description coverage is 100%, with signupId clearly described in the schema itself. The tool description does not add any additional parameter meaning or examples, but since the schema already fully documents the parameter, the baseline of 3 is appropriate.

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

  Purpose5/5

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

  The description clearly states that the tool reports slots that are still open/empty for a specific sign-up, using the resource ('sign-up') and the specific scope ('open/empty'). This distinguishes it from sibling tools like signupgenius_report_filled and signupgenius_report_all, which focus on filled or all slots respectively. The verb is implicit but unambiguous, given the tool name and description.

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

  Usage Guidelines3/5

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

  The description implies when to use this tool (when needing open slots) but does not explicitly mention alternatives or exclusions. It does provide a key precondition: requires SIGNUPGENIUS_USER_KEY (Pro subscription) and no session mode, which is practical guidance. However, it lacks direct 'when-to-use vs. alternative' language, so it earns a middle score.

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

• signupgenius_list_created_allA
  4.2/5.0
  Behavior3/5

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

  The annotation readOnlyHint=true already signals a safe read operation. The description adds the context that both active and expired sign-ups are included, which is helpful but doesn't disclose other behaviors like pagination or return format. Given the simple nature of the tool and the annotation, this is adequate but not rich.

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

  Conciseness5/5

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

  The description is a single, focused sentence that immediately states the verb, resource, and scope. It contains no filler or redundant information.

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

  Completeness4/5

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

  For a simple list-all tool with no parameters and readOnlyHint annotation, the description provides sufficient context for selection and invocation. It doesn't mention return format or ordering, but such details are not critical for this tool's simplicity.

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

  Parameters4/5

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

  The tool has zero parameters and an empty input schema, so there are no parameter details to explain. The baseline for 0 params is 4, and the description does not need to compensate since there is nothing to clarify.

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

  Purpose5/5

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

  The description clearly states the tool lists ALL sign-ups created by the authenticated user, explicitly including both active and expired. This distinguishes it from sibling tools like list_created_active and list_created_expired, which have narrower scopes.

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

  Usage Guidelines4/5

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

  The description's mention of 'ALL' and 'active and expired' implicitly tells the agent to use this tool when needing the full set of sign-ups, versus status-specific siblings. However, it does not explicitly name alternatives or state when not to use, so it's clear but not fully explicit.

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

• signupgenius_list_group_membersA
  4.2/5.0
  Behavior4/5

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

  The readOnlyHint annotation already marks this as a safe read operation, and the description's 'List' is consistent with that. The description adds useful context by specifying the returned fields ('name, email, memberid'), which is not present in the schema. No contradictions.

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

  Conciseness5/5

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

  The description is a single sentence that front-loads the action and resource, contains no filler, and effectively conveys the tool's purpose and return content.

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

  Completeness4/5

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

  For a simple list tool with one required parameter and a readOnly annotation, the description adequately covers the action, resource, and return fields. It omits sort/pagination behavior, but the schema documents sort and the operation is low-complexity, so the lack of extra detail is acceptable.

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

  Parameters3/5

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

  The schema already documents groupId with a reference to signupgenius_list_groups and sort with an enum, covering 50% of parameters with descriptions. The description adds minimal parameter-level meaning beyond reinforcing that groupId refers to a group, so the schema carries most of the semantic load.

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

  Purpose5/5

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

  The description uses the specific verb 'List' with the resource 'members of a SignUpGenius group' and indicates the basic fields returned (name, email, memberid). This clearly distinguishes it from sibling signupgenius_get_group_member, which targets a single member.

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

  Usage Guidelines4/5

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

  The description provides a clear use case: when you need to list members of a group. It does not explicitly mention alternatives or exclusions, but the context is unambiguous and directly implies when to invoke this tool.

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

• signupgenius_list_groupsA
  4.2/5.0
  Behavior4/5

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

  The description adds value beyond the readOnlyHint annotation by explicitly stating that it returns groupid, title, and member count for each group. It also clarifies the scope (created by the authenticated user). No contradictions with annotations exist.

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

  Conciseness5/5

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

  The description is two concise sentences, with the main action front-loaded. The first sentence states the purpose, and the second gives return value details. No words are wasted.

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

  Completeness4/5

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

  Given that there is no output schema, the description appropriately lists the return fields. The tool has only one optional param and a readOnly annotation, so the description is sufficient for a simple list tool. A minor gap is lack of pagination or default sort behavior, but this is not critical for expected usage.

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

  Parameters3/5

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

  Schema description coverage is 100%, with the single 'sort' parameter fully documented in the schema (enum asc/desc and description). The description adds no additional parameter info, so the baseline of 3 applies.

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

  Purpose5/5

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

  The description clearly states the tool lists groups created by the authenticated user, specifies the resource (groups) and the action (list), and clarifies the scope. It distinguishes itself from sibling tools like list_group_members and get_group_member by focusing on the group collection itself, not members.

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

  Usage Guidelines4/5

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

  The description provides clear context for when to use the tool: when listing groups owned by the authenticated user. It does not explicitly mention alternatives, but the scope is well-defined and no exclusions are needed. The sibling names themselves differentiate this from signup/report tools.

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

• signupgenius_report_filledA
  4.2/5.0
  Behavior4/5

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

  Beyond the readOnlyHint annotation, the description discloses that a specific API key is required and that session mode is unsupported for reports. This adds meaningful behavioral context not available from annotations alone, though it does not detail output structure 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.

  Conciseness5/5

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

  The description is a single concise sentence followed by a brief requirement clause. It front-loads the core purpose and avoids any filler or redundancy, earning a high score.

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

  Completeness4/5

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

  For a simple one-parameter report tool with readOnly annotation and clear purpose, the description covers essential context including auth requirements and session limitations. However, since there is no output schema, it would benefit from explicitly stating what the report returns, but the tool's purpose makes this reasonably inferable.

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

  Parameters3/5

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

  The schema already thoroughly describes the only parameter (signupId) with type and description, providing 100% coverage. The tool description adds no additional parameter information, so the baseline score of 3 is appropriate.

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

  Purpose5/5

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

  The description clearly states the tool's function: generating a report for a sign-up restricted to already-filled slots. This distinguishes it from sibling tools like report_available (available slots) and report_all (all slots), using a specific verb and resource.

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

  Usage Guidelines4/5

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

  The description provides clear context: it is for filled slots, implying this is the right tool when interested in filled slots. It also specifies a requirement (SIGNUPGENIUS_USER_KEY, Pro subscription) and a limitation (session mode not supported), though it does not explicitly name alternatives like report_available or report_all.

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

• signupgenius_add_group_memberA
  4.3/5.0
  Behavior4/5

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

  The description explicitly states 'Writes data' and adds a confirmation requirement, which is behavior beyond the readOnlyHint: false annotation. It also clarifies that first/last names are optional. It doesn't mention behaviors like duplicate handling or errors, but the confirmation instruction adds meaningful transparency for a write operation.

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

  Conciseness5/5

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

  The description is two sentences: the first states the action and optionality, the second provides the write/confirm warning. It is front-loaded, free of fluff, and every sentence earns its place.

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

  Completeness3/5

  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 and low schema parameter coverage, the description is adequate but leaves gaps. It covers the primary action and confirmation, but does not explain return values, error cases (e.g., duplicate email, invalid group), or idempotency. These would be valuable for an agent to invoke correctly and handle outcomes.

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

  Parameters4/5

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

  Schema coverage is only 25% (only emailaddress has a description). The description compensates by explaining the core semantic: the member is added by email address, and first/last names are optional. This adds meaning beyond the schema, though it does not detail groupId beyond its name, which is self-explanatory in context.

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

  Purpose5/5

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

  The description clearly states the action: 'Add a member to a SignUpGenius group by email address.' It specifies the resource (member/group), the method (email address), and optional parameters (first/last name). This distinguishes it from sibling read tools like list_group_members and get_group_member.

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

  Usage Guidelines4/5

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

  The description provides clear context: this is for adding members, and it explicitly warns 'Writes data — confirm with the user before invoking,' which serves as a usage guideline. It does not explicitly name alternatives or exclusions, but the action verb and resource make the intended use unambiguous relative to the read-only sibling tools.

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

• signupgenius_legacy_get_my_signupsA
  4.4/5.0
  Behavior4/5

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

  The description adds the meaningful constraint 'Session mode only', which is not captured in the annotations (readOnlyHint: true). It also references the specific endpoint, providing context about the underlying behavior. Since readOnlyHint already covers the read-only nature, the description adds supplementary behavioral context without contradicting annotations.

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

  Conciseness5/5

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

  The description is two concise sentences with the most important constraint ('Session mode only') front-loaded. It delivers purpose, endpoint reference, and usage guidance without any redundant content, making every sentence earn its place.

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

  Completeness5/5

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

  For a zero-parameter, read-only tool with no output schema, the description is sufficiently complete. It states what the tool does, when to use it, and a key behavioral constraint (session mode). The level of detail matches the tool's complexity.

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

  Parameters4/5

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

  The input schema has zero parameters, so the baseline is 4 per the rubric. The description doesn't need to explain parameters because there are none, and it does not introduce any misleading parameter-related statements.

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

  Purpose4/5

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

  The description clearly states the tool 'Returns the same sign-up listing the SignUpGenius wizard sees', identifying the specific resource and action. It also differentiates from siblings by noting it provides 'fuller data than signupgenius_list_created_*', which helps distinguish it from similar list tools, though the reference to a wildcard group is slightly less explicit than naming a specific sibling.

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

  Usage Guidelines5/5

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

  The description explicitly says 'Use when you want fuller data than signupgenius_list_created_* provides', giving clear when-to-use guidance. It also states 'Session mode only' as a prerequisite, effectively telling the agent when it is applicable. This is strong usage direction beyond simply describing the function.

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

• signupgenius_get_public_signupA
  4.5/5.0
  Behavior5/5

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

  Goes beyond the readOnlyHint/openWorldHint annotations by disclosing that it fetches the rendered page, returns a structured envelope with specific fields, and works without API credentials. This adds valuable context about behavior and requirements, with no contradiction with annotations.

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

  Conciseness5/5

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

  The description is three sentences, each earning its place: it states the action, lists output fields, and gives a concrete use case. No fluff or redundancy; information is front-loaded.

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

  Completeness5/5

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

  Given a single parameter, no output schema, and good annotations, the description is complete: it explains input, output structure, auth requirements, and when to use. The presence of many sibling tools is mitigated by the explicit public/no-auth framing and use-case sentence.

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

  Parameters3/5

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

  The input schema already covers the parameter fully (100% coverage), describing both full URL and slug formats. The description provides an example URL pattern, but this largely duplicates the schema description, so it adds minimal extra meaning beyond the structural definition.

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

  Purpose5/5

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

  The description explicitly states 'Look up a SignUpGenius sign-up by its public URL or slug' and lists the returned fields, making the tool's purpose unambiguous. It distinguishes itself from siblings like list_my_signups by emphasizing 'public', no auth, and the URL/slug input.

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

  Usage Guidelines4/5

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

  Provides clear guidance: 'Use this when the user pastes a sign-up link and asks what it is or when it is.' Also notes that no auth is required, which helps differentiate from authenticated-only sibling tools. However, it does not explicitly name alternatives or state when not to use it, preventing a perfect score.

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

• signupgenius_report_allA
  4.5/5.0
  Behavior5/5

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

  Annotations already declare readOnlyHint=true, and the description goes beyond that by detailing what the report contains (every slot, participant, custom-question answers) and disclosing authentication requirements (Pro key, no session mode). This adds substantial behavioral context without contradicting the annotations.

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

  Conciseness5/5

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

  The description is two sentences: the first delivers the core purpose, the second adds critical authentication requirements. Both sentences are information-dense with no filler, and the most important information is front-loaded.

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

  Completeness5/5

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

  Despite lacking an output schema, the description clearly explains what the report returns (every slot, participant, custom answers) and the necessary conditions for use (Pro key, no session mode). Given the tool's read-only nature and the presence of sibling tools for filtered reports, this description is complete enough for an agent to select and invoke it correctly.

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

  Parameters3/5

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

  There is only one parameter (signupId) and the schema description covers it fully with 'Sign-up ID (signupid).' The tool description adds no additional parameter semantics, but with 100% schema coverage, a baseline of 3 is appropriate.

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

  Purpose5/5

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

  The description clearly states 'Full report for a sign-up: every slot plus the participant who claimed it', which specifies the tool's exact purpose and scope. It distinguishes itself from sibling tools like signupgenius_report_available and signupgenius_report_filled by covering every slot, not just a subset.

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

  Usage Guidelines4/5

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

  The description provides clear context: it requires SIGNUPGENIUS_USER_KEY and a Pro subscription, and explicitly notes that session mode is not supported for reports. However, it does not explicitly compare with alternative report tools or state when to prefer this over report_available or report_filled, so it lacks explicit exclusion guidance.

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

• signupgenius_rsvpA
  4.6/5.0
  Behavior5/5

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

  The description goes beyond the annotation (readOnlyHint=false) by explicitly stating 'Writes data — confirm with the user before invoking,' making the write behavior clear. It also discloses the internal flow (PreProcessSignup → getSignupInfo → processSignUpFormHandler), adding valuable context not present in any structured field.

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

  Conciseness5/5

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

  The description is three sentences with no filler. It front-loads the core action ('RSVP'), then adds necessary scoping, a warning, and an exclusion. Every sentence contributes distinct information without redundancy.

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

  Completeness4/5

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

  The description covers the purpose, supported sign-up types, internal flow, and key limitation (no slot sign-ups). It also warns about write behavior. While it does not describe return values or error handling, for a simple RSVP action the coverage is strong; a small gap exists around expected success/failure response behavior, but this is not critical given the tool's simplicity.

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

  Parameters3/5

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

  The input schema already describes most parameters (6/8, ~63% coverage). The description adds context about the response parameter by linking it to Yes/No/Maybe buttons, but it does not elaborate on firstname/lastname or other parameter details beyond what the schema provides, so the added value is modest.

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

  Purpose5/5

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

  The description opens with a specific verb and resource: 'RSVP to a SignUpGenius sign-up,' clearly identifying the tool's action. It further distinguishes the tool by scoping it to Yes/No/Maybe-style sheets and explicitly excluding slot-based sign-ups, which differentiates it from sibling tools like signupgenius_get_signup_slots.

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

  Usage Guidelines5/5

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

  The description provides explicit when-not guidance by stating 'Slot-based sign-ups ... are NOT supported by this tool; a slot signup tool is a separate concern.' It also instructs to 'confirm with the user before invoking,' giving a clear prerequisite for use.

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

• signupgenius_get_profileA
  4.7/5.0
  Behavior5/5

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

  Beyond the readOnlyHint annotation, the description discloses that there are two distinct modes ('key mode hits /v2/k/user/profile; session mode hits /v3/member/profile'), which is significant behavioral context that affects invocation and interpretation. It also specifies the returned user attributes.

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

  Conciseness5/5

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

  The description is two sentences, front-loaded with the purpose, followed by usage guidance and endpoint details. Every sentence adds value with no redundancy or filler.

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

  Completeness5/5

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

  For a zero-parameter, no-output-schema tool, the description is complete: it states what it returns, suggests a use case, and clarifies the two endpoint modes. No critical information appears missing.

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

  Parameters4/5

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

  The tool has zero parameters, so the baseline is 4. The description adds no parameter details, but none are needed. It compensates by explaining what the profile contains, which is the output semantics.

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

  Purpose5/5

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

  The description clearly states the verb 'Get' and the specific resource 'SignUpGenius profile', listing the returned fields (name, email, member ID, subscription level). This distinguishes it from sibling tools focused on signups, reports, and groups.

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

  Usage Guidelines4/5

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

  Provides explicit usage context: 'Useful as a first call to confirm credentials.' It does not name alternatives, but the sibling tools are clearly about other domain objects, so the intended usage is clear. The key/session mode distinction adds practical guidance.

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

• signupgenius_get_signup_slotsA
  4.7/5.0
  Behavior5/5

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

  Beyond the readOnlyHint and openWorldHint annotations, the description discloses that participant names appear only when the endpoint publishes them and that each item reports the slot's 'hidenames' setting, which helps explain empty lists without implying access issues. It also explicitly states 'Requires NO auth', adding valuable behavior context.

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

  Conciseness5/5

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

  The description is three sentences, front-loaded with the primary purpose. Every sentence adds value: the first covers what slots include, the second provides usage guidance and alternatives, and the third explains a subtle behavior (hidenames). There is no fluff or repetition.

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

  Completeness5/5

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

  With only one parameter and no output schema, the description adequately explains what the tool returns (slot details, availability, hidenames) and how to handle conditional participant names. It also addresses edge cases about empty lists, making it complete for an agent to use correctly.

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

  Parameters3/5

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

  The input schema already provides 100% coverage, describing the parameter as a URL, slug, or numeric id with format details. The description repeats this ('given its URL, slug, or numeric id') but adds no new meaning beyond the schema, so a baseline score of 3 is appropriate.

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

  Purpose5/5

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

  The description uses a specific verb ('List') and clearly identifies the resource ('SLOTS') and scope ('any public SignUpGenius sign-up'), including the data fields (dates, times, locations, spots taken/remaining). It also distinguishes from sibling report tools by explicitly saying to use this instead of signupgenius_report_* for slot availability.

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

  Usage Guidelines5/5

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

  The description gives explicit usage context: 'Requires NO auth and works for sheets the user did not create' and provides a direct alternative ('use this instead of signupgenius_report_* whenever you need slot availability'). This clearly tells when to use this tool over similar ones.

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