Pinpoint
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| PINPOINT_HOME | No | Where annotations are stored (default ~/.pinpoint). | |
| PINPOINT_PORT | No | The port the bridge listens on. Default 7331, must be set to the same number in the popup. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
| resources | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| get_pending_annotationsA | Return every pending annotation (comment + element details + screenshot) as a markdown task list. Use this first. |
| list_annotationsB | One-line summary per annotation. Defaults to pending only. |
| get_annotationB | Full details and screenshot for a single annotation by id or number. |
| recheck_annotationA | Ask the developer's browser to find this element again, right now, and report what changed since they marked it — with a fresh crop next to the original one. Call it before editing anything marked a while ago, and whenever an annotation says it may be stale. A verdict of gone or moved means the selector in the annotation should not be trusted as-is. |
| resolve_annotationA | Mark an annotation done after applying the change. Always call this when you have made the change. |
| reply_annotationA | 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. |
| wait_for_annotationA | Block until the developer adds a new annotation in the browser (or timeout). Useful for a live 'watch' loop: wait → apply → resolve → wait. Each new annotation is handed to exactly one waiting agent, so several agents can watch at once without doing the same note twice. |
| clear_annotationsB | Delete all annotations (pending and resolved). |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| pending |
TDQS
Scored across 8 tools
Each tool has a distinct role in the annotation lifecycle, and descriptions explicitly separate risky pairs like reply_annotation vs resolve_annotation (question vs finished change). The only mild overlap is between list_annotations (one-line summary), get_pending_annotations (full details for all pending), and get_annotation (full details for one), which could occasionally be confused, but the descriptions disambiguate well.
All eight tools follow a predictable snake_case verb_noun pattern targeting the 'annotation' resource (reply_annotation, resolve_annotation, recheck_annotation, get_annotation, clear_annotations, etc.). The only minor deviation is singular vs plural (clear_annotations/list_annotations), which is semantically correct rather than inconsistent.
Eight tools is a tight, well-scoped set that maps cleanly onto the annotation workflow (wait, list, get, recheck, reply, resolve, clear). Every tool earns its place with no redundancy.
The full lifecycle is covered: discovering annotations, inspecting details, checking staleness, asking the developer questions, and resolving. Minor gaps exist — no explicit filtering of resolved annotations or bulk-resolve operation — but these are small workarounds given clear_annotations exists.