DC Member API

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

No annotations exist, so the description carries the full burden. It discloses ordering by creation date and a maximum of 50 results, which is good behavioral context for a read 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 two sentences, front-loaded with the HTTP method and resource path, and every word adds value. 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?

Given zero parameters and no output schema, the description fully covers what the tool does: returns alerts with ordering and a limit. No gaps.

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 are zero parameters and schema coverage is 100%, so baseline is 3. The description adds no parameter-specific semantics (none exist), but it does reinforce the tool's overall purpose.

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 lists alerts, with ordering and a limit ('newest first', 'Maximum 50 results'). It distinguishes from sibling tools like alerts_create or alerts_by_id_delete.

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 tool name 'alerts' and description clearly indicate it's for listing alerts. Sibling tools for create, update, delete provide implicit context, but no explicit 'when not to use' guidance is given.

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: soft-delete by setting active:false, history preserved, mutation of account data. Clearly flags as WRITE operation.

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

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

Four sentences with clear front-loaded purpose. Every sentence adds value (effect, preservation, reactivation, warning). 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?

Despite no output schema, the description fully explains the operation's effect, mutation, and history preservation. Complete for a simple soft-delete 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?

Only one parameter 'alertID' with schema description; description adds no extra meaning beyond what schema already provides. Schema coverage is 100%, 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 deactivates an alert via soft-delete, using specific verb 'Deactivate' and resource 'alert'. It distinguishes from siblings by referencing PATCH for reactivation.

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 soft-delete and mentions alternative PATCH for reactivation. Provides usage context (WRITE operation) but lacks direct comparison to other sibling tools like alerts_create.

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 the full burden. It explicitly warns that this is a WRITE operation that mutates DC account data, and clarifies partial-update semantics ('Only provide the fields you want to change'). This discloses the key behavioral trait without needing annotations.

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

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

The description is extremely concise: three sentences covering the endpoint, the update behavior, and a mutation warning. It is front-loaded and every sentence earns its place 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 partial-update tool with a comprehensive schema and no output schema, the description is reasonably complete. It covers the core behavior, the mutating nature, and the usage pattern. It doesn't cover response details or error cases, but these are not specified in the schema either, and the description is adequate for the tool's complexity.

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

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

Schema coverage is 100% with detailed descriptions for all 6 parameters. The description adds valuable semantic context beyond the schema by explaining that only provided fields will be changed, which is essential for correct partial updates. This elevates the score above the baseline of 3.

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

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

The description clearly states 'Update an alert' and specifies the PATCH /alerts/:alertID endpoint, making it obvious this is the update operation for a specific alert. This distinguishes it from siblings like alerts_create and alerts_by_id_delete.

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 that this tool updates existing alerts and instructs users to provide only the fields they want to change. While it doesn't explicitly mention alternatives or exclusion scenarios, the context is unambiguous enough for tool selection among siblings.

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 warns '⚠️ WRITE operation: this mutates your DC account data,' which no annotations provide. It also discloses that the system will search and deliver digests, and sets a maximum of 10 alerts, adding behavioral context beyond the schema. However, it does not cover error responses or permission prerequisites.

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: a headline, a behavior sentence, a limit sentence, and a mutation warning. All sentences carry actionable information and it is front-loaded with the endpoint and 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?

For a simple create tool with fully described parameters and no output schema, this is nearly complete. It covers the action, system behavior, and a key constraint. The only missing piece is expected return value or error handling, but the schema and simplicity compensate.

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 schema already describes each parameter's purpose. The tool description adds no additional parameter-level details, 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 'Create an alert' and explains what an alert does (searches for matching content, delivers digests). It distinguishes from sibling tools like alerts_by_id_update and alerts_by_id_delete 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 implies when to use this tool (to create a new alert) but does not explicitly discuss alternatives or conditions like when to update an existing alert instead. The limit of 10 active alerts is noted but not framed as a usage guideline.

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

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

With no annotations, the description completely carries the burden. It explicitly states read-only behavior, visibility rules based on membership, and the one-way nature. It sets proper expectations without 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 succinct (6 sentences), front-loaded with the endpoint and purpose, and each sentence adds value. No redundant or 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?

Given no output schema, the description explains the output format (flat newest-first feed, same as app), visibility rules, and limitations (no per-channel filtering). It covers all necessary aspects for an agent to use the tool correctly.

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

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

Schema coverage is 100%, so baseline is 3. The description mentions 'opaque cursor' and 'nextCursor', which aligns with the schema but adds no extra semantics beyond what the parameter descriptions already provide.

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 a GET endpoint to list recent announcements from DC's broadcast channels. It distinguishes itself from siblings like 'announcements_latest' by specifying it returns a flat, newest-first feed. The verb 'list' and resource 'announcements' are explicit.

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 good usage context: it explains visibility mirrors the app, and there is no posting/replying/filtering. It implicitly suggests when to use (to read announcements) but does not explicitly compare with siblings like 'announcements_latest' or state 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?

With no annotations, the description fully discloses behavioral traits: it is a GET (read-only), returns announcements per visible channel, no pagination, result size equals number of channels (~4), and visibility rules identical to /announcements. No contradictions or omissions.

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 (5 sentences) and well-structured: a header line stating the endpoint and purpose, followed by clear explanations of behavior, usage, visibility, and result size. Every sentence adds value without 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?

Given the tool's simplicity (no parameters, no output schema), the description is complete. It explains what the tool does, what it returns, visibility rules, pagination behavior, and result size. It also mentions the alternative tool. No gaps remain.

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

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

The input schema has zero parameters, so schema coverage is 100% trivially. According to the rubric, zero parameters gives a baseline of 4. The description adds no parameter-specific information, but that is unnecessary; it instead adds context about the output and usage, which is appropriate for a parameterless tool.

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

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

The description clearly states it returns the single most recent announcement per visible channel, using specific verbs ('Returns') and resource description. It distinguishes itself from the sibling 'announcements' tool by explicitly contrasting with the full feed.

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: 'Useful as a quick check before drilling into the full feed via GET /announcements.' It specifies when to use this tool versus the alternative, making context 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?

Despite no annotations, the description fully discloses behavior: returns three URLs, includes event categories controlled by toggles, and notes deterministic tokens. It is a safe read 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 well-structured with a bold first line, summary, bullet points, and explanatory text. 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?

With no output schema, the description fully explains the return values (three URLs, toggles, event categories). It provides sufficient context for an agent to understand the output.

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 are no parameters, so baseline 4 applies. The description adds context about the response structure, which is relevant but not required for 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 an iCalendar feed URL and settings. It specifies the verb 'GET' and the resource, and distinguishes itself from the sibling 'calendar_update' by being a read operation.

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 feed URLs and settings, but does not explicitly state when not to use it or compare to alternatives beyond the sibling name.

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 declares this is a WRITE operation that mutates DC account data. Describes return value and behavior on success. No annotations provided, so description fully compensates.

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 focused sentences: purpose, usage nuance, and side-effect/return info. No filler, front-loaded with key 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 tool with 9 simple boolean parameters and no output schema, description covers behavior (partial update, return value, side-effect), and provides complete context for agent invocation.

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

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

