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

With no annotations, the description carries the full behavioral burden. It usefully discloses that it pulls the installed Rojo CLI's version from GitHub and patches it, plus the resulting auto-connect behavior and the git/rojo prerequisites. It still omits important build side effects, such as where the plugin is written and whether it overwrites existing files.

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

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

The description is front-loaded with the action and resource, then adds the relevant build source, patch behavior, and prerequisites. Every clause contributes useful context, and there is no filler or repetition.

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

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

For a zero-parameter build tool with an output schema, the description covers the source of the build, the resulting plugin behavior, and the machine prerequisites. The main remaining gap is the relationship to rojo_install_plugin and the exact filesystem effect of building.

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

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

The tool has zero parameters, so there is no parameter semantics to compensate for. The baseline score of 4 applies because the empty schema is self-explanatory and the description does not need to document inputs.

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

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

The description states a specific verb and resource: build the auto-connect Rojo plugin. It explains the build composition (installed Rojo CLI version from GitHub plus a patch), which is more specific than the name alone. It does not explicitly distinguish this from the sibling rojo_install_plugin, so it falls short of a 5.

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

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

The description implies usage context by naming prerequisites (git and rojo on the machine) and describing the auto-connect behavior. However, it gives no explicit guidance on when to choose this over rojo_install_plugin or other siblings, and no when-not conditions.

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

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

With no annotations, the description carries the burden well: it discloses that the old plugin is backed up to %LOCALAPPDATA%\Roblox\PluginBackups, that Rojo settings (Auto Reconnect, Confirmation Behavior 'Unlisted PlaceId') are mutated, and that changes take effect only on next Studio open. It omits whether the install itself fails or behaves differently when Studio is running, and never mentions the configure_settings opt-out.

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

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

Purpose is front-loaded and every clause (backup path, settings mutation, Studio timing, servePlaceIds prerequisite) adds actionable information. It is dense but not padded; a small structural loosening comes from folding the settings behavior into the same run-on sentence as the install.

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

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

An output schema exists, so return values need not be explained, and the description covers side effects, prerequisites, and timing. The remaining gap is the interaction between Studio being open/closed and failure modes for the install itself.

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

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

The single parameter configure_settings has 0% schema coverage, so the description must compensate. The settings behavior it controls is described, but the description presents it as unconditional ('it also turns on...') rather than tying it to the parameter or explaining how to skip it, leaving the opt-out semantics to inference.

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

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

