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

Annotations only flag the operation as a destructive, non-idempotent write; the description adds substantial non-structured context: the real-world consequence (the person may start receiving invitations), the two-phase confirmation protocol, the phase-1 no-op preview + confirmToken, and the MCP_CONFIRM_MODE fallback. This is exactly the behavioral value a description should add beyond 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?

Purpose is front-loaded before the confirmation detail, and the content largely earns its place. The second sentence is a long multi-clause run-on and the '(MCP_CONFIRM_MODE)' tag is terse, costing a point on structure despite overall efficiency.

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 non-idempotent write tool with 5 params, no output schema, and a two-step confirmation protocol, the description covers the critical path: side effects, the preview return shape, and the fallback token flow. An agent has enough to call it correctly, and the phase-1 return is described in lieu of an output schema.

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

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

Schema coverage is 40% (<50%), so the description carries weight: it establishes email as the required key and first/last as optional, and explains the confirmToken contract (same arguments, only after approval). Only groupId is left semantically undocumented, which is the sole gap.

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

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

States a specific verb and resource ('Add a person to ... groups') plus the keying mechanism (by email address, first/last optional). This clearly distinguishes it from read-oriented siblings like signupgenius_get_group_member and signupgenius_list_group_members without the agent needing to open either schema.

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

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

Gives clear operational context (adding a member, first/last optional) and an explicit pre-condition flow for confirmation. It does not name exclusions or route to sibling alternatives (e.g. removing releasing a slot), so it stops short of a 5, but the when-to-use context is unambiguous.

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 cover the safety profile (destructiveHint=true, openWorldHint=true). The description goes far beyond them, disclosing the two-phase confirmation flow, that the first call writes nothing and returns a preview+confirmToken, the MCP_CONFIRM_MODE behavior, and the identityDiffersFromAccount flag the agent must surface to the user.

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

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

Front-loads the action, then the confirmation protocol, then identity defaults, then the alternative tool. Every sentence carries load, though the confirmation-negotiation passage is dense enough that a tighter phrasing could lose no 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 9-parameter destructive write tool with no output schema, the description supplies exactly the missing pieces: the preview/confirmToken return shape, the confirm-before-write contract, identity defaults, and the routing rule to the sibling.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds real semantics: firstname/lastname/email default to the signed-in account and should be omitted unless signing up someone else, confirmToken is strictly for the no-elicitation fallback and must not be invented or reused, and customFields must include the sheet's required questions.

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?

Opens with a precise verb+resource+scope ('Claim (sign up for) a slot on a slot-based SignUpGenius sheet') and explicitly names the sibling it is not for Yes/No/Maybe sheets (signupgenius_rsvp). An agent can route correctly without opening either schema.

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

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

States when to use it, the sibling alternative (signupgenius_rsvp) for headcount sheets, and prerequisites (slotitemid from list_slots, required customFields from get_public_signup) plus the identity-default rule. Covers when-to-use, when-not, and where inputs come from.

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 safety and external-data scope are covered. The description adds one genuinely non-redundant behavioral fact: the contact fields are only present if the member supplied them during a sign-up, i.e. results can be partially empty. It says nothing about error behavior for invalid IDs or rate limits.

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

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

A single sentence with the verb, resource, and returned fields front-loaded, followed by the availability caveat. Nothing is redundant, though the trailing 'when the member has provided it via a sign-up' clause is slightly loose phrasing that could be tightened.

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

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

With no output schema, the description usefully names the three fields returned, which partly compensates. It leaves the groupId parameter unexplained and gives no guidance on what happens when a member has not provided contact info (empty fields vs. error), which an agent needs for a lookup tool.

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

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

Schema description coverage is 50%: memberId is documented in the schema as the 'communitymemberid returned by signupgenius_list_group_members', but groupId has no schema description and the tool description does not explain it either. The description adds no format, type, or sourcing information beyond what the schema already carries.

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

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

The description gives a specific verb and resource ('Get detailed info for a group member') and even enumerates the returned fields (address, phone, email), so the agent knows exactly what this returns. It does not name or contrast itself with the closest sibling, signupgenius_list_group_members, which is the natural disambiguation partner.

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 phrase 'when the member has provided it via a sign-up' implies a usage condition (fields may be empty if the member never supplied them), which is a useful implicit guideline. However, it never states when to call this versus signupgenius_list_group_members or signupgenius_add_group_member, so routing 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 already flag readOnlyHint and openWorldHint, so the safety profile is covered. The description adds non-obvious behavioral context by disclosing that key mode routes to /v2/k/user/profile while session mode routes to /v3/member/profile, which is genuinely useful for understanding mode-dependent 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?