Schema coverage is 100% with each parameter described as 'Boolean'. Description adds general context about partial updates but does not provide additional meaning per parameter 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?

Clearly states 'Update calendar feed settings' with specific verb and resource, and specifies 'any subset of your calendar feed toggles'. Distinguishes from sibling tools like 'calendar' which is a GET endpoint.

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 guidance: send only toggles to change, omitted fields left untouched, and suggests re-fetching GET /calendar for full state. Lacks explicit when-not-to-use or comparison with alternative update tools, 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?

With no annotations, the description explains the GET nature, specific return fields (members, currentVisitors), and filtering of hidden/guest profiles. It adds context about active trips but lacks details on auth, rate limits, or other 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 well-structured with a clear first line and bullet points for key fields. It is informative without being overly verbose, though a bit lengthy.

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 structure (members, currentVisitors) and filtering. It covers the main expected fields, but could mention other potential details like chapter name.

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 described as 'Chapter ID (same as Google Place ID)'. The description does not add additional meaning beyond that, 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 explicitly states 'Get a single chapter' and details the response structure. It clearly distinguishes from sibling tools like 'chapters' (plural listing) and 'search_chapters' by focusing on retrieving one chapter by ID with specific fields.

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 use when needing full details of a specific chapter, but does not explicitly state when to use or avoid it compared to alternatives. No when-not-to-use guidance is given.

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 discloses sorting order, pagination via cursor, and the presence of Google Place ID for downstream use. It does not mention auth or rate limits, but for a read-only GET endpoint, this is sufficient.

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

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

Two concise paragraphs: the first states the endpoint and key behavior, the second provides an alternative. No wasted words, well-structured.

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

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

The description covers the main use case, sorting, pagination, and how results can be used (Google Place ID for trips). It references the alternative tool. Without an output schema, it gives enough context 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?

Schema coverage is 100% with clear descriptions. The description adds no additional parameter meaning beyond what the schema provides, 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 clearly states it lists all DC chapters sorted by member count, and explains the resource (chapters as city-based community hubs) and the verb (list). It distinguishes from sibling 'search_chapters' by noting the sorting and use case.

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 this tool (list all chapters sorted by member count) and when to use the alternative 'POST /search/chapters' (for searching by city/country name). The 'See also' section gives clear 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 must fully disclose behavioral traits. It only states the return contents (full details, ticket status) and implies a read-only GET operation, but omits authorization requirements, error handling, or rate limits.

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

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

The description is highly concise, consisting of two sentences that include the endpoint and a clear description of the return value. 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?

The tool is simple, but the description could be more complete by mentioning what happens if the event does not exist, authentication requirements, or the structure of the returned details. It is minimally adequate.

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

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

Schema coverage is 100%, so the description adds minimal extra meaning beyond the schema. It reiterates the parameter via the endpoint path but does not provide additional semantic guidance.

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: 'Get event details' for a specific event, including ticket status. It specifies the HTTP method and path, and distinguishes itself from sibling tools like 'events' (list) and '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?

No guidance is provided on when to use this tool versus alternatives. The description does not mention conditions, prerequisites, or exclusions, leaving the agent to infer usage 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 explains the tool returns personal agenda entries (sessions and meetups) and notes the access requirement. While it doesn't cover all behavioral details (e.g., error cases, pagination), it sufficiently discloses what the tool does and its read nature.

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 endpoint and purpose. Each sentence adds value: endpoint, return content, access condition, and related endpoints. 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?

Given the tool's simplicity (1 parameter, no output schema), the description covers the return values, access requirements, and links to management endpoints. It lacks only minor details like response format or error handling, making it nearly complete.

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

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

Schema coverage is 100% with one parameter (eventID) described as 'Event ID'. The description adds minimal extra meaning ('for an event'). Since the schema already covers the parameter, 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 it 'gets your personal agenda for an event' and specifies it returns bookmarked sessions and RSVP'd meetups. It differentiates from siblings like event_schedule (full schedule) and event_agendas (possibly all agendas) by emphasizing the personal aspect.

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 prerequisite ('caller must hold a valid ticket') and mentions related endpoints for managing entries, but does not explicitly compare to siblings or state when not to use this tool. While context is given, stronger guidance on alternative tools would improve score.

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 the full burden. It discloses access requirements ('open to any active DCer who can see the event,' target must hold a valid ticket) and error condition (404 if no agenda). It does not cover auth details or rate limits, but for a simple GET endpoint, 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?

The description is concise and well-structured: first line states the endpoint, second paragraph explains purpose and return value, third paragraph covers access conditions. Every sentence adds value, and the information is front-loaded. No unnecessary 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?

Despite lacking an output schema, the description fully explains what the tool returns ('sessions they bookmarked + meetups they RSVPd to'). It also covers access conditions and error handling. For a simple two-parameter tool, this is complete and sufficient for an AI agent to understand its usage.

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

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

The input schema already covers both parameters (eventID, userID) with descriptions. The description adds minimal extra meaning—it clarifies that userID is the 'target attendee' and implies both are path parameters. With 100% schema description coverage, the description is not needed to explain parameters, so score 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 fetches another attendee's personal agenda for an event, specifying the endpoint pattern and what it returns (bookmarked sessions and RSVP'd meetups). It distinguishes from siblings like event_agenda (own agenda) and event_agendas (multiple agendas) by explicitly mentioning 'another attendee's 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 guidance on when to use this tool: 'Use this so an AI agent can plan together with another DCer (find a coffee window, suggest sessions to overlap, propose a meetup).' It does not explicitly list alternatives or when not to use, 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?

Without annotations, the description carries the full burden. It discloses key behaviors: silently drops non-attendee IDs, returns in order requested, max 20 IDs, and access requirements ('open to any active DCer who can see the event'). Lacks details on rate limits or error handling, but overall 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 well-structured with clear sections (URL, return, use case, query, behavior, access). Every sentence adds value, no fluff. Front-loaded with essential purpose and method.

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 2 params and no output schema, the description covers purpose, usage, behavior, and access. It lacks explicit return format details, but these may be inferred from context or sibling tools. Overall sufficiently complete for an AI agent to select and invoke correctly.

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

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

Schema coverage is 100% and already provides detailed descriptions (e.g., 'Comma-separated userIDs (max 20). Non-attendees are silently dropped.'). The description adds context about URL structure and use-case, but minimal additional parameter semantics. Baseline 3 is appropriate.

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

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

