darian.lagman
WORK / 04

Raiser's Edge NXT MCP

Research

Architectural design study comparing three MCP server topologies for connecting LLM agents to Raiser's Edge NXT — a nonprofit CRM with constituents, gifts, fundraising, events, and analytics domains.

Role
Architecture & prototype
Timeline
2026
Status
Research
Stack
MCPTypeScriptRaiser's Edge NXTOAuth
Raiser's Edge NXT MCP hero

Problem

Raiser's Edge NXT (RE NXT) is a nonprofit CRM with five organizationally distinct domains: constituents, gifts, fundraising, events, and analytics. Different staff touch different domains, the data has different sensitivity profiles (gifts are PII-heavy, events less so), and the API surface is large.

Connecting an LLM agent to "all of RE NXT" via a single tool list does not survive contact with reality. The list balloons, routing accuracy collapses, and the permission model becomes an afterthought. This study compares three MCP topologies for this kind of multi-domain CRM.

Three architectures

Diagram
Domain-split MCP routing
User request
Router
Constituents
Gifts
Events
Role scope

A small router selects the domain server before exposing role-scoped tools.

1. Monolithic MCP

One server, every tool registered. Simple to operate. Routing accuracy degrades past roughly 40 tools, and permission scoping becomes a per-tool problem instead of a per-server boundary.

2. Semantic tool filtering

One server, but tools are dynamically scoped by the user's intent (embedding-similarity over the latest user turn). Cheaper than a full split. Fragile when intent shifts mid-conversation.

3. Multi-server domain split

One MCP server per domain (constituents, gifts, events, analytics). Highest isolation, cleanest permission model, requires a meta-router that picks the right server per turn.

Meta-router

The meta-router is a small classifier — embedding similarity plus a short rules layer — that decides which domain server gets the turn. It is a 200-line problem.

Permission-aware actions

Constituents and gifts are PII-heavy; the spec includes role-scoped tool exposure, not just role-scoped data. A program-staff session shouldn't even see the gifts-mutation tools in its tool list — much less be denied at execution time. This is easier to enforce when tools live on a server you can swap, which is the quiet third reason to split.

Verdict

What I'd do differently

  • Spend less time on the semantic-filter prototype. I knew it wouldn't survive multi-turn conversations after a week; I gave it three.
  • Treat the meta-router as a logging surface from day one. Routing decisions are the most interesting thing to read three weeks later.