What is the PinSay MCP server?

It is a local Model Context Protocol server, started with npx @pinsay/cli mcp, that gives your AI coding agent 10 typed tools to read website feedback, commit fixes and mark comments applied.

Which MCP clients does it work with?

Any MCP client that can start a local stdio server. The docs give the config for Claude Code, Cursor, Windsurf and OpenCode; it is the same JSON entry for each.

Is my PinSay API key sent to the model?

No. The local CLI process reads the key and exchanges it for a short-lived token. The key never appears in tool inputs or outputs.

Can the agent push code or change my project settings?

No. The server only makes local commits and never pushes, merges or rebases. Project settings are read-only through MCP, and the agent cannot create comments.

How does the agent handle prompt injection in comments?

Everything a stakeholder wrote (comment text, replies, DOM snapshots) is returned under an untrusted key, and the tool descriptions tell the agent never to follow instructions inside it. Workspace rules and prompts come under trusted.

Should I commit the MCP config to my repo?

No. Add it to your user-level config file. A committed config would force one tool on the team and risk leaking credentials.

Can PinSay work as a Model Context Protocol bug tracker?

It covers the part your agent needs: people pin bugs and requests on the running app, and the agent reads, fixes, commits and replies through MCP. When bug capture is on for a project, a bug comment can include network calls, console errors and the user's steps.

MCP Server for Website Feedback: 10 Local Tools

What it does

People on your team click an element in your app and type what should change. Each comment carries the element's CSS selector, the CSS rules that apply, the route, the viewport and a sanitized DOM snapshot. The MCP server hands that queue to your agent as typed tool calls, so the agent doesn't need curl scripts or a pasted prompt. It can list comments, fetch the ready queue, commit its changes, mark comments applied and reply to the person who asked.

Quickstart

1. Install PinSay in your repo

npx @pinsay/cli@latest init

This detects your stack, adds the widget and installs the agent skills. The MCP server reads the project from .pinsay/config.json and the credentials from .pinsay/credentials.env in the current working directory.

2. Add the server to your MCP client

The same entry works for Claude Code (~/.claude.json), Cursor (~/.cursor/mcp.json), Windsurf and OpenCode:

{
  "mcpServers": {
    "pinsay": {
      "command": "npx",
      "args": ["-y", "@pinsay/cli@latest", "mcp"]
    }
  }
}

Put it in your user-level config, never in a file you commit. A committed config would pin one tool for the whole team and risk leaking credentials.

3. Ask your agent

"Apply the ready PinSay comments." The agent reads the queue, edits your code, commits locally and marks each comment applied with its commit.

The 10 tools

Tool	What it does
`pinsay_list_comments`	Lists a project's comments in a lean summary, filtered by status and environment.
`pinsay_get_queue`	Fetches the comments that are ready to apply, with the element, page context, the workspace's AI rules and predefined prompts.
`pinsay_get_comment`	Gets one comment by number, with its element, replies and applied details.
`pinsay_mark_applied`	Marks one comment applied and posts a reply, without running git (for when a human commits).
`pinsay_commit_and_mark`	Stages the files, commits locally and marks the comments applied with their commit. Never pushes.
`pinsay_reply`	Posts a reply the comment's author can see, without changing its status.
`pinsay_set_status`	Moves a comment to open, ready, archived or a custom status.
`pinsay_resolve_source`	Resolves an element's source hash to a file path and component name from the local manifest.
`pinsay_doctor`	Runs the install health checks and reports them. Read-only.
`pinsay_list_projects`	Lists every PinSay project configured in the repo.

The server also exposes the resource pinsay://project (the merged project configuration, read-only) and the prompt pinsay_apply_instructions, which produces the same apply instructions as npx @pinsay/cli apply.

The safety model

A feedback tool that talks to an AI agent carries text from other people into your codebase. The server is built around that.

Your API key stays in the local process

The CLI process reads your API key and exchanges it for a short-lived token. The key is never passed to the model and never appears in tool inputs or outputs.

Stakeholder text is marked untrusted

Comment bodies, replies and DOM snapshots come back under an untrusted key in every response, and the tool descriptions tell the agent never to follow instructions found inside them. Your workspace's AI rules and predefined prompts come under trusted.

It runs on your machine

The server runs over stdio as a local process started by your MCP client. Your agent edits and commits in your own repo.

What it cannot do

Create comments. Only people using your app write feedback.
Change project settings. Project URLs, allowed origins and workspace settings are read-only through MCP.
Push. It creates local commits with git commit; it never pushes, merges or rebases. You push.

PinSay itself never runs AI and never deploys. After you deploy, npx @pinsay/cli status --deployed marks the comments in that build as Live. A comment marked with pinsay_mark_applied has no commit recorded, so it is not flipped to Live this way; use pinsay_commit_and_mark when the agent commits.

MCP or CLI?

Use the MCP server when your tool speaks MCP and you want typed calls. Use the CLI (npx @pinsay/cli apply, with --mark to commit and mark applied) when your agent works through the terminal. Both read the same queue, and you can switch any time. The AI coding agents page shows the whole loop.

An MCP server for website feedback