Description clearly states it returns agendas (bookmarked sessions + meetup RSVPs) for multiple attendees in a single call, using a specific verb ('Get') and resource ('multiple attendees' agendas'). It distinguishes from sibling tools like 'event_agenda' which likely covers single attendees.

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: 'when an AI agent needs to plan around several DCers at once — comparing schedules, finding shared sessions, building a meetup invite list.' Implicitly differentiates from single-attendee alternative. Does not explicitly state 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 carries the full burden. It discloses ticket/RSVP filtering, hidden/guest exclusion, profile shape, access control, pagination order, and cursor handling. This level of transparency exceeds typical API descriptions.

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 structured with a lead sentence, then bullet-like sections for Access and Pagination. Every sentence adds information; no filler. Despite length, it remains scannable.

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

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

For a list endpoint with no output schema, the description covers what is returned, access, pagination, and exclusions. It doesn't document error cases or response envelope details, but the core usage is fully 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?

The input schema covers all 3 parameters with descriptions (100% coverage). The description adds semantic context by explaining that results are newest first, that limit defaults to 100 and ranges 1-100, and that cursor is an opaque token from nextCursor. This goes beyond the schema's simple 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 opens with the endpoint and a clear verb-resource summary ('List event attendees'). It then precisely defines which attendees are included (valid paid ticket or valid/maybe RSVP) and explicitly excludes refunded/canceled tickets and hidden/guest profiles, distinguishing it from sibling attendee tools.

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

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

The description provides clear context: any active DCer can use it, and it matches the in-app attendee tab. It does not explicitly name alternatives or state when not to use it, but the context is sufficient for a list endpoint.

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 is a WRITE operation that mutates account data, silently drops non-attendees, explains slot derivation from session schedule, and details sorting logic. 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 front-loaded endpoint and purpose, followed by parameter details, algorithm, sorting, auth, and warning. 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 complex tool with no output schema, the description sufficiently covers algorithm, sorting, auth requirements, and side effects. User can understand what the tool does and how to use it correctly.

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

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

Schema coverage is 100%, so baseline 3. Description adds default values, min/max constraints for minDurationMinutes, and clarifies that non-attendee IDs are silently dropped, providing additional context beyond the parameter 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 'Find shared free time slots across attendees' with a specific endpoint and verb. It distinguishes from sibling tools like event_schedule_bookmark or event_agenda by focusing on free slot computation.

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

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

Provides explicit usage examples ('find a coffee window with one DCer, or a junto-style lunch slot for a group') and implies context, but does not explicitly contrast with alternative tools or state 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?

No annotations are provided, so the description carries full burden. It discloses the return type (list of attendees who RSVPd) and access condition, but does not mention pagination, error handling, or rate limits. The reference to another endpoint's shape adds some 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?

Description is two sentences plus an access line, all front-loaded with key information. No redundant content. Every sentence contributes to understanding the tool.

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

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

For a simple list endpoint with 2 required params and no output schema, the description covers purpose, output, access, and shape reference. Minor gaps: no mention of empty results or error cases, but adequate for the 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% with basic parameter descriptions. The description does not add extra meaning beyond the path structure. Baseline is 3 due to high coverage, and no additional semantic value is provided.

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 verb 'List', resource 'meetup attendees', and scope 'for a specific meetup'. It references another endpoint for profile shape, distinguishing 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?

Access condition is provided ('any active DCer who can see the event'), and the description implicitly differentiates from event_attendees by mentioning the same shape as /events/:eventID/attendees. However, explicit when-not or alternative comparisons are missing.

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 explicitly marks as WRITE operation, mutates DC account data, explains atomic/idempotent update of rsvpCount, and mentions chat subscription 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 well-structured: starts with HTTP path, then purpose, then requirements, then side effects. 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?

Given no output schema, the description covers the effect, side effects, atomicity, and idempotency. It lacks error conditions or what happens with invalid tickets, but is fairly complete 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% with descriptions. The description adds context about joining/leaving but does not provide new parameter details 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 action ('RSVP to / leave a meetup') and uses specific verbs ('Join or leave'). It distinguishes from sibling tools like event_rsvp (for events) and event_meetup_attendees (for listing attendees).

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 usage context: requires a valid ticket, atomic and idempotent update, and side effects on chat. It lacks explicit when-not-to-use or direct alternatives, but the 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, but the description fully covers behavior: only approved meetups returned, chronological sorting, time-zone handling with wall-clock fields and IANA timezone. Also discloses access rules and what requires a ticket. No contradictory information.

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 headings and bullet points. Every sentence adds value: endpoint path, behavior, access, time-zone handling. No redundancy. Efficient use of space.

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 listing tool with one parameter and no output schema, the description covers everything an agent needs: purpose, access conditions, filtering, sorting, and time-zone handling. Sibling tools fill gaps for related actions.

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 eventID described as 'Event ID'. Description does not add semantic detail beyond the schema, but the context of listing meetups for that event is clear. Appropriate baseline score.

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 approved member-organized meetups for an event, sorted chronologically. The verb 'List' and resource 'event meetups' are explicit. It distinguishes from sibling tools like event_meetup_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?

Explicitly states when to use: 'Returns the approved member-organized meetups for an event'. Specifies access conditions (any active DCer who can see the event) and limitations (only approved meetups). Implicitly differentiates from RSVP and attendee listing tools.

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

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

With no annotations provided, the description carries the full burden and explicitly states '⚠️ WRITE operation: this mutates your DC account data.' This clearly informs the agent of the mutation behavior. There is no contradiction with annotations.

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

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

The description is concise: three sentences with no wasted words. It front-loads the HTTP method and resource, then adds key conditions and a warning. Every sentence earns its place.

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

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

For a simple tool with only 2 required parameters and no output schema, the description is reasonably complete. It explains preconditions (free event, rsvpEnabled) and the mutation nature. It could mention expected outcomes (e.g., confirmation, error handling) but is adequate given the tool's simplicity.

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

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

Schema coverage is 100%, so baseline is 3. The description adds no additional meaning beyond the schema: it mentions eventID in the path and status implicitly, but does not explain values or formats. The schema already provides enum descriptions for status, so the description adds negligible 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's purpose: 'RSVP to a free event' with the HTTP method and endpoint. It distinguishes from siblings by specifying 'free RSVP (not ticketed)' and the condition 'rsvpEnabled: true', differentiating it from event_meetup_rsvp and virtual_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 clear guidelines: 'Only works for events with rsvpEnabled: true' and 'not ticketed'. It implicitly tells when to use this tool (for free RSVP events) and when not (ticketed/meetup/virtual events). However, it does not explicitly mention alternatives like event_meetup_rsvp.

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 pagination via cursor, limit cap (1-50), and inclusion of past events via ?past=true. However, does not mention rate limits, auth requirements, or data freshness.

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 three-part structure: title, behavior description, and usage guidance with alternatives. Every sentence adds value, 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 no output schema and optional parameters, the description sufficiently covers purpose, behavior, parameters, pagination, and alternatives. Complete for a list 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?

Schema coverage is 100% with descriptions for all three parameters. Description adds context (e.g., '?past=true' syntactic hint, cursor for pagination) but does not significantly deepen understanding 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 tool lists upcoming events sorted by date, specifies the HTTP method, and distinguishes from sibling 'search_events' which searches 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 provides when-to-use vs alternatives (search_events for name/topic queries), and notes filters like past, cityID, country, since, until for narrower scopes.

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 structure (full schedule, sorted), access constraints, and important time-zone behavior (wall-clock time vs UTC). This is transparent and useful for 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?

The description is concise, front-loaded with the endpoint and purpose, and then provides essential details on access and time-zone handling. Each 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?

Given no output schema, the description explains the return value (full schedule, sorted) and time-zone handling. However, it omits details about the structure of session objects and whether pagination is used. It 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% description coverage for the single parameter eventID, so the schema already provides the meaning. The description adds context about the endpoint path but no new parameter semantics beyond the schema.

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

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

The description clearly states the tool retrieves an event's schedule via GET /events/:eventID/schedule, specifying it returns sessions sorted chronologically. It does not explicitly differentiate from siblings like event_agenda, but the purpose is unambiguous.

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

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

The description provides access rules (any active DCer can view public schedule) and time-zone handling guidance. However, it does not specify when to use this tool over alternatives like event_agenda or event_agenda_get, nor does it mention 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?

Despite no annotations, the description discloses the return shape (same as event attendees), access requirement, and nature of the list (bookmarked attendees). It lacks details on pagination or error handling, but for a simple read operation, it provides 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?

The description is concise, front-loads the purpose with the endpoint path, and includes only essential information (shape reference, access condition). No redundant 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?

The description covers purpose, access, and return shape reference. Given no output schema and simple required parameters, it is mostly complete. Minor omission: no mention of pagination or list limits, but expected list size for bookmarked attendees is typically small.

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

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

Schema description coverage is 100% (both 'eventID' and 'sessionID' have descriptions). The description adds no additional parameter semantics beyond the 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?

The description clearly states the verb ('List'), resource ('session attendees'), and condition ('people who bookmarked it'). It distinguishes from siblings like 'event_attendees' and 'event_meetup_attendees' by specifying the bookmarking criterion.

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

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

The description implies usage context (listing bookmarked attendees) and includes an access note ('any active DCer who can see the event'). However, it does not explicitly state when to use this tool versus alternatives like 'event_attendees' or provide conditions for avoidance.

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 carries the burden of behavioral disclosure. It clearly labels the operation as a WRITE (mutates account data), describes idempotent counter updates, and mentions requirements. No contradictions found.

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 (few sentences) and well-structured, starting with the endpoint, then the action, then requirements and details. Every sentence adds value with no wasted words.

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

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

For a simple toggle without an output schema, the description covers all necessary aspects: purpose, prerequisite, atomic behavior, and mutation warning. It is 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 coverage is 100%, so parameters are already documented. The description adds context beyond the schema by explaining the bookmark toggle analogy and idempotency, which enhances understanding without being redundant.

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 as 'Bookmark / unbookmark a session' and provides a concrete analogy (bookmark/star icon). It also correctly identifies the HTTP method and resource. While sibling tools like event_rsvp exist, the description distinguishes this as a bookmark toggle without ambiguity.

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

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

The description explicitly states the prerequisite ('Requires a valid ticket for the event'), giving a clear condition for when to use. It does not, however, provide direct guidance on when not to use or contrast with alternatives like event_agenda or event_rsvp, leaving some room for inference.

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

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

The description discloses ordering by tier and filtering of deleted sponsors, and notes access requirements. With no annotations, it carries the full burden, but it does not cover error handling, pagination, or other potential behaviors.

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 path. Every sentence is meaningful and there is 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 simplicity of the tool (one parameter, no output schema), the description covers purpose, ordering, filtering, and access. However, it could be more complete by mentioning the response format or potential error 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 describes the single parameter 'eventID' as 'Event ID', which is sufficient. The description does not add extra meaning beyond the schema, so a baseline score of 3 is appropriate.

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

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

The description clearly states the tool lists event sponsors, provides the HTTP method and path, and specifies ordering by tier and filtering of deleted sponsors. It is distinct from sibling tools like 'event' or 'events' which deal with different 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 mentions that access is for any active DCer who can see the event, implying usage context. However, it does not explicitly state when not to use this tool or mention any alternatives among the many sibling tools.

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

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

Discloses idempotency, write operation, and limit behavior. Without annotations, this covers key behavioral traits. No 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?

Most sentences are relevant, but the digression about digest sections is tangential and adds unnecessary length.

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, prerequisites, and constraints adequately for a simple tool. Lacks return value details but no output schema required.

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 describes cityID well (100% coverage). Description adds value by explaining how to obtain the parameter from other endpoints.

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 'Follow a chapter' with HTTP method and resource. Specifies idempotency and distinguishes from siblings like follows_chapter_delete.

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 prerequisite (target must exist in chapters list) and constraint (cap 50 with error). Lacks explicit comparison to other follow tools but offers adequate 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 provided, so description carries the burden. It declares WRITE operation and idempotency but does not specify success behavior or auth requirements beyond 'mutates your data.'

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

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

Three concise sentences front-loading purpose, idempotency, and side effects. 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 single-parameter tool with no output schema, the description is nearly complete. Could mention response status but not essential.

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 clear description for cityID. The description adds no additional meaning beyond what the schema already provides.

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 'Unfollow a chapter' with idempotency and the HTTP method. It distinguishes from the sibling follows_chapter_create which is for following.

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 usage is clear from the name and description. No explicit when-not or prerequisites are needed due to simplicity, but some guidance on auth could improve 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?

Discloses cap of 50 follows and role in powering digest sections. No annotations provided, but description covers key traits for a read-only list.

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 description with front-loaded endpoint info. Additional context about digest usage is relevant but could be split; still 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, it explains return type (mini-chapters with Place ID) and cap. Adequate for a simple list tool with many siblings.

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 is 100%. Description need not add param info; baseline 4 for zero-param tools.

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?

Clear verb 'List' and resource 'followed chapters', with specific detail about returning Google Place ID per chapter. Distinguishes from create/delete 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?

States usefulness for creating trips and surfacing activity, and mentions driving locator_digest sections. Implicitly when to read, no explicit when-not but context given.

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 the read-only nature (GET), a cap of 150 follows, and the response structure including a 'cap' field. It also explains how the output relates to other endpoints, giving good transparency for a simple read 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, with three sentences that are front-loaded with the primary purpose. Each sentence adds necessary detail without redundancy or unnecessary length.

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 covers the return shape (mini-profile), the cap, and integration with other endpoints. It also explains the utility in locator digest, making it complete for the tool's complexity.

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

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

The input schema is empty, so schema coverage is 100%. While the description does not add parameter information (none exist), it adds value by explaining what the tool returns and its context, exceeding the baseline of 3.

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

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

The description clearly states 'List the DCers you are currently following,' providing a specific verb and resource. It distinguishes itself from sibling tools like 'follows_chapters' and 'follows_profiles_by_id_create' by focusing on listing followed profiles.

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

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

The description provides context on how the output integrates with other endpoints (e.g., 'roundtrips cleanly with GET /profile/:userID') and mentions the cap and its use in locator digest. However, it does not explicitly state when to use this tool versus alternatives or 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?

With no annotations, description fully discloses write mutation, idempotency, target requirements, cap behavior (409 response), and response structure. Warns about WRITE operation.

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

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

Well-structured and front-loaded, but includes tangential locator/digest note. Could be slightly more concise without losing essential info.

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

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

For a single-param tool with no output schema, description covers response (mini-card, count) and all failure modes, making it complete for agent decision-making.

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 value by explaining how to obtain userID (discovery via GET endpoints) and clarifying it refers to a DCer.

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 'Follow a DCer' with HTTP method and endpoint. Distinguishes from sibling tools like follows_chapter_create by specifying resource type (profile vs chapter). Covers idempotency and constraints.

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 failure conditions (target must exist, publicly visible, no self-follow, cap of 150) and idempotency. Does not explicitly contrast with sibling tools, 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?

Discloses it is a WRITE operation, idempotent, and returns updated count. No annotations provided, so the 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?

Very concise: two sentences and a warning. Front-loaded with HTTP method and purpose. No wasted words.

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

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

Given no output schema, the description explains the return (updated count) and idempotency. Adequate for a simple delete, but could mention response format.

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 does not add meaning beyond the schema's description of userID.

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 'Unfollow a DCer' and differentiates from sibling tools like follows_profiles_by_id_create and follows_chapter_delete. It uses a specific verb and resource.

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

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

The description provides a clear use case: 'whenever you want to stop seeing a DCer in your /locator/digest favoritePeople section.' However, it does not explicitly mention when not to use it or 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 reveals that the tool returns total unread count and per-room breakdown, and limits to subscribed/member rooms. However, it does not disclose behavior like idempotency (implied by GET), error handling, or any side effects. It provides moderate 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 extremely concise, using just two sentences (plus a title line) to convey purpose, return value, and scope. Every part is necessary and front-loaded. 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 param, no output schema), the description adequately explains what is returned (total and per-room unread counts) and the scope. It does not cover error scenarios or response format details, but for a straightforward read tool, it is nearly complete. Missing only minor details.

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

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

