DC Member API

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

Discloses read-only nature (GET, one-way), visibility scoping by user role, and flat feed format. With no annotations, the description carries the full burden and effectively covers key behaviors. Could mention rate limits or response structure but covers essential 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?

Three sentences front-load the HTTP method and purpose, then add details and constraints. No wasted words; every sentence adds value. Efficient and clear.

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 no output schema, the description covers the main behavioral aspects (read-only, visibility, content scope, ordering). Missing is explicit mention of pagination details (e.g., nextCursor field), but overall complete for a simple list 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?

Input schema has 100% coverage with descriptions for both parameters (limit, cursor). The description adds context about ordering ('newest-first') but does not elaborate on parameter usage beyond schema. Baseline score of 3 is appropriate as schema already does 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?

Clearly states it lists recent announcements from DC's broadcast channels. Distinguishes from sibling 'announcements_latest' only implicitly by describing the full feed rather than the latest one. Could be more explicit about the difference.

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?

Describes what the tool cannot do (no posting, replying, per-channel filtering), implying when not to use it. Lacks explicit guidance on when to use this versus the sibling 'announcements_latest' or other tools. Usage context is inferred rather than prescribed.

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?

Without annotations, the description fully covers behavioral aspects: it indicates this is a GET request (read-only), explains no pagination, states the result size equals the number of visible channels (~4), and details visibility rules for DC members vs. DC BLACK. No contradictions.

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

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

The description is extremely concise, with two short paragraphs. The first line is a clear summary with endpoint, verb, and overview. Every sentence adds value: purpose, usage, visibility, pagination, alternatives. No wasted words.

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

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

For a tool with zero parameters, no output schema, and simple functionality, the description is complete. It covers what the tool returns, visibility rules, pagination behavior, and even suggests the alternative. All necessary information is present.

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?

With zero parameters and 100% schema coverage, no additional parameter documentation is needed. The description adds no param info, but none is required. Baseline of 4 is appropriate as the schema already fully describes the parameter structure (empty).

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 latest announcement per channel via 'GET /announcements/latest' and explicitly differentiates it from the full feed tool 'GET /announcements'. The verb 'returns' with 'single most recent announcement' specifies the action and resource precisely.

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 advises using this tool as a 'quick check before drilling into the full feed' and names the alternative 'GET /announcements'. It also clarifies visibility rules identical to that sibling, giving clear context for when to use this vs. the full feed.

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 transparently explains the output (three URLs, toggles) and notes deterministic tokens. Without annotations, it covers behavior adequately, though authentication requirements are not explicitly stated.

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 well-organized with bullet points and clear sections, front-loading the purpose and then detailing the URLs. No unnecessary sentences.

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 no output schema, the description thoroughly covers the return values. It could mention if the URLs require authentication, but overall it provides sufficient context for a simple retrieval 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?

With zero parameters and 100% schema coverage, the description adds value by detailing the response structure and the meaning of each URL, beyond the empty input 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 it retrieves the iCalendar feed URL and settings. It distinguishes itself from siblings like 'calendar_update' by focusing on read-only retrieval of the feed configuration.

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 what the tool returns and includes details about the three URLs and toggles. It implicitly indicates this is for retrieving settings, but could be more explicit about when to use versus modifying tools like calendar_update.

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?

Without annotations, the description discloses that this is a WRITE operation mutating account data, returns { updated: true }, and that feed URLs are stable. This is sufficient for the tool's simplicity.

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

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

Every sentence adds value, uses bullet points and an emoji for the warning. It is concise and well-structured with no 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?

Covers return value, re-fetching for full data, and partial update behavior. Lacks error handling details but is adequate for a simple update 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?

Although schema coverage is 100%, each parameter only says 'Boolean'. The description adds meaning by calling them 'calendar feed toggles' and explaining partial update semantics.

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

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

The description clearly states the tool updates calendar feed settings, specifies it is a PATCH operation, and distinguishes itself from the sibling 'calendar' tool which likely retrieves 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?

It instructs to send only toggles to change and to re-fetch GET /calendar for full data, providing clear usage context. However, it does not explicitly state when not to use 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?

Without annotations, the description transparently explains the returned data: members and visitors, with filtering of hidden/guest profiles and limit of 100 members. It lacks details on authentication, rate limits, or potential errors, but covers the essential behavior well.

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

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

The description is concise with a clear header and bullet points. No extraneous words; every sentence adds value. It is well-structured 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 lack of output schema, the description explains the main return fields (members, visitors) and their structures. It does not mention other chapter details or error cases, but for a simple tool with one parameter, it is sufficiently complete for most use cases.

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

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

The input schema already describes cityID as 'Chapter ID (same as Google Place ID)' with 100% coverage. The description adds no additional parameter semantics beyond the URL notation, so it meets the baseline but does not exceed.

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

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

The description clearly states the tool's purpose with 'GET /chapters/:cityID — Get a single chapter' and elaborates on the specific data returned (members and visitors). It distinguishes from the sibling 'chapters' tool by specifying 'single chapter' and the details included.

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 a specific use case ('who is in <city> right now?') but does not explicitly mention when to use alternatives like 'chapters' for listing all chapters or 'search_chapters' for searching. Guidance is present but not comprehensive.

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?

No annotations provided, but the description discloses sorting by member count, pagination via cursor, and that each chapter has a Google Place ID. It does not mention auth or rate limits, but as a GET list endpoint, the description is fairly transparent.

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

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

Three concise sentences with clear structure: endpoint introduction, output usage with cross-reference, and see also for sibling. No unnecessary 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?

Covers core functionality and distinguishes from sibling. However, without an output schema, it does not describe the full return format (e.g., fields of a chapter), which could be helpful for 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?

Schema coverage is 100% with param descriptions. The description adds context about member count sorting and cursor pagination, but does not add new meaning beyond the schema for the parameters themselves, so baseline 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 clearly states the tool lists all DC chapters sorted by member count, and distinguishes from the sibling tool search_chapters for searching by city/country name, providing a specific verb+resource+sorting.

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 when to use this tool (list all chapters) and when to use the alternative search_chapters (for specific city/country search), and mentions how to use the output for creating trips via POST /trips.

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?

No annotations provided. Description indicates a read operation ('GET') and mentions return of ticket status, but lacks details on authentication, side effects, or rate limits. Adequate but not rich.

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

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

Two concise sentences that front-load the HTTP method and purpose. No unnecessary 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 simple one-parameter read-only tool, the description covers the essential outcome (full details, ticket status). Lacks response structure but acceptable given no output schema.

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

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

Schema description coverage is 100% and already defines 'eventID' as 'The event ID'. The description reinforces that eventID identifies the event without adding new semantics. Baseline 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?

Description clearly states the verb ('GET', 'get'), resource ('event'), and scope ('full details including your ticket status'). Distinguishes from sibling tools like 'events' (list) and 'event_agenda' (specific subset).

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?

Implicitly clear that this tool is for retrieving full event details including ticket status. No explicit when-not-to-use or alternatives, but purpose is clear enough for an agent to decide.

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

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

