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

Discloses side effect of opening a browser UI, matching readOnlyHint=false. No contradiction. Could mention that user interaction is required, but acceptable for a simple 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?

Single sentence, no unnecessary words, front-loaded with core action. Perfect conciseness.

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

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

Tool has no parameters and an output schema exists (not shown), so description need not detail returns. It sufficiently covers the initiation aspect but could mention prerequisites like needing to be logged out.

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

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

No parameters exist, and schema coverage is 100%. Description adds no parameter info, but baseline is 3 per guidelines for high coverage.

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

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

Description clearly states the action ('begin login flow') and method ('via local browser UI'). Distinguishes from siblings like vrchat_auth_status and vrchat_auth_logout by implying this is the initiation step.

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?

Implied usage as the first authentication step, but no explicit when-to-use or alternatives (e.g., use vrchat_auth_status to check if already authenticated). No guidance on 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?

Annotations indicate readOnlyHint=false, and the description adds 'clear session' to disclose the destructive behavior. However, it does not detail side effects, such as invalidating tokens or requiring re-authentication, leaving room for ambiguity.

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 at 4 words, front-loading the core action. Every word is necessary and contributes to clarity, making it appropriately sized for this simple tool.

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

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

Given the tool's simplicity (no parameters, output schema exists), the description fully covers the needed context. It explains the primary action and result (clearing session), requiring no further elaboration.

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

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

The tool has no parameters, so the input schema requires no further explanation. Baseline 4 applies as the description does not need to compensate for parameter documentation.

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 'Logout and clear session' clearly specifies the verb (logout) and resource (session). It distinguishes itself from sibling tools like vrchat_auth_begin (login) and other auth-related tools, making the purpose unambiguous.

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

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

The description provides no guidance on when to use this tool vs alternatives, such as when a session should be cleared or prerequisites like being logged in. It lacks context for proper invocation.

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

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

The description adds no behavioral context beyond the annotation readOnlyHint=true. It does not describe what the tool returns, side effects, or error conditions. For a tool with no annotations beyond readOnlyHint, the description should provide more detail.

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 but at the expense of clarity. It is under-specification rather than efficient communication. A single phrase does not serve the agent's need to understand 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?

Given the presence of an output schema, the description is still incomplete. It does not explain the meaning or use of the output. Even for a simple auth check, a sentence like 'Returns the current authentication status of the user (logged in/out, user ID, etc.)' would be expected.

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

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

The tool has no parameters, so the input schema is fully self-documenting (100% coverage). The description does not need to add param info, but it also fails to provide any additional context about the output. Baseline of 3 is appropriate as the schema already accounts 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 'Auth status.' is a tautology of the tool name and does not specify what aspect of authentication status is returned, e.g., whether it checks login state, token validity, or user identity. It fails to distinguish from sibling tools like vrchat_status_get or vrchat_auth_begin.

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. There is no mention of prerequisites, typical use cases, or exclusions.

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

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

The readOnlyHint annotation already establishes the safety profile, and the description merely repeats 'read-only' without adding new behavioral context such as auth requirements, rate limits, data freshness, or side effects. It does not contradict the annotation.

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

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

The description is a single sentence with the action and target front-loaded. It contains no filler or redundant elaboration, making it well-structured for quick 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?

For a read-only getter with an output schema, the core operation is covered. However, optional parameters are undocumented and no alternative tools are mentioned, so an agent would need to rely on schema inference and sibling-tool names to fully understand selection and invocation behavior.

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

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

With 0% schema description coverage and 4 parameters, the description should compensate by explaining parameter meaning. It only clarifies that avatarId is the lookup key, while fields, compact, and maxArrayLength are left entirely to inference from their names.

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

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

The description clearly states the action ('Get'), the resource ('avatar profile'), and the lookup key ('avatarId'). It is specific enough to be distinguished from sibling user/world profile tools, though it does not explicitly contrast them.

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

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

No guidance is provided about when to use this tool versus alternatives like vrchat_user_profile, vrchat_world_profile, or vrchat_avatar_update. The read-only marker describes a property of the operation, not a use case or exclusion.

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

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

Goes well beyond the destructiveHint annotation by detailing no-undo behavior for asset fields, tag merge semantics that preserve author tags, clearContentTags removing unknown content tags, and two-directional releaseStatus risks (public leak / private breakage). 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?

Every sentence earns its place: it front-loads the core action, then provides essential caveats about asset fields, tag behavior, releaseStatus, and dryRun. The structure is logical and dense without redundancy.

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

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

Given the tool's 8 parameters, mutation risk, and nuanced tag behavior, the description is remarkably complete. It covers scope, restrictions, edge cases, risk warnings, and a preview mechanism. An output schema exists, so the lack of return-value detail 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 covers 100% of parameters, but the description adds critical semantics: the exact content tag enum values, the merge/replace behavior for tags, the role of clearContentTags, the dual dangers of releaseStatus, and the purpose of dryRun for previewing. This far exceeds the baseline.

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

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

Opens with an explicit verb and resource: 'Edit your own avatar metadata', and enumerates exactly which fields are editable (name, description, releaseStatus, content tags). It also distinguishes itself from read-only siblings like vrchat_avatar_profile and clarifies that asset fields are out of scope.

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: this is for editing your own avatar's metadata, and it explicitly excludes asset fields. It gives warning conditions (releaseStatus risks, tag merge behavior) that guide when to be cautious, though it doesn't name alternative tools or state a 'when not to use' beyond scope.

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

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