Schema description coverage is 100% for the single parameter 'limit'. The description does not add additional meaning or context for the parameter beyond what the schema provides. Baseline 3 is appropriate as the schema already documents the parameter adequately.

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 counts, providing total and per-room breakdown. It also specifies the scope (rooms the user is subscribed to or a member of). While it doesn't explicitly differentiate from siblings like rooms_inbox, the purpose is specific and distinct enough.

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

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

No guidance is given on when to use this tool versus alternatives such as rooms_inbox or rooms_summaries. The description only includes a constraint (which rooms are included) but does not help the agent decide between similar tools.

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

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

No annotations provided, so description carries burden. It discloses return shape and empty state behavior. Doesn't mention authentication or side effects, but GET implies read-only and no 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?

Two concise sentences, front-loaded with endpoint and purpose. No wasted words.

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

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

For a simple read endpoint with no parameters and no output schema, the description provides the return shape and empty state, making it complete for an agent to understand expected output.

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 in schema, so baseline 4. Description adds value by explaining the return structure and empty state, which compensates for lack of output 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 it is a GET endpoint for retrieving interests config. It specifies the resource 'interests' and the action 'get config'. Distinguishes from sibling 'interests_create' by being 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?

While not explicit about when to use vs alternatives, the read nature is clear from 'GET' and 'Get your interests config'. Implicitly distinguishes from mutation tool 'interests_create'. Could explicitly mention use cases.

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 explicitly notes it is a WRITE operation that mutates account data. It also discloses that unknown slugs are silently ignored, which is important for user understanding.

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 operation and parameters; the second warns about mutation. 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 simple mutation tool with one parameter, the description covers the key behaviors (silent ignore, mutation) and parameter constraints. It doesn't specify return values (no output schema) but that is acceptable.

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 the description adds context about the 'updates' map format, the max 20 entries, and the silent ignoring of unknown slugs. This goes beyond the schema 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 clearly states 'Subscribe or unsubscribe from interests' and specifies the POST endpoint. It identifies the resource and action, though it doesn't explicitly differentiate from sibling tools like 'interests' (likely a GET).

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 how to use the tool (single call, map format, max 20 entries) but does not provide guidance on when to use this versus alternatives, or 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?

