Provides tools for interacting with Git repositories on Azure DevOps/TFS, including listing repositories, branches, commits, and managing pull requests.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@TFS MCP Server list my assigned work items"
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.
An MCP server (Node.js) that bridges Claude Code with an on-premise Azure DevOps Server / TFS
collection (set your own collection URL via TFS_ORG_URL).
Auth: Personal Access Token (PAT).
In TFS: top-right avatar → Security / Personal Access Tokens → New Token. Grant scopes: Work Items (Read & Write) and Code (Read & Write).
Related MCP server: ADO MCP Server
Variable | Required | Description |
| yes | Collection URL, e.g. |
| yes | The personal access token |
| no | Default project name (so you don't pass it every call) |
| no | REST API version (default |
| no |
|
claude mcp add tfs \
--env TFS_ORG_URL=https://your-tfs-server/YourCollection \
--env TFS_PAT=<your-pat> \
--env TFS_PROJECT=<your-default-project> \
--env TFS_IGNORE_SSL=true \
-- node /absolute/path/to/tfs-mcp-server/src/index.jsOr add to .mcp.json / settings manually (see mcp.example.json).
General
tfs_list_projects
Work Items
tfs_query_work_items — run a WIQL query
tfs_get_work_item
tfs_create_work_item
tfs_update_work_item
tfs_add_work_item_comment
Git / Pull Requests
tfs_list_repos
tfs_list_branches
tfs_list_commits
tfs_list_pull_requests
tfs_get_pull_request
tfs_create_pull_request
Add a comment to a work item.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| text | Yes | ||
| project | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description only states the action 'Add a comment' without disclosing any behavioral traits such as idempotency, permission requirements, side effects, or success/failure behavior. With no annotations provided, the description carries the full burden of transparency but fails to address these aspects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at six words, but it sacrifices necessary detail. While brevity is valued, the omission of parameter explanations and usage context makes it too sparse for a tool with three parameters and no schema descriptions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has three parameters, no schema descriptions, no output schema, and no annotations, the description is insufficient. It does not explain required inputs, return values, or constraints, leaving the agent without enough context to use the tool reliably.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, and the tool description does not explain any of the three parameters (id, text, project). Without any semantic context, the agent must infer parameter meaning solely from names, which is insufficient for proper invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Add' and the resource 'a comment to a work item,' which precisely identifies the tool's function. It is distinct from sibling tools like tfs_query_work_items or tfs_create_work_item, which deal with different operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, nor does it mention prerequisites or exclusions. For instance, it does not specify that the work item must exist or that this tool is for adding new comments rather than editing existing ones.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a pull request from a source branch to a target branch.
| Name | Required | Description | Default |
|---|---|---|---|
| title | Yes | ||
| project | No | ||
| description | No | ||
| repositoryId | Yes | ||
| sourceBranch | Yes | Source branch name without refs/heads/ | |
| targetBranch | Yes | Target branch name without refs/heads/ |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must carry the burden. It does not disclose behavioral traits like whether notifications are sent, approval flows, or draft creation, omitting key behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, very concise but omits essential information, making it under-specified for the complexity of the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 6 parameters (4 required), no output schema, and low schema coverage, the description is incomplete; it fails to cover required fields, return values, or error conditions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is low (33%), and the description adds no parameter details beyond the schema. Critical parameters like repositoryId, title, and description lack explanation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (create), the resource (pull request), and the relationship (from source to target), which distinguishes it from sibling tools like tfs_list_pull_requests.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, nor any prerequisites such as requiring branches to exist or permissions, leaving the agent without clear usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a work item. Pass the type (e.g. Bug, Task, User Story) and a map of field reference names to values.
| Name | Required | Description | Default |
|---|---|---|---|
| type | Yes | Work item type, e.g. 'Bug', 'Task', 'User Story' | |
| title | Yes | ||
| fields | No | Additional fields, keyed by reference name e.g. {"System.AssignedTo":"user@x.com","System.Description":"..."} | |
| project | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states 'Create' implying mutation but lacks details on required permissions, error handling, or what happens with invalid fields. Since no annotations are provided, the description carries the full burden, which it does not fulfill adequately.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences, front-loading the core verb and resource. No unnecessary words; every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 4 parameters (2 required), a nested object, no output schema, and no annotations, the description is too minimal. It does not explain the return value, mandatory title param, or process behavior, leaving significant gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50% (type and fields have descriptions). The description adds examples for 'type' and explains 'fields' as a map of reference names to values, but it omits 'title' (required) and 'project', failing to compensate fully for gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create a work item' and mentions the type parameter with examples (Bug, Task, User Story), which distinguishes it from sibling tools like query, update, or get. However, it does not explicitly mention the required 'title' parameter, slightly reducing clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like tfs_update_work_item or tfs_query_work_items. The description does not mention prerequisites, restrictions, or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get details of a single pull request.
| Name | Required | Description | Default |
|---|---|---|---|
| project | No | ||
| repositoryId | Yes | ||
| pullRequestId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description fails to disclose any behavioral traits (e.g., read-only, authentication needs, rate limits). Agent has no safety cues.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, no fluff. Front-loaded with purpose. Could include parameter structure but remains efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 3 parameters and no output schema, the description is severely lacking. Does not explain return details or parameter usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet description adds zero parameter meaning. No mention of parameter roles, formats, or constraints beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Get details of a single pull request,' specifying verb and resource. It distinguishes from sibling tools like list or create.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool or alternatives. Sibling tools exist but no context provided for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a single work item with all its fields by ID.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states 'Get' which implies read-only, but does not disclose any additional behavioral traits such as permissions required, rate limits, or whether it retrieves related data. Adequate for a simple read operation but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no unnecessary words. It efficiently conveys the action and scope.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema, no annotations), the description is minimally adequate. It lacks details about the return format or any edge cases, but for a straightforward get-by-ID operation, it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% (no description in schema properties). The description adds meaning by specifying 'by ID' for the id parameter, but does not elaborate on what the ID represents (e.g., Work Item ID). With low coverage, the description compensates minimally; baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Get' and identifies the resource as 'a single work item with all its fields by ID'. This clearly distinguishes it from sibling tools like tfs_query_work_items (which lists multiple items) and tfs_create_work_item (which creates).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when fetching a single work item by ID, but provides no explicit guidance on when not to use it or mention of alternatives. It is clear but lacks exclusion criteria or context about when to prefer siblings like tfs_query_work_items.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List branches of a Git repository.
| Name | Required | Description | Default |
|---|---|---|---|
| project | No | ||
| repositoryId | Yes | Repository id or name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states 'list branches' without mentioning any constraints (e.g., authentication, pagination, or scope) that an agent would need to consider.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, but it is too sparse to add value. While efficient, it does not justify its brevity with meaningful detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a list tool with no output schema, the description should indicate what is returned (e.g., branch names) and any pagination behavior. It lacks this context, making it incomplete for an agent to anticipate the output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50% (repositoryId has a brief description, project has none). The tool description adds no parameter information beyond what the schema provides, failing to compensate for the low coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List branches of a Git repository' clearly states the action (list) and the resource (branches of a Git repository), which is distinct from sibling tools like tfs_list_repos (list repositories) and tfs_list_commits (list commits).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, nor are there any prerequisites or when-not-to-use instructions. The description offers no usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List recent commits for a Git repository, optionally filtered by branch.
| Name | Required | Description | Default |
|---|---|---|---|
| top | No | ||
| branch | No | Branch name (without refs/heads/) | |
| project | No | ||
| repositoryId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral traits. It only states 'list recent commits' implying a read operation, but fails to disclose authentication needs, destructive potential, pagination, rate limits, or ordering. This leaves significant gaps for an agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no redundancy. However, it is too brief for the tool's complexity, missing crucial details. Conciseness is valued, but here it sacrifices completeness for brevity, earning a 4.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters, no output schema, and no annotations, the description is insufficient. It does not explain what 'recent' means, default behavior, required parameters, or return format. The tool is more complex than the description acknowledges.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is only 25% (one parameter, 'branch', documented). The description adds no parameter details beyond what is in the schema, failing to explain 'top', 'project', or 'repositoryId'. With low coverage, the description should compensate but does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'list', the resource 'commits', and the scope 'for a Git repository' with an optional branch filter. It distinguishes from sibling tools like tfs_list_repos and tfs_list_branches by explicitly mentioning commits.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as tfs_list_branches or tfs_list_repos. There is no mention of prerequisites, exclusions, or use cases, leaving the agent without context for appropriate invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all team projects in the TFS collection.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. However, the tool is a simple listing operation; description accurately states it lists all projects but provides no details on access requirements, pagination, or performance considerations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with no extraneous information. Efficient and to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Description provides basic purpose but does not describe the output structure (e.g., what fields are returned per project). Given no output schema, agents may benefit from knowing the returned data format. However, the tool is simple and the lack of parameters reduces complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no parameters; the description correctly indicates listing all projects without filters. Schema coverage is 100%, and no additional parameter semantics are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb 'list', resource 'team projects', and scope 'all'. It distinguishes from sibling tools focused on different resources (work items, repos, etc.).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. No when-not-to-use conditions or prerequisites mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List pull requests for a repository.
| Name | Required | Description | Default |
|---|---|---|---|
| top | No | ||
| status | No | ||
| project | No | ||
| repositoryId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It lacks details on default ordering, pagination (though 'top' parameter exists), rate limits, or authorization. It merely states 'list' without any behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise, but it lacks necessary details. It front-loads the core purpose but does not earn its place due to missing information about parameters and behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 4 parameters, no output schema, and no annotations, the description is insufficient. It does not cover parameter semantics, behavioral traits, or usage context, leaving an agent with significant ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description should explain the parameters. It does not mention repositoryId, top, status, or project. For example, 'status' enum is not clarified, and 'top' pagination is not explained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List pull requests for a repository' clearly states the verb (list) and resource (pull requests), and distinguishes it from siblings like tfs_get_pull_request (single PR) and tfs_list_repos (repositories).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. For a list tool, it should mention that it returns all PRs for a repo and that tfs_get_pull_request is for a single PR or tfs_create_pull_request for creating one.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List Git repositories in a project (or the whole collection if no project).
| Name | Required | Description | Default |
|---|---|---|---|
| project | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Only states core behavior; does not disclose safety, authentication needs, or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no waste, front-loaded with verb and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for simple tool with one optional param and no output schema. Lacks details on return format or pagination but sufficient given low complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, description compensates by explaining that the 'project' parameter is optional and defaults to whole collection. Adds meaning beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description specifies verb 'List' and resource 'Git repositories' with clear scope ('in a project or whole collection'). Differentiates from siblings like tfs_list_projects which lists projects instead.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use guidance. Context is clear (listing repos) but no alternatives or exclusions mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run a WIQL query and return matching work items (id + key fields). Provide a full WIQL SELECT statement.
| Name | Required | Description | Default |
|---|---|---|---|
| top | No | Max number of full work items to expand (default 50) | |
| wiql | Yes | WIQL query, e.g. "SELECT [System.Id] FROM WorkItems WHERE [System.WorkItemType]='Bug' AND [System.State]='Active'" | |
| project | No | Project name (defaults to TFS_PROJECT) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden; it mentions output format (id + key fields) but omits pagination, side effects, auth needs, or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two succinct sentences, front-loaded with purpose and a clear usage instruction, with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a query tool with 3 well-described parameters and no output schema; could detail return fields more, but sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, baseline 3; description adds value by specifying that a full WIQL SELECT statement is required, enhancing schema semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the verb 'Run a WIQL query' and the resource 'work items', distinguishing it from sibling tools like tfs_get_work_item (single item) or tfs_list_projects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides a usage hint ('Provide a full WIQL SELECT statement') but lacks explicit guidance on when to use versus alternatives, and no when-not scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update fields on an existing work item by ID.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| fields | Yes | Fields to set, keyed by reference name e.g. {"System.State":"Resolved"} |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It only says 'Update fields' but does not explain whether fields are merged or replaced, what side effects occur (e.g., validation, history, permissions), or what happens on failure. This is minimal transparency 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no redundant words. It is properly front-loaded. However, it could be slightly too terse given the need for more detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, no annotations, and nested object parameters, the description is incomplete. It does not explain return values, error handling, or the effect of updating fields. For a mutation tool, this is insufficient for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50% (only 'fields' has a description). The tool description adds no information about the 'id' parameter or further clarifies 'fields' beyond the schema. The agent must rely on the schema's example, but the description adds no extra semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Update fields'), the resource ('existing work item'), and the identifier ('by ID'). It effectively distinguishes from sibling tools like tfs_create_work_item (creation) and tfs_get_work_item (retrieval).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With sibling tools like tfs_create_work_item and tfs_add_work_item_comment, explicit context or exclusions are missing, leaving the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0tfs_add_work_item_commenttfs_create_pull_requesttfs_create_work_itemtfs_get_pull_requesttfs_get_work_itemtfs_list_branchestfs_list_commitstfs_list_projectstfs_list_pull_requeststfs_list_repostfs_query_work_itemstfs_update_work_itemScored across 12 tools
Each tool targets a distinct resource and action (e.g., query vs. get vs. create work items; list vs. get vs. create pull requests), with no overlapping purposes. The tool descriptions clearly differentiate them.
All tools follow a consistent 'tfs_verb_noun' pattern using snake_case (e.g., tfs_list_projects, tfs_create_work_item). The verbs are simple and align with standard CRUD operations, making the naming predictable.
With 12 tools covering projects, work items, and git repositories, the number is well-scoped for a TFS MCP server. Each tool serves a distinct purpose without unnecessary redundancy or bloat.
The tool set covers core workflows: CRUD for work items (except delete), PR lifecycle (list, get, create), and repository browsing. Minor gaps like work item deletion or branch/repo creation exist, but the surface is largely complete for common tasks.
Persistent memory for Claude Code and Cursor. Stop re-explaining your project every session.
Share context and questions between Claude instances — VS Code, claude.ai web, and mobile.
Build and supervise fleets of agents from Claude Code, Codex or Cursor. Connects over OAuth.
Connect Claude to your Platform7n workspaces — chat, links, and tasks. One-click OAuth.
