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

Given that annotations only provide readOnlyHint=false (which means the tool writes data), the description goes beyond this by explicitly stating 'Writes data — confirm with the user before invoking.' This adds a caution about user confirmation and clearly indicates a mutation, which is important for an agent to know. It does not contradict the annotations; in fact, it reinforces the write operation.

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

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

The description is concise and front-loaded with the core purpose. It states the action, target, method, optional fields, and a clear warning in just two sentences. Every sentence adds value, and the structure is efficient.

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 relatively simple mutation tool with 4 parameters (2 required) and no output schema, the description covers the essential aspects: what it does, what it needs, and what side effects to expect. It does not specify return values or error handling, but the low complexity and lack of output schema mean that these are less critical. The explicit write warning adds to completeness.

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 schema description coverage is only 25%, and the only parameter with a description is 'emailaddress' (in the schema). Required parameters (groupId, emailaddress) are described by name, but groupId has no description beyond type and constraints. The description adds that first/last name are optional, but does not explain how these parameters are used or any additional semantics, leaving the agent to infer meaning.

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 action ('Add a member'), the resource ('SignUpGenius group'), the method (by email address), and notes that first/last name are optional. This distinguishes it from sibling tools like 'list_group_members' or 'get_group_member' which are read-only and require a member ID.

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 usage (add a member to a group) but does not explicitly state when to use this tool versus alternatives. It also does not mention any prerequisites, such as having the correct groupId or ensuring the email is not already in the group. The explicit warning to confirm with the user is helpful but not a full usage guideline.

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

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

Annotations only declare readOnlyHint=false and destructiveHint=false, but the description goes far beyond: it discloses that the tool WRITES data visible to the organizer, explains the confirmation prompt behavior (MCP_CONFIRM_MODE), and details the two-phase fallback where the first call writes nothing and returns a preview plus confirmToken, with only a repeat call submitting. This is exactly the behavioral context an agent needs to avoid accidental writes, and it is not derivable from 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?

Two sentences, with the core purpose and the critical write-warning front-loaded before the fallback mechanics and sibling routing. The confirmation concept is explained somewhat redundantly (prompt mention plus full fallback explanation), but given the real complexity of the two-phase flow, every sentence earns its place.

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

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

For a 9-parameter mutation tool with no output schema, the description covers the essentials: purpose, write-safety, confirmation protocol, phase-1 response contents (sheet, slot, identity, confirmToken), and the rsvp alternative. Minor gaps remain—failure modes like already-claimed slots or full sheets are not mentioned—but the critical agent-facing behavior is well covered.

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

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

Schema coverage is 67%, and the schema already provides rich descriptions for the most complex parameters: confirmToken's two-step protocol and customFields' requirement to mirror signupgenius_get_public_signup.customFields. The description adds the conceptual flow behind confirmToken but does not systematically compensate for the ~33% of parameters lacking schema descriptions. This is adequate but not exemplary.

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 opens with a specific verb+resource: 'Claim (sign up for) a slot on a slot-based SignUpGenius sheet.' It scopes the tool to slot-based sheets and differentiates it from signupgenius_rsvp for headcount sheets, and by naming the inverse sibling (release_slot exists) the claim semantics are unambiguous. An agent can immediately tell what this does and what it is not.

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 guidance is explicit: the description states when this tool applies (slot-based sheets) and names the exact alternative with its trigger condition ('For Yes/No/Maybe headcount sheets use signupgenius_rsvp instead'). It also reveals that slotitemid is obtained via signupgenius_list_slots in the schema, routing the agent to the prerequisite tool. Nothing is left to inference.

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

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

The readOnlyHint annotation already covers safety, and the description adds meaningful behavioral context by stating which fields are returned and that availability depends on the member having provided them via a sign-up. This goes beyond the annotation without contradicting it.

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 a single front-loaded sentence with no filler. Every clause adds useful information: the action, the resource, the fields, and the availability condition.

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-only lookup with two required parameters and no output schema, the description covers the essential return contents and data-availability caveat. It is slightly incomplete in not explaining groupId, but the overall context is sufficient for an agent to use the tool correctly in most cases.

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 50%, and the description does not meaningfully compensate for the undocumented groupId parameter. The memberId parameter is well-explained in the schema, but the description adds no details about what groupId represents or how it relates to group membership.

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 uses a specific verb ('Get detailed info') and a specific resource ('a group member'), and clearly enumerates the returned fields (address, phone, email). It also adds a scope condition ('when the member has provided it via a sign-up'), which distinguishes it from the sibling list_group_members and get_profile tools.

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 provides useful context about data availability, but it never explicitly says when to choose this tool over siblings like signupgenius_list_group_members or signupgenius_get_profile. The memberId schema description hints that the ID comes from list_group_members, but the tool description itself does not name alternatives or exclusions.

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

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

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.

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.

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.

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.

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.

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.

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