The description explicitly states it is a read-only GET endpoint, lists the funnel statuses, and describes the fields in each record. As no annotations are provided, the description carries the full burden and covers key behavioral traits, though it does not mention authentication or rate limits.

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

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

The description is well-structured with markdown for lists and code references. It is front-loaded with the purpose and contains no redundant sentences. Slightly verbose due to detailed funnel explanation, but still efficient.

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

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

Given the tool has only two parameters, no output schema, and no annotations, the description is remarkably complete. It explains the data returned (funnel status, invite type, invitee info, timestamps), pagination via cursor, and the two source types, leaving no significant gaps.

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

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

Schema description coverage is 100%, with both parameters (limit, cursor) well-described in the schema. The description adds no additional value beyond the schema for understanding the parameters, so baseline score of 3 applies.

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

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

The description clearly states the purpose: 'List your invites' with specific verb and resource. It distinguishes from sibling tools by referencing invites_create and invites_permacode, and explains the two source types (manual, permaCode) that appear.

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 does (list referral invites) and implicitly distinguishes from related endpoints by mentioning the other endpoints for creating invites or fetching permacode. However, it does not explicitly state when not to use this tool or provide direct comparisons 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?

Explicitly states it is a WRITE operation, mutates DC account data, queues an email, and the invite appears immediately with status 'new'. No annotations provided, so the description fully bears the burden.

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 title, description, effects, and warning. Not overly verbose but contains multiple sentences; could be tightened slightly without losing 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?

Covers key aspects: return behavior (invite shows in GET /invites), email delivery via background task, and immediate status. No output schema, but description sufficiently explains outcomes.

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?

Adds meaning beyond the schema: email as destination, fullName used in greeting and dedup, whyDC as optional note for admin queue. 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?

Description clearly states it sends an invite (POST /invites) and specifies the action: queue a templated email, pre-credit as referrer, and immediate status 'new'. It is specific and distinct from sibling tools like alerts_create or 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?

Explicitly says when to use (send an invite) but does not mention alternatives or when not to use. No direct sibling for invites_create exists, but guidance on when to use other invite-related tools (e.g., GET /invites) is missing.

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 carries burden. Describes a read-only GET operation and the purpose without concealing side effects. 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?

Extremely concise: two sentences. Front-loaded with HTTP method and endpoint, then response description. 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 no output schema, description adequately covers the return value (your permacode) and usage (share link). Could note that it's read-only or idempotent, but overall 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?

Input schema has no parameters (100% coverage). Description adds value by explaining what is returned (permanent referral code) and its purpose.

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's a GET endpoint that returns your permanent referral code. The verb 'Get' and resource 'permacode' are specific. Distinct from sibling tools like invites_create (create invites) and invites (likely list invites).

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?