With no annotations, the description carries the full burden. It correctly implies a read-only GET operation and specifies an access requirement (valid ticket). It does not mention other behavioral aspects like rate limits, but the operation is simple and non-destructive.

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 well-structured: a header with the endpoint, a concise explanation, bullet points listing the agenda contents, and a separate access and management note. It is efficient without being overly long.

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 absence of an output schema, the description sufficiently explains what the tool returns (sessions and meetups). It also covers the access prerequisite. For a simple read operation, the description 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?

The sole parameter `eventID` has a schema description 'Event ID', and schema coverage is 100%. The description adds no additional context about the parameter beyond the schema, 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 clearly states the tool's purpose: to GET the user's personal agenda for an event. It specifies what constitutes the agenda (bookmarked sessions and RSVPed meetups). However, it does not explicitly differentiate from sibling tools like `event_agenda_get` and `event_agendas`, leaving ambiguity about their specific roles.

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 a key usage condition: the caller must hold a valid ticket. It also suggests related endpoints for managing agenda entries. However, it does not guide when to use this tool versus similar siblings (e.g., `event_agendas`), which would improve decision-making.

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

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

With no annotations, the description carries full burden. It discloses the return content (bookmarked sessions + meetup RSVPs) and error condition (404 if no ticket). It does not mention permissions, rate limits, or side effects, but for a read-only GET, this is sufficient and transparent.

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

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

The description is concise with two focused paragraphs. The first explains the action and use case, the second covers access conditions. Every sentence contributes meaningfully with no 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 tool's simplicity (2 params, no output schema), the description is complete: it explains what is returned, the use case, access rules, and error case. No missing aspects like pagination or format are 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?

Schema coverage is 100%, baseline 3. The description adds value by clarifying 'userID' is the target attendee and 'eventID' is the event, and contextualizes them within the use case of viewing another's agenda. This goes beyond the schema's basic descriptions.

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 another attendee's personal agenda (bookmarked sessions + meetup RSVPs) for an event, using a specific verb 'Get' and resource 'another attendee's agenda'. It distinguishes from siblings like event_agenda (probably own agenda) by specifying 'another attendee' and provides a concrete use case for planning together.

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 guides when to use the tool ('plan together with another DCer') and gives access conditions (open to active DCers who can see the event, target must have a valid ticket). It does not explicitly list alternatives or when not to use, but the context is clear.

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

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

With no annotations, the description fully carries the behavioral disclosure burden. It clearly states that non-attendee IDs are silently dropped, and that results are returned in the order requested. Access is described as open to active DCers who can see the event. This is fairly comprehensive, though it could mention if the response is paginated or has a size limit.

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 well-structured with a one-line summary, a usage paragraph, and labeled sections (Query, Behavior, Access). Every sentence adds value without redundancy, making it 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?

The description covers purpose, parameters, behavior, and access. It mentions the return content (bookmarked sessions + meetup RSVPs) but lacks details on response structure, especially since no output schema is provided. Overall, it provides sufficient context for an AI agent to use the tool effectively.

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 provides detailed descriptions for both parameters (eventID and userIDs), including the comma-separated format and max 20 IDs. The description reinforces this but does not add new semantic information beyond the schema, warranting a 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 explicitly states the tool's purpose: retrieving agendas for multiple attendees in a single call. The verb (GET) and resource ('agendas for multiple attendees') are clear, and the multi-attendee focus distinguishes it from sibling tools like event_agenda.

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 scenarios: planning around several DCers, comparing schedules, finding shared sessions, building invite lists. It also notes access constraints and silent dropping of non-attendees, giving clear guidance on when to use 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?

No annotations provided, so description carries full burden. Details filtering logic, profile shape, and accessibility, providing clear behavioral expectations.

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?

Well-structured with clear sections: header, logic, output shape, access. Every sentence adds value without redundancy.

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

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

Explains output profile shape and privacy-gated fields despite no output schema. Covers all necessary context for a 2-parameter 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 has 100% coverage for both parameters. Description adds endpoint path and context about filtering but not additional parameter details beyond 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?

Clearly states 'List event attendees' with specific criteria (valid paid ticket or valid/maybe RSVP). Distinguishes from sibling `event_meetup_attendees` implicitly by focusing on 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?

Specifies access ('any active DCer') and what is excluded (refunded/canceled tickets, hidden/guest profiles). Does not explicitly mention alternatives, but context is sufficient for a list 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?

No annotations provided, so description carries full burden. It explains WRITE operation, slot grid computation, sorting, and auth requirements. Discloses that non-attendee IDs are silently dropped.

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?

Well-structured with clear sections, precise language, and no unnecessary sentences. Efficiently conveys all needed 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?

Covers return value (slots ranked by freeFor), auth, edge cases (non-attendees), and constraints (minDuration, etc.). Complete despite no output schema.

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

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

All parameters are described in schema (100% coverage), but description adds practical context like defaults, ranges, and purpose, exceeding schema alone.

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?

Clearly states it finds shared free time slots across attendees, specifies endpoint, and distinguishes from siblings. No sibling has similar purpose.

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

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

Provides concrete use cases (coffee window, lunch slot) and mentions auth requirement and silent dropping of non-attendees. Does not explicitly say when not to use, but context is clear.

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

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

No annotations provided; description indicates read-only GET and access requirement but omits details on pagination, ordering, 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?

Two sentences plus access line; endpoint pattern front-loaded; 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?

References output shape via another endpoint, but lacks pagination info and error handling; adequate for a list tool without output schema.

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

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

Schema covers both parameters with basic descriptions; description adds context that meetupID is for a specific meetup within an event, but adds little beyond 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?

Description clearly states 'List meetup attendees' with specific resource and verb. Distinguishes from siblings like event_attendees and event_meetup_rsvp.

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

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

Specifies access (any active DCer who can see event) and references output shape via another endpoint, but lacks explicit when-not-to-use or alternative selection 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?

With no annotations, the description fully covers behavioral traits: declares it a write operation, mentions atomic and idempotent update of rsvpCount, and details side effects on linked chat channels.

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?

Concise at 5 sentences. Uses clear structure: HTTP method and path, then action, then prerequisites, then side effects, then warning. No 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?

Lacks output schema description, but the tool's effect and side effects are well explained. Could mention response structure or error conditions, but not essential for a simple RSVP 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?

Schema coverage is 100%, so the baseline is 3. The description adds no extra parameter meaning beyond what the schema already provides for 'joined', 'eventID', and 'meetupID'.

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 ('join or leave a meetup') and the resource ('meetup'). It distinguishes from siblings like 'event_rsvp' (for events) and 'event_meetup_attendees' (likely read-only).

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?

Describes when to use (to RSVP/join/leave a meetup) and prerequisites ('requires a valid ticket'). Mentions side effects (chat subscription) but doesn't explicitly state when not to use or list 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?

No annotations are provided, so the description carries full burden. It discloses that only approved meetups are returned, sorted chronologically, and explains time-zone handling with explicit wall-clock fields and IANA timezone. Access rules are clearly stated, and no contradictions exist.

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 well-structured with clear sections (introduction, access, time-zone handling). Every sentence adds value without redundancy. It is appropriately sized and 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 no output schema, the description adequately explains returned data (approved meetups, sorted chronologically) and includes access and time-zone handling. It covers essential aspects for the tool's purpose, though exact fields of meetup objects are not specified.

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?