Front-loaded with the core action and returned fields, followed by a usage hint and endpoint detail. All three sentences earn their place, though the endpoint path detail is somewhat technical and could be trimmed for pure invocation purposes.

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

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

With no output schema, the description compensates by listing the profile fields returned and noting the mode-specific endpoints. Combined with readOnly annotations, an agent has everything needed to call this 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?

The tool takes zero parameters, so there is no parameter semantics to document; baseline is 4. The description correctly implies no input is required by framing it as a profile lookup of the authenticated user.

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

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

States a specific verb (Get) and resource (the SignUpGenius profile of the authenticated user), and enumerates the returned fields (name, email, member ID, subscription level). This clearly distinguishes it from sibling list/get tools that operate on groups, members, or 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?

Gives a concrete usage cue: 'Useful as a first call to confirm credentials,' which tells the agent when this tool is appropriate. It stops short of naming alternatives or exclusions, but the intent is clear.

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?

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds a real constraint ('Session mode only') and discloses the underlying endpoint, but does not explain what session mode means or what the wizard listing contains, leaving meaningful behavioral gaps for a legacy endpoint.

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

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

Two front-loaded sentences with the constraint first and the sibling comparison second; no filler. The raw API endpoint is arguably noise for an agent but conveys legacy provenance cheaply.

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 tool with no output schema, this covers purpose, a sibling alternative, and an access constraint. It stops short of clarifying the 'session mode' prerequisite or the shape of the returned listing, which is the main remaining ambiguity.

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 no parameters, so there is nothing for the description to document; the 4 baseline applies. No parameter-related information is missing.

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

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

States a clear verb ('Returns') and resource ('the same sign-up listing the SignUpGenius wizard sees'), and differentiates from siblings by citing 'fuller data than signupgenius_list_created_* provides'. The reference to the internal API endpoint adds specificity, though 'the same listing the wizard sees' is somewhat indirect as a description of the data.

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

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

Gives a clear usage condition ('Use when you want fuller data than signupgenius_list_created_* provides') and names the alternative tools, which is exactly the sibling-routing an agent needs. The precondition 'Session mode only' is stated but never explained, so the agent cannot fully judge when this tool is actually available.

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 cover read-only and open-world characteristics, so the bar is lower, and the description adds genuinely new behavior: in session mode the result includes both active and expired entries, requiring client-side enddate filtering. This is exactly the kind of trait annotations cannot express.

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

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

Two tight sentences, front-loaded with what the tool returns, followed by the one non-obvious behavioral caveat. 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?

With no params, no output schema, and annotations covering safety, the description supplies the one thing an agent could not infer: that the 'active' name is misleading in session mode. It could be more complete by naming the sibling tools that return expired/all lists.

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 and schema coverage is 100%, so the baseline of 4 applies. There is no parameter detail the description needs to add.

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

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

States a specific verb+resource ('List sign-ups created by the authenticated user') with a clear owner scope. It does not explicitly differentiate itself from the closely related siblings list_created_expired and list_created_all, though the 'active' framing and the enddate note hint at the distinction.

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

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

It gives a conditional ('if you need only active') but as a client-side workaround rather than routing the agent to the sibling tools (list_created_all, list_created_expired). Usage is implied rather than made explicit against alternatives.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety and reach profile is covered. The description adds the useful scope facts that results span active and expired sign-ups and are limited to the authenticated user's own creations, but says nothing about volume, ordering, or pagination for a potentially large 'ALL' listing.

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

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

One sentence, no filler, with the scope qualifier and the active/expired distinction front-loaded. 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?

For a zero-parameter, read-only listing tool whose annotations carry the safety profile, the definition covers who, what, and scope. The only minor omission is any hint about result volume/ordering, which matters somewhat for an 'ALL' query with no output schema to describe the return shape.

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 per the rubric the baseline is 4 and there is nothing for the description to disambiguate. Schema coverage is 100% (empty object), so no gap exists to compensate for.

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

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

