`post_users_by_id_resend_invitation`

Changes data · you confirm first

Calls POST /api/users/{id}/resend-invitation as the signed-in person · REST reference

Re-send the sign-in invitation email to a user who has not accepted

Requires execute:CreateUserCommand — the same permission as the original invite; platform staff bypass it. Sign-in is one-time-code based, so the mail carries NO token to re-mint: it points the recipient at the login page, matching the welcome mail the approvals flow sends. Only a user still in INVITED or PENDING can be re-invited; any other status is a 409. A user whose status is absent entirely falls through the guard and IS re-invited. A mail-transport failure is reported, never swallowed — a silent failure here would look to the operator exactly like a successful resend. The login URL is built from FRONTEND_URL, defaulting to http://localhost:5173.

Arguments

Argument	Type		Description
`id`path	string (uuid)	required	User id. Not format-validated by this route.

Example call

A client sends this over the MCP session; Claude and other agents build it for you. The values are placeholders — the shape is real.

json

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/call",
  "params": {
    "name": "post_users_by_id_resend_invitation",
    "arguments": {
      "id": "11111111-1111-4111-8111-111111111111"
    }
  }
}

Confirmation

The client shows the person the exact request and waits. Nothing runs until they tick Make this change. See Reading and changing.

Result

On success (HTTP 200) the tool returns one text item holding the API's JSON, pretty-printed.

The invitation email was handed to the transport.

json

{
  "message": "Invitation resent"
}

Fields

Field	Type	Description
`message`	"Invitation resent"

When it fails

A failed call returns isError: true with the API's message as text. A change the person declines, or lets time out, also comes back this way and nothing changes.

403: Authenticated, but the caller holds none of the required permissions.
404: No such user — also what a failed DAL read produces, because UserService.getUserById catches and returns null.
409: The user has already accepted; the message names the current status. Any status other than INVITED or PENDING lands here.
502: The mail transport rejected the message. The transport's own text is logged, not returned — the body carries "Invitation email could not be sent".

What the model is shown

This is the tool exactly as the server lists it in tools/list. The description starts with the REST call it makes.

json

{
  "name": "post_users_by_id_resend_invitation",
  "description": "POST /api/users/{id}/resend-invitation — Requires `execute:CreateUserCommand` — the same permission as the original invite; platform staff bypass it. Sign-in is one-time-code based, so the mail carries NO token to re-mint: it points the recipient at the login page, matching the welcome mail the approvals flow sends. Only a user still in INVITED or PENDING can be re-invited; any other status is a 409. A user whose `status` is absent entirely falls through the guard and IS re-invited. A mail-transport failure is reported, never swallowed — a silent failure here would look to the operator exactly like a successful resend. The login URL is built from `FRONTEND_URL`, defaulting to `http://localhost:5173`.\n\nThis changes data. The person is asked to confirm it before it runs, and nothing happens if they decline.",
  "inputSchema": {
    "type": "object",
    "properties": {
      "id": {
        "type": "string",
        "description": "User id. Not format-validated by this route."
      }
    },
    "required": [
      "id"
    ]
  },
  "annotations": {
    "readOnlyHint": false,
    "destructiveHint": true,
    "idempotentHint": false,
    "openWorldHint": false
  }
}