Only one parameter (eventID) with schema description 'Event ID'. The description does not add significant semantic details beyond the schema, but the endpoint path and context indicate its use. Since schema coverage is 100%, 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 explicitly states 'GET /events/:eventID/meetups — List event meetups' and explains it returns approved member-organized meetups sorted chronologically. It clearly distinguishes from siblings like event_meetup_attendees and event_meetup_rsvp that deal with individual meetup actions.

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 on when to use this tool: to list approved meetups for an event. It details access requirements (any active DCer who can see the event) and necessary conditions for further actions (RSVP requires ticket). However, it does not explicitly state alternatives or when not to use.

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 warns that this is a WRITE operation that mutates account data, which is critical behavioral context. Since no annotations are provided, the description carries the full transparency burden. It does not detail return format or error handling, but the note about mutation is sufficient for a simple write 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 concise, with only a few sentences that front-load the endpoint and primary action. No redundant information, and the structure is clear.

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 tool with no output schema, the description explains the key constraints (rsvpEnabled) and mutation nature. It lacks details about overwriting existing RSVPs or return values, but the information provided is sufficient for typical 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?

Schema coverage is 100%, with both parameters described in the schema. The description adds context about the 'free RSVP' constraint, which indirectly relates to the 'status' enum, but does not add significant detail beyond the schema. Baseline 3 is appropriate.

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

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

The description clearly states the tool's purpose: 'POST /events/:eventID/rsvp — RSVP to a free event'. It specifies the verb (RSVP) and resource (event), and distinguishes from ticketed events and sibling tools like event_meetup_rsvp and virtual_event_rsvp by noting 'free RSVP (not ticketed)'.

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 usage conditions: 'Only works for events with rsvpEnabled: true' and 'RSVP to a free event (not ticketed)'. However, it does not explicitly state when to use alternatives like event_meetup_rsvp, although sibling tool names imply those are for meetup/virtual events.

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?

No annotations provided, so description must disclose behavior. It describes returning upcoming DC events sorted by date and pagination via cursor, but suggests additional query parameters (cityID, country, since, until) not present in the input schema, which could mislead the agent.

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

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

Three sentences plus a 'See also' section, front-loaded with the core purpose, no wasted words, uses markdown for clarity.

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?

Adequate for a list endpoint but lacks details on the response structure (e.g., fields of each event) and does not address rate limits or authentication needs, given no annotations or output schema.

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

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

Schema coverage is 100% with descriptions for all three parameters. The description adds context for 'past' and cursor pagination, but introduces four unsupported parameters (cityID, country, since, until) that are not in the schema, causing inconsistency and potential confusion.

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 'List upcoming events' with a specific verb and resource, distinguishes from sibling 'search_events' by noting different use cases (date-sorted vs search by name/topic).

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 suggests using 'search_events' for name/topic queries and mentions combining filters like cityID, country, since, until for narrower scopes, though it doesn't explicitly state when to avoid 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?

With no annotations, description provides thorough behavioral details: time-zone handling (ISO 8601 strings in venue-local wall-clock time, timezone field), access rules, and sorted output. No contradictions.

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

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

Concise, front-loaded with main action. Three short paragraphs: endpoint & function, access, timezone handling. No unnecessary 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?

Covers return structure (full schedule, sorted, with timezone info). No output schema, but description compensates. Could mention if pagination exists, but likely not needed for full schedule.

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%, baseline 3. Description does not add extra meaning about the eventID parameter beyond what schema provides (just 'Event ID'). Adequate but not improved.

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

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

Description clearly states it returns the full schedule (sessions) for an event, sorted chronologically. It includes the endpoint path and verb (GET /events/:eventID/schedule), and distinguishes from sibling tools like event_agenda.

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?

Describes access conditions: any active DCer who can see the event can view public schedule, but personal agenda actions require ticket. No explicit when-not-to-use or comparisons with siblings, but context is clear.

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

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

No annotations are provided, so the description carries the full burden. It explains the bookmarking behavior and implies it is read-only via the GET method in the path. However, it does not explicitly state idempotency or side effects.

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

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

The description is concise and front-loaded with the endpoint path and purpose. Every sentence is necessary and adds value without redundancy.

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

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

Given the tool's simplicity (2 params, no output schema), the description covers the key aspects: purpose, access, and relation to event_attendees. It could mention pagination or response structure, but the reference to event_attendees helps.

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 covers both parameters (eventID, sessionID) with descriptions, achieving 100% coverage. The description adds no additional meaning beyond the schema, such as format or constraints, so a baseline score of 3 is appropriate.

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

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

The description clearly states the tool lists session attendees who have bookmarked the session, using the verb 'List' and specifying the resource as session attendees. It distinguishes from siblings like event_attendees by focusing on bookmarkers.

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 mentions access requirements ('any active DCer who can see the event') but does not explicitly guide when to use this tool versus alternatives like event_attendees or event_schedule_bookmark. The hint about same profile shape is helpful but not directive.

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?

Describes atomic and idempotent update of rsvpCount, and warns it's a write operation mutating account data. No annotations provided, so description carries full burden; it covers key behaviors well.

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?

Concise with a clear header, brief paragraphs, and a warning emoji. Front-loaded with purpose. Could be slightly shorter but structure is effective.

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

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

Covers prerequisites, idempotency, atomic update, and write nature. No output schema, so return values not required. Missing error details but overall adequate for 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%, and description adds no extra meaning beyond the schema. Baseline of 3 applies; the description aligns with schema but doesn't enrich it.

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 bookmarks/unbookmarks a session, equating it to the bookmark/star icon. It distinguishes from sibling tools like event_rsvp by specifying it modifies the personal agenda.

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 mentions prerequisite (valid ticket) and that it's a write operation. It doesn't explicitly exclude alternatives but implies use case is toggling bookmark state. Clear context for when to use.

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

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

With no annotations, the description carries full burden. It transparently discloses ordering, filtering of deleted sponsors, and access restrictions. It does not explicitly confirm idempotency, but the HTTP GET method implies it. The behavior is clearly described without contradiction.

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 highly concise with three focused sentences. It front-loads the endpoint and purpose, then adds ordering, filtering, and access details with no wasted words.

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

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

Given the tool's simplicity (1 parameter, no nested objects, no output schema), the description covers purpose, behavior, and access adequately. However, it lacks details on the output structure (fields of each sponsor), which would be helpful since no output schema is provided.

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 describes the single parameter 'eventID' with 100% coverage. The description adds no additional semantic detail beyond the schema, meeting the baseline of 3 for high coverage without extra value.

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 event sponsors for a given event, specifying the HTTP method and path. It explicitly mentions ordering by tier and display order and filtering of deleted sponsors, making its purpose distinct from sibling tools like event_attendees or event_rsvp.

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

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

The description provides access restrictions (any active DCer who can see the event), which guides when the tool can be used. However, it does not explicitly contrast with alternative tools or provide conditions for when not to use it. For a simple list tool, this is sufficient but not fully explicit.

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

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

Despite no annotations, the description explicitly states 'WRITE operation: this mutates your DC account data.' It also discloses idempotency and the 409 error on hitting the cap, providing full behavioral transparency.

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

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

