Sift MCP server

Read from the package source without running it. The installed server may list more.

• apply_decision_to_content

  Apply a workflow Decision to a content item (POST /v3/accounts/{account_id}/users/{user_id}/content/{content_id}/decisions). Content-level decisions target one piece of user-generated content — typical for content_abuse abuse type (e.g. take-down a listing flagged as scam). Requires SIFT_ACCOUNT_ID.

• apply_decision_to_orderwrite action

  Apply a workflow Decision to a specific order (POST /v3/accounts/{account_id}/users/{user_id}/orders/{order_id}/decisions). Order-level decisions target a single transaction rather than the whole user (e.g. 'approve_order_payment_abuse' on a manually-reviewed high-value order). Requires SIFT_ACCOUNT_ID.

• apply_decision_to_session

  Apply a workflow Decision to a session (POST /v3/accounts/{account_id}/users/{user_id}/sessions/{session_id}/decisions). Session-level decisions target a specific authenticated session — typical for account_abuse abuse type (e.g. force-logout a session that was hijacked). Requires SIFT_ACCOUNT_ID.

• apply_decision_to_user

  Apply a workflow Decision to a user (POST /v3/accounts/{account_id}/users/{user_id}/decisions). Decisions are the modern replacement for Labels — they both classify the entity for Sift's ML and trigger any configured side effects (e.g. a Block decision on a $payment_abuse user will cause that user's future $transaction events to be blocked). Requires SIFT_ACCOUNT_ID.

• get_content_decisions

  Fetch the decisions currently applied to a content item (GET /v3/accounts/{account_id}/users/{user_id}/content/{content_id}/decisions). Requires SIFT_ACCOUNT_ID.

• get_order_decisionswrite action

  Fetch the decisions currently applied to an order (GET /v3/accounts/{account_id}/orders/{order_id}/decisions). Note: the order-level GET path does NOT include user_id, unlike the order-level apply path. Requires SIFT_ACCOUNT_ID.

• get_session_decisions

  Fetch the decisions currently applied to a session (GET /v3/accounts/{account_id}/users/{user_id}/sessions/{session_id}/decisions). Requires SIFT_ACCOUNT_ID.

• get_user_decisions

  Fetch the decisions currently applied to a user (GET /v3/accounts/{account_id}/users/{user_id}/decisions). Returns the active decision per abuse type. Requires SIFT_ACCOUNT_ID.

• get_user_score

  Fetch the latest Sift score(s) for a user (GET /v205/users/{user_id}/score). Does NOT trigger a rescore — it returns whatever score was last computed. The score is a float in [0, 1]; higher means more fraud-like. Optionally filter by abuse_types.

• get_workflow_runwrite action

  Fetch the status of a Sift Workflow run (GET /v3/accounts/{account_id}/workflows/runs/{run_id}). The run_id is returned in the response to events sent with return_workflow_status=true. The run status tells you which route of the workflow was taken and which decisions were applied. Requires SIFT_ACCOUNT_ID.

• label_user

  Label a user as fraud or not-fraud via the legacy Labels API (POST /v205/users/{user_id}/labels). Labels are the classic supervised-learning feedback channel for Sift's ML model. Note: most new integrations use the Decisions API (apply_decision_to_user) instead — labels are kept for backward compatibility. Still supported for ongoing model feedback.

• link_session_to_userwrite action

  Send a $link_session_to_user event to Sift's Events API (POST /v205/events). Use when a user signs in or up after pre-login activity — links the anonymous session's signals back to the now-known user, retroactively scoring earlier events.

• rescore_user

  Force Sift to recompute a user's score right now (POST /v205/users/{user_id}/score). Use when you have externally-observed signal that should invalidate the last score (e.g. a manual decision) but have not sent a new event.

• send_chargebackwrite action

  Send a $chargeback event to Sift's Events API (POST /v205/events). Convenience wrapper around send_event for the most common ML-feedback signal: a confirmed chargeback. Sift uses chargeback events as a strong negative-label signal for the payment_abuse model. Optionally request a synchronous score with return_score=true.

• send_content_statuswrite action

  Send a $content_status event to Sift's Events API (POST /v205/events). Used to update the moderation status of user-generated content (listings, posts, messages, profiles) — feeds Sift's content_abuse model.

• send_custom_eventwrite action

  Send a custom (merchant-defined) event to Sift's Events API (POST /v205/events). Use for events not covered by Sift's reserved $-prefixed catalog. Custom event names should NOT start with '$' — Sift treats anything without the $ prefix as merchant-defined. Useful for domain-specific signals (e.g. 'kyc_check_passed', 'phone_verified').

• send_eventwrite action

  Send a fraud signal to Sift's Events API (POST /v205/events). The `type` parameter selects the event kind ($create_order, $transaction, $login, $create_account, $update_account, $chargeback, $order_status, etc). Additional fields ($user_id, $session_id, $order_id, custom fields) are passed via `fields` and merged into the body. Use `return_score=true` to get a synchronous score in the response.

• send_loginwrite action

  Send a $login event to Sift's Events API (POST /v205/events). Convenience wrapper for tracking login attempts — both successful and failed attempts feed Sift's account_abuse model.

• send_logoutwrite action

  Send a $logout event to Sift's Events API (POST /v205/events). Convenience wrapper for tracking session terminations.

• unlabel_userwrite action

  Remove any existing label on a user (DELETE /v205/users/{user_id}/labels). Optionally scope by abuse_type.

• Code scan6 source files scanned25/25
• –Live reliabilityno gateway calls yet and no remote to proben/a
• –Tool poisoningtools not inspected (local package is not executed); not countedn/a
• Auth qualitystatic API keys via environment variables6/15
• Maintenancelast push 29 days ago15/15
• Maintainer identityregistry namespace matches repository owner7/10

Safety score

82/100

higher than 63% of 48,255 servers

Tools

20

the typical server has 7

Tools that change things

55%

typical: 0%. Fewer write tools means less an agent can break

GitHub stars

271

more than 95% of 28,688 servers

Sift: common questions

Is Sift MCP server safe?

Mostly: it is graded B (82/100). Read the Sift safety report

How do I install Sift?

It runs on your machine. Copy the Claude Code, Cursor, VS Code or Claude Desktop config from the install section.

Does Sift need an API key?

Yes. The registry entry asks for SIFT_API_KEY.

Is Sift maintained?

The last commit was 67 days ago (2026-08-29). The latest release is v0.2.0-alpha.3.

What can I use instead of Sift?

Servers from other publishers that do the same job: UniFi Protect MCP server.

How does Sift compare with other MCP servers?

safety score 82/100 (higher than 63% of 48,255 servers); tools 20 (the typical server has 7); tools that change things 55% (typical: 0%. Fewer write tools means less an agent can break). Full comparison.