Skip to main content
Glama

mdr_ask

Ask inline questions anchored to specific text in a file during a review session and get replies from the reviewer.

Instructions

Ask the user one or more questions anchored to specific text in a file inside an active review session. Each question becomes an inline marker the user sees and can reply to in the md-redline UI. Returns with the reply text as soon as the user has answered every question, or with whatever partial replies exist when they finish the review (Done / Finish review), or empty-handed if the session ends another way. Replies also land in the marker threads on disk, so when this tool returns without reply text you should re-read the file(s) before concluding the user did not answer. Use this when a comment is unclear, or when you hit a planning fork while editing. Prefer asking over guessing when the right answer would meaningfully change your edit.

Only one mdr_ask can be pending per session at a time. If this returns "a previous mdr_ask is still pending", post a reply to the prior question via mdr_review (with a replies: payload targeting that commentId) — that resolves the pending ask in-place — and then retry mdr_ask with your new questions.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
questionsYes
sessionIdYesSession ID from a previous mdr_review call, or the sessionId of an active mdr_request_review handoff. Both work: asking a clarifying question about a comment the user left during their own review is the primary use case.
Behavior5/5

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

No annotations exist, so description fully handles transparency. It discloses blocking behavior (waits for answers), partial reply handling, disk persistence of replies, and the exact recovery procedure for pending ask. No 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/5

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

The description is well-structured with logical flow: purpose, behavior, return conditions, usage guidance, and error handling. Slightly verbose but each sentence adds value.

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

Completeness5/5

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

Given the tool's interactive nature and lack of output schema, the description thoroughly covers all scenarios: normal reply, partial replies, empty-handed returns, pending ask resolution, and disk persistence. Very complete.

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

Parameters4/5

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

The input schema covers 50% of parameters with descriptions; the description adds context for sessionId usage (accepting session IDs from previous calls) and the overall question-asking flow. However, it could elaborate more on optional fields like contextAfter/contextBefore.

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

Purpose5/5

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

The description specifies the exact action: asking questions anchored to text in a file. It includes contextual details about inline markers and returns. The tool's purpose is distinct from siblings like mdr_review (which posts replies) and mdr_request_review (which initiates review).

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

Usage Guidelines5/5

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

Provides explicit when to use ('when a comment is unclear, or when you hit a planning fork while editing') and what to do if a previous ask is pending ('post a reply to the prior question via mdr_review... then retry'). This gives clear decision context.

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

Install Server

Other Tools

Latest Blog Posts

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/dejuknow/md-redline'

If you have feedback or need assistance with the MCP directory API, please join our Discord server