The description contains extraneous information about the digest sections (favoritePeople, favoriteCities) which is not directly relevant to the tool's action. The core description could be more concise without sacrificing clarity.

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 one parameter and no output schema, the description covers all necessary aspects: the action, preconditions, idempotency, cap, and side effects. It is complete for the agent to understand when and how to invoke it.

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 describes cityID as 'Chapter ID (Google Place ID).' The description adds significant value by specifying how to obtain the cityID: from 'GET /chapters (each entry has cityID)' or 'GET /places/search (type === "city").' This goes 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 clearly states 'POST /follows/chapters/:cityID — Follow a chapter' and 'Follow a DC chapter (city hub).' The verb 'follow' and resource 'chapter' are explicit. It distinguishes from siblings like 'follows_chapters' (list) and 'follows_chapter_delete' (unfollow) by focusing on creation.

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 preconditions: 'Target must exist in the chapters list (discover via GET /chapters).' It also mentions the cap of 50 and the resulting error code. However, it does not explicitly state when not to use (e.g., if already following), though idempotency implies it is safe.

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?

No annotations provided, so description carries full burden. Clearly states it's a WRITE operation (mutation) and idempotent. Adds useful behavioral context beyond the minimal purpose.

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?

Extremely concise: three short lines including endpoint, action, and warning. No wasted words; 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?

For a simple one-parameter delete tool, description covers purpose, behavior, and idempotency. Lacks return value details, but no output schema exists. Adequate for 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 describes cityID as 'Chapter ID to unfollow' with 100% coverage. Description adds no additional meaning beyond the schema, meeting baseline.

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

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

Description clearly states the verb (unfollow), resource (chapter), and action. It explicitly says 'Unfollow a chapter' and gives the HTTP method and endpoint. Distinguishes from sibling tools like follows_chapter_create.

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

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

States idempotency (safe to retry), and marks as WRITE operation. Provides context for when to use (unfollowing). Lacks explicit comparison to alternatives, but the purpose is specific enough.

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

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

With no annotations, the description carries the burden. It states the tool lists followed chapters, has a cap of 50, and its role in locator_digest. It implies a read-only operation and requires authentication (as it references 'your' follows). No contradictions.

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

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

The description is three sentences, each providing essential info: the endpoint and basic action, details about entries and cap, and integration with locator_digest. No wasteful text; front-loaded with the primary purpose.

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

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

The description explains the return structure and cap, which is adequate for a 0-parameter tool without output schema. It also gives a use-case. However, it doesn't mention pagination or whether the list is ordered, but the cap implies a fixed set. Slightly incomplete but sufficient.

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

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

The input schema has zero parameters, so the description need not add parameter meaning. It instead adds value by describing the return content (Google Place ID, cap), which is beneficial given no output schema. This exceeds the baseline expectation.

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 starts with 'List followed chapters', clearly specifying the action and resource. It explains that chapters are city hubs and that each entry includes a Google Place ID, making the tool's purpose very clear. It also differentiates from sibling tools like follows_chapter_create and follows_chapter_delete by focusing solely on listing.

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 this tool is for reading followed chapters, and the sibling tools for creating/deleting are separate. It mentions a cap of 50 follows, indicating limitations. However, it does not explicitly state when to use this over alternatives like follows_profiles, but the context is clear enough.

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?

No annotations are provided, so the description carries the full burden. It discloses the cap of 150 follows, the echoed cap field, and connection to locator/digest features. Authentication or mutation safety is not mentioned, but for a list endpoint 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 concise with two short paragraphs. The first sentence states the purpose, followed by useful details. Some extra context about locator/digest could be moved, but overall it's well-structured and not verbose.

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

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

Given the tool has no parameters and no output schema, the description provides sufficient context: what it does, the response shape, a practical limit (150), and downstream integrations. It is complete for an agent to 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?

The input schema has no parameters, so schema coverage is 100%. The description adds value by explaining the response structure and the cap, which are not in the schema. With no parameters, a baseline of 4 is appropriate.

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

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

The description clearly states 'List the DCers you are currently following,' using a specific verb and resource. It distinguishes itself from sibling tools like follows_profiles_by_id_create (add a follow) and follows_profiles_by_id_delete (remove a follow) by focusing on listing.

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 that it returns a list of followed profiles with a cap of 150 and that the same mini-profile shape is used elsewhere, implying it's for read-only access. However, it does not explicitly state when to use this tool over alternatives (e.g., for mutations), though the sibling names provide context.

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?

Since no annotations are provided, the description fully discloses behavioral traits: WRITE operation, idempotency, error codes (404, 409), and response structure (mini-card and count). This goes beyond minimal expectations.

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 efficient (~120 words) with a clear structure: HTTP method, action, idempotency, conditions, error handling, response, and a note on downstream usage. The locator digest mention is slightly tangential but 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 follow tool with one parameter and no output schema, the description covers usage, constraints, and error scenarios. It lacks details on authentication or userID format specifics, but overall it is sufficient.

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 the userID parameter (100% coverage), including where to discover it. The description adds no new parameter-level details, so it meets the baseline but does not exceed it.

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 'Follow a DCer', specifying the exact action and resource. It distinguishes itself from sibling tools like follows_chapter_create (follow a chapter) and follows_profiles_by_id_delete (unfollow) by focusing on following a profile.

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 conditions for use: idempotent, target must be public, cannot follow self, cap of 150. However, it does not explicitly contrast with alternative tools or say when not to use, though the sibling names imply 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?

With no annotations, the description carries full burden. It discloses idempotency, success behavior (returns 200 even when not following), and marks it as a WRITE operation. It doesn't mention auth needs or side effects beyond mutation, but covers key points adequately.

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 very concise: two short sentences plus a heading, front-loaded with the endpoint. Every sentence adds value 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 nature (one param, no output schema), the description is complete: explains purpose, use case, idempotency, and behavior. Could optionally mention response format, but not necessary.

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

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

Schema coverage is 100% and the description adds no new meaning beyond the schema's description of 'userID of the DCer to unfollow.' 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 is for unfollowing a DCer, with specific verb ('Unfollow') and resource ('DCer'). It distinguishes from sibling tools like follows_profiles_by_id_create by indicating the opposite 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 explicitly says when to use: 'whenever you want to stop seeing a DCer in your /locator/digest favoritePeople section.' It implies not to use it for following, but could be more explicit about 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?

With no annotations, the description carries full burden. It indicates a GET operation (read-only), returns specific data (total and per-room unread counts), and clarifies the scope. However, authentication requirements or rate limits are not mentioned, which would enhance transparency.

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

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

The description is concise with two sentences—no unnecessary words. The first sentence acts as a title, and the second adds key details. While efficient, it could be slightly more structured to front-load the most critical 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 no output schema, the description mentions the type of returned data (total count and per-room breakdown) but lacks detail on the exact structure (e.g., keys, nesting). For a tool with a single parameter and a clear purpose, this is adequate but not fully complete.

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

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

The input schema has 100% coverage and includes a description for the 'limit' parameter. The tool description does not add additional meaning beyond the schema, so 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 clearly states the tool retrieves unread message counts (total and per-room breakdown) and specifies scope (rooms the user is subscribed to or a member). This is a specific verb-resource combination that distinguishes it from sibling tools like 'rooms_inbox' which lists inbox messages.

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 checking unread counts but does not explicitly state when to use it versus alternatives like 'rooms_messages' or 'notifications'. No when-not-to-use guidance is provided, though the scope limitation is noted.

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?

