Skip to main content
Glama

mdr_ask

Resolve ambiguity mid-review by asking questions attached to specific file text; get inline answers to guide your edits.

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 are provided, so the description fully discloses behavior: returns reply text when user answers, partial replies on review finish, empty if session ends otherwise. It also explains disk persistence and pending limitation.

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 detailed but slightly long at 6 sentences. It front-loads the main purpose but could tighten some phrasing.

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 interactive nature and no output schema, the description fully covers return behavior, pending constraints, and integration with siblings for a complete picture.

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?

Schema coverage is 50%, but the description adds context by explaining the purpose of questions and anchors. However, contextAfter/contextBefore parameters lack full explanation in both schema and description.

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 clearly states the tool asks the user questions anchored to specific text in a file within an active review session. It distinguishes itself from siblings by mentioning inline markers and referencing mdr_review for replies.

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

Usage Guidelines4/5

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

The description explicitly says when to use ('when a comment is unclear, or when you hit a planning fork') and provides guidance on pending constraints ('post a reply via mdr_review then retry'). It does not explicitly state when not to use, but the context is clear.

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