Implies usage: when you need your permanent referral code to share. Does not explicitly state when to use this versus alternatives like invites or invites_create, but the 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, the description fully discloses behavior: it returns rate limits and usage data, and mentions that same data is available via headers. No destructive or hidden side effects are implied.

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 paragraphs: first defines the tool's purpose and output, second adds contextual links to headers and tier info. Every sentence adds value; 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 zero-parameter tool with no output schema, the description fully explains what the tool returns, how limits are determined, and how to access the same data alternatively. It covers all necessary context.

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

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

The input schema has zero parameters and 100% coverage, so no additional parameter descriptions are needed. The description adds no parameter info, but none is required.

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

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

The description clearly states 'GET /limits — Get your effective rate limits + current usage', using a specific verb and resource. It distinguishes this tool from siblings by focusing on rate limit information, which is unique among the sibling tools.

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

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

The description provides explicit guidance on when to use this endpoint ('when you want a JSON snapshot') versus reading headers on every call. It also explains the source of limits (membership tier, admin overrides), helping the agent decide usage 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 provided, so description carries full burden. It explains the response structure and section skipping, which is helpful. Missing details on authentication or rate limits but sufficient for a read-only 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?

Well-organized with bullet points for each section. Every sentence adds value, starting with the HTTP method and 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?

Given complexity of response with four sections, the description is thorough. Could mention prerequisites like having a home city, but overall very complete 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 parameter fully, but description adds extensive details on each section's content and behavior beyond the enum list, providing significant additional 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?

Description explicitly states 'Get locator digest' and explains the resource. It distinguishes from sibling tools like locator_settings by focusing on digest 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?

Provides clear context: 'Use this to surface trip/event activity...' and explains how to select sections. Lacks explicit when-not-to-use or 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 must cover behavior. It describes the return as four toggles and the digest's purpose, but does not disclose side effects, idempotency, or authentication requirements.

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 sentences: the first specifies the HTTP method and endpoint, the second explains the response. 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 (no parameters, no output schema), the description adequately explains what it returns. Could mention authentication or error conditions, 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?

There are no parameters, so the schema covers 100%. The description adds value by hinting at the response structure (four toggles), compensating for the absence of an output 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 retrieves locator email settings via GET, specifies it returns four toggles, and distinguishes from sibling 'locator_settings_update' which is 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?

The description indicates it retrieves settings for reading, and the sibling 'locator_settings_update' implies it should be used when not modifying settings. However, no explicit when-not or alternative is stated.

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

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

The description explicitly warns that this is a WRITE operation that mutates DC account data, using a warning emoji. No annotations are provided, so the description fully carries the burden and does so effectively.

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: two sentences plus a prominent warning. Every part adds value without redundancy. The HTTP method and warning are front-loaded for quick agent parsing.

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 4 boolean parameters with full schema coverage and no output schema, the description covers the tool's purpose, usage pattern, and behavioral traits adequately. Could mention the endpoint path more explicitly, but overall 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 description identifies the parameters as 'Friday locator email toggles' and notes they are boolean. This adds context beyond the input schema (which only gives field descriptions). Schema coverage is 100%, so the description adds meaningful grouping.

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 title and description clearly state it updates Friday locator email settings, with specific reference to toggles. It distinguishes itself from the sibling `locator_settings` (likely read-only) by being the update counterpart.

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 to send only the fields you want to change, providing clear usage context. However, it does not explicitly mention when not to use this tool or suggest alternatives like `locator_settings` for reading.

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. States it is a GET (read-only) and lists returned data, but does not mention authentication requirements, rate limits, or any side effects. Adequate for a simple read 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?

Three sentences, front-loaded with HTTP method and purpose. Every sentence adds value. 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 tool with no parameters and no output schema, the description lists return fields sufficiently. Could be improved by noting authentication requirement, 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?

No parameters exist (empty schema, 0 params), so description does not need to add param meaning. Baseline 4 for zero parameters 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 explicitly states 'GET /membership — Get your membership state' and enumerates return fields. Clearly distinguishes from sibling 'membership_invoices' by focusing on state, not invoices.

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

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

No explicit when-to-use or when-not-to-use guidance. However, the single purpose is clear enough for a simple read tool. Lacks differentiation from alternatives among many sibling tools.

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

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

Discloses key behaviors: newest-first ordering, inclusion of safe-to-share links, and behavior for legacy users (empty array). No annotations are provided, so the description carries the full burden, and it adequately covers safety and return conditions.

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 front-loaded purpose and efficient details. No redundancy or excessive length; 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?

For a simple list tool without output schema, the description explains return values (hosted URL, PDF link) and edge cases (empty array for legacy users). It covers essential context for correct invocation, though pagination details beyond 'limit' are not discussed.

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 'limit' is fully described in the input schema (max 1-100, default 20), so the description adds no extra meaning. Baseline 3 is appropriate given 100% schema coverage.

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

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

The description clearly states the tool lists Stripe invoices, with specific details like newest-first ordering and included fields (hosted-invoice URL, PDF link). It distinguishes itself from other membership-related tools by focusing on invoices, though it does not explicitly differentiate from siblings like 'membership' or other payment 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?

No guidance on when to use this tool versus alternatives (e.g., 'membership' for general membership info). The description implies it is for self-serve receipts but does not specify prerequisites or cases where other tools would be more appropriate.

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 defaults for unset preferences and null email for certain categories. Lacks mention of authentication or rate limits, but acceptable for a simple read 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?

Three concise sentences, front-loaded with main 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?

Provides complete context: what it returns, default behavior, and special cases. References sibling tool for related but separate functionality.

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; schema empty. Description adds value by explaining response structure, defaults, and null handling.

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 retrieves notification preferences, specifying the HTTP method and endpoint. Distinguishes from sibling tool for locator digest.

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 when to use (get preferences) and when not to (for locator digest, use separate tool). Provides alternative.

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

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

Without annotations, the description carries full burden. It explicitly states it is a WRITE operation that mutates data and mentions a specific rejection case. However, it does not cover idempotency, authorization requirements, or rate limits, which are typical for mutation tools.

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 three sentences. It front-loads the HTTP method and purpose, includes a usage guideline, and a 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?

For a tool with one parameter and no output schema, the description covers the operation, partial update behavior, and a specific error condition. It does not mention response format or error codes, but it is largely sufficient for an agent to understand how to use it correctly.

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

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

Schema coverage is 100%, baseline 3. The description adds value by reinforcing the partial update behavior (PATCH semantics) and the constraint on email for reaction/myReaction, which is not in the schema. It enhances understanding beyond the schema 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 clearly states the verb (Update) and resource (notification preferences). It includes the HTTP method PATCH, which distinguishes it from siblings like 'notifications' (likely a GET). However, it does not explicitly differentiate from 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 explains when to use it: to update a subset of preferences, and provides a specific constraint: email is not supported for reaction/myReaction. It lacks explicit alternatives (e.g., for reading use 'notifications'), 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 must carry the full burden. It indicates the tool is a GET request (read-only) and describes the return shape. It does not mention authentication, rate limits, or side effects, but given its simplicity, the description is adequate.

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 and a parenthetical note. It front-loads the HTTP method and endpoint, then immediately states the purpose. 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?