Declares read-only operation, explains the funnel states and data fields (type, name, email, timestamps). With no annotations, description adequately discloses behavior.

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

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

Very concise, uses bullet points for source types and entity attributes. Front-loaded with endpoint and purpose. No extraneous sentences.

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?

Explains response fields and funnel tracking. Without an output schema, the description provides sufficient detail about the returned data and pagination via cursor.

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 clear descriptions for limit and cursor. Description does not add new semantics for parameters beyond the schema, which is acceptable due to 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?

Clearly states 'List your invites' and distinguishes between manual and permaCode sources. Differentiates from sibling tools invites_create and invites_permacode.

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?

Describes when to use (to list referral invites credited to you). Does not explicitly state when not to use, but provides context with source types and sibling tool names for reference.

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?

Discloses WRITE operation mutation, async email delivery, and immediate visibility. No annotations provided, so description fully covers 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?

Short and well-structured: endpoint, action, process, immediate result, mutation warning. No unnecessary 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?

Missing return value/response description and error scenarios (e.g., duplicate invite). Adequate for a simple mutation but could be more complete.

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

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

Schema has 100% coverage, but description adds context like whyDC surfaces in admin review and fullName used for dedup, adding value beyond 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?

Clearly states the action 'Send an invite' with resource 'invite' and context 'referral'. Distinguishes from siblings like `invites` (GET) and `invites_permacode`.

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

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

Provides clear context for when to use (send referral invite) and describes effect, but does not explicitly mention when not to use or list alternatives like `invites_permacode`.

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?

No annotations provided, so description carries full burden. It discloses the return value (permanent referral code) and purpose (sharing for referrals). For a read-only GET with no parameters, this is adequate transparency.

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

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

Two short sentences, front-loaded with the HTTP method and purpose, no extraneous information.

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

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

For a zero-parameter tool with no output schema, this description fully explains what the tool does and how to use the result.

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

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

No parameters, so baseline is 4. The description adds meaning beyond the empty schema by explaining the returned code's 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 uses specific verbs ('GET', 'get') and resource ('permacode', 'permanent referral code'), clearly distinguishing from sibling tools like 'invites' (listing) and 'invites_create' (creating).

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

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

It states when to use: to retrieve and share your permanent referral code. No explicit when-not or alternatives, but context is clear for this simple fetch 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?

No annotations provided, so description fully covers behavior: explains what data is returned (limits, usage, reset windows, calls left), how limits are derived (membership tier vs overrides). No contradictions.

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

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

Well-structured with line breaks and bullet-like clarity. Front-loaded purpose. Slightly verbose but each sentence adds necessary detail; could trim minor 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?

No output schema, but description fully explains return values (limits, usage, reset times, calls left). No prerequisites or side effects to mention. Complete 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?

No parameters exist (schema coverage 100% empty). Description adds value beyond schema by detailing the response contents. Baseline 4 is appropriate for zero 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 clearly states the tool returns effective rate limits and current usage. It uses specific verb+resource ('GET /limits') and distinguishes from other tools by being the only one providing rate limit info.

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 provides when-to-use guidance: 'Use this endpoint when you want a JSON snapshot, or the headers when you want to read it on every call.' No alternatives among siblings for rate limits.

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

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

With no annotations, the description carries full burden. It explains the response structure (four sections) and conditional behaviors (e.g., null homeCity). It doesn't mention auth or rate limits but sufficiently discloses behavior for a read-only operation.

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

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

The description is efficiently structured with a bullet list for sections, front-loaded purpose statement, and no redundant text. 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?

Given no output schema, the description fully explains the return structure (four sections with detailed behavior). The tool is simple (1 optional param) and the description covers all needed context.

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

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

The description adds significant meaning beyond the input schema: it explains how to use the `sections` parameter, lists the four possible values with their full meanings, and provides default behavior. Schema coverage is 100%, but the description enriches understanding.

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 weekly locator digest and differentiates it from siblings by specifying its purpose (the same data that powers Friday email). It uses specific verbs and resources.

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 the tool ('surface trip/event activity around people and cities a member follows') but does not provide when-not-to-use or alternatives. It does offer guidance on omitting sections for narrow integrations.

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?

No annotations are provided, so the description must cover behavior. It indicates a safe GET operation and explains the digest, but omits details like authentication requirements, rate limits, or that the call is idempotent.

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

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

The description is concise (two sentences), front-loads the HTTP method and path, and every sentence adds meaningful information. 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?

Without an output schema, the description adequately explains what the tool returns and the context of the digest. It is complete enough for an agent to understand the tool, though it could mention example toggle names.

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?

With zero parameters, schema coverage is 100%. The description adds value by explaining the return content (four toggles, digest purpose), which goes beyond the empty 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 tool's purpose: retrieving the Friday locator email settings. It specifies the HTTP method (GET), resource, and what it returns (four toggles controlling the digest). Among sibling tools, it distinguishes from locator_digest and locator_settings_update.

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 reading settings, but does not explicitly state when to use this tool versus alternatives like locator_settings_update for writing. No context on prerequisites or exclusions 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?

Explicitly warns 'WRITE operation: this mutates your DC account data', providing essential behavioral information since annotations are absent.

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

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

Three sentences, no wasted words. Front-loaded with endpoint and action.

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?

Simple tool with no output schema; description adequately covers purpose, usage, and behavioral warning, making it fully self-contained.

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 covers all parameters with descriptions. Description adds 'toggles' framing but adds little beyond 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?

Clearly states it updates Friday locator email settings via PATCH. Distinguishes from sibling tools like locator_settings (likely GET) by specifying 'WRITE operation' and 'update'.

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 says to send only fields to change (partial update). Clear context for usage, though no explicit when-not-to-use or alternatives mentioned.

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

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

With no annotations, the description carries full burden. It accurately describes a read-only GET returning state details, but does not mention authentication requirements, error conditions, or any side effects. Adequate but not thorough.

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 HTTP method and purpose, with no extraneous content. 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 zero-parameter tool with no output schema, the description provides sufficient context about what is returned. It lacks mention of authentication or error scenarios, but remains largely complete for a simple GET endpoint.

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?

No parameters exist, and schema coverage is 100%, so baseline is 3. The description does not add parameter information beyond the schema, which is acceptable given there are none.

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 user's full membership state, listing specific fields (role, dates, trial, billing, Stripe link). It distinguishes itself from sibling 'membership_invoices' which handles invoices 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 implies usage for retrieving membership info but does not provide explicit when-to-use or alternatives. No exclusion criteria or context about when not to use 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?

With no annotations, the description discloses key behaviors: GET endpoint, newest-first ordering, safe-to-share URLs, and edge cases. It adequately covers the tool's read-only nature and result characteristics.

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, front-loaded with the endpoint and purpose, with no unnecessary 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?

Given the single optional parameter and no output schema, the description fully covers the tool's functionality, output format, ordering, and edge cases. It is complete for this simple list 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 description does not mention the 'limit' parameter. Since the schema already provides full coverage (100%) with a description for the parameter, the description adds no additional semantic value.

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

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

The description clearly states the tool lists Stripe invoices, newest first, with the verb 'Returns' and specific details about the output format. It is distinct from sibling tools, none of which are invoice-related.

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

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

Provides clear context on when the tool returns empty results (for legacy payment methods or no Stripe customer), but does not explicitly contrast with alternatives since no alternatives exist.

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

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