States a specific verb (list), resource (sign-ups), scope (ALL created by the authenticated user) and explicitly covers both states (active and expired). This cleanly distinguishes it from the sibling subset tools signupgenius_list_created_active and signupgenius_list_created_expired without needing to name them.

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 parenthetical '(active and expired)' signals the superset nature, which implicitly routes the agent away from the active-only and expired-only siblings. However, it never explicitly names those alternatives or states when to prefer the narrow variants, so the routing is inferable rather than stated.

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

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

Annotations already declare readOnlyHint=true, so safety is covered. Beyond that, the description discloses a genuinely non-obvious behavioral trait: that in v3 the endpoint returns active and expired records together, so the result set is broader than the name implies. It stops short of covering pagination or result size, but the surprise disclosure is real added 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?

Two short clauses, front-loaded with the alias relationship and followed by the client-side filtering instruction. Nothing is wasted, though the parenthetical reference to 'session mode' and 'v3' assumes context the agent may not have.

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

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

For a zero-parameter read-only list tool with no output schema, the description covers the essential caveat and the client-side filter. It leaves open what happens outside 'session mode' (the description implies the behavior is conditional), and says nothing about pagination or result volume, which matters for a list tool that can return both active and expired records.

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 with 100% schema coverage, so there is nothing for the description to explain and the baseline of 4 applies. The description correctly adds no redundant parameter talk.

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

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

The description names the resource (created signups) and explicitly frames this as an alias of signupgenius_list_created_active, which lets an agent place it against the sibling tools list_created_active and list_created_all. However, calling it an 'expired' tool while stating it actually returns active + expired together creates mild ambiguity about what the tool itself does versus what the caller must do.

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

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

It gives one concrete usage instruction ('Filter on enddate client-side'), which tells the agent how to obtain expired entries from this call. It does not state when to prefer this over signupgenius_list_created_all or signupgenius_list_created_active, leaving the choice among the three near-identical siblings largely 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 already declare readOnlyHint=true and openWorldHint=true, so safety and external-access profile are covered. The description adds the useful detail of what is returned (name, email, memberid), but says nothing about pagination, ordering, or authorization scope.

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

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

A single front-loaded sentence with the resource first and the return payload parenthetically appended. Every clause earns its place; 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 2-param read-only list tool whose annotations carry the safety profile and which has no output schema, the description does convey the return fields. However, it omits any mention of result ordering or the meaning of the sort parameter, leaving an agent under-informed about output shape.

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 only 50%: groupId is documented in the schema ('Group ID returned by signupgenius_list_groups'), but the sort enum has no description in either the schema or the tool description. The description contributes nothing about parameters, so it fails to compensate for the coverage gap.

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

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

States a specific verb and resource ('List members of a SignUpGenius group') and names the returned fields, which separates it from siblings like get_group_member (singular) and add_group_member. It is clear and specific though it does not explicitly name the alternative listing 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 action 'list members of a group' implies when to use it, but there is no explicit when/when-not guidance nor any reference to the sibling get_group_member for a single member or list_groups for the group list. Usage 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 already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds genuinely useful context by enumerating the returned fields (groupid, title, member count), which matters because no output schema exists. It omits pagination or auth details, keeping it from a 5.

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

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

Two sentences, zero filler, with the scope constraint and the return shape front-loaded. Every clause earns its place.

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

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

For a simple read-only list tool with one optional parameter and no output schema, the description covers both purpose and return fields adequately. The only real gap is the absence of routing guidance against the numerous sibling list tools.

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

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

Schema description coverage is 100% and the single 'sort' parameter is already documented with an enum in the schema. The description adds no syntax or meaning beyond that, so the baseline of 3 applies.

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

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

States a specific verb ('List') and resource ('groups') with a clear scope qualifier ('created by the authenticated user'), so an agent knows exactly what set is returned. It does not explicitly differentiate itself from similarly named siblings such as list_created_active/expired/all, which keeps it short of a 5.

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

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

The description implies usage ('list groups created by the authenticated user') but never states when to choose this tool over alternatives like list_group_members or the various list_created_* siblings, and gives no exclusions or prerequisites. An agent must infer the boundary itself.

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?

With annotations declaring readOnlyHint=true and openWorldHint=true, the safety profile is covered. However, the description adds no behavioral context beyond the basic purpose—no information about authentication, pagination, return format, or rate limits. It does not contradict the annotations, but it also adds little 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, front-loaded sentence with no redundant or filler content. Every word earns its place for a simple listing 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?