Annotations already mark the tool as read-only, and the description adds meaningful behavioral context beyond that: no SignUpGenius auth is required, it works on public sheets not created by the user, and it returns only metadata rather than slots. It does not contradict the annotations, though it could mention error cases or rate limits to reach a 5.

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

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

The description is compact and front-loaded: first sentence states the action and URL format, second summarizes the return payload and auth context, third routes to the sibling tool. Every sentence contributes essential information with no wasted words.

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-parameter read-only lookup with rich schema coverage cherry-picked details, this description is complete. It lists the returned metadata categories, clarifies authentication requirements, and points to the sibling for slot data, so an agent can invoke it correctly without additional information.

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 parameter description already explains the URL and slug format thoroughly. The tool description reinforces this with an example URL pattern, but it adds little semantic value beyond the schema, so a baseline 3 is appropriate.

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

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

Description starts with a specific verb and resource: 'Look up a SignUpGenius sign-up by its public URL or slug' and enumerates what metadata is returned. It also explicitly distinguishes itself from siblings by stating it returns metadata only and pointing to signupgenius_list_slots for dates/times.

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

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

The description gives clear when-to-use context: no auth needed and works for sheets the user did not create. It explicitly names the sibling alternative, signupgenius_list_slots, for date/time availability, which removes ambiguity about which tool an agent should select.

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

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

Annotations already declare readOnlyHint and idempotentHint, so the description's 'Read-only' statement adds little beyond that. However, it goes further by disclosing it never returns the credential itself, explains the diagnostic outputs (source, acceptance, round-trip time, plain-English hint), and the nature of the single authenticated request. This adds meaningful behavioral detail beyond the annotations, though it doesn't cover every edge case like rate limits or exact response format. With annotations present, this is solidly above baseline.

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 four sentences long, each adding distinct value: purpose, output details, read-only safety, and usage trigger. It's front-loaded with the core action, and there is no fluff or redundancy. Every sentence earns its place, making it an exemplar of concise, structured writing.

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, no-output-schema health-check tool, the description covers all essential aspects: what it does, what it reports, when to use it, and a safety guarantee. It doesn't leave an agent guessing about the tool's scope or limitations. The description is complete for its purpose, especially given the rich annotations that already convey read-only and idempotent behavior.

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 has zero parameters, so the schema covers everything (100% coverage trivially). The description correctly avoids discussing parameters since none exist. According to the rubric, 0 params gives a baseline of 4, and the description doesn't need to add anything. It appropriately focuses on behavior and output.

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 tool's purpose: it resolves the credential and makes an authenticated request to api.signupgenius.com, then reports diagnostics. It names the specific resource and action, and distinguishes itself from sibling tools by indicating it's for diagnosing failures ('Call this when a real tool fails'). This is explicit and unambiguous.

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

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

The description gives a clear when-to-use: 'Call this when a real tool fails and you want to know which hop broke.' This is explicit context but doesn't name alternatives or explicitly state when not to use it. However, the condition is clear enough that an agent can infer it's not for normal operations. It stops short of naming sibling tools as alternatives, so it earns a 4 rather than a 5.

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

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

The 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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

The annotation readOnlyHint=true already communicates that this is a safe read operation. The description adds that it returns only basic info, which is useful, but it does not mention pagination, limits, sort behavior, or any other operational caveats.

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 concise sentence states the action, resource, and output fields without any filler. It is front-loaded and easy to parse.

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 low-complexity read-only list tool, the description plus the groupId schema and sort enum are largely sufficient for invocation. It specifies the output fields, though it lacks details about sort semantics and sibling-tool differentiation.

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 schema documents groupId well but leaves sort as a bare enum with no explanation. The description does not mention sort or otherwise compensate for the 50% schema description coverage, so the agent must infer what sorting actually applies to.

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 uses a specific verb and resource—'List members of a SignUpGenius group'—and names the returned fields (name, email, memberid). This makes the tool's purpose clear, and it is distinguishable from listing groups, though it does not explicitly contrast with the sibling 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.

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

No guidance is given about when to use this tool versus get_group_member or add_group_member. The schema notes that groupId comes from signupgenius_list_groups, but the description itself provides no usage context or exclusions.

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

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

The readOnlyHint annotation already communicates safety, and the description adds useful behavioral context by specifying the return fields and the authenticated-user scope. It does not disclose pagination, ordering behavior, or rate limits, but for a simple read-only list tool this is acceptable.

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 a single, focused sentence that front-loads the action and resource, then states the return value. There is no redundant or filler content.

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-only listing tool with one optional enum parameter, the description covers the key information: scope, returned fields, and the fact that it lists groups. It does not mention sorting behavior explicitly or pagination, but the schema covers the parameter and the tool is low-complexity, so the description is nearly complete.

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

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