With no annotations, the description fully discloses behavior: it returns push and email preferences per category, applies defaults for unset preferences, and notes that email is null for reaction/myReaction categories.

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 focused sentences with no redundant content; it front-loads the endpoint and purpose, then adds essential 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?

The description fully covers the tool's behavior, response structure, and edge cases (null email for certain categories), with a clear distinction from a related sibling, despite no output schema.

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

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

The input schema has no parameters to explain, and the description adds valuable context about the response structure and defaults, exceeding the baseline expectation for zero 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 clearly states it retrieves notification preferences via GET /notifications, and explicitly distinguishes from the Friday locator email digest via locator_settings, ensuring no confusion with siblings.

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

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

The description provides explicit guidance on when to use this tool (to get notification preferences) and when not to (for the locator digest), including an alternative tool reference.

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?

No annotations, so description carries burden. It clearly states it's a WRITE operation mutating data and mentions a specific behavioral constraint (email rejection for reaction/myReaction). Could add more on idempotency or auth needs, but sufficient for a simple mutation.

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 plus a warning. Front-loaded with 'PATCH /notifications — Update your notification preferences'. No wasted words. Efficient and clear.

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

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

Covers purpose, partial update, mutation warning, and a specific constraint. No output schema, so description could mention return value (e.g., updated preferences or success). Missing this minor detail, but otherwise complete.

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

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

Schema has 100% coverage but parameter is an object without explicit properties. Description adds critical usage guidance: pass only changed fields, stay-as-is behavior, and email rejection. This adds significant value beyond 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 it updates notification preferences, with 'PATCH' indicating partial update, and the name implies it's distinct from the 'notifications' sibling (likely a GET). The verb 'Update' and resource 'notification preferences' are specific.

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

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

Explicitly says to send only changed categories/channels and that email is rejected for certain categories. Implicitly distinguishes from read tool 'notifications', but does not explicitly mention when not to use or alternative tools for reading preferences.

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 implies a read-only operation (GET), but does not explicitly state no side effects. However, given no annotations, it provides sufficient behavioral 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?

Two short, focused sentences with front-loaded endpoint info. Every sentence adds value without redundancy.

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

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

For a simple fetch with one parameter, the description explains output shape, use case, and limitations of a related endpoint. No output schema 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 description enhances the schema by specifying where to obtain a placeID (from GET /places/search or previous responses) and explains its role in verification, adding meaning 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 clearly states it fetches full details for a Google Place ID, distinguishing it from sibling tools like places_search and trips_create by specifying its role in verification.

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 says it is useful for verifying a placeID before sending to POST /trips, and notes that POST /trips only accepts 'type: city' and rejects venues, providing clear when-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?

With no annotations provided, the description carries full burden. It discloses the response structure (type field classification and enriched location) and explains that venue types are rejected by trips. However, it does not mention rate limits, authentication, or explicit read-only nature, which would enhance transparency.

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

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

The description is concise and front-loaded with the HTTP method and resource. It then provides purpose, details on type field, and usage hints. One could argue the first line is slightly redundant, but overall it's well-structured 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 no output schema, the description explains the response shape (type, enriched location) and how to use results. It covers essential use cases for trip creation and events. Missing elements like pagination or error handling, but it is sufficiently complete for a search tool.

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

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

Schema description coverage is 100%, so the schema already documents both parameters. The description adds marginal value by linking q to 'name' but mostly repeats schema info. Baseline 3 is appropriate.

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

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

The description clearly states the verb (search), the resource (Google Places), and the purpose (look up place ID for trips/venues). It distinguishes from siblings like 'place' and 'search' by specifying its role in obtaining place IDs and enriching locations.

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 the tool (before creating a trip or referencing a venue), provides filtering guidance based on type (city for trips, venue for events), and notes that venue type is rejected by POST/trips. This offers clear context for selection and downstream 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?

With no annotations, the description discloses that it returns full profile and tier-derived state, but omits authentication requirements or safety implications. The GET method implies idempotence, yet explicitly stating read-only nature would improve clarity.

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

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

Three sentences with clear front-loading of purpose. No wasted words, each 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?

Given no output schema, the description adequately explains the tool's behavior and output shape. Could mention authentication or confirm it's a read operation, but overall complete for a simple profile retrieval 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?

Zero parameters and 100% schema coverage mean the description doesn't need to add parameter details. The baseline of 4 applies, and the description adds no redundant param info.

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 explicitly states 'Get your own profile' and distinguishes it from siblings like profile_update by mentioning the PATCH endpoint for updates.

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?

Clearly indicates when to use this tool (to view own profile) and contrasts with profile_update. Could be more explicit about not using for other profiles, but context is sufficient.

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?

No annotations provided, so description carries full burden. It discloses it's a write operation, has stricter rate limits, uses Gemini embeddings and reranking, returns ranked results, and the caller synthesizes narrative. Good transparency.

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

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

The description is long but well-structured with sections, bullet points, and clear heading. Information is front-loaded with summary then detailed. Could be slightly more concise, but 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?

With 11 parameters, no required fields, and no output schema, the description covers all aspects well, including caveats, alternatives, and behavioral notes. Complete enough for an AI agent to use effectively.

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%, but description adds significant meaning: explains two modes, how filters combine (AND), notes on sparseness (gender, currentLocation), alternatives to filters (e.g., trip_discovery), and details on minTeamSize and minAnnualRevenue filtering logic.

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 matches DCers from a description or recommends based on profile. It uses a specific verb ('match') and resource ('DCers'), and distinguishes from siblings by being AI-powered and having two modes.

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 two modes (with/without query) and when to use each. It provides explicit alternatives for locationCurrentPlaceID (use trips instead). Could be more explicit about when not to use, but provides good context.

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?

No annotations are provided, so the description carries full burden. It explicitly labels the tool as a WRITE operation that mutates DC account data and notes non-updatable fields. This is good disclosure, but could mention idempotency, auth requirements, or side effects.

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 sentences, front-loaded with the HTTP method and purpose. It is concise with no unnecessary words or repetition. Every sentence provides useful 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?

The description is adequate for an update operation but lacks mention of return values (no output schema). It does not summarize the grouping of fields (e.g., personal vs professional). Given 30 parameters, a bit more context on what the update accomplishes could be useful. Still, the schema descriptions are thorough.

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 each parameter having a detailed description in the input schema. The tool description adds only a general statement about updating allowed fields and non-updatable fields. It does not enhance understanding beyond the schema, so baseline 3 is appropriate.

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

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

The description starts with 'PATCH /profile — Update profile fields', clearly stating the HTTP method and resource. It specifies only included fields are changed and lists non-updatable fields (location, photo, gender). This distinguishes it from other tools like 'profile' (likely read-only) and other update 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 indicates when to use: to update allowed profile fields. It warns that some fields cannot be updated via API. However, it does not explicitly state when not to use or compare to alternatives like 'profile' (GET) or other update tools. The context is clear but lacks 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?

No annotations provided, so description carries full burden. Explicitly states it's a WRITE operation mutating account data. Privacy note warns about unredacted data. Fully transparent.

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?

Concise, front-loaded with endpoint and purpose. Each sentence adds necessary information (options, privacy, mutation warning). 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?

