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

Beyond readOnlyHint/openWorldHint it adds real behavioral context: a signed-in Rivian session is required and an error is returned otherwise, sessions from every vehicle on the account are aggregated, and output is readable text. The read-only restatement mildly duplicates the annotation, but the auth, scope, and return-format disclosures are substantive additions.

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 resource and ordering, then progressively adds row contents, usage routing, scope, and prerequisites. Sentences are dense and every one carries information; no filler.

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

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

With no output schema, the description compensates by enumerating returned fields (date, times, duration, kWh, cost/free, city, network, charger type). Auth requirements and account-wide scope are covered, so an agent has everything needed to invoke it correctly.

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

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

Schema description coverage is 100%, and the single 'limit' parameter is fully documented in the schema (meaning, example, default of 25). The description adds nothing about the parameter, so the 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?

The first sentence gives a specific verb and resource ('List past charging sessions, newest first') and the second enumerates exactly what each row contains. It explicitly distinguishes itself from the sibling tool rivian_get_charging_session, so an agent can route without opening a 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?

It states when to use it ('Use it for completed sessions') and names the exact alternative for the excluded case ('For a charge in progress use rivian_get_charging_session'). Both the selection condition and the sibling routing are explicit.

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

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

Beyond the readOnlyHint annotation it discloses the auth requirement ('requires a signed-in Rivian session and returns an error without one'), the vehicle-selection behavior ('reads the first vehicle on the account'), the output form ('returns readable text'), and confirms no command is sent to the vehicle. This is rich behavioral context an agent could not derive from the annotations alone.

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

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

Front-loaded with the returned fields and free of filler. There is mild redundancy between 'It does not change a schedule' and the closing 'Read-only: sends no command to the vehicle', but each targets a slightly different concern, so the cost is small.

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, no-output-schema read tool, the description covers purpose, fields returned, auth preconditions, error behavior, vehicle scoping, and the sibling alternative. An agent has everything needed to call it correctly.

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

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

The tool takes zero parameters, so per the rubric the baseline is 4. There is nothing parameter-level the description needs to compensate for, and it correctly implies that no arguments are needed.

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 (get charging schedules saved for the vehicle) and enumerates the exact fields returned (start/end time, duration, enabled, amperage, days of week, location). It explicitly distinguishes itself from the sibling rivian_get_charging_session, so an agent can route without opening schemas.

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

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

Gives the use case ('see when the vehicle is set to charge'), an explicit exclusion ('does not change a schedule'), and names the alternative for the adjacent case ('For a charge in progress use rivian_get_charging_session'). Nothing is left to inference.

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

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

Beyond the readOnlyHint/openWorldHint annotations, it discloses an auth prerequisite and the failure mode ('Requires a signed-in Rivian session and returns an error without one'), an account-scoping quirk ('reads the first vehicle on the account'), a graceful degradation path (reports vehicle charging state when no session exists), and the return shape (readable text). These are operationally relevant facts not present in the annotations.

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

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

The first sentence front-loads the core purpose and field inventory; routing guidance and preconditions follow in a logical order. It is dense and slightly list-heavy, and 'Returns readable text' is low-value filler, but no sentence is redundant.

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 return-value burden and does so by enumerating the fields and stating the format is readable text. It also covers auth, account scoping, and the no-live-session case, so an agent has everything needed to call it and interpret results.

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 takes zero parameters, so per the baseline this scores 4. The description's field list describes outputs rather than inputs, which is appropriate here.

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 ('get the charge happening now') and enumerates the exact fields returned (battery level, kW, kWh, current, elapsed/remaining time, cost, charger identity/location). It explicitly differentiates itself from rivian_get_charging_history and rivian_get_charging_schedule by naming them as the tools for finished and planned sessions.

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 explicit routing rules: use this for a live session, rivian_get_charging_history for finished sessions, rivian_get_charging_schedule for planned charging. It also states the fallback behavior when no live session exists, so the agent knows there is no error case to route around.

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

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