Schema description coverage is 100%: the sort parameter is fully documented with an enum and a description. The tool description does not add parameter detail, but the schema already carries that burden, so 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 uses a specific verb ('List'), names the resource ('groups'), and adds a clear scope ('created by the authenticated user'). It also lists the returned fields, which distinguishes it from sibling 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.

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

The description implies usage: call this when you need an overview of the user's groups. However, it does not explicitly contrast with sibling tools such as list_group_members, get_group_member, or list_created_all, so the agent has to infer when this tool is the right choice.

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

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

Annotations already 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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the description rightly focuses on added context: requiring NO auth, working on sheets the user did NOT create, and returning participant entries with quantity consumed. It also surfaces the per-slot request cost in the includeParticipants parameter, which helps agents plan calls. No mention of rate limits, but the disclosures go beyond the structured hints.

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

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

Three sentences with no filler: the first enumerates the rich output, the second covers accepted inputs and the no-auth/public property, and the third gives the use case. Important differentiators are front-loaded, and every sentence adds decision-relevant 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 read-only, public data-listing tool with three well-documented params and no output schema, the description is complete: it enumerates all output fields, states the input formats, clarifies auth/ownership constraints, and distinguishes from sibling tools. An agent has everything needed to invoke it correctly and interpret the result.

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 fully documents url, onlyAvailable, and includeParticipants, including the request-cost tradeoff. The description restates the accepted input formats (URL, slug, numeric id) but adds little beyond what the schema provides. The baseline 3 is appropriate because the schema carries the parameter documentation burden.

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

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

The description opens with a specific verb and resource ('List every SLOT'), then enumerates exactly what each slot contains, including date, times, title, location, capacity, availability counts, and participant details. It also differentiates itself from the owner-scoped Pro signupgenius_report_* tools by stating it works without auth and on sign-ups the user did not create.

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 explicitly states when to use this tool: for public sign-ups the user did not create, and specifically for answering 'what is still open?'. It also names the alternatives it is not, the Pro report tools, and explains their limitation (key-only AND owner-scoped), giving the agent a clear decision rule.

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

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

Annotations already mark this destructive, and the description goes well beyond them: it warns that the call "removes a real sign-up," requires user confirmation, and explains that in fallback mode the first call returns a preview plus confirmToken and only the repeated call actually withdraws. This is strong disclosure of non-obvious 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?

The destructive warning is front-loaded and every sentence carries necessary information about confirmation behavior. The second sentence is dense and somewhat run-on, but the complexity is justified by the two-step confirmation protocol it must explain.

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 write operation with no output schema, this description covers the essential context: what the tool does, that it mutates data, when confirmation is required, how the fallback token flow works, and the ownership restriction. An agent has enough to invoke it correctly and safely.

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 input schema already documents every parameter thoroughly, including the security restriction on memberId and the confirmToken protocol. The description adds flow context but does not add per-parameter meaning beyond what the schema provides, 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?

The description opens with a specific verb and resource: "Withdraw (give up) a slot the user previously signed up for." It clearly identifies the action and scope, and is easily distinguished from siblings like signupgenius_claim_slot or signupgenius_rsvp.

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 clearly says this is for a slot the user already signed up for and explicitly scopes it to the current user's own sign-up: "only withdraws the current user's own sign-up." It also gives precise confirmation guidance for both MCP confirmation-capable clients and the fallback flow, though it does not explicitly name an alternative tool to use instead.

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

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

Beyond the readOnlyHint annotation, the description discloses substantial behavioral context: the auth requirement (Pro subscription user key), the unsupported session mode, the scope limitation (only sheets the key-holder created), and the inclusion of custom-question answers when present. No contradiction with the readOnlyHint annotation.

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

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

Three sentences, each earning its place: core purpose front-loaded first, then auth/scope constraints, then alternative routing. Zero filler or repetition of schema content.

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 explains the return content (slots, participants, custom-question answers) and fully discloses auth, scope, and session restrictions. Only minor gap: no mention of error behavior when given a signupId not owned by the key-holder, but this is well-covered by the explicit scope warning.

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 the signupId parameter already documented as 'Sign-up ID (signupid).' The description doesn't add parameter-specific syntax or formatting detail, but the baseline of 3 applies because the schema fully carries the parameter documentation burden.

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

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

The description opens with a specific verb+resource: 'Full report for a sign-up' and details exactly what it returns ('every slot plus the participant who claimed it, with custom-question answers when present'). This content distinguishes it sharply from siblings like signupgenius_report_available and signupgenius_report_filled, which clearly cover filtered subsets, as well as signupgenius_list_slots.

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?