Annotations indicate it's not read-only (readOnlyHint=false), and description confirms it 'sends' boops. However, no additional behavioral details such as whether boops are one-time, have limits, or require authentication beyond what annotations give.

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?

Single sentence makes it concise, but lacks structure such as separating usage from parameter details. It could be more informative without becoming verbose.

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

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

Given 8 parameters, nested objects, and an output schema, the description is severely lacking. It does not explain what a boop is, the effect, or what the tool returns. With minimal annotations, the description should provide much more 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?

Description mentions only 'user' and 'users' implicitly via 'one or many users'. With 8 parameters and 0% schema description coverage, the description adds negligible value. Parameters like 'retry', 'dryRun', 'emojiId' are completely unexplained.

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 'Send' and resource 'boops', and specifies scope ('one or many users'). It distinguishes from siblings by being the only boop-related tool, but does not explicitly differentiate from similar 'send' tools like 'invite'.

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 like 'invite' or 'message' tools. No prerequisites, permissions, or context provided.

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

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

The annotation readOnlyHint=false already signals a mutation, but the description adds valuable context with 'local-only', clarifying that it does not affect server state. This goes beyond the annotation, though it could mention side effects or scope details.

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

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

The description is a single short sentence with no wasted words. It is appropriately front-loaded and efficient.

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

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

While the core purpose is clear, the tool has three parameters with no descriptions, and the description does not explain what 'cached data' refers to or when invalidation is needed. An output schema exists but does not compensate for missing parameter semantics.

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 0% and the description provides no explanation of the three parameters (key, area, scope). The agent has no way to know how to use them correctly.

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 invalidates cached data and specifies it's local-only. The verb 'invalidate' is specific and distinguishes this from all listed sibling tools, which focus on auth, status, friends, events, etc.

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 vs alternatives, nor any conditions or prerequisites. The description is too minimal to help an agent decide when invalidation is 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?

The description only repeats the 'read-only' nature already declared by annotations. It adds no additional behavioral context such as rate limits, caching, or response characteristics.

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

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

The description is extremely concise (one short sentence) but does not earn its place as it mostly reiterates the tool name and annotation. It is not overly long, but it lacks substance.

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 5 parameters, nested objects, and an output schema, the description is too brief. It does not explain what 'API config' retrieves or how the parameters affect the result, leaving the agent with insufficient 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?

All 5 parameters are fully described in the input schema (100% coverage). The description does not add any meaning beyond what the schema already 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 the verb 'Fetch' and the resource 'API config', and notes that it is read-only. It distinguishes the tool from siblings, as there are no other config-fetching tools in the sibling list.

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

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

The description provides no guidance on when to use this tool versus alternatives, no exclusions, and no context for appropriate 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?

The annotations already indicate destructiveHint=true and readOnlyHint=false, so the agent knows this is a destructive operation. The description adds 'DELETE operation' which aligns but provides no additional behavioral context about auth requirements, irreversibility, or rate limits.

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

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

Two sentences, no wasted words. The first sentence defines the purpose, and the second provides actionable guidance. Perfectly concise for a generic proxy tool.

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

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

Given the tool is a generic wrapper with 5 parameters including nested objects and an output schema exists, the description is minimal but functional. It relies heavily on external tools (vrchat_operations) for full context, which is reasonable for a generated API client, but could offer more about what the operation does.

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

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

Schema description coverage is 100%, so the schema already documents each parameter. The description adds no extra meaning beyond the schema's descriptions and only directs to other tools for details. 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 calls a DELETE operation by operationId, which is a specific verb+resource. However, it does not differentiate from specific delete tools like vrchat_event_delete, relying on the agent to infer that this is a generic tool for any discovered DELETE 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 tells the agent to use vrchat_operations and vrchat_operation_details to discover parameters, providing context for how to prepare the call. However, it does not explicitly state when to use this tool vs. specific delete alternatives, nor does it mention any exclusions or prerequisites.

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?

readOnlyHint=false already signals this is a mutation, and the description's 'create' wording is consistent with that (no contradiction). However, the description adds no behavioral context beyond the annotation — nothing about draft vs. published events, notification side effects, permission requirements, or that the event must belong to an existing group. For a write operation, this fails to disclose meaningful 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 single sentence is grammatically complete and front-loaded with the verb, so it is genuinely concise. But at five words for a 20-parameter mutation tool, it leans toward under-specification rather than disciplined brevity. It reads more like a summary line than a tool definition.

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 an output schema, return-value explanation is unnecessary, but the description still omits essential operational context: date-time format requirements, enum semantics and defaults, behavior of isDraft/featured/sendCreationNotification, and the relationship between groupId and the calendar. The sparse readOnlyHint annotation does little to fill these gaps. The definition is incomplete for the complexity of this tool.

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

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

