VRChat MCP

by BASIC-BIT

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.10
Disambiguation2/5
Multiple tools have overlapping purposes: vrchat_friends_list, vrchat_friends_search, vrchat_friends_overview, and vrchat_friend_details all retrieve friend information with subtle differences. Similarly, vrchat_invite is a generic catch-all that makes vrchat_invite_user and vrchat_invite_self redundant. The generic vrchat_read/write/delete also overlap with specific operations, creating substantial ambiguity for agent selection.
Naming Consistency4/5
The tools consistently use snake_case with domain prefixes like vrchat_ and vrcx_. Read operations often drop the 'get' verb (e.g., vrchat_world_profile) while writes include verbs (e.g., vrchat_event_create). A few outliers like vrchat_boop, vrchat_me, and vrchat_read/write/delete break the pattern, but overall the naming is systematic and predictable.
Tool Count2/5
At 69 tools, the server is far beyond the recommended range. While VRChat's API is broad, the tool set bundles many small operations (e.g., separate tools for every group/event action) plus generic OpenAPI passthrough tools, making the surface overwhelming and hard to navigate.
Completeness5/5
The tool set covers most VRChat domains: profile, friends, groups, events, posts, instances, worlds, avatars, favorites, and notifications. The inclusion of generic vrchat_read/write/delete with operation discovery ensures that any OpenAPI endpoint can be accessed, so there are no obvious dead ends.
Average 3.4/5 across 69 of 69 tools scored. Lowest: 1.4/5.
See the Tool Scores section below for per-tool breakdowns.
- 1 of 1 community issues answered or closed in the last 6 months
- 33 commits in the last 12 weeks
- Last stable release on August 3, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior1/5
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.
Conciseness2/5
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.
Completeness1/5
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.
Parameters3/5
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.
Purpose1/5
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.
Usage Guidelines1/5
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.
Behavior2/5
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.
Conciseness3/5
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.
Completeness1/5
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.
Parameters1/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description merely says 'Create', which is a write operation, but this is already implied by readOnlyHint: false. No additional behavioral context is given (e.g., permissions required, side effects, or limitations).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (one sentence), but it sacrifices necessary detail. While there is no wasted text, the brevity harms usability, making it merely adequate.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the high parameter count (20) and zero schema descriptions, the description is critically incomplete. It lacks any context about required fields, defaults, or behavior, and does not mention the output schema, leaving the agent poorly informed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
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 should compensate by explaining key parameters (e.g., tags, category, platforms). It does not, leaving the agent with no guidance on parameter usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Create' and the resource 'group calendar event', which is specific. However, it does not distinguish this from sibling tools like vrchat_event_update or vrchat_group_events_list, leaving potential ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidelines are provided. The description does not specify when to use this tool versus alternatives (e.g., updating events, listing events), which is a significant gap given the many event-related siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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.
Conciseness3/5
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.
Completeness2/5
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.
Parameters1/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false, so the description's 'update' adds no new behavioral insight. It does not disclose side effects, whether the update is partial or full replacement, or any restrictions (e.g., cannot change groupId or calendarId).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only one sentence (5 words), which is under-specified for a tool with 20 parameters and complex behavior. Conciseness should provide key details while being efficient; here it omits critical information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite an output schema existing, the description does not indicate what the tool returns or any success/failure conditions. With many optional parameters, it should mention that only provided fields are updated (if true), but it does not.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
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 20 parameters (e.g., which are optional, format expectations beyond schema, or functional roles). The agent must infer entirely from parameter names and types, which is insufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Update a group calendar event,' which clearly identifies the verb (update) and the resource (group calendar event). It distinguishes from sibling tools like create, delete, or get, though it doesn't explicitly differentiate its scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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_event_create' or 'vrchat_group_event_get.' There is no mention of required permissions, prerequisites, or scenarios where update is inappropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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.
Conciseness3/5
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.
Completeness2/5
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.
Parameters1/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description is consistent with annotations (readOnlyHint=false implies write), but fails to disclose any behavioral traits such as side effects, authentication needs, 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and concise, but it is under-specified for the complexity of the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 18 parameters, required fields, and an output schema, the description fails to explain how to effectively use the tool or what the return value represents.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description adds no meaning to any of the 18 parameters, including required ones like worldId, type, and region.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a new instance' is clear with a specific verb and resource. It distinguishes from sibling tools since no other tool creates instances, but lacks any scope detail.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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, no prerequisites or context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description restates the read-only nature already indicated by the readOnlyHint annotation. It adds no additional behavioral context such as authentication requirements, rate limits, 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short, which is concise but at the cost of omitting necessary details. It is front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameter documentation and no output schema description (though output schema exists), the tool is incomplete for an agent to use correctly. The description lacks context for when to select this over similar tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
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 two parameters 'name' and 'worldId'. The description fails to compensate for the lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'summarize' and the resource 'world instances' with dimensions by access type and region. It adds '(read-only)' which clarifies the nature. However, it does not explicitly differentiate from the sibling 'vrchat_group_instances_overview', but the resource distinction is implicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 lacks any context for usage scenarios, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds the behavioral note 'compact results', which goes beyond the readOnlyHint annotation. However, it does not disclose pagination, rate limiting, or what happens when no favorites exist, so the transparency is adequate but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (one sentence), which is concise but lacks structure. It does not break down key behaviors or parameter roles, making it too brief given the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having 16 parameters and no schema-level parameter descriptions, the description offers no information about filtering, pagination, sorting, or output format. It fails to provide a complete picture for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description provides no explanation of any of the 16 parameters, including important filtering and sorting options. This leaves an agent with no understanding of how to form queries or what each parameter does.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists favorited worlds and mentions 'compact results', which hints at a different output format. However, it does not explicitly differentiate from sibling tools like vrchat_favorites (which lists favorites generally) or vrchat_worlds_search, limiting how well an agent can distinguish it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 like vrchat_worlds_profile for full details or vrchat_favorites for other favorite types. The description only says 'read-only', which is already annotated, offering no practical usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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.
Conciseness3/5
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.
Completeness2/5
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.
Parameters1/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior3/5
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.
Conciseness4/5
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.
Completeness2/5
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.
Parameters1/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation readOnlyHint=false already signals a mutation, and the verb 'invite' aligns with that. No additional behavioral context is provided, such as whether the invitation requires friendship, is reversible, or triggers a notification.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that avoids redundancy. It is appropriately short for a simple statement, though it omits useful context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 5 parameters, an output schema, and several sibling invite tools, yet the description only provides a bare statement of function. It does not explain how to construct an invitation, what prerequisites exist, or how it differs from other invite tools, 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.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema includes descriptions for worldId, location, and instanceId, but the tool description adds no parameter semantics. The missing descriptions for userId and messageSlot are not compensated, leaving the agent to infer from names alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the action ('invite') and the target ('a user to an instance'), making the core function clear. However, it does not distinguish this from sibling tools like vrchat_invite_user_to_me or vrchat_group_invite.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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_invite_user_to_me or how to specify the instance (via worldId+instanceId versus location). The schema provides some parameter hints, but the description itself offers no usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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.
Conciseness4/5
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.
Completeness2/5
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.
Parameters1/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description merely repeats '(read-only)' without adding new behavioral context (e.g., authentication needs, rate limits, side effects). It does not address anything beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence that front-loads the purpose. No wasted words, but a slightly expanded structure could improve clarity without sacrificing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one param, read-only, output schema exists), the description covers the basic action. However, it does not explain what a 'VRCX user memo' is or how it relates to sibling tools, leaving some context gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at 0%, the description only mentions 'by userId' but provides no format, valid value range, or explanation of what constitutes a valid userId. This adds minimal value to the schema's bare parameter definition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('VRCX user memo'), and notes it is read-only. However, it does not explicitly differentiate from sibling tools like vrcx_memos_world_get or vrcx_memos_avatar_get, relying on the name for distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., world or avatar memo retrievals). The description does not specify context, prerequisites, or exclusions, leaving the agent without explicit direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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.
Conciseness3/5
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.
Completeness2/5
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.
Parameters1/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true. The description adds 'compact results' but does not disclose pagination, rate limits, or other behavioral traits. Minimal added value beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One efficient sentence front-loading the purpose with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description is too brief for a complex tool with 15 parameters and many siblings. It does not explain pagination, filtering options, or result details, leaving the agent underinformed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description does not explain any of the 15 parameters. It only mentions 'by name' but fails to describe query, filters, pagination, etc. This is a critical gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches worlds by name and returns compact results. It distinguishes from sibling tools like world profile or favorites, though it does not fully capture that the search can use other filters beyond name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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_worlds_favorites or vrchat_world_profile. 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.
Behavior2/5
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.
Conciseness3/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description reinforces read-only behavior. It adds 'enriched world/group info' but does not disclose other behavioral details like pagination or rate limits. The description is adequate but not exceptional beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one sentence of 11 words, extremely concise. However, it could benefit from a slightly more structured format to improve readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 6 parameters and no parameter documentation in the schema or description, the tool is incomplete. The existence of an output schema mitigates the need to explain return values, but parameter usage remains underspecified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate but only vaguely mentions 'status and location'. None of the 6 parameters are explained, leaving the agent without semantic guidance for parameters like statusFilter, includeOffline, instanceDetailLevel, etc.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Summarize', the resource 'friends', and the criteria 'by status and location'. It distinguishes itself from siblings like vrchat_friends_list, vrchat_friends_search, and vrchat_friend_details by emphasizing summarization and enriched info.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. With many sibling tools, the agent receives no context for appropriate invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false, so the tool is a write operation. The description adds 'low-risk write', which characterizes the side effects but does not detail what exactly happens (e.g., joins instance, creates a record). No destructive hint is provided, but the description offers minimal additional transparency 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no unnecessary words. It front-loads the key action and risk level. However, it could benefit from additional structured details (e.g., parameter relationships) without being verbose, potentially reaching 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's 3 parameters, lack of required fields, and no output schema visible, the description is too sparse to ensure correct invocation. It does not specify how to combine parameters or the consequences of different combinations. The presence of an output schema (not shown) mitigates this slightly, but the description remains incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema defines 3 parameters (worldId, location, instanceId) with 0% description coverage. The description does not explain the purpose, format, or any dependencies among these parameters. For a tool with no parameter documentation, this is a critical gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'invite yourself' and the resource 'instance'. It distinguishes this tool from sibling invite tools (e.g., vrchat_invite, vrchat_invite_user) by specifying self-invitation. The parenthetical 'low-risk write' further clarifies its safety profile.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives. It does not mention prerequisites, exclusions, or when not to use it. The 'low-risk write' hint is indirect but insufficient for clear usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description repeats the readOnlyHint annotation, which is already provided. It adds no further behavioral details (e.g., return format, rate limits, authentication requirements). Consistent with annotations, so 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no wasted words. Front-loaded with key info. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having 5 optional parameters and output schema, description is extremely minimal. It doesn't explain the time format, timezone, or why paging/fields are needed. Output schema may help, but description fails to provide sufficient context for effective tool usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but description adds no value for parameters. The parameters (paging, fields, compact, includeMeta, maxArrayLength) are present but not explained, which is confusing for a time-fetching tool. Schema alone doesn't clarify their relevance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb 'Get' and resource 'current system time'. Name reinforces purpose. However, it doesn't explicitly differentiate from sibling tools like vrchat_auth_status or vrchat_status_get, which might also provide time-related info.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. The description doesn't specify context, prerequisites, or exclusions. An agent would need to infer usage from name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true; description only repeats '(read-only)' without adding new behavioral details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise (6 words), front-loaded with action, no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Simple tool with 1 param and output schema present, but lacks detail on default behavior (e.g., when no memo exists) or how worldId is used.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%; description merely mentions worldId in the purpose but adds no meaning beyond the schema type or format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the action (Get) and the resource (VRCX world memo by worldId), and distinguishes from sibling memo tools (e.g., vrcx_memos_user_get, vrcx_memos_avatar_get).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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; lacks context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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.
Conciseness3/5
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.
Completeness2/5
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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the agent knows it's safe. The description adds the optional group listing behavior but doesn't disclose other traits like error handling or authentication needs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no redundancy, front-loading the core purpose and optional group inclusion.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description lacks essential input context: how to identify the user, meaning of fields parameter, and pagination details for groups. This gaps are significant for a 9-parameter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must explain parameters but only implicitly mentions includeGroups. The other 8 parameters (fields, userId, username, etc.) are left unexplained, making tool invocation difficult.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets a user profile and optionally includes groups, using a specific verb and resource. It distinguishes from sibling tools like vrchat_group_profile and vrchat_avatar_profile.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 like vrchat_user_groups. It does not mention exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description adds '(read-only)' which duplicates that. No additional behavioral details are provided (e.g., error handling, data format). With annotations present, the description meets minimal requirements but adds no extra value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 8 words, highly concise and front-loaded. However, it could include slightly more detail without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read operation with one parameter and an output schema available (context indicates 'Has output schema: true'), the description covers the basic purpose and input. However, it lacks information about edge cases or return behavior, making it adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, yet the description only says 'by avatarId' without explaining the parameter format, source, or constraints. It fails to compensate for the lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get', resource 'VRCX avatar memo', and method 'by avatarId'. It distinguishes from sibling tools like vrcx_memos_user_get and vrcx_memos_world_get by specifying 'avatar'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. It does not mention related memo tools or scenarios for selecting this over others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true. The description repeats 'read-only' but adds no additional behavioral context (e.g., no mention of rate limits, auth, or side effects). Acceptable baseline given annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with no wasted words. However, it could include more info without becoming verbose, so not a perfect 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has output schema and 4 params with 0% schema coverage. Description does not cover undocumented params or provide usage context beyond purpose, leaving gaps for agent to infer.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but description only mentions avatarId indirectly. It does not explain fields, compact, or maxArrayLength, failing to compensate for missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the verb (Get), resource (avatar profile), key parameter (avatarId), and indicates read-only behavior. This distinguishes it from sibling tools like vrchat_user_profile or vrchat_world_profile.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 (e.g., vrchat_user_profile). No specification of when not to use or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior3/5
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.
Conciseness4/5
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.
Completeness2/5
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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description includes "(read-only)" which aligns with the annotation readOnlyHint=true. It adds that search is by name or shortCode, but no further behavioral traits (e.g., rate limits, result ordering, exact vs. partial matching) are disclosed. With annotations covering the safety profile, this is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states purpose and constrains search criteria. It is very concise, but could include brief usage guidance without becoming verbose. The structure is effective for minimal information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 4 parameters, a required query, and an output schema, the description covers only the basic search functionality. It lacks details on search behavior (fuzzy vs. exact, case sensitivity), pagination mechanics, and how results relate to the output schema. The output schema may exist but the description does not leverage it for completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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 explains the query parameter implicitly (search by name or shortCode), but provides no meaning for maxItems, maxPages, or pageSize. These parameters relate to pagination and result limits, but the description ignores them, leaving agents to infer from names alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Search) and the resource (groups) with specific search criteria (by name or shortCode). It also notes the tool is read-only, distinguishing it from mutation tools. Sibling tools like vrchat_group_profile and vrchat_group_members have different purposes, so this tool is well-defined.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. Sibling tools like vrchat_group_profile (for a known group) or vrchat_group_events_list (for events) exist, but the description doesn't advise when to choose this search tool over them. No exclusion criteria or use cases are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation 'readOnlyHint: true' already signals safety. The description adds 'read-only' (redundant) and 'recent' implying temporal filtering, but no other behavioral traits (pagination, auth requirements) are disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and front-loaded, but it is efficient for a simple list operation. However, it omits parameter details, which could be added without sacrificing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description lacks details on parameter usage and any behavioral context. For a 6-parameter tool with no schema coverage, this is insufficient for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description mentions nothing about the 6 parameters (type, after, maxItems, etc.). The description fails to add any meaning beyond the schema's property names and types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (list), resource (notifications), and a qualifier (recent), with 'read-only' indicating no side effects. Among siblings, no other notification list tool exists, so it is well-distinguished.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide explicit guidance on when to use this tool versus alternatives, but there are no other notification list tools among siblings, so usage context is implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines3/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters2/5
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.
Purpose4/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters1/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters2/5
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.
Purpose4/5
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.
Usage Guidelines3/5
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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only indicate readOnlyHint=false, so the description carries the transparency burden. It adds the behavioral note 'Status is preserved automatically,' which is helpful. However, it omits other important traits like whether the update is a partial or full replacement, permission requirements, or side effects like overwriting unmentioned fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence under 20 words, front-loading the action and key fields. It's not over-detailed but remains clear. Could benefit from structured bullets or more context for completeness, but it achieves high efficiency for its length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 6 optional parameters and an output schema (not shown). The description lists the updatable fields and mentions automatic status preservation, but lacks critical context like whether the tool does a partial update (implied by optional params), typical response format, or error conditions. For a mutation tool, this is adequate but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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 lists the field names but provides no additional meaning—no syntax, constraints, examples, or default behaviors. For example, 'booping' is ambiguous (maps to isBoopingEnabled), and no explanation of what the boolean means. This is insufficient for an agent to understand parameter usage without prior domain knowledge.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool's purpose: updating profile fields. It lists the specific fields (bio, bioLinks, pronouns, userIcon, booping, content filters), making the action unambiguous. No sibling tool duplicates this function, so differentiation is effortless.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives, such as vrchat_status_set for status-specific changes. The description lacks 'when not to use' or 'prefer alternative' instructions, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters1/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters1/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true. The description adds value by noting the tool is 'cache-backed' (data may be stale) and limits output to 'id + name only', which supplements the read-only nature. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys the essential purpose and constraints with no wasted words. It is appropriately sized for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although an output schema exists (documenting return values), the description fails to provide guidance on the 5 parameters, usage context, or how caching affects behavior. For a tool with multiple parameters, this lack of parameter semantics and usage guidelines leaves the agent under-informed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention any of the 5 parameters (offset, userId, maxPages, pageSize, username). Consequently, the description adds no meaning beyond the schema, which is insufficient given the low coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List'), the resource ('a user's groups'), and constraints ('id + name only, cache-backed'). It distinguishes this tool from sibling group tools like vrchat_groups_search and vrchat_group_profile.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage via 'cache-backed' suggesting lightweight retrieval, but provides no explicit guidance on when to use this tool vs alternatives like vrchat_groups_search or vrchat_group_members. No when-not-to-use or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and readOnlyHint=false, and the description confirms destructive actions (delete roles, remove assignments). However, it adds no new behavioral context such as permission requirements, side effects, or limitations 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that succinctly captures the full scope of actions. It is front-loaded, has no filler, and covers both role definition management and member role assignment.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (11 parameters, 5 actions), the description along with the rich schema and output schema provides enough context for an agent to understand what the tool handles and how parameters connect to actions. Minor gap: no guidance on when to choose specific actions, but this is partly addressed by the enum descriptions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema coverage is 91%, so the schema carries the burden of parameter semantics. The description does not add parameter-level detail, but the schema descriptions are thorough, including distinctions like roleId versus groupRoleId and dependency notes.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the resource (group roles) and multiple distinct verbs (assign, remove, create, update, delete). It differentiates from sibling tools like vrchat_group_roles by explicitly covering role definition CRUD and member role assignment/removal.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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, nor are any exclusions or prerequisites mentioned. The description only states what the tool does, not when it should be chosen.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Read-only behavior matches annotation. Adds identifier options but no further behavioral details (e.g., error handling, permissions). With annotation present, description provides minimal extra value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single short sentence, front-loaded. Concise but lacks detail on parameters, earning a minor deduction due to incompleteness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite output schema and annotation, description fails to contextualize 3 of 5 parameters. Incomplete for a tool with multiple optional parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, description only hints at two parameters (worldId, name) out of five. Does not explain fields, compact, or maxArrayLength, leaving gaps for effective use.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it gets a world profile by worldId or name. The verb 'Get' and resource 'world profile' are specific, distinguishing it from search or list siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage when you have worldId or name. No explicit when-not or alternatives, but the context is clear for this simple retrieval tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true. The description adds the behavioral detail 'Derived from VRCX gamelog OnPlayerLeft entries', which provides useful context. However, it does not disclose any additional traits such as rate limits or data freshness.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only two sentences, front-loaded with the core purpose, and contains no filler. Every part is relevant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and the presence of an output schema (not shown), the description covers the source and read-only nature. However, missing parameter details and usage guidelines make it less complete for optimal agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description does not mention the parameters (limit, daysBack) at all. The agent must infer their meaning from names alone, which is insufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
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 'recent instance sessions', and adds 'read-only' and the source 'VRCX gamelog OnPlayerLeft entries'. It effectively distinguishes this tool from siblings like vrcx_gamelog_world_visits_recent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context (read-only, derived from gamelog) but does not explicitly state when to use this tool versus alternatives, nor does it offer 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.
Behavior4/5
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.
Conciseness4/5
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.
Completeness3/5
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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description implies a read-only lookup, consistent with the readOnlyHint annotation. It does not add behavioral details beyond what annotations already provide, such as error handling or performance characteristics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, concise sentence front-loads the tool's purpose with no unnecessary words. Every part of the description earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no nested objects, output schema present), the description is fully sufficient for an agent to understand and invoke the tool correctly. No gaps are apparent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema fully documents the single parameter. The description merely restates the parameter's purpose ('VRChat OpenAPI operationId') without adding new meaning, meeting the baseline expectation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the verb 'Look up' and the resource 'exact OpenAPI params and request body schema for a VRChat operationId', making the tool's purpose unambiguous. It is distinct from sibling tools that perform other VRChat operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 to inspect an operationId versus directly calling the operation. No exclusions or context are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only provide readOnlyHint=false, so the description carries the burden. It adds that the tool writes, requires status or color, and defaults to current user. However, it fails to disclose what happens when userId is provided (set someone else's status?) or any authorization needs. The description is decent but incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the core action ('Set your status + description (write)') and then adds constraints. It is efficient but could be slightly more structured (e.g., separating parameter explanations). Minimal waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters, no required fields, and an output schema, the description covers the primary purpose and key constraints. However, it misses explanations for userId and description parameters, and does not clarify return value (partially mitigated by output schema). Overall adequate but with notable gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain parameters. It mentions 'status' and 'color' with enum values (though only color values are listed explicitly) and describes their relationship. It also mentions 'description' in the text. However, userId is completely unexplained, and the roles of each parameter beyond the constraint are vague. Two out of four parameters lack adequate semantic guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Set' and the resource 'your status + description', explicitly marking it as a write operation. It further specifies constraints (requires status or color, agreement if both provided) and defaults to current user, distinguishing it from the related read tool vrchat_status_get.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for writing status, especially given the sibling read tool (vrchat_status_get). It outlines constraints like requiring status or color and agreement, providing enough context for decision-making. However, it does not explicitly state when to avoid using this tool or mention alternative tools beyond the implicit contrast with get.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint: false), the description adds only that it calls write operations. It fails to disclose behavioral traits like side effects, authentication requirements, rate limits, or error behavior. For a generic wrapper that performs mutations, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with front-loaded purpose and immediate referral to companion tools. No unnecessary words; every part earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (5 parameters, nested objects, output schema present), the description minimally covers core functionality and directs to discovery tools. However, it omits safety/behavioral context, making it adequate but not complete for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but descriptions like 'OpenAPI request body' or 'OpenAPI params' are generic. The description adds no additional meaning, only pointing to other tools for discovery. Baseline 3 is appropriate given complete but low-quality schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it calls POST/PUT/PATCH operations by operationId, distinguishing it from sibling tools like vrchat_read (GET) and vrchat_delete (DELETE). The verb 'call' indicates execution, and the resource is specified as 'available generated VRChat operation'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells users to use vrchat_operations and vrchat_operation_details to discover parameters and body, providing clear context for when to use this tool. It does not explicitly exclude other tools, but sibling names (vrchat_read, vrchat_delete) imply the read/delete alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explicitly says 'read-only,' which aligns with the annotation. It adds context that the data comes from the local VRCX gamelog, but does not disclose other behavioral traits like what happens if the gamelog is unavailable or the effect of parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the core purpose, and every sentence is necessary. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, the description covers the essential functionality and uses. It has an output schema so return values need not be described. However, missing parameter details slightly reduces completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has two parameters (limit and daysBack) with 0% description coverage, and the description does not mention either parameter or explain their semantics. The description fails to add value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists recent world visits from the VRCX gamelog, specifying the verb (List) and resource (world visits) and indicating it is read-only. It distinguishes from sibling tools like 'vrcx_instances_recent' by explicitly mentioning the gamelog source.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description says it reflects local activity history, which implies it’s for checking your own recent visits. However, it does not explicitly say when to use this vs. alternatives or provide any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses automatic resolution of current instance, adding value beyond annotations. However, misses side effects (e.g., notification to user, failure if not in an instance) and 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two efficient sentences with no redundancy. Key information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers the core action and prerequisite but omits preconditions like being in an instance or user being a friend. Does not differentiate from similar sibling 'vrchat_invite_user'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The userId parameter is adequately described via context, but messageSlot (an optional integer) is not mentioned at all, leaving its purpose unclear despite schema coverage being 0%.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (invite) and the target (a user to your current instance). It distinguishes from siblings by highlighting automatic location resolution, which is unique among invite-like tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides a clear prerequisite: if only a display name is known, use vrchat_friends_search first. Lacks explicit exclusions or alternative tools for different scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description's additional behavioral context is minimal. It correctly indicates a listing operation without contradiction, but does not disclose any further traits like pagination or response details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no extraneous words. It efficiently conveys the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity, the description adequately covers its purpose. An output schema exists (though not shown), so return value details are not required. Could potentially mention that the tool provides a list of operation IDs with availability flags, but it's still sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with all parameters described in the input schema. The description adds no extra meaning beyond the schema; it's a generic overview. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists VRChat OpenAPI operationIds and generated-tool availability, distinguishing it from sibling tools that perform specific read/write/delete actions. It uses a specific verb ('List') and resource ('operationIds and generated-tool availability').
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for discovering available operations but provides no explicit guidance on when to use this tool versus alternatives, nor when not to use it. No exclusions or context are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description reinforces this by stating 'read-only'. It also adds value by detailing the specific data included (up/down state, graph values, incidents, maintenance), providing behavioral context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the key purpose, and includes all essential elements without any redundancy or unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has three optional parameters and an output schema, the description covers the purpose and key data types but lacks explanation of the parameters. This leaves an agent uncertain about how to use 'maxItems' and 'recentHours' effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has three parameters with 0% coverage in description. The description mentions graph values which hints at the 'includeGraphs' parameter, but it does not explain 'maxItems' or 'recentHours'. 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides a compact status-page overview, listing specific data points like up/down state, graph values, incidents, and maintenance. It distinguishes itself from sibling tools such as 'vrchat_status_get' and 'vrchat_auth_status' by focusing on a comprehensive yet compact overview.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions it is read-only and provides a compact overview, but it does not explicitly state when to use this tool versus alternatives like 'vrchat_status_get' or 'vrchat_auth_status'. No usage scenarios or exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
An annotation already provides readOnlyHint=true, and the description adds useful context beyond that: the data source (VRCX logs) and the specific fields returned. It does not contradict annotations. Minor improvement could include behavior when user is not found or freshness of logs, but current info is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently conveys purpose, data source, and output fields. No extraneous words; it is well-structured and front-loaded with the critical verb and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with optional parameters and an output schema, the description covers core purpose and output fields but omits parameter usage guidance and edge-case behavior (e.g., user not found). With richer schema context, a more complete description would add value.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning no parameter descriptions within the schema. The tool description does not mention the parameters (userId, displayName) or how to identify the user, leaving the agent to infer from names only. This is a significant gap for a tool with two identification parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the verb 'summarize' and the resource 'your relationship history with a user'. It also identifies the data source (VRCX logs) and explicitly lists the output fields (time spent, join count, last seen), making it distinct from sibling tools that are likely live API calls or raw session data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies that the tool is for local log-based summaries rather than live data, but it does not explicitly state when to use this tool over alternatives like vrcx_user_relationship_sessions or vrchat_friend_details. There is no guidance on prerequisites (e.g., needing VRCX logs) 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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true. Description adds that results are 'from VRCX logs' and 'limited by default', which gives extra context about data source and default behavior but lacks details on pagination or default limit value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with clear front-loading of purpose and immediate usage guidance. No redundant or irrelevant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, read-only nature, data source, and default limit behavior. Lacks clarification on how to specify the target user (userId vs displayName) and ordering of results. Existence of output schema reduces need to explain return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so description must compensate. Only mentions 'limited by default' hinting at limit parameter, but doesn't explain userId or displayName beyond their names. Parameter names are somewhat intuitive, but the description adds minimal meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'list recent shared instance sessions with a user from VRCX logs', which is a specific verb+resource. Differentiates from siblings by specifying 'deep history' and 'read-only', contrasting with related tools like vrcx_user_relationship_summary.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use this for deep history', implying it's for detailed logs rather than summaries. Does not mention exclusions or alternative tools, but the context of siblings provides implicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description adds that it's a GET operation. No additional behavioral details (e.g., rate limits, caching) are provided, but the read-only nature is clear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core purpose. No fluff, every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's generic nature and the existence of an output schema, the description is adequate. It explains the basic mechanism (calling generated GET ops) and points to discovery tools, but could elaborate on the generated aspect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already explains parameters. The description does not add significant semantic value beyond the meta-guidance about parameter discovery via sibling tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool calls a VRChat GET operation by operationId, distinguishing it from write/delete operations. The verb 'call' and resource 'GET operation' are specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description directs the agent to use vrchat_operations and vrchat_operation_details for parameter discovery, providing explicit guidance. However, it does not explicitly mention when not to use this tool or compare to sibling read tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true. Description redundantly says 'read-only' but adds no new behavioral context beyond that.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no wasted words. Front-loaded with action and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Zero parameters, output schema present, and read-only annotation make this complete. No missing information for an agent to invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters to describe; schema coverage is trivial. The description mentions return content (status+description), which adds value over schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states verb 'Get' and resource 'your current status + description'. Distinguishes from sibling 'vrchat_status_set' by read-only nature.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not guidance, but name and description imply usage for reading status. Alternatives like 'vrchat_status_set' are obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explicitly includes 'read-only', consistent with the readOnlyHint annotation. It also adds behavioral context by specifying what is retrieved (profile, status, location). With annotations covering the safety profile, the description adds value 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently captures the tool's core purpose and key parameters. No extraneous information, perfectly front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the existence of an output schema (not detailed), the description need not explain return values. It covers two of three parameters and the overall action. The missing explanation for 'includeOffline' is a minor gap, but overall the description is fairly complete for a simple detail retrieval tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 explains the purpose of 'name' and 'userId' (identifying the friend). However, there is no mention of 'includeOffline' boolean, leaving its purpose ambiguous. The description adds partial value but not complete for all parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'a friend's profile, status, and location details'. It distinguishes from sibling tools like vrchat_friends_list (list all) and vrchat_friends_search (search), as it targets a specific friend. The read-only qualifier adds clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains that the tool can be used 'by display name or userId', indicating two modes of identification. While it does not explicitly state when to use vs alternatives or when not to use, the purpose is clear enough for typical use cases. A score of 4 reflects a clear context with no exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true. The description adds that groups can be included as a paged list, which is useful behavioral context beyond the annotation. No contradiction and no missing safety info.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: first states purpose, second gives usage guidance. No wasted words, front-loaded with the core action. Perfectly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool complexity (8 optional params, output schema present), the description covers the primary use cases (view presets, custom fields, group pagination). Minor parameters like 'compact' are omitted, but the overall picture is clear. Acceptable completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 explains the 'view' enum, 'fields' array, and group pagination parameters. However, 'compact' and 'maxArrayLength' are not mentioned, leaving a gap. Overall, it adds moderate value over the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Get your profile (read-only)', which is a specific verb+resource. It distinguishes from sibling 'vrchat_user_profile' (another user's profile) and 'vrchat_profile_update' (write). The mention of view presets further clarifies functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context (use view presets, override fields, include groups) but does not explicitly state when not to use this tool or name alternatives. The name and context imply it is for own profile, leaving minimal ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With annotations only providing readOnlyHint=false, the description carries the burden of behavioral disclosure. It adds key quirks: users can be usr_ ids or exact display names, and bare instanceIds are rejected because VRChat needs the worldId. This goes beyond the schema and annotations, though it does not cover auth, rate limits, or error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences cover purpose, user formats, and destination requirements. Each sentence earns its place, and the most critical rejection rule is highlighted. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 12 parameters with nested objects and an output schema. The description covers the core invite flow and key constraints, but leaves several parameters untranslated. It doesn't mention prerequisites (e.g., whether you must be in the instance) or error handling. The output schema mitigates return-value gaps, but the overall context for advanced use is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
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 explain the core parameter relationships: 'here=true', 'location', 'worldId+instanceId', 'user/users', and 'self'. The note about instanceId rejection is valuable. However, advanced parameters (retry, dryRun, continueOnError, message, overwriteMessageSlot) remain unexplained, leaving gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Invite yourself or one/many users to an instance.' It clearly distinguishes this general invite tool from siblings like vrchat_invite_self or vrchat_invite_user by covering both self and multiple users. It also adds details about user identification and destination formats, removing ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use: for inviting self or multiple users to an instance. It explains destination options and the rejected bare instanceId, but does not explicitly name alternatives or state 'use this instead of X'. The sibling names imply separate self/user tools, but the description could be more explicit about trade-offs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes well beyond the minimal readOnlyHint: false annotation. It discloses that the tool replaces the whole post, reads the most recent 300 posts to recover omitted fields, cannot preserve roleIds/imageId for older posts, and reports mergedFromExisting: false in that case. It also explains that notifications are only sent when sendNotification is true. This is rich, non-obvious behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three dense sentences, each earning its place: update semantics, recovery mechanism with edge case, and notification behavior. It is front-loaded with the purpose and contains no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tool's key behavioral complexity: partial updates, old-post fallback, and notification control, while referencing an output field (mergedFromExisting). It does not discuss error cases or permissions, but given the output schema exists and the annotations provide safety info, it is sufficiently complete for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already covers all 9 parameters with 100% description coverage, so baseline is 3. The description adds cross-parameter meaning: omitted fields keep current values, roleIds: [] clears restrictions, and the 300-post window affects which fields can be preserved. This goes beyond the individual schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
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+resource that clearly distinguishes this from sibling tools like create/delete. It also specifies the update semantics (omitted fields keep current values), making the tool's purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the tool name and the verb 'Update,' and the description gives clear context for the operation. However, it does not explicitly contrast with alternatives like vrchat_group_post_create/delete or state when not to use this tool, so the guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true. The description adds value by specifying it operates on the local machine and reports specific fields, reinforcing the read-only nature without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no redundancy, front-loaded with the main verb and expected outputs. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With zero parameters and an output schema present, the description sufficiently covers what the tool does and what it reports. No missing context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so schema coverage is 100%. The description effectively conveys the tool's action without needing parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool detects VRCX locally and reports specific database information (path, active user, version). It is distinct from all sibling tools, which are either VRchat API calls or unrelated to local DB status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
While no explicit when/when-not guidance is given, the uniqueness among siblings makes its usage context clear. Lacks explicit alternatives or exclusions, but the singular purpose minimizes ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![vrchat-mcp MCP server](https://glama.ai/mcp/servers/BASIC-BIT/vrchat-mcp/badges/card.svg)](https://glama.ai/mcp/servers/BASIC-BIT/vrchat-mcp)

Score Badge

Copy to your README.md:

[![vrchat-mcp MCP server](https://glama.ai/mcp/servers/BASIC-BIT/vrchat-mcp/badges/score.svg)](https://glama.ai/mcp/servers/BASIC-BIT/vrchat-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/BASIC-BIT/vrchat-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server