Goes well beyond the readOnlyHint/openWorldHint annotations: it discloses the auth prerequisite ('Requires a signed-in Rivian session and returns an error without one'), the implicit scoping behavior ('Reads the first vehicle on the account'), and the return format ('Returns readable text'). These are exactly the traits an agent cannot derive from the structured fields.

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 core purpose and kept to short, scannable sentences with no filler. The closing 'Read-only: sends no command to the vehicle' partially restates the readOnlyHint annotation, a minor redundancy in an otherwise tight definition.

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

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

For a zero-parameter read tool with no output schema, the description covers everything needed: what it returns, the format, the auth requirement, the error behavior, and the vehicle scope. An agent has no remaining questions before invoking it.

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 takes zero parameters, so the baseline is 4. The description correctly explains why no selector exists by noting it reads the first vehicle on the account, which compensates for the absent vehicle-selection parameter.

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 ('List who and what can open and drive the vehicle') and enumerates the concrete items returned: invited drivers, enrolled phone keys, key fobs. It also explicitly differentiates itself from the sibling rivian_get_user_info, so an agent can route correctly without opening either 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 explicit when-to-use ('Use it to audit access to the vehicle'), an explicit boundary ('It does not add or revoke access'), and names the alternative tool for a related need ('For account and vehicle details use rivian_get_user_info'). Nothing about selection is left to inference.

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

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

Beyond the readOnlyHint/openWorldHint annotations, the description discloses the authentication prerequisite ('Requires a signed-in Rivian session and returns an error without one'), the scope limitation ('Reads the first vehicle on the account'), the side-effect profile ('sends no command to the vehicle'), and the return format including the 'up to date' sentinel. This is exactly the context annotations cannot carry.

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 core capability is front-loaded in the first sentence, followed by usage, alternative routing, return format, auth requirement, and read-only confirmation. Every sentence carries distinct information, though the description is on the long side for a no-argument read tool.

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

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

With no output schema, the description still documents what comes back (readable text, 'up to date' when nothing is pending), the auth failure mode, and the single-vehicle scope. An agent has everything needed to call and interpret it.

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 takes zero parameters, so there is no parameter semantics to compensate for; baseline 4 applies. The description correctly does not invent parameter details.

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 names a specific verb+resource (installed software version, update status, available update) and scopes it precisely, noting it reads the first vehicle on the account. It explicitly distinguishes itself from the sibling rivian_get_user_info, which handles the full account/vehicle list.

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

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

'Use it to check whether an update is waiting' states the triggering condition clearly, and 'For the full account and vehicle list use rivian_get_user_info' names the alternative with the condition that selects it. There is no explicit when-not guidance, but the routing is unambiguous.

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

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

Annotations only declare readOnlyHint and openWorldHint; the description adds substantive behavioral context beyond them – a signed-in Rivian session is required and an error is returned without one, no command is sent to the vehicle, and the response is readable text. This is the kind of auth/prerequisite disclosure that must live in prose.

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 purpose and field list, then alternatives, then prerequisites in a logical order. It is a dense four sentences, but each carries distinct information (content, routing, auth, safety) rather than padding.

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 compensates by enumerating what the response contains (owner, per-vehicle fields, software version, update with release-notes link). Auth requirement, error behavior, and read-only status are all covered, leaving no gap for an agent to fill.

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 takes zero parameters, so the baseline is 4 per the rubric; there is nothing for the description to clarify beyond the empty schema. It correctly does not invent or discuss parameters.

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

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

Specific verb ('Get') plus concrete resource (account owner and each vehicle) with an enumerated field list (name, model, VIN, trim, drive system, colors, wheels, build date, software version, update link). This clearly separates it from siblings like rivian_get_vehicle_state and rivian_get_ota_status without needing to open any 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?

Explicitly states when to use it ('identify the vehicle or the account') and routes to alternatives by name with conditions: rivian_get_ota_status for update progress, rivian_get_vehicle_state for live readings. Nothing is left to inference.

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

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

