What can you do with this server?

This server enables AI agents to read and manage Fix My Comments tasks (VS Code comment threads) via the Model Context Protocol, automatically scoped to the current Git repository and branch. * List open tasks (list_open_tasks): Retrieve all open tasks in the current workspace, optionally filtered by file path. * Get task thread (get_task_thread): Fetch a specific task and its full message history in chronological order. * Post agent reply (post_agent_reply): Append an AI-generated reply to a task thread, including agent ID/name, a summary of actions taken, and an optional list of changed files. * Set task status (set_task_status): Mark a task as resolved or requires_review, optionally providing a reason. Additional behaviors: * Zero configuration — automatically scopes to the current Git repo and branch. * Prevents writes to comment threads that have become outdated due to source code line changes.

How do I use fix-my-comments-mcp?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@fix-my-comments-mcp list open tasks in src/main.ts" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

fix-my-comments-mcp

by duraisamy-gokul

Overview Schema Source Related Servers Score Discussions Admin

TypeScript

Local

fix-my-comments-mcp

MCP server for Fix My Comments — exposes local VS Code comment threads to AI agents (Claude Code, Cursor, Windsurf, etc.) through the Model Context Protocol.

The server is intentionally small: it reads and writes the same JSON files as the VS Code extension, under ~/.fixmycomments/<repo>-<hash>/<branch>/, and communicates over stdio.

How it works

Zero config — the server derives storage from process.cwd() and the current Git branch.
Repo + branch scoped — comments are isolated by repository and branch.
Shared with the extension — the VS Code extension and MCP server read/write the same threads.json and messages.json files.
Stale-comment safe — the server checks anchored line hashes against the current workspace file. Outdated threads are hidden by default and write actions are blocked.

Run your agent from inside the repository root. If you start it from another directory, the server will resolve a different storage path.

Related MCP server: tai-mcp-github

Installation

Option A: Global install via npm (recommended)

npm install -g fix-my-comments-mcp

Then add it to Claude Code:

claude mcp add fix-my-comments --scope user -- fix-my-comments

Option B: Local dev via npm link

git clone <this-repo>
cd fix-my-comments-mcp
npm install
npm run build
npm link
claude mcp add fix-my-comments --scope user -- fix-my-comments

Available Tools

Tool	Description
`list_open_threads`	List open, non-outdated threads for the current branch. Optionally filter by file path.
`get_thread`	Get a thread and its messages; use `messageLimit` to fetch only the latest messages.
`get_message`	Get one comment/message with its thread summary and position.
`get_message_context`	Get one message plus N messages before/after it to avoid loading a whole long thread.
`post_agent_reply`	Append an AI reply, optionally tied to a message and optionally posted as a code suggestion.
`set_thread_status`	Resolve or reopen a thread.
`set_task_message_status`	Check or uncheck a task message.
`add_reaction`	Add an emoji reaction to a message.
`remove_reaction`	Remove an agent's emoji reaction from a message.

Token-efficient reads

Agents should prefer the smallest read tool that answers the question:

Use list_open_threads to discover work.
Use get_message when a message id is already known.
Use get_message_context to fetch a small window around one message.
Use get_thread only when the whole thread is needed, or pass messageLimit for the latest messages.

Outdated thread behavior

By default, the server filters out and blocks writes to outdated threads whose anchored line changed.

list_open_threads excludes outdated threads unless includeOutdated=true.
get_thread, get_message, and get_message_context require includeOutdated=true to inspect stale comments.
post_agent_reply, set_task_message_status, add_reaction, and remove_reaction are blocked on outdated threads.

Requirements

Node.js 18+
The Fix My Comments VS Code extension installed and active in the project

Available Tools

4 tools

get_task_threadA

Get a task and its full message thread in chronological order.

ParametersJSON Schema

Name	Required	Description	Default
`taskId`	Yes	The task id.

TDQS

A3.5/5.0

Behavior2/5

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

No annotations are provided, and the description only states the output format ('chronological order') without disclosing side effects, permissions, or other behavioral traits.

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?

Single, front-loaded sentence with zero extraneous words; every part is essential.

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

Completeness3/5

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

For a simple retrieval tool with one parameter and no output schema, the description provides the basic purpose but lacks details on return structure or potential edge cases.

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?

Schema coverage is 100% for the single parameter 'taskId', and the description adds no extra meaning beyond the schema's 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?

Description clearly states verb 'get' and resource 'task and its full message thread', distinguishing it from siblings like list_open_tasks and post_agent_reply.

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

Usage Guidelines3/5

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

Description implies usage for retrieving a task thread but does not explicitly state when to use vs alternatives or provide exclusion criteria.

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

list_open_tasksA

List all open Fix My Comments tasks for the current workspace and branch. Optionally filter by file path.

ParametersJSON Schema

Name	Required	Description	Default
`filePath`	No	Workspace-relative file path to filter by (optional).

TDQS

A3.6/5.0

Behavior3/5

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

Without annotations, the description carries the full burden. It discloses scope (current workspace and branch) and optional filtering but does not mention return format, pagination, or potential behavior like sorting or limits. It is adequate but not comprehensive.

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 two concise sentences with no redundant words. It front-loads the action and scope efficiently.

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

Completeness2/5

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

Given no output schema and a listing tool, the description fails to explain what is returned (e.g., list of task objects, their fields). It also omits details like ordering or pagination, leaving the agent underinformed about the tool's full behavior.

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 single parameter filePath is documented in the schema with a clear description. The description adds 'Optionally filter by file path,' which aligns with the schema. Since schema coverage is 100%, the description adds minimal new value, meeting the baseline.

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 lists all open Fix My Comments tasks for the current workspace and branch, with optional file path filtering. It is a specific verb-resource combination and is distinct from sibling tools like get_task_thread and set_task_status.

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