Completely covers all parameters and behavioral aspects (mutation, privacy, format constraints). No output schema needed for a report tool. Sufficient for agent to use 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% (baseline 3). Description adds value beyond schema: details on screenshot format, size limits, EXIF stripping, text length, severity defaults, and context key limits.

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?

Clearly states the tool is for reporting issues/feedback to the DC team, using a specific verb and resource (POST /report-issue). It distinguishes itself from sibling tools as the only one for this purpose.

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

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

Explicitly defines when to use (bug report, feedback, question) and what to include. Privacy note adds caution. Lacks explicit alternatives or when-not-to-use, but context makes it 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?

With no annotations provided, the description must disclose behavioral traits. It states the HTTP method (GET), the returned data (subscribed rooms), sorting by `lastActivityAt`, and pagination (cursor-based). It does not mention authentication or rate limits, but for a read-only endpoint 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 three sentences: first defines the endpoint and purpose, second details the results, third gives an alternative. Every sentence adds value, and it is front-loaded with the most important 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?

There is no output schema, so the description should explain what is returned. It lists the types of rooms and mentions sorting and pagination. However, it does not describe the fields in each room object. Given that the tool is a list endpoint, the missing details might be inferred, but a more complete description would be ideal.

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 baseline is 3. The description adds context by mentioning 'Cursor-paginated', which reinforces the purpose of the `cursor` parameter. It also implies the `limit` parameter by stating 'Max results (1-100)', though the schema already provides that. Overall, it adds some value 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 clearly states the verb 'List' and the resource 'your subscribed rooms', and specifies the types of rooms included (DMs, group DMs, channels, etc.). It distinguishes itself from sibling tools like `rooms_inbox` by noting that the latter filters by type.

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

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

The description explicitly says when to use this tool: to list all subscribed rooms. It also provides an alternative: use `GET /rooms/inbox/:type` for filtering by type, giving clear guidance on when not to use 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?

With no annotations provided, the description fully bears the burden of behavioral disclosure. It clearly states that this is a WRITE operation that mutates data, is idempotent, and requires membership. This is comprehensive.

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 efficiently structured: one line for HTTP method/path, then purpose, effect, alternative, access, idempotency, and write warning. Every sentence adds value 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?

For a simple archive operation with one required parameter, the description covers all essential aspects: what it does, its effect, access conditions, idempotency, and that it is a mutation. No missing 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% (the only parameter roomID is described). The description does not add additional meaning beyond the schema's 'Room ID' line. 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 clearly states the verb 'Archive' and resource 'room', and distinguishes from the sibling tool 'unarchive' by explicitly mentioning it. The effect 'hides it from the inbox sidebar without unsubscribing' is specific and unambiguous.

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

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

The description explicitly provides an alternative ('Use `unarchive` to bring it back') and states access requirements ('the caller must be a member/subscriber'). It does not explicitly say when not to use it, but the mention of the alternative provides sufficient 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?

No annotations provided, so description fully informs behavior: HTTP GET, read-only operation, filtering of DC BLACK rooms for DC tier members. It also implies pagination via cursor parameter. No mention of authentication, but GET is generic.

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 very concise: two sentences plus the HTTP method line. No wasted words, front-loaded with the core purpose and HTTP verb.

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 3 parameters, full schema coverage, and no output schema, the description provides adequate context: explains the source of data (in-app modal), filtering rule, and the general browse behavior. It could mention pagination more explicitly, but the cursor parameter covers that.

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

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

Schema coverage is 100% with descriptions for all three parameters. The description adds context about the tool's origin (same as in-app Browse Channels modal) and filtering rules, which complements the schema descriptions without repeating them.

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 browses public rooms of a given type that the user is not subscribed to. It specifies the HTTP method and resource path, and distinguishes from sibling tools like rooms (subscribed rooms) and search_rooms (search all).

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

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

The description tells when to use it: to browse publicly-joinable rooms not yet subscribed to. It mentions a restriction (DC BLACK filtered out for DC tier members). It does not explicitly list alternatives among siblings but the use case is clear.

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

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

With no annotations, the description fully covers behavioral traits: it notes that reading does not mark as read or modify unread state, explains access controls, and details that summaries return null if not available.

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 well-structured with clear sections, uses bullet-like formatting, and every sentence provides unique value. No wasted words, appropriately sized for the tool's complexity.

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 parameter, no output schema), the description is complete. It covers what the endpoint returns, what it does not do (mark read), and provides alternatives for related tasks.

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% (roomID described), but the description adds value by linking the parameter to access semantics (members/subscribers get 403 for unauthorized rooms). This enriches understanding beyond the schema's 'Room ID'.

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 /rooms/:roomID — Get a single room' and specifies it returns metadata plus AI summaries. It distinguishes itself from siblings like 'rooms' (list), 'rooms_summaries' (history), and 'search_messages' (targeted lookup).

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 (get single room metadata + summaries) and when-not-to-use (for history, use other endpoints; for targeted content, use search). It also explains access restrictions (403 for private rooms without membership) and offers see-also references.

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?

No annotations are provided, so the description is the sole source. It states the tool returns subscribed rooms filtered by type and mentions the output shape is same as 'GET /rooms'. However, it does not detail authentication, rate limits, or pagination behavior beyond the schema's cursor parameter.

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, front-loaded sentences with no extraneous information. Every part adds value: a summary and contextual examples.

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 no output schema, the description compensates by referencing the shape of 'GET /rooms' and specifying it filters subscribed rooms. It provides context for nested sibling tools like 'rooms'. Could be more explicit about pagination ordering or that cursor is from a previous response, but overall sufficient.

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 is 3. The description adds minimal value beyond the schema, only providing examples for the 'type' parameter. The schema already adequately describes each 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 lists rooms by type, using a specific verb ('List') and resource ('rooms by type'). It distinguishes itself from the sibling 'rooms' tool by noting it is 'scoped' and providing examples like '/rooms/inbox/dm' for DMs.

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 through scoping and examples but does not explicitly state when to use this tool versus alternatives like 'rooms' or other filtered tools. No when-not or explicit alternatives mentioned.

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?

Discloses read-only nature, no side effects, cursor pagination, member-only access with specific room type rules, and exclusion of hidden/deleted/sunk messages.

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?

Well-organized with bold headers, no fluff, each section adds value and is front-loaded with the core action.

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

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

Covers purpose, access, pagination, and sibling differentiation; lacks description of the return format (message fields), but that is often implicit for list endpoints.

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 already covers all parameters; description adds value by explaining cursor encoding (timestamp) and default/max limits beyond schema descriptions.

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

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

The description clearly states the tool lists messages in a room, specifies it is read-only, and differentiates from search_messages by explaining chronological vs topic use cases.

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 when to use this tool (chronological window) vs search_messages (topic-based), and provides access rules and pagination details.

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 states it is a WRITE operation that mutates data, explains the specific field affected (mutedUntilAt set to far-future), notes no expiry, and clarifies that the room remains in the inbox. With no annotations provided, this description fully discloses 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 concise and well-structured: a short verb-resource line, followed by behavior details, access note, and a warning. Every sentence adds value 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?