Schema description coverage is 0%, so the description must compensate for 20 undocumented parameters. It provides no guidance on the five required fields (description, endsAt, startsAt, title, groupId) and no hints about the strict ISO-8601 date-time pattern, enum defaults (category='other', accessType='group'), or optional flags like isDraft, featured, or sendCreationNotification. An agent would have to reverse-engineer semantics from types, validation patterns, and names.

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 'Create a group calendar event' pairs a specific verb with a resource type, clearly identifying a creation operation. The 'create' verb distinguishes it from siblings like vrchat_event_update, vrchat_event_delete, and the various event-read tools. It misses a 5 only because it omits any scope nuance (e.g., the event must belong to a group) that the required groupId parameter implies.

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 usage context is provided — the description says nothing about when to choose this tool over vrchat_event_update, vrchat_event_delete, or the group event read tools. It also omits prerequisites such as group membership or required permission levels to create events. An agent must infer all selection criteria from the tool name alone.

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

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

Annotations declare destructiveHint=true, so the description adds the safety check context. However, it does not elaborate on the permanent nature of deletion or impact on recurring events.

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?

Single sentence, no wasted words. Front-loaded with the action verb. Perfectly concise.

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

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

For a destructive operation with 3 parameters and an output schema, the description is too minimal. It omits return values, permanence, and consequences for recurring events, which are crucial for correct usage.

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

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

Only targetKind parameter gets context from the description; groupId and calendarId are left unexplained despite low schema coverage (33%). The description fails to compensate for missing 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 it deletes a group calendar event, with the additional step of verifying target type. It uniquely identifies the tool among siblings as the delete event 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?

The description implies the need to verify target type but gives no explicit guidance on when to use vs alternatives like updating or following events. No prerequisites or caveats mentioned.

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

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

The description indicates a mutation action ('follow/unfollow') which is consistent with the annotation readOnlyHint=false, but it adds no additional behavioral context such as idempotency, error conditions, or authorization requirements beyond what the annotations already imply.

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

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

The description is a single, clear sentence with no unnecessary words. However, it is so concise that it omits useful detail, which slightly reduces its effectiveness despite efficient wording.

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

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

Given three required parameters, no schema descriptions, and an output schema that is not detailed, the description lacks essential context such as the effect of isFollowing, success/failure responses, and prerequisites. The agent would likely need to infer or test behavior.

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

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

The description does not explain the meaning or format of any parameter (groupId, calendarId, isFollowing). With 0% schema description coverage, the description fails to compensate, leaving the agent to infer usage from parameter names alone.

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

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

The description clearly states the verb 'Follow or unfollow' and the resource 'group calendar event', which is distinct from other event-related sibling tools like create, update, delete, or 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?

No guidance is provided on when to use this tool, prerequisites (e.g., group membership), or how this tool relates to alternatives like event creation or deletion. The description is purely declarative.

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

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

Annotations already declare readOnlyHint=true; description adds 'read-only' parenthetically but provides no further behavioral context (e.g., pagination, ordering, rate limits). Limited added value.

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

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

Single concise sentence is front-loaded but too sparse given 16 parameters. Every word earns its place, but lacks structure for parameter details.

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

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

Despite presence of an output schema, description is incomplete for a tool with 16 parameters including enums and pagination. Does not guide usage of filtering, pagination, or result 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 0%; description only mentions 'category/tag filters' (categories, tags). Fails to explain other 14 parameters (scope, fields, compact, pagination, etc.) leaving agent uninformed.

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 action 'Discover', the resource 'public calendar events', and optional filters. Distinguishes from sibling tools like vrchat_events_upcoming and vrchat_events_search by focusing on discovery with filters.

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 for read-only discovery with filters, but does not explicitly state when to use this tool versus alternatives. No exclusions or context for replacement.

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

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

Annotations already declare readOnlyHint=true. Description adds 'read-only' which is redundant. Does not disclose additional behavioral traits like auth requirements, rate limits, or pagination behavior.

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

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

Single sentence, concise, but lacks structure and detail. Could be more informative while remaining brief.

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 8 parameters and existing output schema, the description is insufficient. Does not cover pagination parameters (maxItems, pageSize, maxPages) or optional fields. Return value is not contextualized.

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 0% and description provides no explanation for any of the 8 parameters. Only 'searchTerm' is implied by the phrase 'by term', but no semantics are added.

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

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

Clearly states verb 'Search', resource 'calendar events', and filter 'by term'. Includes 'read-only' mode. However, does not differentiate from sibling tools like vrchat_events_discover or vrchat_events_upcoming.

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 for searching by term, but no when-to-use or when-not-to-use guidance. No mention of alternatives or prerequisites.

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 accurately labels the tool as read-only, which aligns with the readOnlyHint annotation and adds no contradiction. It further specifies the default time window, providing behavioral context beyond the annotation. For a simple listing tool with output schema, this is sufficient 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 a single, efficient sentence that conveys purpose, scope, and default behavior without extraneous words. It is front-loaded with the core action and provides additional details concisely.

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 8 parameters and no required parameters, the description is too sparse. It fails to explain how to use the parameters to navigate or filter events, leaving a significant gap for an agent. While the output schema compensates for return values, the input semantics are not addressed.

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

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

The description does not explain any of the 8 input parameters despite 0% schema description coverage. Key parameters like 'from', 'fields', 'compact', 'windowHours' remain undocumented, leaving the agent without critical guidance on how to customize the query. The default window hint only indirectly relates to 'windowHours' but is insufficient.

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', the resource 'calendar events', and the scope 'in the upcoming window'. It also specifies default behavior (next 7 days) and marks the tool as read-only, effectively distinguishing it from sibling event tools like vrchat_events_discover and vrchat_events_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?

