Skip to main content
Glama

Reply to a record

create_reply

Answer an existing packet by creating a new linked reply, leaving the original untouched. Supports question, clarification, objection, counter-decision, and confirmation types.

Instructions

Use to answer a specific packet — question, clarification, counter-decision, objection, or confirmation — instead of editing it; the reply is written as a new packet linked back to the parent, and the parent is never modified. parentId must match exactly one record in the store, and the reply is written privately whenever the parent is private or seed, or private is set.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
refsNoProject-relative paths to reference without copying; each is recorded as a file source link.
tagsNoLowercase slug tags (a-z, 0-9, hyphen) for later filtering; must be unique.
filesNoProject-relative file paths copied into the reply as artifacts, optionally suffixed with a purpose ('diff.patch:source'). Valid purposes are asset, source, reference, and output, plus common aliases.
titleNoShort title for the reply; defaults to 'Reply to <parent title>'.
toRepoNoOverride the recipient repository; when replying to a received packet this defaults to the parent's origin project.
privateNoWhen true, write the reply into the private inbox instead of the outbox. Default false; replies to private or seed parents are private regardless.
summaryYesThe reply itself — the question, correction, or confirmation being sent back.
toAgentNoOverride the recipient agent; by default the reply inherits the parent packet's recipient.
parentIdYesRecord ID of the packet being replied to; must match exactly one record in the store, private records included.
toPersonNoOverride the recipient person; by default the reply inherits the parent packet's recipient.
actorNameNoName recorded as the author of this write; defaults to the server's configured actor, or 'mcp-client'.
nextStepsNoWhat the recipient should do next; rendered as its own section of the reply.
replyTypeYesWhat kind of response this is; recorded on the reply and used by readers to triage it.
sourceLinksNoContext links to record (kind: file, url, commit, issue, record, command, or repo); file links must resolve inside the project root.
Behavior4/5

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

The description adds meaningful behavioral context beyond the annotations: the parent is never modified, the reply is a new linked packet, and the privacy behavior for private/seed parents or when private is set. With readOnlyHint false, these details help the agent understand the write semantics. No contradiction with annotations.

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 two sentences, front-loaded with the action, and each sentence conveys important information. The second sentence is dense but not wasteful, earning a 4 rather than 5 due to slightly complex structure.

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

Completeness4/5

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

For a tool with 14 parameters and no output schema, the description covers the essential behavioral aspects: what the tool does, the parent link, non-modification of parent, and privacy rules. It could mention what the reply packet contains or the expected result, but the description is sufficiently complete for a write operation.

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 100%, so the baseline is 3. The description adds value by explaining the parentId matching requirement and the private default behavior, which complements the schema's description of the 'private' parameter. This extra context justifies a 4.

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's function: answering a specific packet by writing a new linked reply packet rather than editing the parent. It enumerates the reply types and distinguishes from editing, giving a clear, specific purpose that differentiates it from sibling tools like create_packet.

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?

It provides clear usage context: use this to reply to a packet instead of editing it, with explicit requirements (parentId must match exactly one record) and privacy rules. However, it doesn't explicitly name alternative tools or state when not to use it, though the 'instead of editing' implies the contrast.

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/coldlogicAI/3notch'

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