For a simple tool with one parameter and no output schema, the description covers behavioral effect, access requirement, and mutation nature completely. No gaps remain given the context signals.

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 one parameter (roomID) described as 'Room ID'. The description adds no additional meaning beyond the schema, so 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 clearly states the tool mutes a room for notifications. It specifies the action (mute), the resource (room), and the effect (suppresses notifications), distinguishing it from inverse operations like rooms_unmute_create.

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

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

The description indicates the tool is used to mute notifications and specifies an access requirement (caller must be a member/subscriber). However, it does not explicitly contrast with the sibling tool rooms_unmute_create 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?

No annotations are provided, so the description carries full burden. It discloses the write nature ('mutates your DC account data'), auto-subscription behavior, and access constraints. This provides sufficient transparency for the operation.

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

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

The description is concise, well-structured, and front-loaded with the purpose. Every sentence adds value: header line, behavioral details, access requirements, and idempotency note. 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 (1 parameter, no output schema, no annotations), the description covers all necessary aspects: operation type, side effects, prerequisites, and idempotency. It is complete for an agent to make an informed decision.

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?

With 100% schema description coverage for the single parameter (roomID described as 'Room ID'), the description adds no extra meaning beyond the schema. Baseline 3 is appropriate.

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

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

The description clearly states the tool pins a room to the top of the inbox ('POST /rooms/:roomID/pin — Pin a room'). It distinguishes the core action from siblings like rooms_unpin_create, but does not explicitly name the sibling for unpinning.

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: auto-subscription for subscription-type rooms, access prerequisites (interaction history for DMs/group DMs), and idempotency. It implies when to use but doesn't explicitly mention when not to use or directly compare to 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?

No annotations provided, so the description carries full burden. It states this is a WRITE operation that mutates account data, is idempotent, and adds user to the seen subcollection. Missing details like rate limits or authentication, but covers key 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 well-structured with sections for access, idempotency, and warning. It is slightly lengthy but each sentence adds value. Could be marginally tighter but remains clear.

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 one parameter and no output schema, the description is comprehensive: covers access conditions, idempotency, mutability, and what happens upon subscription. No gaps are apparent.

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 only one parameter (roomID) described as 'Room ID'. The description does not add additional meaning beyond what the schema provides, so 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 clearly states the tool subscribes to a room, specifying the room types (channel, discussion, quick-question, event) and distinguishes from siblings like rooms_unsubscribe_create. It uses a specific verb 'Subscribe' and identifies the resource '/rooms/:roomID/subscribe'.

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

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

Provides explicit when-to-use (subscribable public rooms) and when-not (DMs, group DMs, archived/private/hidden rooms). Also specifies prerequisites for event rooms (valid ticket). Gives clear context for 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?

Discloses cursor-based pagination, ordering (newest first), non-overlapping windows per summary, and same access gate as another endpoint. No annotations exist, so description carries full burden and handles it well.

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?

Description is a single paragraph with logical flow: endpoint, what it does, pagination, use case, alternative. No redundant words; 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?

No output schema, but description mentions cursor field in response. Could detail summary fields, but provides enough for basic usage. Given complexity, it's near complete.

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

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

All 4 parameters are described in the schema (100% coverage), but the description adds context: explains cursor usage ('pass from previous response'), type values ('daily or weekly'), and limit default. Adds value beyond 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 explicitly states the endpoint and action: 'List past daily or weekly summaries' for a specific room and type. It clearly distinguishes from siblings like 'rooms_summary' and other related 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?

Provides explicit use case: 'Use this for catch-up workflows' and an alternative tool: 'POST /search/messages with q= and roomID= is faster than reading multiple summaries.'

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?

No annotations are provided, so the description carries full burden. It describes the operation as a read (GET) and mentions access gates, but does not disclose behavior when no summary exists, error codes, or authorization requirements. Some transparency but gaps remain.

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

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

The description is concise with three short paragraphs, front-loaded with the endpoint and purpose. Every sentence adds value, including comparisons to related endpoints. No wasted words.

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

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

For a simple read tool with two parameters and no output schema, the description is mostly complete. It explains the tool's scope, required parameter, and relationship to siblings. Lacks details on response format or error cases, but overall 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?

The schema covers both parameters with descriptions, and the description adds meaning by explaining that daily and weekly summaries cover different windows and live in separate slots. This clarifies the type parameter beyond the schema's simple enum-like description.

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 the tool retrieves the latest daily or weekly summary for a room, using a specific endpoint. It clearly distinguishes from the sibling tool `rooms_summaries` which is for history, providing a precise verb-resource combination.

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 the type is required, explains the difference between daily and weekly summaries, and advises when to use the history endpoint or search_messages instead. It gives clear context and 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?

Discloses write operation, idempotency, access requirement, and effect. With no annotations, the description carries full burden and does so adequately. Could mention potential side effects or error 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?

Very concise: two sentences plus a warning. Front-loaded with the main action (unarchive). Every sentence adds value with no unnecessary 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?

Covers key aspects: purpose, effect, access, idempotency, and write operation. Missing details on error handling or return values, but with no output schema and simple input, it is reasonably complete.

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

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

Schema coverage is 100% with a single parameter 'roomID' described as 'Room ID'. Description does not add additional meaning or constraints beyond the schema, so baseline 3 is appropriate.

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

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

Clearly states the action 'Unarchive a previously-archived room' with a specific verb and resource. Distinguishes from siblings like rooms_archive_create. Also describes the effect: 'Restores it to the inbox sidebar.'

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?

Describes when to use (unarchive a previously-archived room) and access requirement (member/subscriber). Lacks explicit guidance on when not to use (e.g., if room is already unarchived) or comparison to 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?

With no annotations provided, the description effectively discloses that this is a WRITE operation, mutates account data, and is idempotent. Access requirements are also stated, providing good transparency.

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

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

The description is three sentences, front-loaded with the endpoint. It uses clear formatting with warnings and is efficient without unnecessary fluff. Could be slightly more compact, but it's 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?

For a simple tool with one required parameter and no output schema, the description covers essential aspects: purpose, side effect, idempotency, and access. It leaves no major gaps given 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?

There is only one parameter (`roomID`) and the schema already provides a description ('Room ID'). The description adds no further semantic detail, so it meets the baseline for high schema coverage but does not exceed it.

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?

Clearly states the tool unmutes a room and specifies the HTTP method and path. It mentions the side effect of clearing `mutedUntilAt`. However, it does not explicitly differentiate from its sibling `rooms_mute_create`, though the inverse relationship is implied.

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?

Indicates the tool is for unmuting a previously muted room and notes access requirements (member/subscriber) and idempotency. Could be improved by explicitly stating when not to use or naming alternatives, but the context is clear enough.

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

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

With no annotations, description fully discloses that this is a write/mutation operation, idempotent, and requires membership. No contradictions.

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

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

Two sentences plus access note, no redundancy, front-loaded with key action.

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 low complexity (1 param, no output schema), description fully informs agent about purpose, behavior, and constraints.

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

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

Schema coverage is 100% and describes roomID as 'Room ID'. Description adds no extra parameter meaning beyond schema, so baseline 3 applies.

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

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

Description clearly starts with HTTP method and endpoint, uses specific verb 'Unpin a room', explains effect on inbox sort order, and is distinct from sibling rooms_pin_create.

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

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

States access requirement (member/subscriber) and idempotency, implying it's for unpinning rooms. However, lacks explicit when-not or alternative sibling guidance.

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