The description mentions the default window of 7 days, giving a sense of when the tool is appropriate. However, it lacks explicit guidance on when to use this tool versus alternatives (e.g., vrchat_events_search for broader searches) and does not provide exclusion criteria or prerequisites.

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

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

The description adds no behavioral transparency beyond the mutation implied by readOnlyHint=false. It does not explain whether updates are partial or full, what side effects may occur, whether permissions are required, or how missing fields are treated.

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 short and front-loaded, but for a 20-parameter tool it is under-specified rather than appropriately concise. It states only the basic action and omits essential context that should accompany such a complex operation.

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

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

The tool has 20 parameters, 2 required, no parameter documentation, and only a readOnlyHint=false annotation. The one-sentence description leaves out update semantics, identifier usage, side effects, and constraints, so it is far from complete enough for an agent to call it correctly.

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

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

With 0% schema description coverage and 20 parameters, the description needed to explain parameter roles, but it names none. Critical parameters such as groupId, calendarId, sendCreationNotification, and usesInstanceOverflow remain unexplained, leaving an agent to guess how to construct a valid request.

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

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

The description uses a specific verb ('Update') and a clear resource ('a group calendar event'), so an agent can identify the core operation. It does not explicitly differentiate from sibling tools like vrchat_event_create, but the verb and resource make the intent 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?

No guidance is given about when to use this tool versus alternatives such as vrchat_event_create or vrchat_group_event_get, and no prerequisites or exclusions are mentioned. The only usage signal is the word 'update,' which is thin for a complex mutation tool.

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

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

Annotations indicate readOnlyHint=false, consistent with the 'Add' action, but the description adds no additional behavioral context (e.g., idempotency, permission requirements, or effects on existing favorites).

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

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

A single, front-loaded sentence with all essential information and no filler.

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

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

While the description is adequate for a simple add operation, it could mention idempotency, return value, or specific constraints given the existence of an output schema and 3 parameters.

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

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

The description does not elaborate on parameter meanings beyond what the schema already provides (e.g., tags format, relationship between type and tag values). With 67% schema coverage, there is room to add 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 adds a user, avatar, or world to a favorite group. It distinguishes itself from sibling tools like vrchat_favorite_remove and vrchat_favorites.

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 (e.g., vrchat_favorite_remove for removal), nor any prerequisites or exclusions.

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

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

Annotations already indicate destructiveHint=true, and the description confirms removal. No additional behavioral details beyond the annotation, but consistent.

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

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

Two sentences, no filler, front-loaded with 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?

Simple tool with one required param and output schema present; description covers the operation and a key prerequisite, sufficient for the task.

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; description adds clarification that favoriteRecordId is not the target user/avatar/world ID, adding value beyond the schema.

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

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

The description clearly states the action (Remove) and the resource (favorite), and differentiates from sibling tools like vrchat_favorite_add by referencing the lookup step.

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 instructs to use vrchat_favorites first to obtain the favoriteRecordId, providing clear usage context. Lacks explicit when-not-to-use but sufficient for this simple tool.

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

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

Annotations already declare readOnlyHint=true. Description adds 'compact outputs' and enumerates readable resources, providing some behavioral context beyond annotations, but lacks details on pagination, rate limits, or output structure.

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

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

The description is a single concise sentence (15 words) that front-loads the purpose. It wastes no words, but could be more structured by explaining the main parameter (view) that controls which resource is read.

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 complexity (20 parameters, multiple enum options, an output schema), the description is too minimal. It does not cover how to use the view parameter or other key parameters, leaving the agent under-informed for selection and invocation.

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

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

Schema description coverage is 0%, and the description provides no explanation for any of the 20 parameters. The tool's behavior depends heavily on parameters like view, tag, type, but the description offers no 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 explicitly states it reads favorites, groups, limits, and avatars, and specifies read-only nature. It distinguishes from sibling mutation tools (favorite_add, favorite_remove) and other read tools by focusing on favorites.

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 vs alternatives. Does not mention prerequisites, limitations, or recommended scenarios. The description only states 'read-only' and 'compact outputs' without 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?

Annotations already declare readOnlyHint=true, and the description's '(read-only)' merely restates that rather than adding new information. It adds modest context about what is returned (profile, status, location) and hints at offline filtering via the includeOffline parameter, but does not state behavior for missing or offline friends, auth needs, or rate limits. 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?

A single, front-loaded sentence that communicates the action, the resource, and the lookup keys efficiently. The only minor waste is the '(read-only)' parenthetical, which duplicates the readOnlyHint annotation.

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

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

Adequate for a read-only lookup that has an output schema, but real gaps remain: the includeOffline parameter's semantics are undocumented, whether name and userId are mutually exclusive is unstated, and no distinction is drawn from vrchat_user_profile, which likely serves a nearly identical purpose.

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 0%, so the description must compensate. It does clarify that 'name' and 'userId' are alternative lookup mechanisms, adding real meaning for two of three parameters. However, 'includeOffline' is left entirely unexplained, so the compensation is only partial.

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

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