Usage Guidelines3/5

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

The description implicitly indicates when to use the tool (when listing open tasks) but provides no explicit guidance on when not to use it or what alternatives might be more appropriate. The context is clear but lacks exclusionary criteria.

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

post_agent_replyB

Append a reply to a task thread as an AI agent and record execution metadata.

ParametersJSON Schema

Name	Required	Description
`taskId`	Yes	Task id to reply to.
`content`	Yes	Reply message body.
`agentId`	Yes	Machine identifier for this agent (e.g. claude-code).
`agentName`	Yes	Human-readable agent name.
`summary`	Yes	One-sentence summary of what was done.
`reason`	No	Why this action was taken.
`filesChanged`	No	Workspace-relative paths of files the agent changed.

TDQS

B3.4/5.0

Behavior2/5

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

No annotations are provided, so the description must bear full behavioral disclosure. It mentions 'record execution metadata' but does not explain side effects, authorization, or what metadata is recorded—insufficient for a mutation tool.

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 one sentence, front-loaded with the primary action, and contains no extraneous information.

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

Completeness2/5

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

Despite 7 parameters, no output schema, and no annotations, the description is very brief. It omits details about how the reply integrates, error cases, or what execution metadata implies—leaving gaps for the agent.

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?

Schema descriptions cover all 7 parameters at 100% coverage. The tool description adds no additional meaning beyond what the schema already provides, so baseline 3 is appropriate.

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 it appends a reply to a task thread as an AI agent, with a specific verb and resource. It distinguishes from sibling tools like 'get_task_thread' (read-only) and 'set_task_status' (status update).

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

Usage Guidelines3/5

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

The description implies usage for posting agent replies but does not explicitly specify when to use vs alternatives, nor does it mention conditions or prerequisites.

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

set_task_statusB

Set a task status. Agents may set resolved or requires_review.

ParametersJSON Schema

Name	Required	Description
`taskId`	Yes	Task id.
`status`	Yes	New status.
`reason`	No	Why the status is being changed.

TDQS

B3.1/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full burden. It only states the basic action without disclosing consequences (e.g., notifications, reversibility, permissions required). This is insufficient for a write operation.

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 very concise with just one sentence, containing no wasted words. It is front-loaded with the key action. However, it could benefit from additional structure or details.

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

Completeness2/5

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

Given the absence of annotations and output schema, the description should elaborate on return values, immediate effects, and constraints. It fails to provide a complete picture of the tool's behavior.

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?

Schema description coverage is 100%, so the schema already explains each parameter. The description adds no additional meaning beyond what is already in the input schema, so a baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Set') and the resource ('task status'). It specifies the allowed statuses ('resolved' or 'requires_review'), which helps distinguish from sibling tools that are about reading or posting replies.

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

Usage Guidelines3/5

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

The description mentions that agents may set two specific statuses, implying when to use the tool. However, it does not provide explicit guidance on when not to use it or suggest alternatives among sibling tools.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

4 tool updatesv1.0.0Jun 23, 2026
- First observedget_task_thread
- First observedlist_open_tasks
- First observedpost_agent_reply
- First observedset_task_status

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.7/5.0

Scored 2026-06-23 18:25 across 4 tools

Disambiguation5/5

Each tool addresses a distinct operation: retrieving a thread, listing tasks, posting a reply, and setting status. There is no role overlap or ambiguity.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern in snake_case, making them predictable and easy to understand.

Tool Count5/5

With 4 tools, the server is tightly scoped to its purpose of managing comment review tasks. No tool seems extraneous.

Completeness4/5

The set covers core workflows (list, view, reply, update status). Lacking create/delete tools, but those may be handled externally or implicitly supported.

Maintenance

ActivityStale

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

mcp-serverOAuth
com.niftypm
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
Project Management Communication File Systems
2
OneSchema MCP Server
co.oneschema
MCP server that lets AI assistants use all OneSchema features exposed via the public API.
Data Platforms App Automation
1
AgentMarketplace A
io.github.raditotev
MCP Server for an Agent Task Marketplace
Autonomous Agents Agent Orchestration
221
mcpOAuth
net.todoist
Official Todoist MCP server for AI assistants to manage tasks, projects, and workflows.
App Automation Workplace & Productivity Project Management
2

Related MCP Servers

llm-backlog
Project Management Version Control Developer Tools
waabox
F
license
Not graded
quality
C
maintenance
MCP server for managing a project backlog as Markdown files in Git, enabling AI agents to read, create, and update tasks programmatically.
Updated 7 months ago (2026-02-22 19:51 UTC)
2
-
tai-mcp-github
Version Control Developer Tools Project Management
pxl-research
F
license
A
quality
D
maintenance
A minimal MCP server that exposes a focused set of GitHub PR review tools to AI agents, enabling PR listing, detail retrieval, comment viewing, and thread management.
Updated 5 months ago (2026-04-02 09:46 UTC)
5
-
ai-devtool-mcp-server
Developer Tools Version Control
surajrsawat
F
license
Not graded
quality
B
maintenance
MCP server for AI DevTool workflow, exposing tools and resources for code review, repository chat, and repository operations.
Updated 2 months ago (2026-06-30 16:38 UTC)
1
-
collab-mcp
Agent Orchestration Autonomous Agents Project Management
oxiaom
A
license
Not graded
quality
C
maintenance
Multi-AI collaboration MCP server enabling message passing, code review workflows, shared todo lists, and agent management with authentication and role-based access.
Updated a month ago (2026-08-02 08:53 UTC)
134
MIT