Names a specific verb and resource ('Install the plugin rojo_build_plugin ... as Studio's Rojo plugin') and implicitly separates itself from the build step it depends on. An agent can tell this is the install/deploy step rather than the build or start step without opening the schema.

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

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

Gives strong operational context: settings are only configured 'with Studio closed', Studio picks the plugin up on next open, and auto-connect requires 'servePlaceIds' in the project. It does not explicitly state the precondition to run rojo_build_plugin first or what to do if Studio is currently open, so it stops short of explicit when/when-not routing.

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

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

With no annotations, the description carries the load and does well: it discloses that the process is detached and survives session end, that repeat calls are idempotent per project+port, and that a port collision with another project errors. It doesn't say where the serve log/output surfaces or how the process is later terminated (rojo_stop), which are the remaining operational unknowns.

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

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

Front-loaded with the action and its persistence property, then the parameter hint, then the conflict semantics — no filler. The trailing clause 'fails if another project is' is slightly elliptical but still readable.

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

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

An output schema exists, so return values need not be explained, and the description covers persistence, idempotency, and conflict behavior for a two-parameter tool. It stops short of the lifecycle story (how to check or stop the served process), which is the only meaningful gap.

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

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

Schema description coverage is 0%, so the description must compensate. It defines `project` well (folder or .project.json path), but `port` is only alluded to via the conflict rule — its default (34872) and what it means to choose a non-default port are left to the bare schema.

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

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

States a specific verb and resource ('Serve a Rojo project (`rojo serve`)') and scopes it to a background process that outlives the session. That scope plus the port-conflict rule distinguishes it cleanly from rojo_stop and rojo_status.

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

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

Clear about the situation it is for and spells out the no-op case (already served on that port) and the failure case (a different project on the port). It doesn't explicitly point at rojo_status or rojo_stop as the follow-up/diagnostic alternatives, so routing to siblings is left implicit.

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

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

No annotations are supplied, so the description carries the full burden. The interrogative form clearly signals a non-mutating probe, and the parenthetical discloses a behavioral trait beyond the schema - it also reports whether rojo_start was the origin of the running server. However, it doesn't state what happens when no server is found (error vs. a negative result), which matters for a status probe.

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

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

A single compact sentence with the subject scoping ('for this project') and port condition up front, and no filler. The parenthetical clause is slightly awkward but carries real information about the rojo_start provenance.

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

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

For a two-parameter, low-complexity status probe with an output schema present (so return shape need not be explained), the description covers the resource, the port condition, the project scope, and the provenance question. The only missing piece is the failure-mode behavior when the server is not answering.

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

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

Schema description coverage is 0%, so the description must compensate. It does reference both parameters semantically - 'for this project' and 'answering on the port' - tying each to its role in the check. But it adds no format or value guidance (e.g. project path vs. name, the 34872 default, whether a non-default port is common), so it only partially fills the documentation gap.

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

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

The description identifies the resource (a Rojo server for this project) and the check being performed (answering on the port, and whether rojo_start started it), which distinguishes it from rojo_start and rojo_stop. It is phrased as a question rather than a verb-led statement (e.g. 'Check server status'), which slightly softens the action, but the intent is unambiguous.

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

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

Usage is only implied: an agent can infer this is the pre-flight/probe call to run before rojo_start, after rojo_stop, or when a build fails. There is no explicit 'use this when...' clause and no stated exclusions or alternatives, though the reference to rojo_start hints at the lifecycle relationship.

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

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

No annotations are provided, so the description carries the full behavioral burden. It does disclose an important safety constraint — it will only stop a server this process started — but says nothing about behavior when no server exists on the port, whether the stop is graceful, or whether other clients are affected.

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

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

One compact sentence with the resource and the scoping constraint front-loaded. The trailing parenthetical is slightly awkward but adds a real constraint rather than noise.

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

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

The tool is simple and an output schema exists, so return values need not be explained. However, for a lifecycle-terminating tool with no annotations, the description omits error/no-op behavior and the default-port relationship, leaving modest gaps.

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

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

With a single parameter and 0% schema description coverage, the description supplies the key meaning: the port identifies which started server to stop. It does not mention the default value 34872 or whether the port must match the one passed to rojo_start, but the core semantics are covered.

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

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

States a specific verb and resource ('Stop the Rojo server') and ties it to the port the server was started on, which distinguishes it from rojo_start and rojo_status. It does not explicitly contrast with other siblings like studio_import, but the action is unambiguous.

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

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

Usage is implied by the scoping clause 'rojo_start started on this port', and the parenthetical '(never one it didn't start)' gives one useful exclusion. There is no explicit guidance on what to do if no server is running or how this relates to rojo_status as a check-first step.

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

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

With no annotations to lean on, the description carries the full burden and does it well: it discloses that the call seizes mouse and keyboard for about 15 seconds, that returning only means the importer accepted the file, that the Import Queue completes a few seconds later, and that the caller should verify the model landed before using it.

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

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

Five short sentences with no filler, purpose front-loaded ahead of preconditions and then the async-completion caveat. Every clause carries operational meaning the agent would otherwise get wrong.

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

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

Despite a one-parameter tool, the real complexity is environmental, and the description covers all of it: window count, mode, visibility, input capture, timing, and post-call verification. An output schema exists, yet it still usefully explains what a successful return actually signifies.

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

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

Schema coverage is 0%, so the description must compensate for the single 'path' parameter. It does that partially by implying the value is a model file in one of four formats, but it never states whether the path must be absolute, on the local disk, or relative to some working directory.

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

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

Names a specific verb and resource ('Import a model file') and enumerates the supported formats (FBX, OBJ, GLB, GLTF), plus the exact mechanism used (Studio's 3D Importer via File > Import). That mechanism detail alone separates it from the rojo_* siblings, which belong to a different asset pipeline.

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

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

Gives hard preconditions: exactly one Studio window, Edit mode rather than playtesting, and the window must be visible on screen, plus a spacing rule between consecutive imports. It never explicitly contrasts itself with the rojo tools, so the agent must infer the alternative, which keeps it short of a 5.

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