States a specific verb ('Get'), a concrete resource ('a friend's profile, status, and location details'), and the lookup keys ('by display name or userId'). The 'friend's' scope implicitly differentiates it from vrchat_user_profile and vrchat_me, though no sibling is named explicitly.

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 overlapping siblings such as vrchat_user_profile, vrchat_friends_list, or vrchat_friends_search, all of which appear in the sibling list. No when-to-use, when-not-to-use, or alternative-selection conditions are provided.

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

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

Annotations indicate readOnlyHint=false, which is consistent with the description. However, the description does not disclose behavioral details such as rate limits, duplicate request handling, or authorization requirements beyond what is 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 extremely concise, with two short sentences that contain no unnecessary information. It is front-loaded, stating the core action immediately.

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

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

Given the complexity (5 parameters, nested objects, and an output schema), the description is too minimal. It omits details on retry behavior, dry-run mode, error continuation, and output format, leaving significant gaps for the agent.

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

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

The description only clarifies that the 'user' and 'users' parameters accept usr_ ids or display names, but it does not explain the 'retry', 'dryRun', or 'continueOnError' parameters. With 0% schema coverage, the description provides insufficient 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 action 'Send friend requests' to 'one or many users', specifying that users can be 'usr_ ids or exact display names'. This differentiates it from sibling tools like vrchat_invite or vrchat_boop, which involve different actions.

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

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

The description implies the tool is for sending friend requests, but it does not explicitly state when to use it over alternatives (e.g., vs. vrchat_invite for instance invites), nor does it mention prerequisites or exclusions.

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

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

Annotations already declare readOnlyHint=true, so the 'read-only' claim is redundant. The description adds 'cache-backed pagination', which provides useful behavioral context beyond annotations, but no further details on auth needs or side effects.

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

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

Two concise sentences with front-loaded verb and resource. No wasted words; the second sentence adds practical default behavior. Ideal length for a simple 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?

Covers the main purpose and one parameter, but lacks explanation for pagination controls (maxItems, maxPages, pageSize) and detailLevel. With an output schema, return values are covered, but usage of pagination parameters is not.

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

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

With 0% schema description coverage, the description should explain all parameters. It only addresses includeOffline, leaving maxItems, maxPages, pageSize, and detailLevel unexplained. This is a significant gap for a 5-parameter 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 the verb 'List' and resource 'friends', and adds 'cache-backed pagination' for specificity. However, it does not differentiate from sibling tools like vrchat_friends_search or vrchat_friends_overview, which have overlapping purposes.

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 default ('online-only') and how to change it (includeOffline=true). But it offers no guidance on when to use this tool versus alternatives, nor does it mention any exclusions or prerequisites.

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

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

The readOnlyHint annotation already declares the operation non-destructive, and the description reinforces this with 'read-only.' It adds some context about enrichment, but it does not disclose behavior around pagination, default offline-user handling, or how instance detail levels affect results. No contradiction exists.

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

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

The description is a single, efficient sentence that front-loads the action, resource, and core dimensions. The only minor redundancy is repeating 'read-only' despite the annotation, but it does not meaningfully hurt the description.

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?

Output schema and readOnly annotation cover part of the picture, but the tool has six undocumented parameters and a fairly involved filtering/summary behavior. The description does not clarify parameter roles or when to set them, leaving a material gap for confident 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 description coverage is 0%, and the description provides no parameter-level meaning. The distinction between 'status' and 'statusFilter' is ambiguous, and parameters like 'maxLocations', 'minInstanceUserCount', and 'instanceDetailLevel' are left unexplained, forcing the agent to rely on names alone.

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

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

The description uses a specific verb, 'Summarize', identifies the resource, 'friends', and names the key dimensions: status, location, and enriched world/group info. This implies an aggregated overview rather than a raw list, which helps separate it from siblings like vrchat_friends_list, though it does not explicitly name them.

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

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

There is no guidance on when to use this tool versus alternatives such as vrchat_friends_list, vrchat_friends_search, or vrchat_friend_details. The description only communicates the high-level purpose, leaving the agent to infer when this overview is preferred.

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

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

The description adds the key detail that the search is by 'display name' (not username or ID), and reinforces the read-only nature already indicated by annotations. This goes beyond annotations alone.

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 (5 words) with no wasted text. However, the brevity sacrifices completeness; a slightly longer description could improve utility without harming conciseness.

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

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

Given the presence of an output schema (reducing need to describe returns) and annotations, the description is adequate but not thorough. It fails to explain pagination or effect of optional parameters, leaving 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?

With 0% schema description coverage, the description should explain all parameters. It only indirectly covers the 'query' parameter via 'search by display name', but provides no meaning for 'maxResults' or 'includeOffline'. Incomplete compensation.

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

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

The description clearly states the verb 'search', resource 'friends', and criterion 'by display name'. It distinguishes from sibling tools like vrchat_friends_list (which likely lists all friends) and vrchat_friend_details (which shows details for a specific friend).

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 finding specific friends by name, but does not explicitly state when to use this tool over alternatives like vrchat_friends_list or vrchat_friends_overview. No exclusions or prerequisites are provided.

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

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

The annotation only says readOnlyHint=false, so the description correctly conveys a write operation to the signed-in account's gallery. It adds useful context by stating the image is not attached to group posts or events. However, it does not disclose potential side effects such as replacing existing gallery items, rate limits, or upload failure behavior, though the output schema may cover some of this.

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 tightly written sentences. The primary action is stated first, and the differentiation from group-post/event attachment follows immediately. There is no filler or redundant material.

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

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

For a single-parameter upload tool with a detailed input schema and an output schema, the description is sufficient: it identifies the target, the accepted input class, and a key non-goal. An agent has everything needed to select and invoke the tool correctly.

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

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

The input schema already provides 100% coverage for the single parameter imagePath, including path constraints, file type, dimensions, and size limit. The description's mention of 'validated static PNG' aligns with the schema but adds no new parameter-level meaning beyond what the schema already states.

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

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

The description uses a specific verb ('Upload') and resource ('signed-in VRChat account gallery'), and narrows the payload to 'a validated static PNG.' The explicit disclaimer that it 'does not attach the image to a group post or event' distinguishes it from sibling tools like vrchat_group_post_create or vrchat_event_create.

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

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

The description makes the primary use case clear: uploading an image to the account gallery. The sentence 'This does not attach the image to a group post or event' provides an explicit exclusion that helps an agent choose this tool over attachment-related siblings, though it does not name those alternatives directly.

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

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

Annotations already declare readOnlyHint=true. The description adds 'read-only' which is redundant but not contradictory. No additional behavioral details (e.g., error handling, permissions) are provided.

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 one sentence, but it omits essential parameter information, making it under-specific rather than efficiently concise.

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 six parameters and presence of an output schema, the description is insufficient. It does not explain how to identify the event or what the response contains.

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 0%, and the description says nothing about the six parameters (fields, compact, groupId, shortCode, calendarId, maxArrayLength). The agent has no guidance on what each parameter controls.

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 a single group calendar event (read-only).' It uses a specific verb and resource, distinguishing it from sibling tools like vrchat_group_events_list which returns multiple 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?

No guidance on when to use this tool versus alternatives like vrchat_group_events_list or vrchat_group_event_next. Does not mention prerequisites or 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?

The description repeats the 'read-only' hint already present in annotations but adds no further behavioral context such as idempotency, rate limits, or authentication requirements. With annotations present, the bar is lower, yet the description fails to provide additional value.

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

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

The description is a single concise sentence that front-loads the core purpose. However, it is overly terse, sacrificing necessary detail about parameters and context, making it minimally adequate.

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 five parameters, no required ones, and an output schema, the description explains the tool's purpose but lacks details on how to use parameters (e.g., groupId vs shortCode) or what return values look like. It is insufficient for an agent to invoke the tool correctly without additional inference.

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 0%, meaning the input schema provides no descriptions. The tool description does not mention any of the five parameters (fields, compact, groupId, shortCode, maxArrayLength), leaving their semantics entirely unexplained. This is a critical gap.

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

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

The description clearly specifies the verb 'Get', the resource 'next upcoming calendar event', and the scope 'for a group'. It distinguishes from sibling tools like vrchat_group_events_list and vrchat_group_events_upcoming by indicating singularity ('next'), but does not explicitly contrast with vrchat_group_event_get which might also fetch a single event.

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

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

No guidance is provided on when to use this tool versus alternatives such as vrchat_group_events_list or vrchat_group_events_upcoming. There is no mention of prerequisites, context, 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 matches the readOnlyHint annotation, so no contradiction. But it does not add additional behavioral context such as pagination, filtering, or auth requirements beyond what the annotation already indicates.

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

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

The description is very concise (one sentence), but it omits essential details about parameters and usage, making it too brief to be fully useful.

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 9 parameters with no schema descriptions and the tool's simplicity in purpose, the description is incomplete. It does not guide the agent on how to use the tool effectively.

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

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

Schema description coverage is 0%, yet the tool has 9 parameters. The description does not explain any parameters, relying entirely on the schema which lacks descriptions. The description fails to compensate.

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 group calendar events and specifies it is read-only. However, it does not differentiate from sibling tools like vrchat_group_events_upcoming, which may have a similar purpose.

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

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

No guidance is provided on when to use this tool versus alternatives. The description does not mention when-not-to-use or reference other 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?

The description explicitly says 'read-only', which is consistent with the readOnlyHint annotation. It adds the time window constraint, but no additional behavioral traits (e.g., data freshness, side effects, or limits) beyond what the annotation already declares.

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?

Single sentence with no filler. Every word adds meaning. Perfectly concise.

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 having 10 optional parameters and an output schema, the description is minimal. It does not explain the time window, group requirement (groupId/shortCode), pagination controls (maxItems, pageSize, maxPages), or compact/field selection. Incomplete 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 0%, so the description should compensate. It hints at a time window (implied by 'windowHours', 'from' parameters) but does not explain any of the 10 parameters. Most parameters lack any interpretive context, leaving the agent to guess.

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 upcoming group events in a time window and is read-only. The verb 'list' and resource 'upcoming group events' are specific, and it distinguishes from sibling tools like vrchat_events_upcoming (non-group) and vrchat_group_events_list (possibly all 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?

No guidance on when to use this tool versus alternatives. Siblings like vrchat_group_events_list and vrchat_events_upcoming exist but no exclusion criteria or usage context is provided.

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

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

The readOnlyHint annotation already covers safety, so the description adds 'summarize' and 'active' context. However, it does not explain what 'active' means or what the summary entails (e.g., which fields are returned). With annotations present, the bar is lower, and 3 is appropriate.

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

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

The description is a single sentence that front-loads the action and resource. It is concise and avoids fluff, though it could be slightly more informative without losing brevity.

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 3 parameters and 0% schema description coverage, the description is insufficient. It does not clarify parameter relationships or the meaning of 'active'. While an output schema exists, the input semantics are missing.

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

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

Schema description coverage is 0%, but the description adds no parameter meaning. It does not explain groupId vs shortCode, maxInstances limits, or how they affect results. The description fails to compensate for the lack of schema descriptions.

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

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

The description clearly states the action 'summarize' and the resource 'active group instances', and labels it read-only. However, it does not differentiate from sibling tools like vrchat_group_members or vrchat_group_events, which could also involve summarizing group 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?

No guidance is provided on when to use this tool versus alternatives (e.g., vrchat_world_instances_overview for worlds). The description only says 'read-only', which is redundant with annotations, but does not give use-case 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?

Annotations already indicate a write operation (readOnlyHint false). Description adds useful behavioral detail about confirmOverrideBlock overriding blocks. However, it does not disclose rate limits, permission requirements, or side effects of inviting (e.g., notifications, group membership changes).

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 tightly written sentences with no filler. Front-loaded with core purpose, then key details. Every sentence contributes 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?

Despite presence of an output schema (reducing need for return value description), the tool has 8 parameters and many sibling tools. Description fails to cover 3 parameters, lacks guidance on required vs optional parameters (despite stating 'requires groupId or shortCode'), and offers no comparison to other invite tools.

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

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

With 0% schema description coverage, the description adds meaning for 5 of 8 parameters (user, users, groupId, shortCode, confirmOverrideBlock). It clarifies user identifier formats and the confirmOverrideBlock default. Missing explanations for retry, dryRun, and continueOnError.

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 'invite one or many users to a group' and specifies acceptable user identifiers (usr_ ids or display names). However, it does not explicitly differentiate from sibling invite tools (e.g., vrchat_invite, vrchat_invite_user) which serve different contexts.

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 guidance on requiring groupId or shortCode and explains confirmOverrideBlock's default and override behavior. Missing when to use this tool over other invite tools or when not to use it (e.g., permissions, self-invite not mentioned). Parameters like retry, dryRun, continueOnError lack 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?

Annotations already indicate read-only. Description adds that view=all is cached and capped at 10,000, and that default returns compact data. 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?

Two sentences, front-loaded with default behavior, then the exception. No superfluous 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?

With 100% schema description coverage and an output schema, the description provides sufficient high-level behavior. Could mention sorting/filtering briefly, but schema covers that.

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

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

Schema covers all parameters with detailed descriptions. The tool description adds value by summarizing the key difference between page and all views, and noting that offset/pageSize are ignored for all.

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 one page of compact group members by default. Distinguishes between view=page and view=all, and is distinct from sibling tools which deal with search, profile, roles, etc.

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 that view=all should only be used when a complete cached snapshot is needed, and mentions the cap. Does not explicitly compare to alternative tools, 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?

The description adds a meaningful behavioral detail: 'Does not notify members unless sendNotification is true,' which is not captured by the sparse annotations (only readOnlyHint: false). However, it does not disclose other potential behaviors such as permission requirements, side effects beyond notification, or error 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?

The description is a single, front-loaded sentence that immediately identifies the action and includes one crucial behavioral caveat. Every word earns its place; there is no redundant or explanatory 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 complexity (8 parameters, 3 required) and the rich schema descriptions, the description adds the key notification nuance but omits other context such as group membership prerequisites or potential failure modes. The output schema helps, but the description itself is minimal and leaves some operational context unstated.

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

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

The schema already provides 100% coverage for all 8 parameters with descriptive text, so the baseline is 3. The description reinforces the sendNotification parameter ('Does not notify members unless sendNotification is true') but does not add new semantic information beyond what the schema already states.

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

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

The description states a specific action ('Create a group post') and resource ('group post'), with an explicit parenthetical ('announcement') that clarifies the post type. This clearly distinguishes the tool from sibling tools like vrchat_group_post_update and vrchat_group_post_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?

No explicit guidance is provided about when to use this tool versus alternatives, nor are any prerequisites or exclusions mentioned. The only hint is the verb 'Create,' which implies usage but does not offer the contextual guidance that would help an agent choose this over update/delete or other group-related tools.

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

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

Annotations already indicate destructive behavior, but the description adds a valuable non-obvious consequence: members already notified are not un-notified. This provides useful behavioral context beyond the annotation.

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

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

Two brief sentences, front-loaded with the primary action. Every word contributes meaning with no redundancy.

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

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

For a simple delete operation with three parameters and an output schema, the description is minimally complete. It covers the core action and a key consequence, but lacks any context on permissions or relationship to other post tools, though this is somewhat mitigated by schema and 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?

Schema coverage is 100% with descriptions for each parameter. The tool description does not add any parameter-specific meaning beyond what the schema already 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 'Delete a group post' with a specific verb and resource, and the notification caveat adds further specificity. It is distinct from sibling tools like create/update/recent posts.

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 or prerequisites. It does not mention that this should be used for removing existing posts, nor any conditions like permissions or side effects beyond the notification note.

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

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

The description adds no behavioral context beyond the readOnlyHint annotation it repeats. It does not disclose pagination behavior, the need to provide either groupId or shortCode, sorting/ordering, or any side effects or prerequisites. With annotations already covering safety, this adds minimal value.

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

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

The description is a single, front-loaded sentence that captures the essence in under ten words. Every word earns its place; no fluff or unnecessary detail.

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

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

With 6 optional parameters and no required ones, the tool has ambiguous invocation requirements. The description does not clarify how to specify the group (groupId vs shortCode) or the pagination parameters, leaving the agent under-informed. Although an output schema exists, the request construction remains unclear.

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 0%, and the description provides absolutely no explanation of any parameter (groupId, maxItems, maxPages, pageSize, shortCode, publicOnly). The agent is left without guidance on how these optional parameters interact or which combination is required to identify the group.

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

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

The description uses a specific verb ('List'), identifies the resource ('recent posts for a group'), and explicitly marks the operation as read-only, clearly distinguishing it from sibling write tools like vrchat_group_post_create/update/delete. It fully conveys what the tool does with no 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 phrase 'read-only' and the focus on 'recent posts' provide clear context for when to use this tool (viewing group posts) and implicitly that it should not be used for mutations. However, it does not name specific alternatives or provide explicit when-not-to-use guidance, just a clear context without exclusions.

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

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

Beyond the minimal readOnlyHint: false annotation, the description richly discloses non-obvious behavior: VRChat replaces the whole post, the tool reads the most recent 300 posts to recover omitted fields, older posts cannot preserve roleIds/imageId, mergedFromExisting: false is reported, and editing does not re-notify members unless sendNotification is true.

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

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

The description is dense but every sentence earns its place. Core update behavior is front-loaded, followed by merge-window caveats, the response flag, and notification behavior. There is no filler or repetition of schema data.

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

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

Given the output schema exists, the description need not enumerate return fields. It covers the critical operational context: partial updates, the 300-post recovery window, fallback behavior for older posts, the mergedFromExisting response flag, and the notification toggle. An agent has everything needed to call this safely and interpret edge cases.

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

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

Schema coverage is 100%, so the schema already documents every parameter. The description adds meaningful update-specific semantics beyond the schema: omitted fields retain current values, roleIds: [] clears restrictions, and the notification side effect is tied to sendNotification. This exceeds the baseline for high schema coverage.

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

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

The description opens with 'Update a group post', a specific verb and resource, and immediately clarifies partial-update semantics ('Omitted fields keep their current values'). This clearly separates it from sibling create/delete operations without needing to inspect schemas.

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

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

The description makes clear this tool edits an existing post identified by postId, and explains the merge behavior for omitted fields. It does not explicitly name alternatives like vrchat_group_post_create or vrchat_group_post_delete, nor does it state when not to use this tool, so it stops short of a 5.

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

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

Annotations already declare readOnlyHint=true, and the description redundantly states 'read-only', which is consistent. However, the description does not add other behavioral context like authentication requirements, rate limits, or caching behavior. Given that the annotations cover the primary safety trait, a score of 3 is appropriate.

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

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

The description is a single sentence with no unnecessary words. It is front-loaded with the verb and resource, making it easy to scan. Every word earns its place.

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

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

An output schema exists, so return values are not needed. However, with 5 parameters and no description beyond two identifiers, the tool is incomplete for an agent to use without additional context. The description covers core purpose but lacks parameter semantics.

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 0%, yet the description only mentions groupId and shortCode. It fails to explain the purpose of 'fields', 'compact', and 'maxArrayLength'. With no parameter details, the agent cannot correctly invoke the tool, especially for optional filtering or formatting.

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

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

The description clearly states the verb 'Get', the resource 'group profile', and the two identifier methods (groupId or shortCode). It distinguishes this as a single-profile fetch tool among multiple group-related siblings, though it could be more explicit about when to use this vs. group search or membership 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 implies you need either groupId or shortCode, but it does not provide explicit guidance on when to use this tool over alternatives, such as vrchat_groups_search for listing groups. There is no mention of prerequisites or exclusions.

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

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

The annotation already declares readOnlyHint=true, and the description reinforces it with 'read-only'. It adds the behavioral detail of returning 'compact fields', but otherwise does not disclose further side effects, permissions, or response behavior beyond what the schema/output schema might provide.

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

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

The description is one compact sentence with the action front-loaded, no filler, and no redundant restating of the tool name. Every word contributes meaning.

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

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

Although an output schema exists and readOnly annotation reduces safety concerns, the description does not adequately cover parameter semantics for identifying a group (groupId vs shortCode). An agent would likely need additional context to invoke this reliably, making it incomplete despite its simple appearance.

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 0%, so the description must compensate. It explains the 'view' distinction (roles vs templates) but does not clarify the meaning or usage of 'groupId' or 'shortCode' — for example, whether they are alternatives, required, or how they select the group. This leaves key parameters ambiguous.

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

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

The description uses a specific verb 'List' with a clear resource ('group roles or role templates') and signals 'read-only', which distinguishes it from the sibling management tool vrchat_group_roles_manage. It also notes compact fields, making the output scope 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 statement clearly frames the tool as a read-only listing operation, implying it is for retrieval rather than management. However, it does not explicitly name alternatives or state when not to use it, so it stops short of full guidance.

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