The description covers the tool's purpose, usage, and output shape (same as GET /places/search). Given there is no output schema and only one parameter, the description is sufficiently complete for an agent to understand how and when to use 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 provides 100% coverage with a description for placeID. The tool description adds context by clarifying it's a Google Place ID and explains where to obtain it (from GET /places/search or previous responses), enhancing the schema's minimal 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 clearly states it fetches full details for one Google Place ID, distinguishing from the search tool. It also explains the specific use case of verifying a placeID before using it with POST /trips, establishing a distinct purpose.

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

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

The description explicitly advises using this tool to verify a placeID before sending it to POST /trips, noting that POST /trips only accepts type:'city' placeIDs and rejects venues. It also mentions the output shape matches GET /places/search, providing context for when to use each. However, it doesn't include exhaustive 'when not to use' scenarios, but the guidance is still solid.

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 return fields (type, enriched location) and their implications for API usage (venue matches rejected by POST /trips). However, it does not explicitly state that the operation is read-only or mention rate limits/auth, which would elevate transparency further.

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

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

The description is front-loaded with the HTTP method and verb, and every sentence adds value. It is structured logically: start with purpose, then usage context, then result interpretation. No redundant or 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?

Given the tool has only two parameters, no output schema, and no annotations, the description provides sufficient context for correct invocation. It covers the primary use case, result filtering, and integration with other endpoints (POST /trips, event/meetup APIs). The agent has all necessary information to select and 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?

Schema coverage is 100%, so the baseline is 3. The description does not add semantic nuance beyond the parameter descriptions in the schema. It rephrases the query purpose but provides no additional context about acceptable formats or edge cases for either 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 searches for places by name and explains its primary use case for looking up a Google Place ID before creating a trip or referencing a venue. It distinguishes itself from the 'place' sibling by noting that results can be passed directly to POST /trips without a follow-up GET /places/:placeID.

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 the tool (before creating a trip or referencing a venue) and how to filter results (type === 'city' for trips, either type for events/meetups). It implicitly contrasts with the alternative 'place' tool by stating that no follow-up is needed, giving the agent a clear decision rule.

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

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

The description discloses the return shape (full profile, identical across tiers), and that it includes tier-derived state. Since no annotations are provided, the description adequately covers behavioral aspects, though it omits authentication requirements or rate limits.

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

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

The description is extremely concise, consisting of two sentences plus a code reference. It front-loads the HTTP method and purpose, and 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?

Without an output schema, the description sufficiently explains what is returned (full profile, same shape regardless of tier, includes editor fields and tier-derived state). It also guides users to the update tool, making it complete for this read-only 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?

There are no parameters, and the schema coverage is 100%. Thus, the description does not need to add parameter info. A score of 4 is appropriate for zero-parameter tools.

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 own profile via GET /profile, specifying it returns every field from the profile editor plus tier-derived state. It distinguishes itself from the PATCH /profile update tool.

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

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

It explicitly states when to use: to get your own profile, and mentions the PATCH /profile tool for updates. However, it does not address when not to use it, such as needing another user's profile, though the context of 'your own profile' implies that limitation.

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 AI-powered nature, write operation, mutation of account data, rate limits, and limitations of filters like gender and location. No annotations exist to contradict.

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 sections and bullet points, but somewhat lengthy. Front-loaded with key info; 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?

Covers both modes, filter behaviors, rate limits, and limitations. Lacks output schema but describes return type ('ranked results'). Sufficient for the tool's complexity.

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

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

Adds significant context beyond the schema: explains modes, how filters interact, when they under-recall, and how to combine them. Schema coverage is 100% but description enriches every 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's purpose: matching DCers based on a natural-language description or recommending based on the user's profile. It distinguishes two modes and contrasts with sibling tools like search_profiles.

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 guidance on when to use each mode, warns about rate limits and sparsely populated filters, and suggests alternative tools (e.g., trips for current location).

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 correctly identifies the operation as a WRITE mutation to DC account data and states which fields are immutable. 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?

Description is front-loaded with the HTTP method and core purpose. It is compact (5 sentences) and covers key points without excess. Could potentially be more structured, but it's 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 30 parameters, no output schema, and no annotations, the description provides sufficient context: what the tool does, which fields are mutable, and the destructive nature. Adequate for an agent to use it correctly.

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

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