Given the low complexity (no parameters, no output schema) and annotations covering safety, the description is minimally adequate. It misses explicit guidance on how this tool relates to similar sibling list tools, which could affect selection. The return values are implied but not stated.

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 empty input schema and 100% schema coverage mean there are no parameter semantics to describe, and the description appropriately does not invent any.

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

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

The description states a specific verb ('List') and a specific resource ('sign-ups the user has been invited to'). This distinguishes it from siblings like list_signedupfor or list_created_*, but it does not explicitly name or contrast with those alternatives, keeping it at 4 rather than 5.

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

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

The description offers no guidance on when to use this tool versus alternatives. It does not mention any conditions, prerequisites, or exclusions (e.g., 'use this instead of list_signedupfor when you only want invitations'). Usage is only implied by the tool name and description.

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 safety profile is covered by structured data. The description adds one useful scoping nuance — that these are sign-ups the user personally joined, not ones they created or were invited to — but says nothing about return shape, pagination, or volume.

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

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

A single front-loaded sentence with no filler. For a zero-parameter listing tool the scope qualifier is the one piece of information that matters, and it is stated immediately.

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 and a trivial input, the description's main remaining duty is disambiguation from near-identical siblings like legacy_get_my_signups and list_invited, which it does not address. It is adequate but leaves the agent guessing among overlapping list tools.

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 and the schema is empty, so there is nothing for the description to document; baseline 4 applies. No misleading parameter claims are made.

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

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

The description gives a specific verb ("List") and a clearly scoped resource ("sign-ups the user has personally signed up for"), which distinguishes it from the created/invited variants by ownership. However, it does not name or distinguish itself from the close sibling signupgenius_legacy_get_my_signups, which sounds like it may return the same thing.

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 statement of when to use this tool versus the many sibling list tools (list_invited, list_created_all, legacy_get_my_signups). The agent must infer selection purely from the phrase "personally signed up for," with no explicit alternative routing.

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?

Goes well beyond the destructiveHint=true annotation by disclosing the full two-phase confirmation protocol: the client-side prompt when elicitation is supported, the fallback where the first call is a no-op returning a preview plus confirmToken, and the requirement to echo the token with identical arguments. This is exactly the kind of behavior an agent must know before invoking a destructive write.

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 purpose is front-loaded in the first sentence and the destructive warning follows immediately; every clause carries information. It is dense and somewhat run-on, but no sentence is 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 destructive, no-output-schema mutation with a non-trivial confirmation handshake, the description supplies the missing pieces: the confirm-first requirement, the preview contents, and the token round-trip. Nothing an agent needs in order to call it safely is absent.

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

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

Schema coverage is already 100%, so the baseline is 3, but the description adds real meaning: it explains what the preview exposes (sheet, slot, whose entry) and the lifecycle rules for confirmToken (never on first call, never invented, never reused, ignored under elicitation), which the schema alone does not convey.

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

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

States a specific verb ('Withdraw/give up') and resource ('a slot the user previously signed up for'), which cleanly distinguishes it from the inverse sibling signupgenius_claim_slot without opening either schema.

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

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

The when-to-use is clear (undo a prior sign-up) and it adds a real exclusion: only the current user's own entry can be withdrawn, a different memberId is rejected. It never names an explicit alternative sibling, so it stops short of 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?

Annotations only declare readOnlyHint and openWorldHint; the description adds substantial context beyond them: the required credential and subscription tier, that session-based auth will fail, and that results are scoped to sheets created by the key-holder. It also discloses the return content shape (slot + participant + custom answers).

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

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

Three tight sentences, front-loaded with what the tool returns, then the auth/scope caveats, then the alternative. No filler and every clause carries operational 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 single-parameter, read-only reporting tool with no output schema, the description covers all the decision-relevant facts: what is returned, what auth and subscription are required, which sheets are in scope, and which sibling to use instead. Nothing needed to call it correctly is missing.

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

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

There is a single parameter and schema description coverage is 100%, with signupId fully documented in the schema (type, bounds, meaning). The description adds no format or identifier guidance beyond what the schema already states, so this sits at the baseline for a well-covered single-param tool.

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

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

The description states a specific verb and resource: a full report per sign-up containing every slot, its claiming participant, and custom-question answers when present. It clearly separates itself from signupgenius_list_slots, but does not articulate how it differs from its close siblings signupgenius_report_filled and signupgenius_report_available.

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

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

