Provides tools to query and update a sales CRM database hosted on Supabase, including prospect search, pipeline summary, follow-up tracking, status changes, and note addition.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@nexus-mcp show me my pending follow-ups"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An MCP (Model Context Protocol) server that exposes a real sales CRM as tools an AI agent can call — plus a CLI that does the same job with no model involved.
Built to solve an actual problem, not as an exercise. I run a small web-development studio and my CRM had grown to ~270 prospects with long free-text notes that nobody re-read. Prospects who had shown interest were quietly dying in the list, because a spreadsheet only shows you what you remember to look for. The first time I ran this, it surfaced two leads I had abandoned a week earlier.
$ nexus-crm hoy
VENCIDOS (1)
────────────
#a3f21c08-4d19-4b7e-9e02-6c1f8b40d772 Estudio Ferrari & Asoc. · Legal · Zárate [Respondió]
contacto: contacto@ferrari.example.com · seguir: 2026-07-24 · $450000
vencido hace 3 día(s)
ABANDONADOS — nadie les puso fecha (4)
──────────────────────────────────────
#7b90e4d1-2c53-49aa-8f61-0d5e7a3c9b14 Odontología Norte · Salud · Zárate [Respondió]
contacto: +54 9 3487 000002 · $590000
...The output above comes from
demo/seed.sql— invented businesses, invented phone numbers, reservedexample.comdomains. No client data lives in this repository.
Tool | What it does |
| Free-text search across name, industry, area, contact and notes, with optional filters by status/industry/area |
| Pipeline snapshot: count per status, overdue follow-ups, abandoned leads, total value at stake |
| Who to chase: overdue, upcoming, and abandoned — interested, not discarded, and with no follow-up date set |
| Move a prospect along the pipeline |
| Append a dated entry to the prospect's history, in the same format the CRM's own UI writes |
The third one is the reason this exists. Overdue follow-ups are easy — any list view shows them. Leads with no date at all are invisible by construction, and those are the ones that cost money.
Related MCP server: Follow Up Boss MCP Server
TypeScript · Node 22 · @modelcontextprotocol/sdk · Supabase (PostgreSQL) · Zod
Tool inputs are validated with Zod schemas, so the model gets a typed contract and a useful error instead of a silent failure. The server speaks MCP over stdio, which is what desktop MCP clients expect.
The prospectos table has RLS enabled. Worth knowing, because it fails quietly: with the publishable key alone, Supabase returns an empty list rather than an error — so the tools look like they work and report zero results.
The server signs in with email/password before its first query and holds an authenticated session, which is what the RLS policy checks. Credentials live in .env, never in the repo.
npm install
cp .env.example .env # fill in your Supabase project and login
npm run buildAs a CLI:
node dist/cli.js hoy
node dist/cli.js resumen
node dist/cli.js buscar odonto
node dist/cli.js estado 42 "Respondió"
node dist/cli.js nota 42 "resent the quote, he'll look at it this week"As an MCP server, add it to your client's config:
{
"mcpServers": {
"nexus-crm": {
"command": "node",
"args": ["/absolute/path/to/nexus-mcp/dist/server.js"]
}
}
}Then ask in plain language: "who should I follow up with today?", "mark Ferrari as replied and note that he asked for the quote again".
demo/seed.sql creates the table, its RLS policy and 15 fictional prospects — invented names, phone numbers and negotiation notes. Run it in an empty Supabase project, point your .env at it, and everything below works against that instead.
It doesn't replace the CRM and it doesn't collect data on its own. It's a query-and-update layer on top of a database that already existed. The CRM UI stays the place where records are created; this is for the question a UI is bad at answering: what am I forgetting?
MIT
Suma una entrada al historial de seguimiento de un prospecto, con la fecha de hoy. Respeta el formato del CRM, así que la nota aparece en el panel de historial como una más.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Id del prospecto (UUID, sale de buscar_prospectos) | |
| texto | Yes | Qué pasó, en una línea |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full burden. It discloses the automatic date and CRM formatting but omits idempotency, permissions, or error handling. Moderately transparent for a simple append operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core action. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with 2 params and no output schema, the description covers the main behavior. Missing details on return value or errors, but adequate for its simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, baseline 3. The description adds context about date auto-fill and CRM format but does not enhance parameter-specific meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the specific action: adds an entry to the follow-up history of a prospect with today's date. It distinguishes from sibling tools like 'buscar_prospectos' (search) and 'cambiar_estado' (change status).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for adding notes but does not explicitly state when to use it versus alternatives like 'cambiar_estado'. No guidance on prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Busca prospectos en el CRM por texto libre (nombre del negocio, contacto o notas) y/o por estado, rubro y zona. Devuelve una lista con el id de cada uno, que es lo que necesitan las herramientas de cambiar_estado y agregar_nota.
| Name | Required | Description | Default |
|---|---|---|---|
| zona | No | Filtrar por zona o ciudad | |
| rubro | No | Filtrar por rubro | |
| texto | No | Texto libre: nombre, rubro, zona, contacto o notas | |
| estado | No | Filtrar por un estado exacto | |
| limite | No | Cuántos traer (por defecto 25) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description discloses the tool returns IDs but does not specify the full output structure (e.g., whether additional fields are returned). It adequately indicates the workflow relationship.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two succinct sentences, front-loaded with the core function, and every word contributes to understanding the tool's purpose and usage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no output schema, the description explains the return value (IDs needed for other tools) but could be more specific about the structure of the response (e.g., any other fields included).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear descriptions for all 5 parameters. The description adds no new parameter-level meaning beyond summarizing filters, which is already covered by the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches prospects in CRM by free text and filters, and defines its output (list with IDs needed by cambiar_estado and agregar_nota), distinguishing it from other tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains that the output IDs are required by cambiar_estado and agregar_nota, implying when to use it, but does not explicitly state when not to use it or mention alternatives like resumen_pipeline.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Mueve un prospecto de estado en el pipeline. El id sale de buscar_prospectos.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Id del prospecto (UUID, sale de buscar_prospectos) | |
| estado | Yes | Estado nuevo |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose any behavioral traits beyond the basic action (moving a prospect). It lacks details on side effects, permissions, or reversibility.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise: two short sentences. It front-loads the core action, but could arguably be slightly more structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity and no output schema, the description is minimally adequate but lacks behavioral context that would help an agent fully understand implications.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description adds no new meaning beyond what the schema already provides. For a high-coverage schema, this baseline score is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Mueve' and the resource 'prospecto de estado en el pipeline', distinguishing it from siblings like buscar_prospectos (search) or resumen_pipeline (summary).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description hints that the id comes from buscar_prospectos, providing usage context, but does not explicitly state when to use this tool versus alternatives or provide exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Foto general del pipeline de ventas: cuántos prospectos hay en cada estado, cuántos seguimientos están vencidos, cuántos quedaron abandonados y cuánta plata hay en juego.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses what is returned (counts, overdue, abandoned, money) and implies a read-only snapshot ('foto general'). Could add details like whether data is real-time or cached, but overall adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with key information, no wasted words. Every part contributes to understanding the tool's output.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and no output schema, the description is nearly complete. It covers all expected metrics. Could clarify the monetary metric (total pipeline value vs weighted). Still adequate for a simple overview tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Zero parameters, so schema coverage is 100%. Description doesn't need to explain params. Baseline 4 applies as it adds value by describing the output content.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it provides a 'Foto general del pipeline de ventas' (overall picture) with specific metrics (prospects per state, overdue follow-ups, abandoned, money). It uses a specific verb 'resumen' and resource 'pipeline', and distinguishes from sibling tools that focus on individual prospects or status changes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this vs alternatives. However, the description implies it's for a high-level snapshot. Adding explicit when/when-not would improve, but context from siblings suggests it's for overview while others are for detailed actions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
A quién hay que seguir. Devuelve tres grupos: los seguimientos vencidos, los que vencen en los próximos días, y los prospectos abandonados (mostraron interés, nadie los descartó y no tienen fecha de seguimiento cargada). El tercer grupo es el que no aparece en ninguna planilla.
| Name | Required | Description | Default |
|---|---|---|---|
| dias | No | Ventana hacia adelante en días (por defecto 7) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the three output groups and their logic (e.g., abandoned prospects lack follow-up date). However, it does not explicitly state that the tool is read-only or if any mutations occur, though the context suggests query behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences in Spanish, front-loaded with 'A quién hay que seguir' and immediately detailing the three groups. No redundant or extra information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite lacking an output schema, the description thoroughly explains the three result groups, including edge cases (abandoned prospects). Given the simplicity (one optional parameter), this is sufficient for an agent to understand the tool's return value.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the only parameter ('dias'), which already includes a description. The tool description does not add additional meaning or usage details beyond what the schema provides, resulting in a baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns three groups of pending follow-ups: overdue, upcoming, and abandoned prospects. This distinguishes it from siblings like 'buscar_prospectos' (prospecting) or 'resumen_pipeline' (pipeline summary), making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for identifying who needs follow-up, but does not explicitly state when to use it versus siblings like 'buscar_prospectos' or 'cambiar_estado'. No exclusions or alternatives are mentioned, leaving guidance implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.0.0agregar_notabuscar_prospectoscambiar_estadoresumen_pipelineseguimientos_pendientesEach tool has a clearly distinct purpose: search, pipeline overview, follow-ups, status change, and note addition. No overlap in functionality.
All tool names follow the snake_case verb_noun pattern consistently (e.g., buscar_prospectos, cambiar_estado). No mixing of conventions.
5 tools is well-scoped for a CRM pipeline management server. Each tool serves a specific need without overloading or underproviding.
The set covers reading (search, pipeline summary, follow-ups) and updating (status change, add note) but lacks creation and deletion tools for prospects, which are notable gaps for a CRM context.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
API-first CRM for LLMs - contacts, companies, deals and activities over a native MCP server.
MCP server unifying ERPs, CRMs, APIs and knowledge base for Claude, ChatGPT and Gemini.
MCP server for LeadDelta — manage LinkedIn connections and CRM data via AI assistants.
The HubSpot MCP Server acts as a bridge that enables AI assistants and Large Language Models to securely interact with HubSpot CRM data through natural conversation, without requiring users to understand complex API structures. It provides read-only access to standard CRM objects (contacts, companies, deals, tickets, products, invoices, and more) and their associations, secured via OAuth 2.0, allowing AI agents to perform tasks like summarizing deals, fetching company updates, and looking up record changes.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/NexusDev-ar/nexus-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
