relia_setupExact, project-specific steps to install Relia in the code open in the editor (Node, Next.js, browser apps, Python): which files to add, the lines to load first, source maps, and how to name signed-in users. The steps include two choices for the founder (screen replays, identifying users).
| Name | Required | Description | Default |
|---|---|---|---|
| project | No | Relia project id or name. Needed when the token covers more than one project. |
Changes observed during successful MCP inspections.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, so the description doesn't need to cover safety. It instead adds genuinely new behavioral context: the output is tailored to the workspace currently open, is framework-specific, and contains two founder decisions (screen replays, user identification) that the agent must surface rather than decide alone. It omits what happens for unsupported frameworks or a stale editor context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with what the tool produces, no filler. The second sentence is slightly run-on and the parenthetical founder choices would read better as a separate short clause, but nothing is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description carries the burden of describing the return value, and it does: files to add, load order, source maps, user naming, plus embedded decisions. The main gap is that it doesn't say how the instructions interact with relia_check_setup or what state the repo must be in first.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one optional parameter, and the schema already explains it at 100% coverage ('needed when the token covers more than one project'). The description's phrase 'code open in the editor' implicitly documents the default behavior when no project is passed, which is a small but real addition — baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific resource and action: project-specific steps to install Relia in the code currently open in the editor, with a framework list (Node, Next.js, browser apps, Python). It is clearly distinguishable from generic siblings, but it never names relia_check_setup — the obvious adjacent tool — so the agent must infer the routing itself.
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 by 'install Relia in the code open in the editor'; there is no explicit when-to-use statement, no mention of pairing with relia_check_setup to verify the result, and no guidance for the case where the user has not yet created a project.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.