It gives explicit prerequisites (SIGNUPGENIUS_USER_KEY with a Pro subscription), an exclusion (session mode is not supported), a scope limitation (only sheets the key-holder created), and names a preferred alternative (signupgenius_list_slots) with the exact condition that selects it — getting slot dates/times on any sign-up without auth.

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 supply readOnlyHint/openWorldHint; the description goes well beyond them by disclosing auth prerequisites (Pro key), a hard scope limit (creator-owned sheets only), and unsupported session mode — all material facts an agent cannot infer from the annotation set.

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

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

Two sentences, zero filler, and the most decision-relevant constraint (what the report contains) is front-loaded before the auth caveats and the alternative recommendation.

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

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

Covers auth, scope, and sibling routing thoroughly for a one-parameter report tool. The only omission is what the returned report actually looks like — no output schema exists here, so a brief note on the return shape would have closed the last gap.

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

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

There is a single parameter (signupId) and the schema already documents it at 100% coverage with type and constraints, so the description adds nothing parameter-specific. Baseline 3 is appropriate when the schema fully carries the load.

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

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

States a specific verb+resource combination ('report for a sign-up') with an explicit scope ('restricted to slots that are still open/empty'), which cleanly separates it from the sibling report_all and report_filled variants without opening their schemas.

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

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

Gives explicit when-to-use conditions: requires SIGNUPGENIUS_USER_KEY with a Pro subscription, session mode is unsupported, and only sheets the key-holder created are covered. It also names an alternative (signupgenius_list_slots) with the precise condition that selects it and notes that it needs no auth.

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 and openWorldHint, so the description carries the operational burden — and it does: it discloses the SIGNUPGENIUS_USER_KEY / Pro-subscription requirement, that session mode is unsupported for reports, and that results are limited to sheets created by the key-holder. These are exactly the auth and scope constraints an agent must know before invoking.

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?

Purpose is front-loaded in the opening clause, followed by prerequisites and then the routing alternative. Every clause carries a distinct constraint (auth, session-mode exclusion, scope, sibling preference) 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 read-only report with one parameter, the definition covers auth, scope, and sibling routing thoroughly. The only minor gap is that it never hints at what the report contains (fields, pagination, volume), and with no output schema present the description is the only place that could say so.

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?

There is a single parameter with 100% schema description coverage, so the schema already documents signupId fully. The description adds no syntax, format, or ID-sourcing detail beyond what the schema provides, which is the baseline 3 for a fully-covered schema.

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

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

The first sentence names a specific artifact (a report for a sign-up) and a precise scope (slots that have already been filled), which cleanly separates it from the sibling signupgenius_report_available. An agent can tell exactly what this returns without opening the schema.

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

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

It explicitly names the alternative (signupgenius_list_slots) and the condition that selects it (slot dates/times/availability on ANY sign-up, no auth needed). It also states the auth prerequisite and the scope limit (only sheets the key-holder created), so the agent knows when this tool is and is not usable.

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 declare destructive=true, idempotent=false, openWorld=true, and the description goes well beyond them: it discloses that data is written and visible to the organizer, the elicitation vs. two-step confirmToken fallback, the refusal on duplicate responses, and the identityDiffersFromAccount flag. The main remaining gap is that it does not state what a successful submission returns beyond the phase-1 preview, though no output schema exists to cover 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 purpose and write-semantics are front-loaded, and the dense sentences carry distinct constraints rather than repeating themselves. It is long, but nearly every clause adds a routing or safety fact; a little more white space around the two-step fallback would aid scanning.

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

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

With no output schema, the description compensates by enumerating the preview contents (sheet, response, head counts, identity, confirmToken) and the exact two-phase call sequence. Combined with the annotations, an agent has everything needed to invoke this correctly, including the confirmation requirement.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds genuine meaning: it explains that firstname/lastname/email default to the signed-in account and should be omitted unless responding for someone else, and it details the confirmToken's exact lifecycle (same arguments, only after approval, never invented or reused). This goes beyond the schema text.

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

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

States a specific verb (RSVP) and resource (SignUpGenius sign-up) and immediately scopes it to the Yes/No/Maybe-style sheets rather than slot claims. It names the sibling it is not (signupgenius_claim_slot), so an agent can route between them without opening a schema.

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

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

Gives explicit when-to-use (RSVP sheets), when-not-to-use (slot-based sign-ups → signupgenius_claim_slot), a refusal condition (existing response → edit in web UI), and the confirmation protocol. Alternatives and exclusions are all named.

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