vnyan-mcp
Server Quality Checklist
Latest release: v0.1.0
- Disambiguation5/5
Each tool targets a distinct aspect of VNyan (e.g., parameters, triggers, bones, graphs). Despite some tools having multiple actions (vnyan_pendulum, vnyan_collider), descriptions clearly delineate their purposes, preventing confusion.
Naming Consistency3/5All tools prefix with vnyan_, but naming patterns vary: some are simple nouns (vnyan_avatar, vnyan_status), others use noun_verb (vnyan_settings_get, vnyan_graph_write), and some combine nouns (vnyan_node_schema, vnyan_bridge_graph). This inconsistency can make it harder to predict tool names.
Tool Count4/5With 30 tools, the server covers a broad range of VNyan functionality, from basic parameters to advanced graph manipulation and bridge setup. While some tools could be merged (e.g., separate REST, WebSocket, OSC tools), the count is justified by the platform's complexity.
Completeness4/5The tool set covers nearly all major VNyan features, including avatar state, parameters, triggers, blendshapes, bones, physics (pendulum/collider/stretchbone), props, settings, expressions, gestures, graphs, and external integrations. Minor gaps like audio control or tracking details are absent, but the core surface is solid.
Average 4.2/5 across 30 of 30 tools scored. Lowest: 3.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit in the last 12 weeks
- Last stable release on
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
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.jsonto 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
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It states 'read+write' and live plugin source, but lacks details on atomicity, error handling, or return values. This partial disclosure leaves significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words. The key actions and context are front-loaded. Every sentence contributes value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema is provided, and the description omits what the tool returns (especially for 'get') and error conditions. This is a significant gap for a CRUD tool, making it incomplete for an agent to use confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds no extra meaning beyond the schema; 'get/set/clear' is already in the action enum description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the verb (get/set/clear), resource (VNyan named dictionaries), and distinguishes from sibling tools by mentioning the specific data store used in node graphs and REST API.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use (for dictionary operations) but provides no explicit guidance on when not to use or alternatives among sibling tools. The mention of 'plugin (live, read+write)' gives context but 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?
Although no annotations are provided, the description clearly indicates the tool is read-only ('Read-only inventory') and explains that installing a plugin DLL remains a user action, implying it does not modify the system. This is sufficient behavioral disclosure for a simple list operation. It does not discuss edge cases like no assemblies found, but that is not critical.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, each providing essential information: the action (lists DLLs) and the read-only nature. There is no redundancy or extraneous text. It is appropriately sized for a parameterless tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema, the description partially explains the return value (lists DLLs and metadata), but does not specify the format or structure of the output. It is adequate for a simple inventory tool but could be more complete by mentioning that it returns an array of plugin objects or a list of names. Considering the low complexity, it meets a minimal baseline.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters, and schema description coverage is 100%. The description does not add any parameter semantics because there are none. The baseline score of 3 is appropriate; there is no missing information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists DLLs in the Assemblies directory and reads metadata from IVNyanPluginManifest if present. The verb 'lists' and resource 'DLLs' are specific, and it distinguishes from sibling tools that deal with other VNyan components (e.g., graphs, effects) by explicitly calling it a plugin inventory. However, it does not explicitly contrast with similar listing tools like vnyan_graph_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/5Does 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. It implies it is for viewing installed plugins, but does not mention when not to use it or suggest other tools for related tasks like searching or filtering. There are no usage conditions or prerequisites stated.
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?
With no annotations, the description must disclose behavioral traits. It states read+write capability and live source, but does not detail side effects, rate limits, or error conditions. More context on data freshness or mutation scope would improve 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences efficiently convey purpose, scope, and source without fluff. Front-loaded with the core action, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 5 params, no output schema, and no annotations, the description covers the basic function and source but omits return value format, error handling, and example usage. Adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents all parameters. The description adds context about parameter origin (node graphs) but does not enhance parameter meaning beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: get/set numeric/text parameters and expand bracketed references. It also specifies the source (plugin, live, read+write) and connects to node graph concepts, distinguishing it from siblings like vnyan_avatar or vnyan_trigger.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by referencing node graph parameters, but lacks explicit guidance on when to use this tool versus alternatives or when not to use it. No mention of prerequisites or limitations.
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?
Without annotations, the description carries the full burden. It discloses that overrides take priority over tracking, that values are live, and specifies the source as a plugin. However, it does not detail side effects like persistence or interaction with tracking when overrides are active.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively short (two sentences) and front-loads the essential actions (read, set/clear) and source. It could be slightly more organized but is efficient for its length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 4 parameters and no output schema or annotations, the description covers core functionality but omits details about the difference between setOverride and setMeshOverride, and the exact behavior of clearing vs setting 0. It is adequate but leaves some questions open.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline 3. The description adds context about the value range (0-100) and that setting 0 removes the override, which aligns with schema but does not significantly deepen understanding beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads blendshape values and sets/clears override values, and mentions it uses the same mechanism as the Blendshape node. This distinguishes it from sibling tools focused on other aspects like avatar, parameters, or bones.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides general usage context (live, read+write) but does not explicitly specify when to use this tool over alternatives or when not to use it. The mention of 'same mechanism as the Blendshape node' offers implicit guidance for users familiar with VNyan.
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 no annotations provided, the description carries the full burden. It discloses that list/read are disk reads, always readable; export writes a file; import adds/replaces by name and requires VNyan closed. It also explains the internal structure of expressions (input windows, AND-gating). The guard reference for import adds useful context. Minor omissions: no mention of permissions or side effects beyond file writes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly concise, using two sentences to explain the core concept and then a list-like format for actions. It front-loads the essential idea of an expression mapper entry and avoids redundancy. Every sentence adds unique information, with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 parameters, no output schema, and moderate complexity, the description covers the data model and each action's purpose. However, it lacks details on return values (e.g., what list returns, format of read output) and error conditions. For a tool with no output schema, describing the return structure would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with all parameters described. The description adds significant value beyond the schema: it clarifies that 'name' is the expression name used for read/export, 'path' is a .vnexp file path for import/export, and elaborates on each action's effect (e.g., 'export' writes a standalone .vnexp file, 'import' reads and adds/replaces). This extra context aids correct parameter usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly defines the tool as dealing with 'Expression Mapper entries' and explains the core concept (input blendshape value windows that force outputs). It lists and describes each action (list, read, export, import) with specific behavior. While it does not explicitly differentiate from siblings, the unique resource and actions make the purpose distinct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides usage context for each action: list/read are 'always readable' and read from settings.json, export writes a standalone .vnexp file, import requires VNyan closed and is guarded like vnyan_settings_set. However, it does not specify when to prefer this tool over alternatives (e.g., vnyan_settings_get/set) or when not to use it, limiting 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?
With no annotations provided, the description carries full burden. It reveals that the tool reads from disk, is always readable, and performs specific data transformations (decoding, flagging encrypted values). This goes beyond bare essentials, though it doesn't mention if it's idempotent or has side effects beyond reading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-constructed sentence that conveys all essential information without redundancy. It is front-loaded with the core action and ends with source and readability, making it efficient and scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a single parameter, no output schema, and no annotations, the description covers the main aspects: operation, source, and data processing. It is complete enough for an agent to decide usage, though it could benefit from mentioning the output format (e.g., returns a JSON graph structure) for full completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (one parameter 'slot' fully described). The tool description does not add further meaning to the parameter beyond what the schema already provides (slot numbers mapping to files). Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'reads' and the resource 'VNyan node graph'. It details specific actions like parsing, resolving connections, decoding MessageBoxNode text, and flagging encrypted paths. This distinguishes it from sibling tools like vnyan_graph_write (write) and vnyan_graph_list (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/5Does 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. It notes 'always readable' but lacks context about prerequisites, exclusions, or scenarios where another tool (like vnyan_graph_write or vnyan_bridge_graph) would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description discloses key behaviors: integer truncation for numeric parameters, recommendation to use text for decimals, explicit explanation of 'enqueue' behavior with waitTimeAfterMs, and the limited scope of 'recent'. Does not mention error handling or side effects, but covers main behavioral traits well.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Description is brief but packs essential information. Three sentences cover purpose, source liveness, and scoping. Could be slightly restructured with bullet points, but current format is efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 11 parameters and no output schema, the description explains key usage details like integer truncation and enqueue semantics. Lacks return value explanation and error cases, but overall adequate for a well-schematized tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% coverage with detailed descriptions. The description adds extra meaning: explains integer truncation caveat, recommends text params for precision, and gives usage guidance for 'enqueue' wait time. This goes beyond what the schema alone provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states multiple actions (call, queue, reset, read) on the resource 'VNyan's named Triggers', and adds crucial context that triggers are global across all node graphs. This distinguishes it from sibling tools like vnyan_param or vnyan_api_fire.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. The description mentions that triggers are global and 'recent' is only since plugin load, but does not compare with other tools like vnyan_param (for parameters) or vnyan_api_fire (for direct API calls).
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 no annotations, the description adds value by stating the tool is live, supports read+write, and returns empty results (not errors) when VNyanNet is unconfigured. However, it does not disclose potential side effects of RPC or slot modifications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loading the core capabilities and adding a critical behavioral detail. Every sentence is informative, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 16 parameters and 11 actions, but the description only provides a broad overview. Details about each action (e.g., getSlot vs setSlot) are absent, and the output behavior is not described. The schema covers parameters, but usage completeness is limited.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds no per-parameter information; it only gives a high-level context. The schema already sufficiently documents each parameter's meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool reads connected players, slot transforms, sends RPCs, and reads recent events. It also mentions the source and error behavior. This clearly distinguishes it from sibling tools focused on other VNyan features.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for VNyanNet multiplayer operations but provides no explicit when-to-use or when-not-to-use guidance compared to alternatives. The mention of empty results when unconfigured is helpful but not sufficient for strong differentiation.
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?
No annotations are provided, so the description carries the full transparency burden. It mentions that the same content is published as MCP resources, which is a behavioral alternative, but does not disclose side effects, authentication needs, or rate limits. As a read-only reference tool, the lack of such disclosure is less critical, but the description could add more context about the nature of the content (e.g., 'long-form' implies no mutation).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently conveys the tool's purpose and behavior. It is front-loaded with the main purpose and includes key details like the topic list and the omission behavior. While it could be slightly shorter, it is not verbose and every phrase adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that the tool is a read-only reference with a simple optional parameter and no output schema, the description is fully complete. It tells the user what topics exist, how to list them, and notes the alternative resource access. No additional information is needed for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers the single parameter 'topic' with enum values and a description. The description adds that omitting the parameter lists available topics and that content is also available as resources. With 100% schema description coverage, the description provides marginal additional meaning, earning a baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it provides 'Long-form reference documentation' and enumerates the specific topics (e.g., node-authoring, bone-names). This distinguishes it from action-oriented sibling tools like vnyan_trigger or vnyan_bone. The verb 'read' is implied, and it covers a distinct resource purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It explains that omitting 'topic' lists available topics, providing a clear usage path. However, it does not explicitly contrast with the alternative MCP resource access method (vnyan://guide/<topic>), though that is mentioned. No exclusions or when-not-to-use guidance are given, but the overall usage context is clear.
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?
No annotations are provided, so the description must carry behavioral transparency. It mentions 'always readable' for list and 'plugin, live' for set/toggle, hinting at persistence, but does not clarify side effects, permissions, or error conditions. Adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences concisely cover the tool's purpose and modes. Every sentence adds value, and the description is front-loaded with the main action. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple parameter set and absence of output schema, the description adequately covers the tool's functionality. It explains the two operation modes and parameter requirements. Could mention return format for list, but still complete for most use cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds context that set/toggle require an existing prop and that active defaults to true, complementing the schema. However, it does not significantly enhance beyond the schema's own descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists configured props or sets/toggles visibility by name, with specific distinctions between modes. It references the Toggle Prop node and Twitch redeem, differentiating from sibling tools which cover other VNyan features.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly indicates when to use each action (list vs. set/toggle) but lacks explicit guidance on when not to use alternatives or prerequisites. Context from sibling tools helps, but more direct usage advice would improve the score.
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?
No annotations exist, so description carries full burden. It discloses that the tool accesses a plugin, is live and read+write, and that removal is not safe. However, does not mention return values or idempotency of addCamera.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences. First sentence covers purpose, second adds critical usage warning. No fluff, front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Description covers purpose and a key warning, but lacks return value information (e.g., what list returns, success for add). With no output schema, this gap reduces completeness. Parameter details are well-covered in schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. Description adds minimal value beyond schema, mostly repeating names. The only extra insight is that flag1-4 have unknown meanings. Could clarify ignored params when linkToMainCamera is true, but schema handles that.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists or adds Spout2 cameras, with a specific verb and resource. It distinguishes from sibling tools by explicitly mentioning Spout2 cameras, which none of the other tools cover.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit warning about lack of safe removal and directs users to VNyan's own panel for that action. Also mentions source and read/write nature. Lacks explicit when-to-use vs. alternatives beyond the removal 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It notes the blocking nature and timeout expectation for file dialogs, which is critical. It does not mention potential failure modes or return behavior, but it covers the most important aspect for an interactive UI 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: the first lists the operations, the second provides essential behavioral context and source. Every word serves a purpose with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description could be more specific about return values (e.g., what the theme operation returns). However, for a tool with only three enum actions, it provides enough context to use it effectively, and the blocking behavior is clearly communicated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All three parameters are fully described in the schema (100% coverage). The description adds context about blocking and file path resolution but does not significantly enhance the parameter meaning beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states two distinct operations: reading the active color theme and opening file dialogs to resolve file paths. It uses specific verbs ('read', 'open') and resource nouns ('color theme', 'file dialog'), and the sibling tools are all unrelated, so it is well-differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly warns that the file dialog actions block until the user responds, advising a generous timeout. This is a key usage guideline. While it does not explicitly state when not to use it, the action enum makes the choice clear, and there are no overlapping siblings that require exclusion criteria.
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 no annotations, the description carries the full burden. It discloses the plain-text format, fire-and-forget behavior, and that it requires no plugin and connects to a native port. However, it does not mention error handling or what happens if the command is not matched.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences with no wasted words. It front-loads the action and key details, making it efficient for an AI agent to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description provides sufficient context for a simple fire-and-forget tool with 2 parameters and no output schema. It covers the protocol, behavior, and source. Minor missing details like case sensitivity are not critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and both parameters have schema descriptions. The description adds value by explaining the plain-text frame format and how the command parameter is matched against a WebSocket Command node, which goes beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it sends a plain-text frame to a specific WebSocket endpoint to trigger a matching node. The verb 'Send' and resource 'VNyan WebSocket command' are explicit, and the format details distinguish it from sibling tools like vnyan_api_fire.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions 'Fire-and-forget, no JSON' which implies use for simple commands without expecting a response, but it does not explicitly state when to use this tool versus alternatives like vnyan_api_fire for JSON-based commands. No exclusion criteria 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?
No annotations are provided, so the description carries full burden. It discloses that the source is a plugin, live, and read-only, which is clear behavioral context for a read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the core purpose, and includes a clarifying source note. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, no-output-schema tool that simply returns a boolean, the description completely covers the tool's behavior and source, making it fully comprehensible.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, and schema coverage is trivially 100%. The description adds no parameter info, which is acceptable as per baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it reports whether an avatar is currently loaded, which is a specific verb+resource. It distinguishes from sibling tools by clarifying 'Source: plugin (live, read-only)'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage as a status check but provides no explicit guidance on when to use or not, nor any alternatives. It is minimal but sufficient for such a 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 no annotations, the description carries full burden. It discloses live plugin behavior, immediate effect, frame-by-frame reapplying, and that diskList is always readable. It does not mention potential side effects or permissions needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two dense sentences with no wasted words. Each clause adds essential information about actions, behavior, and usage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 6 parameters, no output schema, and no annotations, the description explains actions and parameter constraints well but lacks details on return format for 'get' and 'diskList', leaving the agent uncertain about expected outputs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds value by specifying which parameters are for 'set' only and providing typical default values (e.g., 0.19 for handSize). This goes beyond the schema's basic type and description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads or sets the current avatar's head/torso/hand collider size and offset, with three specific actions (get, set, diskList). It distinguishes itself from sibling tools by focusing solely on collider manipulation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context: 'get'/'set' are live and immediate, 'diskList' lists override files, and advises comparing against 'get' to check saved override match. However, it does not explicitly state when not to use this tool or mention alternatives among siblings.
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 no annotations, the description properly discloses network behavior (UDP, localhost:28569), address selection logic based on value type, and the fire-and-forget nature. It lacks details on error handling or rate limits, but these are minor for such a 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core action, no extraneous information. Every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no output schema, two parameters), the description covers all essential aspects: what it does, how it communicates, and the behavior for different value types.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, providing baseline 3. Description adds value by explaining how the OSC address is chosen based on the value's JS type ('/VNyan/Param/Float' or '/VNyan/Param/String'), which is not apparent from the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sends a UDP OSC message to set a VNyan parameter, specifying the protocol, target, and mechanism. This distinguishes it from sibling tools that use graph nodes or plugins.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Implied usage: 'fire-and-forget, no graph node needed' and 'source: native port, no plugin required' indicate when to use. However, it does not explicitly list alternatives or when not to use this tool, leaving some ambiguity among siblings like vnyan_param.
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?
With no annotations provided, the description fully discloses behavioral traits: it is fire-and-forget with no return value, payload values must be strings (binds to Dictionary<string,string>), and it uses a specific localhost address. This provides the agent with complete understanding of the tool's behavior and constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, each adding essential information: the mechanism (POST to REST API), the purpose (trigger API Message node), and constraints (fire-and-forget, string payloads). No unnecessary words; every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately covers the tool's behavior, constraints, and address. It lacks information about error handling or potential failures, but for a fire-and-forget tool with no return value, the provided context is sufficient for an agent to use it effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds valuable meaning beyond the schema: it explains that the action parameter must match an API Message node's configured Action, and that payload values are strings that bind to Dictionary<string,string>. This enhances the agent's understanding of parameter usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool POSTs an action and payload to VNyan's REST API to trigger an API Message node. The verb 'POSTs' and the resource 'VNyan's built-in REST API' are specific, and the description distinguishes it from sibling tools by mentioning 'native port, no plugin required' and the fire-and-forget 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the tool's function and that it is native (no plugin required), implying it should be used for triggering API Message nodes. However, it does not explicitly state when to use this tool versus alternatives like vnyan_trigger or vnyan_dict, nor does it provide exclusions or conditions for use.
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?
Despite no annotations, the description transparently discloses that reading a bone after overriding shows the pre-override value, and it mentions the source (plugin, live, read+write). This adds significant behavioral context beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences plus a note; front-loaded with the main purpose. Could be slightly more structured by separating read and write operations, but overall concise and informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, so description should clarify return values for 'get' action (e.g., returns position/rotation). It mentions reading position/rotation but doesn't specify format. Also doesn't describe response for set/clear. Adequate for a simple tool but missing some return details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all 5 parameters. The description adds extra context: Euler degrees, bone name format, and a reference to vnyan_guide for full list. It goes beyond the schema by explaining the override behavior related to set/clear actions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the tool reads bone position/rotation or sets/clears rotation overrides using HumanBodyBones names. It distinguishes from sibling tools like vnyan_blendshape or vnyan_param by focusing on bone operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Describes when to read vs set/clear and explains a behavioral nuance (reading shows pre-override value). However, it does not explicitly compare to sibling tools or state when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses key behavioral traits: no getter capability, MCP only tracks sent values, and the effect toggling behavior. It could mention error handling but is largely transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with three sentences that front-load the core purpose and quickly cover requirements and limitations. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers prerequisite, behavior, and parameter context adequately for a 3-parameter tool with no output schema. Missing error handling, but overall complete for typical usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so description adds value beyond schema by explaining the toggling behavior of the toggle parameter and the default values, though it does not elaborate on all parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool drives a post-processing effect (bloom/vignette) via a bridge graph's TriggerNode, providing specific examples and distinguishing it from siblings like vnyan_bridge_graph (install action) and vnyan_trigger (general trigger).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states the prerequisite (bridge graph install) and the limitation that the tool does not read back applied state. However, it does not explicitly mention when not to use it or alternative tools for other effects.
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?
With no annotations provided, the description fully discloses the tool's behavior: it is read-only, reads from disk, and cannot set/fire gestures. This covers the key behavioral traits an AI agent needs to know.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loading the core purpose and then adding behavioral context. Every sentence earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description explains what the list contains (gestures with per-finger curl thresholds), which is sufficiently complete for a read-only listing tool. It could be slightly more detailed about the output format, but it is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so parameter semantics are irrelevant. The description adds no parameter information, but baseline for 0 params is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Lists' and the resource 'configured hand gestures', specifying the data they contain (per-finger curl thresholds). This distinguishes it from sibling tools like vnyan_settings_get or vnyan_expression, which deal with different 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies that this tool is for reading only ('read-only') and that gestures cannot be set programmatically, but it does not explicitly state when to use this tool over alternatives or provide exclusion criteria. Usage context is implied but not 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?
No annotations provided, but description discloses source (disk) and behavior (always readable). It does not mention rate limits or auth, but for a read-only list, this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with action, no wasted words. Perfectly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description could elaborate on return format, but it covers purpose and source adequately for a simple list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters (0 params), so baseline 4. Description adds no parameter info, which is acceptable given no parameters to document.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb 'Lists' and resource 'node-graph tabs', specifying the file pattern and returned fields (name, active flag, node count). This distinguishes it from sibling tools like vnyan_graph_read.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
States 'Source: disk, always readable', implying no special permissions needed. While it doesn't explicitly compare to siblings, it provides sufficient context for a simple list operation.
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 no annotations, the description fully discloses what it reports (health, RPC methods, directory, version) and sources, adding relevant behavioral details without contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Packed with information but front-loaded and well-structured; slightly long but every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and no output schema, the description fully covers the tool's behavior and return values, making it complete for an information-only status check.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so baseline 4 applies; the description adds context about the output, which compensates for absence of schema details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it checks VNyanMcp bridge reachability and reports health, which distinguishes it from sibling tools that perform actions like setting parameters or triggering gestures.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly notes this is 'the one place to confirm what this server actually resolved on your machine,' giving clear context for diagnostic use, though it doesn't list alternatives for similar checks.
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?
Without annotations, the description carries the full burden. It explains that 'list' is always readable and 'add' is write-only. It clarifies that all numeric parameters are multipliers or local-space offsets, not absolute world positions. It also notes that omitted fields use defaults (listed in schema). However, it does not mention behavior on duplicate names or error handling, which would add further transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively concise given the 30 parameters, using one sentence per operation and one for general parameter behavior. It front-loads the action choices. However, it repeats some information that is already in the schema (default values), which could be trimmed. Still, it remains efficient and to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 30 parameters and no output schema, the description covers the parameter semantics and action differentiation well, but it lacks information about return values (e.g., what 'list' returns) and error conditions. It does not describe the result of a successful 'add' or potential failures, leaving some gaps for an agent to fully use the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema coverage, the baseline is 3. The description adds value by explaining that all clamp/scale/move/offset params are relative (multipliers/local offsets) and that omitted fields use the defaults listed in the schema. This provides context beyond the raw parameter descriptions in the input schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool manages stretch bones with two distinct actions: 'list' (reads from disk) and 'add' (creates at runtime). It differentiates between these operations and implicitly distinguishes from sibling tools by focusing specifically on stretch bones, a concept not covered by other tools in the list (e.g., vnyan_bone, vnyan_avatar).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly explains when to use each action: 'list' for the persisted set (disk, always readable) and 'add' for runtime creation (no live read-back). It also warns that there is no live read-back for 'add', guiding the agent to use 'list' for persisted state. This provides clear context and avoids misuse.
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?
With no annotations, the description fully discloses behaviors: graph wiring, trigger name collision handling, export vs direct slot write (with VNyan closed requirement), backup behavior, and global trigger scope. Every important behavioral trait is covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dense paragraph that efficiently conveys core concepts. While not broken into sections, it front-loads purpose and flows logically. Every sentence contributes value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 2 parameters and no output schema, the description covers all key aspects: actions, collisions, install modes, and constraints. Minor missing detail on return format, but overall complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, providing baseline 3. The description adds meaningful context: explains the effect of each action (preview lists actions, install writes) and the slot parameter (advanced/fallback, requires VNyan closed, backs up).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it's for making post-processing effects and lights controllable via a bridge graph, with specific actions like preview and install. It distinguishes from sibling tools like vnyan_trigger and vnyan_effect by explaining the graph construction role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use preview (check collisions) vs install (write graph), and notes different install modes. It does not explicitly compare to all siblings but provides sufficient context for usage decisions.
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 fully compensates for lack of annotations by disclosing the tool's derivation (decompiling Assembly-CSharp), the meaning of 'possiblyIncomplete: true', and that it requires no VNyan connection (offline). It sets appropriate expectations for data quality and operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is moderately concise, using three sentences to convey all necessary information. It is front-loaded with the main purpose and efficiently packs details about derivation, limitations, and offline operation. Slightly verbose but not wasteful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has only one optional parameter, no output schema, and no annotations, the description is remarkably complete. It covers what it returns, its source, potential incompleteness, and operational mode (offline). No gaps remain for an agent to safely use this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter, but the description adds significant meaning: it explains the format expected for 'type' (e.g., 'CallTriggerNode'), the effect of omitting it, and what the output contains (socket layout, value keys). This goes beyond the schema's minimal description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states it looks up a node type's socket layout or lists all types when omitted, using specific verbs and resource details. It distinguishes itself from sibling tools which focus on different VNyan aspects (avatar, param, etc.), making the purpose clear 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to include the 'type' parameter (to see a specific node) versus omit it (to list all types). It does not explicitly state when not to use this tool or provide alternatives, but the context from sibling tools implies it is the sole tool for node schema information.
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?
With no annotations, the description fully bears the burden. It discloses: reads from disk, always readable, secrets redacted, and excluded categories. No contradictions or missing behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences. The first sentence states the action and scope, the second adds key behavioral details (source, availability, redaction, exclusions). No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with one param and no output schema, the description covers source, availability, redaction, and exclusions. It lacks explicit description of the output format, but the purpose is clear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with an enum and description for 'area'. The description adds value by listing the enum values in context and explaining what is not included (other categories), which supplements the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Reads settings.json' and lists the specific areas covered (tracking/output/graphics/audio/connections/misc). It also distinguishes from sibling tools by listing what is excluded (props, colliders, etc.) and noting their dedicated 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context about the data source (disk) and availability (always readable regardless of VNyan running). It implicitly guides usage by excluding other areas, but does not explicitly state when to use this tool versus alternatives beyond referencing other 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?
With no annotations, the description fully discloses behavior: requires closed VNyan due to triple-write, backs up file, refuses unknown and dedicated-tool keys, and notes flat namespace. Does not detail return value or error handling, but that is acceptable given no output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a well-structured paragraph with front-loaded action, followed by warnings, prerequisites, and usage tips. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple parameter structure and no output schema, the description provides sufficient context for an agent to use correctly: what it does, prerequisites, safety measures, and how to find keys. Minor omission: doesn't explicitly state that the file is modified on disk, but 'source: disk' implies that.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers all parameter semantics with 100% coverage. Description adds context about the key namespace (flat, ~279 keys) and provides guidance on how to discover valid keys, which goes beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'patches' and resource 'settings.json', and distinguishes from sibling tools by noting that certain keys have dedicated tools (props, colliders, etc.). Also clearly differentiates from vnyan_settings_get which is for reading.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states the prerequisite that VNyan must be closed, warns about silent overwrite, and recommends calling vnyan_settings_get first to see current values or vnyan_guide for key index. Also tells which keys to avoid (dedicated-tool keys) and directs to those tools instead.
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?
With no annotations provided, the description fully carries the transparency burden. It discloses that runtime chains are separate, don't persist, and are handled via numeric handles. It explains parameter clamps, defaults, and subtle behaviors like elasticity affecting floppiness vs snap-back, and notes VNyan's lack of per-bone distribution curves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-organized paragraph that front-loads the action summary and clearly separates the two chain groups. Every sentence adds value, and there is no unnecessary repetition or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite lacking an output schema, the description covers all essential aspects: it explains what the tool does, the two distinct use cases, parameter behaviors, and offers a pointer to a guide for deeper physics. For a complex tool with 8 parameters, this is comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although schema coverage is 100% (baseline 3), the description adds significant context beyond the schema: defaults, ranges, clamps, per-action applicability (e.g., 'value' behavior differs for setPosition vs setRotation), and detailed physics explanations. This greatly enhances understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly distinguishes between the 'list' action for reading UI-configured chains from the other actions that manage runtime-only chains. It specifies the verb 'reads' for list and 'manage' for others, and explicitly states they are not the same. This differentiation helps the agent select the correct action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use 'list' versus the other actions by separating them into two groups: disk-based vs runtime. It also references a guide for further physics explanation. However, it does not explicitly mention when not to use the tool or name alternative tools among siblings.
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?
No annotations provided, so description carries full burden. Discloses destructive nature of slot write, backup behavior, requirements (VNyan closed), runtime type safety, terminal nature of most action nodes, and limitations on file-path literals.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear sections, bold for key constraints, and front-loaded purpose. Some redundancy with schema descriptions but overall efficient for complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers all aspects: workflows, prerequisites, side effects, type safety, limitations, and references to related tools. No output schema but description explains return behavior (file or slot write). Complete for a complex authoring tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, baseline 3. Description adds critical context: explains two modes via slot parameter, clarifies id not written to file, value strings encoding, type safety for valueConnections.toIndex, and alternative for file paths.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it builds a node graph from a spec, with two modes (export and slot write). Distinguishes from sibling tools like vnyan_graph_list and vnyan_graph_read by focusing on authoring/writing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use guidance: default export for general use, slot mode for advanced cases requiring VNyan closed. Warns about NodeGraphCount and refers to vnyan_settings_get and vnyan_guide. Differentiates from vnyan_graph_read lag.
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?
Discloses the sunLight bug causing crashes, that the tool is one-way fire-only, and that MCP tracks sent value not actual state. Comprehensive given no 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Efficiently packed with all necessary details, no redundancy, each sentence adds value, well-structured with purpose, special cases, requirements, and limitations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers prerequisites, edge cases (sunLight bug), limitations (no getter), and source. With no output schema or annotations, this description is fully adequate for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but description adds crucial context: toggle and intensity are ignored for sunLight, and explains the fire-only nature of sunLight beyond enum values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it drives ambient light intensity via bridge graph's TriggerNode, lists specific keys (bloom, vignette, ambientLight, sunLight), and distinguishes from sibling tools like vnyan_bridge_graph which installs the graph.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly notes when not to use certain parameters (sunLight ignores intensity/toggle), requires prior install of vnyan_bridge_graph, and explains that no getter exists, so agent knows not to expect readback.
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:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/seth-rah/vnyan-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server