Skip to main content
Glama
Sign In
Pinpoint

Pinpoint

by gowtham012
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

Ask the developer about a note

reply_annotation

Ask the developer a question about an annotation instead of resolving it — when the request is ambiguous, or you need a decision before you change code.

Instructions

Ask the developer a question about an annotation instead of resolving it — when the request is ambiguous, or you need a decision before you change code. They read your message on the pin in their browser and answer there; the note then comes back to you as pending with the whole conversation attached (it reaches wait_for_annotation and the Claude Code hook like a new note). Until they answer it is off the pending list. Never use this to report a finished change — that is resolve_annotation.

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": {
      "id": "<id>",
      "message": "<message>"
    },
    "name": "reply_annotation"
  }
}

Input Schema

NameRequiredDescriptionDefault
idYes
messageYesYour question or message, shown to the developer on the pin

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.7.2

TDQS

A4.6/5.0
Behavior5/5

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

With no annotations provided, the description carries the full behavioral burden and does so well. It explains that the message appears on the pin, the developer answers in the browser, the annotation returns as pending with the conversation attached, it reaches wait_for_annotation and the Claude Code hook, and it is off the pending list until answered.

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

Conciseness5/5

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

The description is front-loaded with the core action and immediate usage conditions. The extra lifecycle detail is useful rather than wasteful, and the final sentence cleanly routes the agent to the alternative tool.

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?

The description covers the workflow, state transition, downstream notification path, and alternative tool, which is strong for a two-parameter tool with no annotations or output schema. The remaining gap is that the id parameter's meaning is only implied rather than explicitly stated.

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?

The message parameter is reinforced as the question shown to the developer, and the workflow implies that id refers to the annotation. However, the id parameter has no schema description and the tool description never explicitly defines it, so it does not fully compensate for the 50% schema coverage.

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 states a specific action: asking the developer a question about an annotation instead of resolving it. It explicitly distinguishes this from resolve_annotation, so an agent can select it without opening the sibling schema.

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?

It gives explicit when-to-use conditions: the request is ambiguous, or a decision is needed before changing code. It also gives an explicit when-not: never use this to report a finished change, because that is resolve_annotation.

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

Deploy Server

Other Tools