Pod

Yes, this is on purpose. Pod is built for agents, so the default page is plain HTML.
Human? View the normal website.
Agent? You probably prefer /mcp/autotask/issues.md or /mcp/autotask/issues.json, or Pod over MCP.

Reported issues for Autotask

Pod holds 20 of 27 problems reported by people outside the maintainer team. Issues filed by the project's own owners, members and collaborators are excluded entirely — a maintainer's release checklist is not a warning to a prospective user.

Back to Autotask.

Most discussed

[Bug] Since 2.30.0 no autotask-mcp.mcpb is included in release artifacts

Component

Documentation

What happened?

Readme says: "Download autotask-mcp.mcpb from the latest release" When navigating to the releases page it only contains source zip since the release of 2.30.0, prior releases still included the mcpb file

Steps to reproduce

  1. Navigate to Releases page
  2. Attempt to find a mcpb file

Environment

No response

Read the thread · 2026-08-13 · closed · external user · 2 comments

searchCompanies ignores page parameter — cache pre-warm loops 100× on the same page, blocking all tool calls. LAZY_LOADING env var is dead code.

Two compounding bugs in the company-mapping cache cause every tool call to hang for ~80 seconds on first invocation (and again every 30 minutes when the cache TTL expires):

  1. searchCompanies in src/services/autotask.service.ts drops the page parameter when calling the underlying SDK. Every page in MappingService.refreshCompanyCache's loop re-fetches page 1, so the cache ends up with the same 200 records regardless of tenant size, after burning 100× pagination API calls.
  2. **The `L

Read the thread · 2026-05-14 · closed · external user · 4 comments

serverInfo.version reports hardcoded "1.0.0" instead of actual package version

Summary

The MCP initialize handshake returns serverInfo.version: "1.0.0" regardless of which release of autotask-mcp is actually running. We verified this on a freshly-pulled v2.24.4 Docker image (ghcr.io/wyre-technology/autotask-mcp:v2.24.4):

{
  "result": {
    "protocolVersion": "2024-11-05",
    "serverInfo": {
      "name": "autotask-mcp",
      "version": "1.0.0"
    }
  }
}

Expected

serverInfo.version should reflect the actual server build (e.g. 2.24.4)

Read the thread · 2026-05-12 · closed · outside contributor · 3 comments

[Bug] API Threshold messages

Component

MCP Tool

What happened?

Expected: No errors Actual: I keep getting errors that the app disconnected AND I get email warning that the API Threshold has exceeded.

I am using a dediced API system user for my claude desktop, i am the only one using it, Any ideas on how to reduce this

Steps to reproduce

I in this case i was asking of a project status report including the status detail notes on all open, non internal projects

Environment

No response

Read the thread · 2026-04-22 · closed · external user · 7 comments

[Enhancement] - Feature Request: Service Calls support (for Tickets)

Tool type

Existing Tool Enhancement

What are you adding or changing?

Hey Aaron + Team 👋

First of all — huge thank you for building autotask-mcp. This is genuinely one of the coolest things I've come across in a while, and the effort you've put into it really shows. We've been experimenting with it and it's been a blast.

Feature Request: Service Calls support (for Tickets)

We work heavily with Service Calls in Autotask — it's core to how we schedule and plan work on tickets

Read the thread · 2026-03-22 · closed · external user · 3 comments

Feature Request: Add autotask-mcp to Docker MCP Registry

Feature Request

It would be great if autotask-mcp could be added to the Docker MCP Registry. This would allow users to easily install and run the Autotask MCP server via Docker Desktop's MCP Toolkit, making setup much simpler.

Why?

Read the thread · 2026-02-06 · closed · external user · 4 comments

Works in Claude Chat but not in Claude Cowork – special configuration required?

Description

The autotask-mcp server works correctly when used in Claude Chat, but it does not work in Claude Cowork (I have not tested Code).

Steps to Reproduce

  1. Configure the autotask-mcp MCP server as described in the README.
  2. Use it in Claude Chat — it works as expected.
  3. Try using it in Claude Cowork — it does not function.

Expected Behavior

The MCP server should work in both Claude Chat and Claude Cowork.

Actual Behavior

The server only works in Claude C

Read the thread · 2026-02-06 · closed · external user · 3 comments

Feature Request: Add support for reading Items in Approve and Post status

Hi there!

First of all, thank you so much for creating this MCP integration for Autotask! It's incredibly useful and well-built.

Feature Request

I was wondering if it would be possible to add support for reading Items that are in the Approve and Post statuses? This would be a great addition to the current functionality and would help streamline our workflow even further.

Thank you for considering this request, and keep up the great work!

Read the thread · 2026-02-05 · closed · external user · 6 comments

Most recent

ARM build for Docker image

Tool type

Other

What are you adding or changing?

Would it be possible to include an ARM build for the Docker image?

This would make it possible to run the MCP server on an ARM system.

API endpoints involved

No response

Breaking changes

Read the thread · 2026-08-30 · open · external user · 0 comments

Possible fix(deps): 3 vulnerable dependencies in package-lock.json

Spotted what might be an issue in website/package-lock.json around line 2021.

Astro versions prior to 6.4.6 allow Server‑Side Rendered (SSR) applications to fetch prerendered error pages (e.g., /404, /500) using a URL built from the incoming request's Host header. Because the Host header is not validated, an attacker can supply a malicious host, causing the server to make an arbitrary HTTP request and expose the response data. This SSR Server‑Side Request Forgery (SSRF) can lead to informatio

Read the thread · 2026-08-25 · open · external user · 0 comments

[Enhancement] Add Contract Management Tools (Search, Update, Creation)

Tool type

API Coverage Expansion

What are you adding or changing?

Contract management is one of the most frequent PSA tasks for MSPs, but autotask-mcp currently has no tools covering the Contracts entity (39 tools today cover Companies, Tickets, Projects, Time Entries, etc., but not Contracts).

  1. Contract search / listing - Query contracts by Account, Status (Active/Expired/Cancelled), Contract Type, and date range. - Return contract header fields only (no service lines) to keep res

Read the thread · 2026-08-10 · closed · external user · 1 comment

[Bug] queueID missing from autotask_search_tickets tool definition

Component

MCP Tool

What happened?

Expected: the tool should allow for searching with a queueID argument as per documentation.

https://github.com/wyre-technology/autotask-mcp/blob/main/website/src/content/docs/reference/tools.md#tickets

Actual: The definition is missing from the [code](name: 'autotask_search_tickets',)

Steps to reproduce

Payload:

Request (tools/call JSON-RPC to autotask_search_tickets):
{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/call",
  "params":

[Read the thread](https://github.com/WYRE-AI/autotask-mcp/issues/208) · 2026-07-22 · closed · external user · 1 comment

### PATCH /Contacts returns HTTP 404 on Autotask Zone DE1 (Zone 18) — update_contact broken + missing userDefinedFields

## Summary

Three related bugs that make it impossible to update Contact records (including 
user-defined fields) on **Autotask Zone 18 / DE1 (European zone)**:

1. `PATCH /{Entity}` (collection-level PATCH with ID in body) returns **IIS HTML 404** on Zone 18
2. `autotask_update_contact` is missing the `userDefinedFields` parameter
3. `autotask_raw_request` does not allow `PUT`, so there's no workaround

---

## Feature Request / Completeness

It is important that **all Contact fields are fully 

[Read the thread](https://github.com/WYRE-AI/autotask-mcp/issues/133) · 2026-06-07 · closed · external user · 2 comments

### [Bug] autotask_create_ticket_note does not use Field Info for Publish and NoteType

### Component

MCP Tool

### What happened?

autotask_create_ticket_note has static values in tool description, however they can vary and thus should be dynamic.

Tool definition should be configured to query fields / entityinformation for `Publish` and `NoteType` from: /V1.0/TicketNotes/entityInformation/fields during tool call for accuracy.

From tool.definitions.ts:

        noteType: {
          type: 'number',
          description: 'Note type (1=General, 2=Appointment, 3=Task, 4=Ticket, 5=

[Read the thread](https://github.com/WYRE-AI/autotask-mcp/issues/126) · 2026-05-28 · closed · external user · 1 comment

### [Enhancement] Add issueType and subIssueType to autotask_update_ticket tool

### Tool type

Existing Tool Enhancement

### What are you adding or changing?

issueType and subIssueType are not exposed in the autotask_update_ticket tool. Would be useful for ticket triage.

### API endpoints involved

PATCH /v1.0/tickets

### Breaking changes

- [x] This change modifies existing tool behavior

[Read the thread](https://github.com/WYRE-AI/autotask-mcp/issues/109) · 2026-05-21 · closed · external user · 1 comment

### Four `search*` tools advertise filter params they silently drop — `searchContracts`, `searchConfigurationItems`, `searchInvoices`, `searchTasks`

## Summary

Four `autotask_search_*` MCP tools publish an `inputSchema` advertising filter properties (e.g. `companyID`, `searchTerm`, `status`) with descriptions like *"Filter by company ID"* — but the underlying service methods read **only** `options.filter` and `options.pageSize`. The advertised properties are accepted, logged at debug level, and then discarded. Every call returns the first N records of the entity table regardless of what the caller asked for.

The `filter` escape hatch the s

[Read the thread](https://github.com/WYRE-AI/autotask-mcp/issues/105) · 2026-05-15 · closed · external user · 2 comments

### [Bug] autotask_search_tasks ignores all filter parameters, returns same generic dataset every call

### Component

MCP Tool

### What happened?

The `autotask_search_tasks` tool returns the same generic set of ~100 old completed tasks regardless of which filters are provided. Filters like `assignedResourceID`, `status`, and `projectID` appear to be ignored.

### Steps to reproduce

Use search_tasks tool with filter of assignedResourceID

### Environment

Azure App Container  - Custom agent in Copilot studio.  Other requests working as expected.

[Read the thread](https://github.com/WYRE-AI/autotask-mcp/issues/104) · 2026-05-15 · closed · external user · 2 comments

### [Bug] autotask_create_service_call is defined twice

### Component

MCP Tool

### What happened?

autotask_create_service_call tools are defined twice and it is causing issues when adding the MCP server to some MCP gateways.

### Steps to reproduce

Attempting to add the Autotask MCP server to a third-party MCP Gateway 

Duplicate exported definitions in: **src > handlers > tool.definitions.ts**

### Environment

- MCP Server version latest from main

[Read the thread](https://github.com/WYRE-AI/autotask-mcp/issues/71) · 2026-04-24 · closed · external user · 1 comment

### Expose contactID as a filter parameter for autotask_search_tickets.

### Tool type

Existing Tool Enhancement

### What are you adding or changing?

Add contactID as a supported filter parameter to the autotask_search_tickets tool.

The Autotask REST API already supports querying tickets by contactID — the field is confirmed as isQueryable: true via autotask_get_field_info on the Tickets entity, and the field is actively populated on tickets. However, contactID is not currently exposed as a filter in the autotask_search_tickets tool parameters.

Current behavior:

[Read the thread](https://github.com/WYRE-AI/autotask-mcp/issues/65) · 2026-04-11 · closed · external user · 2 comments

### Feature Requests: Missing ticket/project fields, checklist items, zone auto-detection & more

### Tool type

Existing Tool Enhancement

### What are you adding or changing?

Hey Aaron,

first of all — I want to genuinely thank you, multiple times over. We use this MCP 
every single day as a team, and I mean that without any exaggeration. What you've 
built here has fundamentally changed the way we work. Our colleagues are thrilled, 
our workflows are smoother, and we're only just starting to discover the full 
potential. It's truly impressive what you've put together — thank you, thank y

[Read the thread](https://github.com/WYRE-AI/autotask-mcp/issues/55) · 2026-04-05 · closed · external user · 2 comments

The remaining reports are on [the project's issue tracker](https://github.com/wyre-technology/autotask-mcp/issues).