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

Annotations already indicate a safe, read-only, idempotent operation. The description adds meaningful context by noting it operates across all user events and returns a list of per-event restriction records, which goes beyond the annotations. However, it doesn't mention potential pagination or data freshness, but for a simple read-only 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 two concise sentences with no redundant information. It is front-loaded and 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?

Given the tool's simplicity (one optional param, strong annotations, and an output schema), the description is complete enough. It specifies the scope and return type, while the schema and annotations cover the remaining details.

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 sole parameter 'fields' is fully documented in the schema with descriptions, including available fields. The description does not add additional parameter semantics, so it matches the baseline 3 for high schema coverage.

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 gets restrictions across all events, using a specific verb and resource. This distinguishes it from the sibling tool get_event_restrictions, which is presumably for a single event.

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

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

The phrase 'across all of your Partiful events' provides clear context for when to use this tool (when needing restrictions from multiple events). It does not explicitly mention alternatives or exclusions, but the scope is clear enough from the description and sibling names.

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, idempotentHint, and non-destructive, so the description only needs to add context. It adds that the events are 'awaiting your cohost response,' which clarifies the state of the returned data beyond what annotations provide.

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

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

The description is a single sentence, front-loaded with the action and resource, and every phrase adds value. No filler or 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?

For a simple read-only list tool with one optional parameter and rich annotations, the description is complete. It states the return type and scope, and the output schema handles return structure details.

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 provides 100% coverage for the single 'fields' parameter with a clear description. The tool description adds no extra parameter information, so it meets the baseline for schema-covered parameters.

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

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

