droid-mcp

droid_result

Read-only

Read a session's latest result text or git diff, paged by byte offset so you can fetch large output in manageable chunks and continue with nextOffset.

Instructions

Read a session's latest result text and/or the git diff in its cwd, paged by byte offset (use nextOffset to continue).

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "session": "<session>"
    },
    "name": "droid_result"
  }
}

Input Schema

Name	Required	Description	Default
`offset`	No
`include`	No
`session`	Yes
`maxBytes`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Nov 13, 2026

TDQS

B3.2/5.0

Behavior3/5

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

readOnlyHint=true already covers the safety profile, and the description usefully adds that the output is paged by byte offset and can include text, diff, or both. It does not disclose what happens if the session has no result yet, whether the diff can be absent, or what the returned chunk looks like. Notably it refers to 'nextOffset' as the continuation token, a field that does not appear in the input 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/5

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

A single front-loaded sentence with no filler, stating the core operation before the paging mechanics. It is dense but readable; the only defect is the mismatched nextOffset/offset naming.

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

Completeness3/5

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

For a four-parameter read tool with no output schema, the description covers the essential read-and-page story but omits expected return shape beyond 'text and/or diff', behavior on empty results, and clarification of session identity. Adequate, not complete.

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

Parameters3/5

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

Schema description coverage is 0%, so the description must carry parameter meaning; it explains offset-based paging and that include accepts text and/or diff, which maps to two of four parameters. It leaves 'session' and 'maxBytes' (the byte cap) unaddressed, and its 'nextOffset' reference does not match the 'offset' parameter in the schema.

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

Purpose4/5

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

The description opens with a specific verb ('Read') and names the two resources precisely: a session's latest result text and the git diff in that session's cwd. An agent can distinguish it from droid_wait or droid_find, though it does not explicitly say so.

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

Usage Guidelines2/5

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

It implies usage ('latest result', 'use nextOffset to continue') but never states when to call this versus siblings such as droid_wait or droid_find, nor any prerequisite like a session having completed. The reader has to infer the workflow position.

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

Deploy Server