tfs-mcp-server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| TFS_PAT | Yes | Personal access token (sent as Basic auth) | |
| TFS_BASE_URL | Yes | Collection URL, e.g. https://tfs.corp.local/tfs/DefaultCollection | |
| TFS_API_VERSION | No | API version, default 6.0 | 6.0 |
| TFS_INSECURE_TLS | No | Set to true to accept self-signed certificates | |
| TFS_DEFAULT_PROJECT | No | Project used when a call omits project | |
| TFS_BATCH_CONCURRENCY | No | Parallelism for fan-out batch tools (default 5) | 5 |
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
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| get_work_itemA | Get a single work item: metadata (type, title, state, assignee, area/iteration, tags, dates), rich-text content (description, repro steps, acceptance criteria), relations (parent/children/links) and optionally its comments. |
| get_work_itemsA | Read many work items in one call (uses the workitemsbatch API, chunked by 200 ids). Missing ids are reported in |
| get_work_item_commentsA | List discussion comments of a work item (paged). Returns comment ids needed for update_work_item_comment. |
| update_work_itemA | Update a work item's metadata via JSON Patch. |
| update_work_itemsA | Apply the same update (state + assignedTo, optionally more fields/comment) to many work items. Uses the wit/$batch endpoint (one HTTP request per 200 items) and falls back to parallel single PATCH calls if $batch is unavailable. Per-item results are reported. |
| add_work_item_commentA | Add a discussion comment to a work item. Plain text is converted to HTML; HTML is accepted as-is. Returns the new comment id. |
| add_comment_to_work_itemsA | Add one comment text to many work items. The comments API has no batch endpoint, so requests are fanned out with bounded concurrency; per-item results (comment ids / errors) are reported. |
| update_work_item_commentA | Replace the text of an existing comment (use get_work_item_comments to find comment ids). |
| get_queryA | Read a saved work item query by GUID or path (e.g. 'Shared Queries/Team/Open Bugs'): name, path, type, columns and WIQL text. For folders, children are listed (depth 1). |
| run_queryA | Execute a saved query by GUID or path and return the matching work items. Optionally append a custom WIQL filter ( |
| run_wiqlA | Execute an arbitrary WIQL query string as-is, e.g. "SELECT [System.Id] FROM WorkItems WHERE [System.TeamProject] = @project AND [System.State] = 'Active'". Returns the matching work items (flat) or the link tree (tree/oneHop queries). |
| list_repositoriesA | List Git repositories in a project (or in the whole collection when no project is given), with default branch and URLs. |
| get_file_contentA | Read a file from a Git repository at a given branch/commit/tag (default: the repo's default branch). Text files are returned inline; binaries as base64. If the file does not exist, the error explains whether the repository, the branch or the directory is missing and lists the parent directory's entries. |
| get_files_contentA | Read several files from one repository at the same branch/commit/tag in a single call. Existence and metadata are checked with one itemsbatch request, then contents are fetched in parallel. Missing files are reported per path with the same verbose diagnostics as get_file_content. |
| list_directoryA | List files and folders under a directory path in a Git repository (one level or full recursion) with metadata: object ids, content type, and the latest commit that touched each entry. |
| get_current_identityA | Identify the user behind the configured PAT: id, display name, account (DOMAIN\user or e-mail), descriptor, plus a ready-to-use |
| search_identitiesA | Find users or groups by display name, account name or e-mail to obtain a valid |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 17 tools
Most tools target clearly distinct resources and actions, such as fetching a single work item vs. many, or reading file content vs. listing a directory. The main area of potential confusion is between the singular/plural comment tools, especially add_work_item_comment and add_comment_to_work_items, though their descriptions clarify the difference.
Tool names mostly follow a consistent snake_case verb_noun pattern: list_, get_, update_, add_, run_, and search_. Minor deviations exist, notably add_comment_to_work_items vs. add_work_item_comment and get_current_identity, but overall the naming is predictable and readable.
17 tools is slightly above the ideal range but reasonable for a server covering both work item management and Git repository file access. Each tool serves a distinct purpose, and the count reflects the breadth of the domain without feeling bloated.
The work item surface is strong for reading and updating, including bulk operations and comments, but there is no create_work_item or delete_work_item, which is a notable lifecycle gap. The Git side is also read-only, covering file/directory access but no branch, commit, or repository management operations.