Pawsitive Future Pawsitive FutureDeveloper docs

post_auth_approve

Changes data · you confirm first

Calls POST /api/auth/approve as the signed-in person · REST reference

Approve a pending organization signup by contact email

Convenience endpoint. The admin console drives /api/approvals/signups/{id}/approve instead, which takes the contact USER ID; this one resolves the user from the email first and then approves. Platform-staff only, gated by requirePlatformStaff (a permission-derived check, never a role name) - the same gate as the /api/approvals routes. The approving user id is taken from the caller's token, never from the body. Unlike the public OTP routes, this one is authenticated, so the 404 for an unknown address is not an enumeration concern.

Arguments

ArgumentTypeDescription
bodyJSONobjectrequiredThe request body, as a JSON object. Its fields are listed below.

Fields of body

FieldTypeDescription
emailstring (email)requiredContact email of the pending signup.

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_auth_approve",
    "arguments": {
      "body": {
        "email": "name@example.org"
      }
    }
  }
}
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.

Signup approved.

json
{
  "message": "User approved successfully"
}

Fields

FieldTypeDescription
messagestring

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.

400

The request was malformed or failed a guard.

403

Either the caller is not platform staff, or the bearer is a DONOR token — a valid credential from the other realm, which the platform auth middleware refuses with 403 rather than 401 because re-authenticating would mint the same token.

404

No such resource — or none this caller may see.

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_auth_approve",
  "description": "POST /api/auth/approve — Convenience endpoint. The admin console drives /api/approvals/signups/{id}/approve instead, which takes the contact USER ID; this one resolves the user from the email first and then approves. Platform-staff only, gated by requirePlatformStaff (a permission-derived check, never a role name) - the same gate as the /api/approvals routes. The approving user id is taken from the caller's token, never from the body. Unlike the public OTP routes, this one is authenticated, so the 404 for an unknown address is not an enumeration concern.\n\nThis changes data. The person is asked to confirm it before it runs, and nothing happens if they decline.",
  "inputSchema": {
    "type": "object",
    "properties": {
      "body": {
        "type": "string",
        "description": "The JSON request body: { email*: string (Contact email of the pending signup.) }"
      }
    },
    "required": [
      "body"
    ]
  },
  "annotations": {
    "readOnlyHint": false,
    "destructiveHint": true,
    "idempotentHint": false,
    "openWorldHint": false
  }
}