Schema has 100% coverage with individual parameter descriptions. The tool description adds context about PATCH semantics and immutable fields, which complements the schema well.

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 profile fields via PATCH, with a specific verb and resource. It distinguishes itself from sibling tools like 'profile' (GET) and 'profile_match_create' (different 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?

Explicitly mentions that only included fields change and lists fields that cannot be updated via API (location, photo, gender). Provides a warning about mutation. However, it does not explicitly contrast with alternative tools like 'profile' for when to use this vs reading.

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 fully addresses behavioral traits. It explicitly states this is a 'WRITE operation' that mutates account data, warns that screenshots and text are sent unredacted, and details screenshot constraints (format, size, EXIF stripping). 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 concise, with a clear header line, followed by details, privacy note, and mutation warning. Every sentence provides essential information without redundancy. Well-structured for quick consumption.

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 usage and constraints but lacks information about what happens after submission (e.g., response format, confirmation, error handling). For a mutation tool, this is a gap. With no output schema, expecting basic success/failure feedback would improve completeness.

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

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

Schema coverage is 100%, so baseline is 3. The description adds meaningful context beyond the schema, such as base64 encoding details for screenshot, size limits, and data URL format. It also clarifies the 'context' parameter as 'debug context'. This adds value for the agent.

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: 'Report an issue or feedback' and 'Submit a bug report, feedback, or question'. It uses specific verbs (report/submit) and identifies the target resource (issues/feedback to DC team). No sibling differentiation needed as no other reporting tools exist.

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 optional features (screenshot inclusion) and provides a privacy note, offering clear context. However, it does not explicitly state when to use this tool versus alternatives, but given no alternative reporting tools in siblings, the guidance is adequate.

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 present, so description carries full burden. It discloses cursor-paginated behavior and sorting order. Could mention that it's read-only, but the GET verb implies it. Lacks details on side effects or response structure beyond pagination.

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 short sentences, front-loaded with endpoint and purpose. No wasted words; each sentence adds essential 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, description explains return types (list of rooms) and sorting. Lacks details on response shape (room object fields) but sufficient for a 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?

Schema coverage is 100%, so baseline is 3. Description adds value by explaining cursor usage ('from a previous response's nextCursor') and reinforces limit default. Confirms pagination context 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 the tool lists subscribed rooms with specific types (DMs, group DMs, channels, etc.) and mentions sorting by lastActivityAt. It distinguishes itself from sibling tools like rooms_inbox or rooms_browse.

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 (list all rooms) and when-not-to-use via alternative: 'To filter by type use GET /rooms/inbox/:type'. This helps the agent choose correctly.

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 discloses that this is a WRITE operation that mutates data, is idempotent, and requires membership. It explains the behavioral effect (hide from inbox sidebar) but could additionally note what data exactly is changed.

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 four short sentences, each adding critical information. It uses formatting (bold, emoji) to highlight access and WRITE nature, and front-loads the main 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?

For a simple tool with one parameter, the description covers the action, effect, side effects (idempotent), access requirement, and reversal operation. No gaps are present given the tool's simplicity and lack of 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% (roomID 'Room ID'), so baseline is 3. The description does not add any parameter-level detail beyond what the schema already provides.

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 the resource 'a room', with the specific effect of hiding from inbox sidebar without unsubscribing. It distinguishes itself from the sibling tool 'rooms_unarchive_create' by explicitly mentioning unarchive.

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 (to hide from inbox sidebar without unsubscribing), access requirements (must be a member/subscriber), and the reverse operation (use unarchive). It also notes idempotency.

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 correctly implies a read operation (GET) and mentions filtering behaviors. However, it lacks details on authentication, rate limits, or the absence of destructive 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 with two sentences that front-load the endpoint and purpose. Every sentence provides value 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?

The description covers usage context (room type, subscription status, DC BLACK filter) but does not describe the return format or pagination behavior, which is important given the cursor parameter and absence of an output schema.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds no additional meaning beyond the schema for parameters; only 'type' is referenced in context.

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 'browse' and the resource 'publicly-joinable rooms by type'. It explicitly notes that it returns only rooms the user is NOT subscribed to, distinguishing it from other room tools like rooms_subscribe_create or rooms.

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 this tool (to discover rooms not yet subscribed to) and notes filtering of DC BLACK rooms. However, it does not explicitly contrast with sibling tools like rooms (which lists subscribed rooms) or rooms_subscribe_create.

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 that reading does not modify unread state or mark as read, and addresses access restrictions. It explains the return values for summaries (null if absent). No annotations were provided, so the description carries full burden and does a good job, though it does not mention rate limits or data freshness.

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?

Starts with the route and core action, then efficiently covers access, side effects, response structure, and alternative tools. Every sentence adds value, and the structure is clean 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 one parameter, no output schema, and no annotations, the description covers purpose, usage, behavior, and alternatives quite thoroughly. It lacks explicit mention of rate limits or full response shape, but for a simple single-room retrieval tool, it is nearly complete.

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

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

Only one parameter (roomID) with schema description 'Room ID'. Since schema description coverage is 100%, baseline is 3. The description adds context about what the tool returns but does not elaborate on the parameter format or constraints, so no extra 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 retrieves a single room's metadata and AI summaries, using the verb 'Get' and specifying the resource. It distinguishes itself from sibling tools like rooms, rooms_summaries, and search_messages by focusing on single room retrieval with summaries.

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 access conditions (members, subscribers, DCers, with clear 403 cases). It specifies that this endpoint does not mark the room as read, and offers alternatives like POST /search/messages for specific content queries and other endpoints for summary history.

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 mentions the return shape matches GET /rooms, but does not disclose that it only returns subscribed rooms, pagination behavior, or required authentication. Adequate but could be more explicit.

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, well-structured sentences. The endpoint and purpose are front-loaded, with a clarifying example. No unnecessary content.

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

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

Given 3 parameters and no output schema, the description adequately explains the tool's purpose and scope. It references the shape of another tool but does not fully define the return structure. Still complete for a straightforward listing tool.

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

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

Schema coverage is 100%, so the baseline is 3. The description does not add additional meaning to parameters beyond what the schema provides (e.g., type allowed values, limit, cursor). No extra 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 explicitly states the tool lists rooms by type, with an HTTP endpoint and concrete examples (DMs, group DMs). It clearly distinguishes from the sibling 'rooms' tool by specifying it returns a filtered 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?

Indicates this is the scoped version of GET /rooms, implying use when a specific room type is needed. Does not explicitly state when not to use, but the context is clear and alternatives are inferable from sibling tools.

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

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

No annotations provided, so description carries full burden. It clearly states read-only behavior, no side effects, exclusion of hidden/deleted/sunk messages, and cursor-paginated, newest-first order. 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?

Well-structured with clear sections, front-loaded purpose and key behavior. Each sentence adds value; no waste. Slightly longer than necessary but still efficient for the 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 no output schema, description covers pagination, access rules, exclusion of certain messages, and sibling differentiation. Could mention response format (list of message objects) but is adequate for agent selection and invocation.

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

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

Schema coverage is 100%, baseline 3. Description adds extra meaning: for 'before' it explains it encodes the previous page's oldest message timestamp; for 'roomID' it lists discovery methods; for 'limit' confirms max 50. 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 clearly states the tool lists messages in a room with explicit verb ('List') and resource ('messages in a room'). It distinguishes from sibling search_messages by describing use cases (chronological window vs topic search).

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 guidance on when to use this tool vs alternatives: 'This endpoint is the right call when you want a chronological window... search is the right call when you want a topic.' Also details access restrictions and pagination 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 provided, the description carries the full burden. It discloses that it is a WRITE operation, sets a persistent mute state until explicitly unmuted, and only suppresses notifications (room still visible). This covers key behavioral traits, though it could mention idempotency or rate limits.

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

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

The description is well-structured with a clear first line (HTTP method and path), followed by a precise explanation, access condition, and a warning label. Every sentence is necessary and contributes to understanding, with no extraneous text.

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

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

Given the tool's low complexity (single parameter, no output schema) and the context provided (effect, access, mutation warning), the description is fully adequate. No additional details are required.

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 100% of parameters, and the description implicitly identifies roomID as the path parameter. However, it adds no additional meaning beyond the schema's 'Room ID' description. 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 action (Mute), the resource (a room), and the specific effect: suppressing notifications while keeping the room in the inbox. It explicitly mentions the far-future timestamp and the need for explicit unmuting, distinguishing it from related tools 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?

It provides access requirements (must be a member/subscriber) and a warning about mutation, but does not explicitly guide when to use this tool versus alternatives (e.g., rooms_unmute_create or other notification-related tools). The context is clear enough for most use cases.

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 explicitly states it's a WRITE operation that mutates data, mentions auto-subscription behavior, and idempotency. This is thorough behavioral disclosure.

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

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

The description is concise and well-structured: method path, action, conditions. Minor redundancy (e.g., 'Pin a room' in both title and body), but overall 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?

With one parameter and no output schema, the description fully covers behavior, access constraints, and idempotency. Enough for an agent to determine correct usage without ambiguity.

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

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

Only one parameter (roomID) with schema description 'Room ID'. Description adds context about roomID's role in the URL and access conditions, going beyond the schema. However, parameter semantics are simple, so a high score is still appropriate.

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