Goes well beyond the readOnlyHint/openWorldHint annotations by disclosing the auth requirement ('Requires a signed-in Rivian session and returns an error without one'), the account-scoping behavior ('Reads the first vehicle on the account'), the unit convention ('Distances follow the unit set in the vehicle'), and the side-effect profile ('sends no command to the vehicle'). These are the operational facts an agent needs before calling.

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-loads the resource and its contents, then moves to routing rules, then prerequisites and safety. Every sentence carries distinct information (contents, alternative routing, units, auth, read-only) with no filler.

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

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

With no output schema, the description compensates by enumerating the returned state categories, and it covers the auth prerequisite, account scoping, unit conventions, and the read-only guarantee. An agent has everything needed to call this correctly and interpret the result.

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

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

Schema description coverage is 100%: the single 'properties' parameter already documents accepted names, the omit/empty-array behavior for a full report, and the failure mode for unknown names. The description adds nothing further about the parameter, so the baseline 3 for fully-documented schemas 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 verb and resource ('Get the live vehicle state as readable text') and enumerates the exact contents returned (battery, doors, windows, tires, location, climate, software versions, security/trailer). It clearly distinguishes itself from the charging and OTA siblings by naming them explicitly.

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

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

Gives an explicit when-to-use rule ('Use it for how the vehicle is right now') and routes three adjacent cases to named alternatives: rivian_get_charging_session for active charge, rivian_get_charging_history for past charges, and rivian_get_ota_status for updates. Nothing is left to inference.

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

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

Annotations only declare write/open-world/non-destructive, but the description adds substantive behavior: it replaces the current session, persists to ~/.rivian-mcp/session.json, leaves sign-in pending until OTP is submitted, and returns either a signed-in message or a code-sent message plus credential errors. This is exactly the context annotations cannot convey.

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 purpose and trigger condition; every sentence carries distinct information (trigger, persistence, OTP flow, returns). It is dense but slightly long, with the return-value sentence arguably recoverable from behavior, so not quite maximal conciseness.

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

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

With no output schema, the description compensates by describing both success and failure return messages and the pending-OTP state. Trigger conditions, credential source, side effects, and follow-up tool are all covered for what is a moderately complex auth operation.

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?

There are zero parameters, and the description explicitly confirms 'Takes no arguments' alongside the fact that credentials come from server configuration (RIVIAN_EMAIL/RIVIAN_PASSWORD) rather than the call. That removes any ambiguity about supplying credentials as 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?

States a specific verb+resource ('Sign in to Rivian') and immediately distinguishes itself from the sibling read tools, which all fetch state rather than establish a session. An agent can tell from the first clause that this is the authentication entry point.

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

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

Explicitly names the conditions for calling ('when no session is saved or after the session expires') and notes that a saved session is restored automatically on launch, so the agent knows when NOT to call. It also routes the OTP follow-up to rivian_submit_otp by name, covering the alternative path.

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

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

Annotations only cover the safety profile (readOnlyHint=false, destructiveHint=false, openWorldHint=true); the description goes further by disclosing a concrete side effect (session persisted to ~/.rivian-mcp/session.json), a configuration dependency (RIVIAN_EMAIL from server config), and both success and rejection return behavior.

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

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

Four short sentences, front-loaded with the action and the sequencing constraint, followed by the side effect and return behavior. No filler and nothing repeated from the schema.

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 must describe returns, and it does ('a message saying you are signed in, or an error if Rivian rejects the code'). Combined with preconditions, auth source, and persistence, an agent has everything needed to call it correctly.

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

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

There is a single parameter with 100% schema description coverage, so the schema already defines format, type, and the no-spaces rule. The description adds only the faintly useful provenance detail that the code arrives by phone or email, which is the baseline-3 case.

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 ('Finish a Rivian sign-in with the verification code') and names the sibling tool it complements (rivian_login), so the agent can distinguish it from the eight other rivian_* tools immediately.

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 an explicit precondition ('Use it only after rivian_login reported that a code was sent') and states the failure path when that precondition is unmet ('it returns an error and asks you to call rivian_login'). That is a full when-to-use / what-happens-otherwise rule.

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