Explicit when-to-use and when-not-to-use guidance: the description states this tool requires the Pro SIGNUPGENIUS_USER_KEY and only covers sheets the key-holder created, then explicitly routes agents to signupgenius_list_slots for slot dates/times/availability on any sign-up, noting that alternative 'needs no auth.' Nothing is left to inference.

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

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

Annotations only declare readOnlyHint=true, so the description adds valuable behavioral context: auth requirements, scope limitation to key-holder-created sheets, and unsupported session mode. It doesn't describe output format or pagination, but for a read-only report with these constraints, the added detail is strong.

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

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

Two sentences, front-loaded with the core purpose, then constraints and an explicit alternative. Every clause earns its place with 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-parameter read-only tool with no output schema, the description covers purpose, prerequisites, scope limits, and the recommended alternative. The only minor gap is not specifying the exact deliverable (e.g., columns of the report), but the phrase 'slots that are still open/empty' sufficiently sets expectations.

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 signupId parameter is already described in the schema as 'Sign-up ID (signupid)'. The description adds no extra semantic detail about the parameter, so it stays at the baseline of 3.

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

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

The description states a specific resource (a sign-up) and scope (slots that are still open/empty), and differentiates from siblings by contrasting with signupgenius_list_slots for slot-level detail. Though 'Report' is a noun, the intent is unmistakable and the scope restriction separates it from report_filled/report_all.

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 explicitly says when not to use this tool ('For slot dates, times and availability on ANY sign-up... prefer signupgenius_list_slots') and names the alternative. It also states prerequisites (SIGNUPGENIUS_USER_KEY, Pro subscription, session mode not supported, only sheets the key-holder created), giving clear selection criteria.

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

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

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds auth requirements, session-mode restriction, and scope limitation to the key-holder's own sheets, which are behavioral constraints beyond the annotation. It does not detail the report's output structure or pagination, but those are not critical given the tool's simplicity.

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 two sentences: the first front-loads the purpose, the second packs constraints and the alternative. Every clause earns its place with no redundancy or 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-parameter, read-only report tool, the description covers auth, scope, and the key sibling alternative. It does not explicitly describe the report's return format, but given the absence of an output schema and the tool's clear purpose, this is a minor gap. The guidance to use list_slots for availability is a strong addition.

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 only parameter signupId has a schema description ('Sign-up ID (signupid).'), providing 100% coverage. The tool description does not add any extra meaning about the parameter beyond what the schema already states, 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 clearly states the tool produces a report for a sign-up, specifically restricted to already-filled slots. The phrase 'restricted to slots that have already been filled' distinguishes it from report_all and report_available, and the mention of list_slots as an alternative further differentiates its purpose.

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 explicitly lists prerequisites (SIGNUPGENIUS_USER_KEY, Pro subscription, session mode not supported, only sheets the key-holder created) and names the alternative signupgenius_list_slots with the condition 'prefer ... on ANY sign-up (including sheets the user did not create)' and notes it needs no auth. This gives clear when-to-use and when-not-to-use guidance.

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

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

The description discloses far more than the annotations: it states this tool WRITES DATA, explains the confirmation prompt behavior, details the two-step fallback with confirmToken, and specifies that it refuses to add a second response. This is exactly the behavioral context an agent needs for a mutating tool.

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

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

The description is dense but every sentence serves a purpose: purpose, write-safety, confirmation behavior, refusal condition, and sibling routing. It front-loads the core function and then layers the necessary workflow detail without redundancy.

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?

Given the tool has no output schema and minimal annotations, the description carries a heavy burden and meets it fully. It covers what the tool does, what it writes, when confirmation is needed, what the fallback returns, when it refuses, and when to use a different tool — leaving no critical gap for an agent to call it correctly.

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 67%, so the schema carries much of the parameter documentation. The description adds essential semantics for confirmToken by explaining the phase-1 preview, the repeat-call requirement, and the 'never invented, never reused' rule. It also clarifies the high-level flow around response, url, and identity, though firstname/lastname remain minimally documented.

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 opens with a specific verb and resource: 'RSVP to a SignUpGenius sign-up (the Yes/No/Maybe-style sheets...)'. It further distinguishes itself from the slot-based sibling by stating 'Slot-based sign-ups ... are NOT handled here — use signupgenius_claim_slot for those', so an agent can identify the correct tool unambiguously.

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

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

The description provides explicit when-to-use guidance, including the confirmation workflow, the fallback two-step flow, and the refusal case for existing responses with a directive to use the web UI. It also names the alternative tool for slot-based sign-ups, making the decision boundary clear.

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