# Reported issues for CIPP Pod holds 8 of 8 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 [CIPP](/mcp/cipp). ## Most discussed ### addScheduledItem: blank task name, ISO timestamp throws, and CIPP error strings returned as success Found by the #67 preflight. `src/services/cipp.service.ts`. Three distinct defects in one method. ### 1. Task name never lands `Add-CIPPScheduledTask` reads `$task.Name`; the service sends `taskName`. The task is created with `Name = ''` — this breaks the `DisallowDuplicateName` check, logs as `Added task with ID `, and leaves the task effectively unfindable in the scheduler UI. ### 2. ISO timestamp throws The tool schema documents `scheduledTime` as ISO 8601. CIPP does `[int64]$task. [Read the thread](https://github.com/WYRE-AI/cipp-mcp/issues/76) · 2026-07-25 · closed · external user · 1 comment ### setOutOfOffice sends UserPrincipalName/enabled instead of userId/AutoReplyState — tool is non-functional

Sibling of the setEmailForwarding report, found by the same #67 preflight. src/services/cipp.service.ts.

Symptom

cipp_set_out_of_office returns HTTP 500 with:

Could not set Out of Office for user: . Error: ...

Note the blank username — that's the tell.

Root cause

Invoke-ExecSetOoO.ps1 reads $Request.Body.userId and $Re [Read the thread](https://github.com/WYRE-AI/cipp-mcp/issues/75) · 2026-07-25 · closed · external user · 1 comment ### setEmailForwarding sends no forwardOption — ExecEmailForward returns a null-StatusCode 500; tool has never worked in any mode

Found by the #67 payload-preflight convention. src/services/cipp.service.ts.


Symptom
cipp_set_email_forwarding returns an opaque HTTP 500 carrying a PowerShell worker stack trace:
CIPP API returned HTTP 500 for POST /api/ExecEmailForward:
Cannot create object of type 'Microsoft.Azure.Functions.PowerShellWorker.HttpResponseContext'.
Cannot convert null to type 'System.Net.HttpStatusCode'.

Reprodu

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

### listUsers searchField/searchValue are silently ignored — returns the entire tenant

Different class from the write-contract reports, and it affects probably the most-used tool in the server. `src/services/cipp.service.ts`.

### Symptom

```
cipp_list_users(tenantFilter: '',
                searchField: 'userPrincipalName',
                searchValue: '')
```

returned **all 93 users in the tenant**. The search parameters had no effect, and the response was large enough to blow the client's tool-result limit.

### Root cause

`listUsers` passes `searchFiel

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

### offboardUser payload matches nothing in ExecOffboardUser — no offboarding action has ever run

Found by the #67 payload-preflight convention (diffing the outbound body against the matching Invoke-*.ps1 $Request.Body.* reads). src/services/cipp.service.ts. Flagging as security-relevant rather than merely broken.

Symptom
cipp_offboard_user returns HTTP 400 listing validation errors. No offboarding action has ever executed through this tool.
Root cause
Invoke

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

### cipp_edit_user sends a payload shape upstream Invoke-EditUser.ps1 never reads (UPN + licenses broken)

Surfaced by external PR #66 (self-closed by author before review — substance verified independently).

## Confirmed against upstream CIPP-API source (`KelvinTegelaar/CIPP-API`, `Invoke-EditUser.ps1`)

- **UPN**: line 34 — `$UserPrincipalName = "$($UserObj.username)@$($UserObj.Domain ? $UserObj.Domain : $UserObj.primDomain.value)"`. Upstream builds the UPN from `username` + `Domain`/`primDomain.value` and **never reads a `userPrincipalName` body field**. Our `editUser` (src/services/cipp.service.

[Read the thread](https://github.com/WYRE-AI/cipp-mcp/issues/67) · 2026-07-18 · closed · outside contributor · 1 comment

### Post-approval scope drift on CIPP MCP admin tools?

Hi,

I’m looking at cipp-mcp because the tool surface has a real admin trust boundary: M365 user/admin actions, offboarding, MFA/session controls, mail forwarding, and tenant-level operations.

One question I’m exploring:

If a client approves a CIPP MCP tool in one state, should the runtime re-check trust if that tool’s scope or side effects change later?

Example drift cases:

- a read/list tool later gains disable/offboard behavior
- a narrow admin action later gains broader tenant scope
- ma

[Read the thread](https://github.com/WYRE-AI/cipp-mcp/issues/60) · 2026-06-25 · open · external user · 0 comments

### Tool calls return JSON-RPC -32602 instead of tool-level isError when credentials missing

## Reproduction

When CIPP credentials are not configured, calling any tool fails at the JSON-RPC param-validation layer:

```json
{"error": {"code": -32602, "message": "CIPP_BASE_URL is not configured. Set it in your environment or MCP client config."}}
```

## Expected

Per MCP semantics, tool-level errors should set `isError: true` on the tool result with a message in `content`, not return JSON-RPC error `-32602 invalid params`. The `-32602` error code semantically means *the request was malf

[Read the thread](https://github.com/WYRE-AI/cipp-mcp/issues/3) · 2026-04-28 · closed · outside contributor · 1 comment

## Most recent

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