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/cipp/issues.md or /mcp/cipp/issues.json, or Pod over MCP.

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.

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 <guid>, 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 · 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 · 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 · 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: '<tenant>',
                searchField: 'userPrincipalName',
                searchValue: '<a single upn>')

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 · 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 · 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 · 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 · 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:

{"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 · 2026-04-28 · closed · outside contributor · 1 comment

Most recent

The remaining reports are on the project's issue tracker.