The description uses a specific verb ('Get') and resource ('events') with a clear scope ('where you've been asked to cohost'), distinguishing it from sibling tools like get_my_events or get_pending_cohost_request_for_event. It explicitly mentions returning a list of event objects awaiting response.

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 implies the use case: listing events for which the user has a pending cohost response. It does not explicitly mention alternatives or exclusions, but the context is clear enough for an agent to select this tool over similar ones.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the description's safety disclosure burden is low. The description adds value by specifying the return format (array of profiles with id, name, display name, username), but does not disclose pagination, rate limits, or auth requirements. No contradiction with annotations.

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

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

The description is a single concise sentence that is front-loaded with the verb and resource. Every word earns its place, with no wasted filler or redundant restating of the tool name.

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's low complexity (one optional parameter, no required fields, rich annotations, and an output schema), the description covers the essential purpose and return shape. It is slightly incomplete in not explicitly guiding selection versus the filtered sibling, but overall it is sufficient for a simple list operation.

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 (fields) is fully described in the schema (100% coverage), including available dot-path fields. The tool description adds no additional parameter meaning beyond what the schema already provides, so the baseline of 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 ('Get') and resource ('your Partiful contact list') and clearly states the return value. It is distinct from sibling get_contacts_filtered_by_event by referring to the general contact list, though it does not explicitly name the 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 clearly implies when to use the tool (when you need the full contact list), and the sibling name suggests a filtered alternative. However, it does not explicitly state when to use this over get_contacts_filtered_by_event or other contact-related tools, offering no exclusions or alternative 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 declare read-only, open-world, and idempotent hints, so the safety profile is covered. The description adds a meaningful behavioral detail: the endpoint does not paginate and returns the full list in one call. This goes beyond the annotations without contradicting 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 two sentences with no filler. The first sentence states the core purpose, and the second adds a single relevant behavioral trait (non-pagination). It is front-loaded and 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 tool's simplicity, a rich schema (2 params fully described), and presence of an output schema, the description covers the essential purpose and a key behavioral nuance. It lacks explicit guidance on sibling alternatives, but it is sufficiently complete for correct invocation.

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

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

The input schema fully describes both parameters (event_id and fields) with 100% coverage, including the list of available dot-path fields. The description adds no additional parameter semantics beyond what the schema already provides, so the baseline score 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's function: retrieving contacts that can be invited to a specific Partiful event. It uses a specific verb ('Get'), a resource ('contacts'), and a scope ('filtered by event'), and distinguishes itself from siblings like get_contacts by adding the non-pagination behavior and invite eligibility.

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 for fetching inviteable contacts for a given event, but it does not explicitly compare with alternatives such as get_contacts or state when not to use this tool. No explicit 'use this instead of that' guidance is provided, so the usage context is only implied.

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, destructiveHint=false, idempotentHint=true, and openWorldHint=true, so the safety profile is covered. The description adds the scope ('you've created') and return shape ('array of card objects (id, title, image)'). However, there is a minor inconsistency: the description says 'image' while the schema mentions 'imageUrl', which could cause slight confusion. Overall, it is consistent with annotations and adds useful context.

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 primary purpose, and contains no fluff. Every word earns its place, making it highly concise and well-structured.

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 tool is simple with one optional parameter, comprehensive annotations, and an output schema. The description covers the core purpose and return type. It could mention pagination or an explicit note that no filtering is possible, but given the output schema exists and the tool is likely low-risk, the description is sufficiently complete for an agent to invoke 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?

The input schema has 100% coverage for the single optional 'fields' parameter, which is well described. The description does not add parameter-specific guidance beyond mentioning the returned fields, but it does align with the schema's field names (except 'image' vs 'imageUrl'). Baseline 3 is appropriate since the schema carries the semantic weight.

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') and resource ('digital cards you've created on Partiful'), clearly distinguishing it from sibling get_* tools. It states exactly what data is returned, making the tool's purpose 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 implies when to use the tool (when you need your created digital cards), but it does not explicitly mention alternative tools or when not to use it. Given the large sibling set of get_* tools, some explicit exclusion would be helpful, but the context is reasonably 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 declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so safety is covered. The description adds meaningful behavior context: these are publicly discoverable events surfaced to the user, not necessarily tied to invitations or RSVPs, and returns an `events` array. This goes beyond what annotations and schema alone convey, though it doesn't detail auth or rate limits.

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

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

The description is front-loaded with the main purpose in the first sentence, then uses a second sentence to differentiate from a cluster of sibling tools with specific names. Every phrase earns its place, and the length is justified given the many related tools. No fluff or repetition.

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

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

The tool has a single optional parameter, a rich output schema, and comprehensive annotations. The description fully explains what the events are, where they appear (home page tab), and how they differ from similar tools. There is no missing information about return shape or semantics that would confuse an agent.

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 'fields' is well-documented in the schema with a comprehensive list of available dot-path fields and the note to omit for all fields. Since schema coverage is 100%, the description doesn't need to add parameter semantics, and it doesn't provide extra value here. Baseline 3 is appropriate.

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

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

The description clearly states the tool gets open-invite / discoverable Partiful events for the home page 'Open invite' tab, returning an `events` array. It explicitly names multiple sibling tools (get_my_rsvps, get_my_upcoming_events_for_home_page, etc.) and differentiates by saying these events aren't necessarily ones you've been invited to or RSVPed to, making the purpose 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 provides explicit guidance on when to use this tool versus alternatives: it contrasts with invited/RSVPed event tools, and also distinguishes from get_my_saved_events and get_my_followed_events. This gives clear context for selection without needing to inspect sibling descriptions.

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 idempotency. The description adds meaningful behavioral context beyond annotations: the 'host-only' access restriction and the fact that it returns settings rather than actual discover-page info. This helps the agent understand auth requirements and semantic 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?

The description is two sentences, front-loaded with the core purpose, and every phrase adds value. The sibling distinction is concise and does not waste 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 read-only getter with a simple two-parameter schema and output schema present, the description fully explains the tool's role, its host-only nature, and how it fits among related tools. No critical information is missing.

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

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

Schema description coverage is 100%, so the baseline of 3 applies. The description does not add any additional parameter-specific meaning; the event_id and fields parameters are adequately documented in the schema. No further compensation 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 clearly states the verb ('Get') and the resource ('discover-page curation options for a hosted Partiful event'), and explicitly distinguishes the tool from two sibling tools (get_event_discover_info and get_event_discover_status), making its purpose 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 provides clear context by noting the tool is 'host-only' and refers to 'host-side settings', which implies when it should be used. It also differentiates from two related tools, but does not explicitly state 'use this instead of X when Y', so it falls short of full explicit 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?

Annotations already declare read-only, idempotent, non-destructive behavior, lowering the transparency burden. The description adds useful behavioral context by disclosing the exact return shape (`decoratorsByEventId` keyed by event ID) and providing examples of decorator types, which goes beyond the structured 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 sentences, front-loads the key action, and includes only essential details. No wasted words; every phrase adds value.

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

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

The tool is simple with only two parameters, a clear output schema, and comprehensive annotations. The description, combined with the schema and annotations, fully covers the necessary context for correct invocation and expectation of results.

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 parameter descriptions already exist for `event_ids` and `fields`. The description does not add additional meaning about parameter syntax, defaults, or relationships, so it stays at the baseline for high coverage.

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 identifies the tool's purpose: retrieving decorators/metadata for explore page event cards, with concrete examples like badges and trending. This specific verb+resource scope distinguishes it from sibling tools such as get_event_discover_info and get_discover_curation_options.

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 context (explore page event cards) but does not explicitly state when to prefer this tool over siblings or mention any exclusions. Given the large set of similar get_* tools, explicit alternatives would strengthen 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 declare readOnlyHint, idempotentHint, and destructiveHint=false, covering safety. The description adds the return format (array of comment objects with author, text, timestamp), which is useful behavioral context. It does not mention pagination or error behavior, but with annotations covering the safety profile, this is sufficient.

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 action, followed by a concise return value explanation. Every word is meaningful, no fluff or repetition.

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

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

The tool is simple, schema covers all parameters, annotations cover safety, and an output schema exists (though not shown). The description states the return shape, making the tool fully usable. There's no missing critical 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?

Schema coverage is 100%: both event_id and fields are fully described in the input schema. The description adds no parameter-specific details beyond the schema, so the baseline of 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 clear verb ('Get') and specific resource ('comments/discussion') tied to an event ID, and states the return type. This unambiguously differentiates it from sibling getters like get_event_info or get_event_media.

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 implies the usage context: call this when you need comments for a specific event. It does not explicitly mention alternatives or exclusions, but the purpose is so specific that no confusion arises among the many sibling tools.

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, openWorldHint, idempotentHint, and non-destructive. The description adds value by specifying the exact data returned (region, sections, tags) and reinforces the read-only nature implicitly through 'get'. It does not contradict annotations and provides useful behavioral context beyond the raw flags.

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 redundant phrasing. The first sentence states the action and payload; the second sentence preempts confusion with related tools. Well front-loaded and 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?

Given the tool's simplicity, the complete schema, rich annotations, and presence of an output schema, the description fully covers purpose, usage, and distinctions. Nothing critical is missing.

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

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

Schema description coverage is 100%: both event_id and fields are fully documented. The description does not add new parameter-level details beyond what the schema already provides, so the baseline score of 3 applies. The mention of 'region, sections, tags' mirrors the schema's available fields.

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

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

The description uses a specific verb-resource pair ('Get discover-page info') and explicitly enumerates the content (region, sections, tags). It also names two sibling tools and contrasts their purposes, making the tool's function unmistakable.

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 versus alternatives: 'Distinct from get_event_discover_status... and get_discover_curation_options...' This gives clear exclusions and clarifies the intended scenario for this tool.

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 read-only, idempotent, non-destructive behavior. The description adds minimal extra behavioral context beyond the return value, but does not disclose edge cases like event not found or open-world behavior. Since annotations cover the safety profile, a 3 is appropriate.

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 compact sentences that front-load the core purpose and include sibling differentiation without any redundant words. Every sentence adds value.

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

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

For a simple read-only check with two parameters and an output schema, the description sufficiently covers purpose and differentiation. It does not mention potential alternative get_discoverable_events, but that is not necessary for this tool's basic usage. The description is complete enough for 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?

Schema coverage is 100% for both parameters (event_id and fields), with descriptions already present. The tool description does not add any parameter-specific 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 clearly states the tool checks whether a Partiful event is listed on explore/discover and returns the discoverability flag/status. It goes further by explicitly distinguishing it from get_event_discover_info and get_discover_curation_options, making the purpose 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 provides explicit differentiation between this tool and two related siblings, indicating when to use this tool (to check if listed) versus alternatives (to get region/sections/tags or host-only settings). This gives clear usage context and excludes 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 destructiveHint=false, so the agent knows this is a safe read operation. The description adds the scoping detail 'displayed' and states the return type, but doesn't disclose additional behavioral traits like pagination, auth requirements, or edge-case handling. This is comparable to the calibration example where scoping was noted but scored 3 due to missing richer context.

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 verb and resource, and every sentence adds value. There is no fluff or repetition of schema/annotation details.

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?

This is a simple read-only retrieval tool. Annotations cover safety, schema covers both parameters, output schema presumably covers return shape, and the description clarifies the exact semantic (displayed host messages). Nothing critical is missing for a tool of this 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?

Schema description coverage is 100%, with both event_id and fields already clearly documented. The description's 'by ID' reinforces event_id but doesn't add substantive meaning beyond the schema. Per calibration, a high-coverage schema means a baseline of 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 the specific verb 'Get' with the resource 'host messages displayed on a Partiful event's page', clearly identifying what the tool does. It distinguishes this from sibling tools like get_event_comments or get_event_info by focusing on host messages specifically.

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 clear context: you use this tool when you need the host messages displayed on an event page. It doesn't explicitly name alternatives or exclusions, but the wording makes the usage scenario obvious and distinct from related getters.

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, but the description adds valuable behavioral context: the event object shape, the fact it works beyond invitations, and the specific omission of the current user's RSVP status. This goes beyond what annotations convey, mitigating potential misconceptions.

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, followed by a concise caveat about scope. Every sentence 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?

Given the output schema exists, the return format is covered. The description provides the key contextual elements: scope (any viewable event), the content type (event object), and the distinguishing exclusion (current user's RSVP). No critical behavioral or usage gaps for a read-only 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 coverage is 100%, with both parameters described thoroughly, including the extensive dot-path list for 'fields'. The description adds minimal extra meaning beyond the schema, so the 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 states 'Get full details for a specific Partiful event by ID' with a clear verb and resource, and enumerates the content ('title, dates, location, ownership, host/guest display settings, guest status counts'). It also distinguishes itself from sibling RSVP-list tools by noting it works for any viewable event, making the purpose unmistakable.

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 when to use it ('Works for any event you can view') and contrasts with 'RSVP-list tools' by noting it excludes the current user's own RSVP status. This provides clear when-to-use and when-not-to-use guidance, naming an alternative category of tools.

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, idempotentHint=true, and destructiveHint=false. The description adds that it returns an array with URL, content type, and uploader, which largely mirrors the output schema and does not reveal significant new behavioral traits.

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 short sentences, front-loaded with the action and resource, and contains no unnecessary words. It effectively communicates the tool's purpose and return value.

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

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

For a simple read-only getter with two parameters and an output schema, the description is adequate. It explains the main resource and return format, though it lacks explicit alternative guidance, which is partially captured in the usage guidelines dimension.

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 description only summarizes fields already listed in the schema (e.g., media.url, media.contentType). It does not provide additional parameter semantics beyond what the schema already conveys.

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' and identifies the resource as 'photos and media uploaded to a Partiful event by ID.' This clearly distinguishes it from sibling tools that focus on other event aspects like comments, info, or guests.

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 with 'by ID' and focuses on media, but it does not explicitly mention alternatives or state when not to use the tool. No exclusions or trade-offs are discussed, so guidance is only implicit.

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 destructiveHint=false, so the description only needs to add context beyond safety. It does by specifying the scope ('current authenticated user') and the nature of the returned data ('capability flags'). This is useful and consistent with the annotations, though it does not discuss response format or edge cases.

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 that immediately states the action and resource. It includes a useful example list of flags without fluff, and 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 tool's simplicity, the presence of a full output schema, and complete annotations, the description is complete enough. It accurately describes the core behavior and scope, and the output schema handles return value details.

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 both parameters ('event_id' and 'fields') already described in the schema. The description only adds 'by ID' and examples of capability flags, which marginally reinforces the schema but does not provide additional semantics or usage details beyond what the schema already offers.

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 retrieves the current authenticated user's permission level and capability flags for a specific Partiful event. It uses a specific verb ('Get') and resource ('permission level and capability flags') and distinguishes itself from sibling event-related tools by focusing on permissions rather than event details or guest lists.

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 when to use the tool: when you need the current user's permissions for an event. It does not explicitly mention alternatives or exclusion criteria, but the context is clear given the sibling tools are all read-oriented and focused on other aspects. No misleading 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 declare readOnlyHint, idempotentHint, and destructiveHint false. The description adds valuable context by disclosing the response shape ('returns a `restrictions` array') and the caveat that per-restriction shapes are undocumented and pass through as-is, setting expectations about unknown fields.

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 core action and examples, and the pass-through caveat justifies its inclusion. No wasteful wording.

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 schema covers parameters and annotations cover safety, the description adds return-shape and data-shape caveats. It is sufficiently complete for a simple read-only tool, though it could explicitly distinguish from get_all_event_restrictions.

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 100% description coverage for both parameters (event_id and fields). The description adds no meaningful parameter semantics beyond what the schema already provides, so the baseline of 3 is appropriate.

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

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

The description clearly states 'Get the restrictions... for a Partiful event by ID' with concrete examples like minimum age, capacity, and approval requirements. It distinguishes from sibling get_all_event_restrictions implicitly via 'by ID', but does not explicitly name the sibling.

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

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

Usage is implied: call when you need restrictions for a specific event ID. No explicit when-not guidance or alternative sibling mention (e.g., get_all_event_restrictions) is provided.

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 destructiveHint=false, establishing safety. The description adds behavioral context by specifying the return shape (eligibility boolean and reason when ineligible), which goes beyond the annotations. It does not cover error handling or permission requirements, but the annotations lower the bar.

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 short sentences, with the main action front-loaded ('Check whether a Partiful event by ID is eligible for ticketing') and a concise follow-up on the return value. There is no redundancy or superfluous detail.

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 tool is simple, with an output schema, rich annotations, and full schema parameter coverage. The description adequately explains the tool's purpose and key output without needing to repeat schema details. Edge cases like event-not-found are not mentioned, but the output schema and annotations make the description sufficient for this straightforward read-only eligibility check.

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 both event_id and fields already well-documented. The description reinforces that event_id is the target event and that the response includes eligible/reason, but it does not add new parameter syntax or constraints beyond the schema. Baseline 3 is appropriate.

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

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

The description uses a specific verb ('Check') and resource ('Partiful event by ID') and clearly states the outcome ('eligible for ticketing'). This distinguishes it from sibling tools like get_tickets_for_event or get_host_ticket_types, which deal with actual ticketing details rather than eligibility.

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 (when you need to determine ticketing eligibility) but provides no explicit context or exclusions. It does not name alternative tools for related queries, such as get_ticket_fee_config or get_host_ticket_types, leaving the agent 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 declare this as read-only, idempotent, and non-destructive (readOnlyHint: true, idempotentHint: true, destructiveHint: false). The description adds value by stating the response container ('a `users` array of profile objects') and narrowing the scope to 'current user's' followers, which clarifies auth context. No contradictions with annotations.

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

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

Two sentences, no redundancy. The first sentence states purpose and return type, the second provides the key sibling distinction. 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 simple read operation with one optional, schema-covered parameter, an output schema, and safety annotations, the description covers purpose, scope, return shape, and the most important alternative. This is a complete and self-sufficient description for an agent to select and invoke the 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?

The only parameter, 'fields', is fully documented in the input schema with a clear explanation of dot-path field names and available options. Since schema coverage is 100%, the description need not repeat parameter details; the baseline of 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 the specific verb 'Get', identifies the resource as 'the current user's followers on Partiful', and specifies the return shape as 'a `users` array of profile objects'. It explicitly distinguishes this from get_following, so there is no ambiguity about which direction the follow relationship points.

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 closely related alternative get_following and explains the difference: 'who the current user follows, not who follows them'. This gives clear guidance on when to choose one over the other. It also scopes the tool to 'current user', implying use when you need the authenticated user's follower list.

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 read-only, idempotent, non-destructive behavior. The description adds valuable context about the direction of the relationship (who follows whom) and clarifies the output is a userIds array, which helps prevent misuse beyond what annotations convey.

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 action and resource, and includes only essential information. It efficiently clarifies purpose, sibling distinction, and downstream usage without any fluff.

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 an output schema, the description fully covers the purpose, relationship to alternatives, and follow-up actions. No gaps are evident, and annotations cover the safety profile.

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

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

The schema has 100% coverage for the single optional 'fields' parameter, so the description doesn't need to explain it. The description mentions the available 'userIds' field, but that is already present in the schema description. No additional parameter meaning is added.

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 user IDs the current user follows, using the specific verb 'Get' and the resource 'user IDs'. It explicitly distinguishes from get_followers, making the purpose unambiguous and differentiating it from a closely related sibling tool.

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 directly names get_followers as the alternative and explains the distinction, and also suggests using get_users to resolve the IDs. This provides explicit when-to-use and next-step 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 declare readOnlyHint and destructiveHint false, covering the safety profile. The description adds useful context: access restricted to hosts, and the return format (payments array with charges, fees, tax, promo codes). No contradiction with annotations.

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

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

The description is a single sentence that leads with the primary purpose, then states the key return detail. 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?

Given the output schema, complete parameter descriptions, and annotations, the description is sufficient for a read-only tool. It provides host-only context and the return type, but could be more explicit about how it differs from closely related ticket tools. Still adequate.

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

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

Schema description coverage is 100%: all three parameters have descriptive text, including the fields param with dot-path options. The description adds little beyond summarizing what the payments array contains, which the schema already enumerates. Baseline 3 is appropriate.

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

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

The description clearly states a specific verb ('Get'), the resource ('ticket payment history'), and scope ('for a specific guest on a hosted Partiful event'). It also notes 'host-only', which distinguishes it from broader ticket tools like get_tickets_for_event.

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

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

The description implies clear usage context: a host retrieving a specific guest's payment history. It mentions 'host-only' but does not explicitly name alternative tools or state when not to use it. That's sufficient context, but not the explicit exclusions that would earn 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, idempotentHint, and openWorldHint, covering the main behavioral safety profile. The description adds value by describing the return shape (array of guest RSVP records) and the 'every invitee' scope, but does not disclose potential pagination, rate limits, or behavior when event_id is invalid. Since annotations carry the safety burden, this is acceptable but not exceptional.

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 core action and resource ('full guest list for a Partiful event by ID'), then details the return structure. Every sentence carries useful information with no repetition 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?

The tool is a simple read-only list operation with only two parameters and a clear output schema. The description, combined with annotations and schema, is sufficient for correct invocation. Minor gaps like pagination or error handling are not critical in this low-complexity context, so a 4 reflects completeness without exceeding 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 description coverage is 100%: event_id and fields both have descriptive comments in the schema. The description doesn't add new parameter-level meaning beyond reinforcing that the guest list is full (implying fields can be omitted for all). Given the schema's high coverage, baseline 3 is appropriate.

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

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

The description clearly states the function: obtaining the full guest list for a specific Partiful event by ID. It specifies the resource (guest list), the verb (get), and the scope (full, every invitee), distinguishing it from sibling tools like get_mutual_guests or get_contacts_filtered_by_event that imply filtered or partial guest 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?

The phrase 'full guest list' and 'by event ID' provides clear context for when to use this tool: when all invitee RSVP records are needed for a single event. It doesn't explicitly name alternatives or exclusions, but the 'full' vs. 'filtered' framing implicitly contrasts with related tools, offering sufficient usage 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 declare readOnlyHint, idempotentHint, and destructiveHint=false. The description adds an ownership scope ('you're hosting') and briefly describes the return shape (list of objects with code, discount, usage limits), enriching the annotation-only safety profile.

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 terse sentences: the first states purpose and scope, the second states the return type. No filler or redundancy; front-loaded and easily scannable.

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 presence of a rich schema, good annotations, and an output schema, this description covers the essentials: what the tool does, for whom, and the high-level result. Nothing critical is missing for this simple read-only 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 coverage is 100% for both parameters (event_id, fields), and the fields parameter lists all available dot-path options. The description's mention of 'code, discount, usage limits' only paraphrases the schema, adding no new semantic depth. 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 uses a specific verb ('Get'), names the resource ('promo codes'), and scopes it ('for a Partiful event you're hosting'). It clearly distinguishes this tool from siblings, none of which handle promo codes.

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 'you're hosting' provides clear context for when to use the tool (only for events you host) and implies it's the dedicated promo-code retrieval tool. No explicit exclusions or alternatives are given, but the context is sufficient for such a unique operation.

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, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds return format details ('Returns a list of ticket type objects (name, price, quantity, enabled/disabled state)') which is useful context beyond annotations. No contradictions. This meets the baseline 3 for adding some value without extensive behavioral disclosure.

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 action, and contains no filler. Every clause adds value: the verb, the resource, the host scope, and the return type details. This is a model of conciseness.

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 a rich annotation set (readOnly, idempotent, non-destructive), full schema coverage, and an output schema present, the description is sufficient for the tool's moderate complexity. It clearly states the return shape and host-only scope. It doesn't need to explain return values due to output schema. Could mention default include_disabled behavior, but that's minor. Completeness is strong, so 4.

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 all three parameters have descriptions in the input schema. The description mentions 'name, price, quantity, enabled/disabled state' which echoes the available fields but doesn't add meaning beyond what the schema already provides. Baseline 3 is appropriate given the high schema coverage.

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 gets ticket types/tiers for a Partiful event, with a specific verb 'get' and resource 'ticket types/tiers'. It adds the host context ('you're hosting'), which differentiates it from generic ticket tools like get_tickets_for_event. However, it doesn't explicitly contrast with sibling tools, so it falls slightly 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 for hosts (e.g., 'event you're hosting') but provides no explicit when-to-use vs alternatives or exclusions. There are no mentions of alternatives like get_tickets_for_event or get_event_ticketing_eligibility. The guidance is implicit rather than explicit, placing it at a 3.

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 context beyond the annotations by specifying scope ('current user') and recency ('most recent'). It doesn't contradict the readOnlyHint or idempotentHint. It could mention behavior when no prior answers exist, but given the output schema and simple nature, this isn't a critical gap.

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 (about 14 words) that front-loads the verb 'Get' and directly communicates the resource and purpose. 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?

This is a simple read tool with one optional parameter, full schema coverage, and annotations indicating read-only/idempotent behavior. The description's clarity about the resource and use case, combined with the existing structured metadata, makes it complete for agent selection and invocation.

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

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

The input schema fully describes the single parameter 'fields' with details about dot-path, omission behavior, and available values ('shortAnswer'). The description adds no parameter-specific information, but with 100% schema coverage, the baseline of 3 is appropriate.

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

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

The description clearly states the action ('Get') and resource ('current user's most recent RSVP questionnaire answers'), and adds a distinct use case ('prefill future RSVP questionnaires'). It differentiates from sibling tools like get_my_rsvps by specifying questionnaire answers rather than RSVP statuses.

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 context by noting the tool is 'used to prefill future RSVP questionnaires,' which implies when to use it. It doesn't explicitly mention alternatives or exclusions, but the intended use case is clear enough for an agent.

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 establish the safety profile (readOnlyHint, idempotentHint, destructiveHint false). The description adds meaningful behavioral insight by defining what 'mutual guests' means (people invited to this event who you're also connected to elsewhere), which is beyond annotation coverage. It doesn't mention pagination or edge cases, but the output schema and annotations cover the essentials.

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 with zero waste. The first sentence states the primary purpose and defines mutual, the second explicitly differentiates from siblings. All content earns its place and is front-loaded for quick comprehension.

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 this simple read-only list tool with two well-documented parameters, an output schema, and rich annotations, the description fully captures the purpose, scope, and relationship to nearby tools. Nothing critical is missing.

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

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

Schema descriptions cover 100% of the parameters: event_id is described as 'The Partiful event ID' and fields are fully listed with dot-path semantics. Since the schema already provides clear parameter meaning, the description adds no additional parameter-level detail, warranting the baseline score 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 uses a specific verb ('Get') and clearly defines the resource: 'guests you have in common with a specific Partiful event.' It also explicitly distinguishes the tool from two key siblings (get_guests and get_mutuals), making its purpose 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 explicitly states when to use this tool by contrasting it with alternatives: 'Distinct from get_guests (every guest, not just mutual ones) and get_mutuals (your mutual connections generally, not scoped to one event).' This provides clear exclusions and context for selecting this tool.

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, openWorldHint, idempotentHint, and destructiveHint, so the safety profile is established. The description adds valuable context: it explains the return format ('array of user profiles (id, name, display name, username)') and the scope behavior (not event-specific). This goes beyond what annotations provide.

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

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

The description is three concise sentences, each serving a clear purpose: defining the tool, stating the return shape, and clarifying scope with an alternative. 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?

Given the tool's simplicity (one optional parameter, output schema present, annotations provided), the description fully covers the core behavior, return structure, and sibling differentiation. It is contextually complete for an agent to select and invoke the tool 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 100% with the 'fields' parameter fully described in the input schema, including available dot-path fields. The description adds no additional parameter meaning, so the baseline of 3 is appropriate.

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

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

The description clearly states a specific verb and resource: 'Get your mutual connections on Partiful — people you've been at the same events with.' It also differentiates from the sibling tool get_mutual_guests by explicitly stating this is not scoped to a single event. This makes the tool's purpose unambiguous and distinct.

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 usage guidance: 'Not scoped to a single event; use get_mutual_guests instead if the question is about one specific event's guest list.' This clearly states when to use this tool and when to use an alternative, exceeding a mere implication.

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, destructiveHint=false, and idempotentHint=true, so the safety profile is well-established. The description adds valuable context by specifying the return format: an array of community objects with id and name. This goes beyond annotations without contradicting 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?

Two short sentences: the first states the primary purpose, the second states the return shape. No filler words or redundancy. The description is front-loaded and every word contributes.

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

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

Given the simplicity of the tool (one optional parameter, clear read-only semantics, and an output schema present), the description is complete. It tells the agent what the tool returns and what scope applies. There are no complex side effects or hidden behaviors that need disclosure.

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's description of the 'fields' parameter is fully descriptive (dot-path field names, omission behavior, available fields). Since schema coverage is 100%, the description does not need to repeat parameter details. It adds no extra semantics but also doesn't conflict with the schema.

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

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

The description clearly states the verb ('Get') and the specific resource ('Partiful communities you belong to'), which distinguishes it from sibling tools that retrieve other entity types (events, contacts, etc.). It explicitly scopes the operation to 'you' (the authenticated user), removing ambiguity.

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

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

The description implies a clear use case: fetching the current user's communities. However, it does not mention when to use this tool versus alternatives or any exclusions (e.g., 'use get_communities for all communities'). No explicit comparison or exclusion criteria are provided beyond the natural scope of 'you belong to.'

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/openWorldHint/idempotentHint and destructiveHint=false, so safety is covered. The description adds meaningful behavioral context beyond annotations by defining what 'following' means (events from hosts/pages followed without necessarily RSVPing) and by clarifying the event array return. It doesn't cover pagination or rate limits, but the low-risk read-only nature plus semantic context justifies a 4.

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, no fluff. The first sentence front-loads the primary purpose and output; the second sentence efficiently disambiguates from sibling tools. Every phrase 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 tool's simplicity (one optional param, read-only, output schema present), the description fully covers the necessary context: what the tool returns, the semantics of 'following', and differentiation from closely related tools. The schema documents parameters and output, so no further return-value explanation is needed.

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, 'fields', has a detailed description in the schema with a full list of dot-path field names and instructions to omit for all fields. Schema coverage is 100%, so the description correctly does not add extra parameter details. Baseline 3 applies because the description adds no parameter-specific semantics beyond the schema.

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

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

The description uses a specific verb ('Get') and resource ('Partiful events you're following'), clearly stating the output format ('as an `events` array'). It explicitly distinguishes the tool from get_my_saved_events, get_discoverable_events, and get_my_rsvps, making the purpose unambiguous even among many siblings.

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

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

It provides explicit when-to-use guidance by naming three alternative tools and their semantics: saved events (bookmarked), discoverable events (public invite), and RSVPs (invited/RSVPed). This tells the agent exactly when to choose this tool over those 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, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the 'pastEvents' array return shape and past-filtering behavior, but does not disclose additional behavioral details like rate limits or pagination. With annotations present, this level of added context warrants a 3.

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 exactly two sentences: the first states the core purpose and output, the second provides sibling differentiation. Every word earns its place, and the key information is front-loaded.

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 only one optional parameter, no required arguments, an output schema, and comprehensive annotations, the description fully covers purpose, scope, and alternatives. No critical context is missing for correct selection and invocation.

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

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

The single parameter 'fields' has 100% schema description coverage, listing all available dot-path fields in detail. The description adds no additional parameter semantics beyond what the schema already provides, so the baseline score of 3 is appropriate.

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

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

The description uses a specific verb ('Get'), clearly identifies the resource ('your past Partiful events'), and provides precise context ('for the home page All past events tab'). It also distinguishes the tool from siblings by naming the counterpart and alternative, making its purpose 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?

Explicitly states this is the past-only counterpart to get_my_upcoming_events_for_home_page and directs users to get_my_rsvps for complete history. This gives clear when-to-use and when-to-use-alternative guidance, going beyond implied usage.

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, openWorldHint, idempotentHint, and destructiveHint. The description adds meaningful context about the inclusivity of the result set (invited or RSVPed, any status/time) and the richness of data returned, which goes beyond the annotation safety profile. It does not mention potential pagination or rate limits, but the output schema covers return structure.

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, the first immediately states the main purpose and output. The second sentence is dense with sibling comparisons but each mention is necessary for disambiguation. No fluff or repetition; 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?

Given the simple parameter structure (one optional field selector), rich output schema, and thorough annotations, the description sufficiently covers what the tool does, what it returns, and how it differs from alternatives. No critical gaps for an agent to select and invoke 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 description coverage is 100% for the single 'fields' parameter, so the schema fully documents its syntax and options. The description highlights that the tool returns the 'richest per-event data' and lists example fields, which aligns with but does not exceed the schema's list of available fields. Thus 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 'Get' with resource 'every Partiful event you've been invited to or RSVPed to', clearly stating scope ('any status, any time period') and output ('events array with richest per-event data'). It distinguishes from siblings by naming exact alternatives and their differing 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?

Explicitly contrasts with sibling tools: 'Broader than get_my_upcoming_events_for_home_page/get_my_past_events_for_home_page', 'distinct from get_published_events', and 'distinct from get_discoverable_events/get_my_saved_events/get_my_followed_events' with reasons. This provides 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?

Annotations already declare readOnly, openWorld, idempotent, and non-destructive traits. The description adds useful context about the semantic scope ('explicitly saved for later') and the return shape ('as an events array'), though it doesn't detail pagination or ordering. Given strong annotation coverage, this is sufficient and adds value beyond the structured data.

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, no filler. The first sentence front-loads the verb+resource+output shape, and the second sentence provides essential sibling disambiguation. 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?

With a single optional parameter, a complete output schema, and rich annotations indicating a safe read operation, the description fully covers the necessary context. It explains what the tool returns and when to use it, so no gaps remain.

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 'fields' parameter fully documented via a list of all available dot-paths. The description does not mention parameters, so it adds no additional meaning, but the schema already carries the burden. Baseline 3 is appropriate.

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

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

The description clearly identifies the resource ('your saved/bookmarked Partiful events') and the action ('Get'), and explicitly distinguishes it from three named sibling tools. This makes the tool's purpose 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 explicit when-to-use guidance by contrasting with get_discoverable_events, get_my_followed_events, and get_my_rsvps, explaining exactly what each alternative returns. This is the gold standard for sibling differentiation.

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 read-only, idempotent, and non-destructive behavior. The description adds valuable context about the curated future-only nature of the result and the shape as an `upcomingEvents` array, which is beyond structured fields. No contradiction with annotations.

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

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

The description is compact and well-structured: the first sentence states the purpose and return type, and the second sentence gives clear alternatives. Every word earns its place, with no 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?

The description fully covers the tool's purpose, scope, and relationship to sibling tools. With rich annotations, an output schema, and a single optional parameter, no additional context is needed for safe and effective use.

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 single optional `fields` parameter is fully described in the input schema with an extensive list of dot-path options, so schema coverage is 100%. The description does not add further parameter details, but the schema is rich enough that the baseline of 3 is appropriate.

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

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

The description clearly states the tool retrieves upcoming Partiful events specifically for the home page 'Upcoming' view and returns an `upcomingEvents` array. It uses a specific verb and resource, and distinguishes itself from sibling tools like get_my_rsvps and get_published_events.

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

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

The description gives explicit guidance on when to use this tool versus alternatives: it is the future-only, home-page-curated subset, while get_my_rsvps covers complete RSVP/invite history and get_published_events covers hosted-only events regardless of date. This clearly delineates usage contexts.

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, openWorldHint, idempotentHint, and destructiveHint=false, covering the safety profile. The description adds context beyond annotations by specifying the host-only restriction and the nature of the returned data (sales, fees, payable amount), which helps the agent understand what to expect.

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, well-structured sentence that front-loads the primary action and includes essential qualifiers (host-only, ticketed event) without any 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 presence of an output schema and clear annotations, the description sufficiently covers the tool's purpose and access restrictions. It could add details about currency or result formatting, but these are likely covered by the output schema, so the description is complete enough for selection and invocation.

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

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

The schema already covers both parameters with descriptions (event_id and fields, the latter saying 'No selectable fields available'). The description does not add parameter-specific details, but the schema is self-sufficient, so this is adequate. No additional insight is needed beyond the schema.

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

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

The description uses a specific verb ('Get') and clearly identifies the resource ('host payout summary for a ticketed Partiful event'), while also listing the key contents (total sales, fees, amount payable). This distinguishes it from sibling tools like get_guest_payment_info or get_ticket_fee_config.

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 context: it is host-only and applies to ticketed Partiful events. This implies the intended audience and use case, though it does not explicitly name alternatives or state when not to use it.

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 the safety profile (readOnlyHint, openWorldHint, idempotentHint, destructiveHint). The description adds valuable behavioral specifics: it returns null when no request is pending, and describes the response structure. It does not fully detail error handling or authentication, but the extra context meets the bar for a well-annotated 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 two concise sentences, front-loaded with the main action and followed by the return behavior. Every word contributes meaning, with no redundant details or fluff.

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 output schema exists, so return values are already documented. The description adds the conditional null behavior and confirms the response fields, which is sufficient for this simple read-only tool. It doesn't cover edge cases like invalid event IDs, but that is not necessary given the tool's straightforward nature and existing 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?

The input schema already fully describes both parameters (event_id and fields) with dot-path options listed. The description does not add new parameter semantics; it only mentions the response fields, which are already in the schema. With 100% schema coverage, the description provides no additional value here, so the baseline of 3 is appropriate.

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

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

The description clearly states the action ('Get'), the resource ('pending cohost invitation'), the scope ('for a Partiful event by ID'), and a conditional ('if the current user has one outstanding'). It also describes the return value and null case, making it distinct from sibling tools despite their similar names.

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 when to use this tool: to retrieve a pending cohost invitation for a specific event. It provides clear context, but no explicit alternatives or exclusions are mentioned, even though sibling tools like get_cohost_requested_events exist. The narrow purpose makes the use case obvious, but a 5 would require explicit 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?

Annotations already declare read-only, open-world, idempotent, and non-destructive behavior. The description adds valuable behavioral context by specifying that the tool returns events across any time period and summarizing the response structure (events array with title, date, location, guest counts). It does not mention pagination or ordering, but that's beyond what annotations need and the description already adds more than the 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 two sentences, front-loaded with the verb and scope, then immediately gives alternatives. Every sentence carries necessary information without redundancy, making it efficient 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?

With one optional parameter fully covered by the schema, comprehensive annotations, and an output schema present, the description provides sufficient context: it states the purpose, scope, and usage guidance, and doesn't need to repeat return field details. The description enables an agent to select and invoke the tool 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 only parameter, 'fields', is fully documented in the input schema with a description and a comprehensive list of dot-path values. Schema coverage is 100%, so the baseline applies. The description adds nothing beyond schema about how to use the parameter; it only mentions example output fields, not parameter usage.

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 ('Get'), the exact scope ('all Partiful events you are hosting'), and the time range ('any time period'). It also explicitly distinguishes the tool from sibling tools by naming them and explaining the differences (host role vs. attendee, time-scoping).

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 directly instructs when to use this tool over alternatives: 'Use this instead of get_my_rsvps...' and explains why those alternatives are not suitable (attendee status or time-scoped home-page views). 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?

Annotations already declare readOnlyHint, idempotentHint, and non-destructiveHint, covering the safety profile. The description adds the behavioral nuance that omitting event_id returns the platform default, which is useful, but the listing of return fields is redundant given the output schema.

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. It efficiently communicates purpose and the event/default distinction in a compact form.

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 a well-specified schema and output schema, plus annotations, the description covers all essential decision points: the tool's purpose, the meaning of optional event_id, and the type of data returned. No missing prerequisites or side-effect warnings are necessary for this read-only 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?

Both parameters are fully described in the schema with 100% coverage. The description's emphasis on event-specific vs. default behavior is already captured in the event_id schema description, and the available fields are listed in the schema. Thus, the description adds no new parameter semantics beyond the schema.

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

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

The description uses a specific verb 'Get' and clearly identifies the resource: Partiful's ticketing fee configuration, enumerating the components (flat fee, fee rate, custom rate indicator). This clearly distinguishes it from siblings like get_event_ticketing_eligibility or get_tickets_for_event, which address different ticketing aspects.

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 explains the two usage modes: for a specific event via event_id or for the platform default when omitted. It does not explicitly name alternatives, but the scope is clear and no sibling tool overlaps with fee configuration, so an agent can infer when to use it.

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, idempotentHint, and destructiveHint, so the safety profile is known. The description adds valuable context: the tool is host-only and works for ticketed events, which implies access restrictions and preconditions not present in 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 sentences with no redundant wording. It front-loads the main purpose and then efficiently differentiates from sibling tools. 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 read-only getter with an output schema, the description covers purpose, access restriction, and distinctions from related tools. It does not mention error cases or behaviors for non-ticketed events, but these are secondary. Overall it is complete enough.

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 both event_id and fields are described. The description does not add parameter-level detail beyond the schema, but the schema itself is adequate. Baseline 3 is appropriate.

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

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

The description clearly states the tool gets all tickets sold for a ticketed Partiful event, with a specific verb and resource. It explicitly distinguishes itself from get_tickets_for_ticket_type and get_guest_payment_info, making the scope 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 names two alternatives and explains how they differ: get_tickets_for_ticket_type is scoped to one ticket type, and get_guest_payment_info covers one guest's payment history. This gives clear guidance on when to choose this tool over those.

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, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds value by disclosing the host-only access requirement and the narrower scope relative to the sibling tool, which is useful behavioral context beyond the annotations.

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

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

The description is two sentences: the first states the core functionality and access requirement, the second gives a direct comparison to a sibling tool. Every word earns its place; there is no redundancy or unnecessary detail.

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 that the tool has an output schema, return values are already documented. The description covers the purpose, access constraint, and the relationship to the nearest sibling tool, which fully equips an agent to select and invoke it correctly.

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

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

The schema description coverage is 100% and both required parameters (event_id and ticket_type_id) have clear descriptions. The tool description does not add extra parameter-level detail, but the schema already provides complete semantics, so a baseline of 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-resource pair ('Get all tickets sold for one ticket type') and explicitly distinguishes it from the sibling get_tickets_for_event by noting the narrower scope. This makes the tool's purpose unambiguous and differentiates it from similar 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 states that this tool is 'host-only' and explicitly compares it to get_tickets_for_event ('every ticket on the event, all types'), making it clear when to use this tool versus the broader sibling. This is explicit usage 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 declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. The description adds useful behavioral context beyond annotations by stating that party stats are 'baked into every response,' implying the response always includes those stats regardless of field selection. This is a non-obvious behavior not captured in annotations or schema.

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 primary purpose, then a clear alternative. Every sentence contributes: the first defines the tool's scope, the second provides sibling differentiation. No filler or 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?

With 2 parameters, complete schema coverage, an existing output schema, and strong annotations, the description covers everything needed: what it fetches, what fields are returned, and when to use a more specific alternative. It is sufficiently complete for an agent to select and invoke the tool 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 description coverage is 100% for both parameters (user_ids and fields), providing dot-path field details and array semantics. The description adds value by clarifying that party stats are always included even if fields are specified, which is not explicitly stated in the schema. This enhances the meaning of the 'fields' parameter.

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

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

The description clearly states the tool 'Fetch Partiful user profiles by their IDs' with specific verb and resource. It lists return fields (name, display name, username, profile image) and explicitly distinguishes from sibling get_users_party_stats by noting the party stats are included and when to use the alternative.

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

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

The description provides explicit usage guidance: 'Use get_users_party_stats instead if you only need attended/hosted event counts, not full profile info.' This directly tells the agent when not to use this tool and names the alternative.

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 read-only and idempotent behavior, so the bar is lower. The description adds context by specifying the return shape ('statsByUserId') and noting what it does not return (full profile info), which informs expected behavior 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 sentences, front-loaded with the tool's core purpose, then a useful contrast, then the return shape. Every sentence earns its place with no 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 simple batch lookup, the presence of an output schema, and strong annotations, the description is complete enough for the agent to select and invoke the tool correctly. It covers purpose, when to use, and 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?

Schema coverage is 100% with descriptions for both parameters. The description adds minimal extra meaning beyond noting 'batch' and the return key, so the baseline of 3 is appropriate as schema carries the heavy lifting.

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

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

The description clearly states it 'Get just the party stats' for 'a batch of Partiful user IDs', using a specific verb and resource. It explicitly contrasts with the sibling get_users, distinguishing itself by what it returns and omits.

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 clearly indicates when to use this tool by noting it is 'lighter weight than get_users' and explaining what get_users returns instead. This implies use this for stats-only needs, though it doesn't explicitly state exclusions or alternative scenarios.

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 explicitly labels it as a 'write action' that 'changes state on your account,' adding context beyond the annotations (which already indicate readOnlyHint=false). It also warns against speculative calls, providing behavioral nuance. While the annotations already cover idempotency and non-destructiveness, the description adds meaningful intent guidance, so it earns a 4.

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 primary action, and every sentence earns its place. The warning about speculative use is valuable and not redundant. It is ideally sized for quick comprehension.

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 state-changing operation, the annotations (readOnlyHint, idempotentHint, destructiveHint) and the presence of an output schema, the description is fully sufficient. It explains what the tool does, when to use it, and its side effects, leaving no critical gaps for an agent to fill.

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 description does not discuss parameters, but the input schema already provides clear descriptions for both 'event_id' (the Partiful event ID) and 'fields' (though it says no selectable fields are available). With 100% schema description coverage, the description need not add parameter details, so the baseline of 3 is appropriate.

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

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

The description clearly states the tool's function: 'Mark all notifications for a Partiful event as read.' This is a specific verb ('mark') and resource ('notifications for a Partiful event'), and it naturally distinguishes itself from the many read-only sibling tools (all 'get_*' tools) by indicating a state-changing action.

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 explicit guidance on when to use: 'Only call this when the user's intent is clearly to mark notifications read; do not call it speculatively to 'check' notification state.' This clearly delineates appropriate from inappropriate use, which is especially important given the sibling tools are all read-only.

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