# Run one workflow across Claude, ChatGPT and Cursor

> MCP means write once: verify each client with ping and reuse the same research workflow wherever you work.

- For: Developer
- Category: Agent & Workflow Automation
- MCP tools: ping, chat
- HTML version: https://veridive.com/mcp/use-cases/same-workflow-every-client

## The problem

Your research workflows live where you built them: the prompt sequence that works in Claude, the setup you rigged in Cursor, the thing you'd have to rebuild if you switched. Tool-specific workflows are the new vendor lock-in — softer, but real: every client change or team-member difference means re-plumbing the same logic against a different integration.

MCP's actual promise is the boring one: the *protocol* is the integration. The veridive server speaks the same tools to Claude, ChatGPT, Cursor, VS Code and whatever ships next — which means a workflow written against the tools (not the client) runs everywhere, survives client churn, and onboards a teammate with a config file instead of a rebuild.

## How veridive MCP helps

**ping** is the portability test: connect the veridive server in a new client, ping, and the workflow's foundation is verified — same server, same tools, same behavior. What changes per client is chrome (how scheduling works, where configs live); what persists is everything that matters: the tool calls and the prompt logic.

**chat** rounds out the portable layer: conversational continuity through veridive itself (the chat tool carries a resumable id), so even multi-turn research threads survive client hops. The practical wins: your personal workflows follow you across tools; team workflows distribute as MCP configs plus prompt docs; and client choice becomes preference again instead of architecture.

## How to run it

1. **Connect veridive MCP everywhere you work** — Same server, same key (or per-client keys) — Claude settings, ChatGPT connectors, Cursor's mcp.json, VS Code's.

   ```
   Ping veridive to confirm this client's connection works.
   ```
2. **Write workflows against tools, not clients** — Prompt sequences that name veridive tools and goals port cleanly; client-specific chrome stays out of the core.

   ```
   Run my standard research workflow on <topic>: sweep with deep_search, import the best sources, answer with citations — same as I run it in <other client>.
   ```
3. **Distribute to the team as config** — A project-level mcp.json plus the prompt doc — onboarding a teammate is a file, not a build.

   ```
   Ping veridive from this fresh setup and run the team's briefing workflow to verify the config distribution worked.
   ```

## Problems it solves

- Workflows lock to the client they were built in — soft vendor lock-in via rebuild cost.
- Team members on different assistants can't share the same research automations.
- Client migrations mean re-plumbing every integration the workflows leaned on.
- Multi-turn research threads die at client boundaries.

## Why it's valuable

- Write once against the tools; run in every MCP client, present and future.
- Team workflows ship as configs + prompt docs — onboarding is a file.
- Client choice returns to being preference, not architecture.
- The chat tool's resumable threads carry context across the hops.

## Example prompts

```
Ping veridive — verify this client's connection.
```

```
Run the standard research workflow on <topic>, exactly as in <other client>.
```

```
Fresh setup: ping, then run the team briefing to verify the config.
```

## FAQ

**What actually differs between clients?**

The chrome: how scheduling works, where the MCP config lives, UI affordances. The tool layer — every veridive capability — is identical by protocol, which is the portability guarantee.

**How does chat help with portability?**

veridive's chat tool returns a resumable chat id — a conversation thread that lives server-side. Start a research thread in one client, continue it in another by resuming the id.

**One shared key or per-client keys?**

Both work; per-client keys make usage attributable and revocation surgical. For teams, a project-scoped config with its own key is the clean pattern.

## Related use cases

- [Wire MCP health checks into CI](https://veridive.com/mcp/use-cases/mcp-health-check-ci.md) — A ping in your pipeline catches broken keys and endpoint drift before your agents fail silently in production.
- [Chain search → import → interrogate in one agent](https://veridive.com/mcp/use-cases/search-import-interrogate-pipeline.md) — The full pipeline in one conversation: find the best sources, pull them into the library, and question them — hands off.
- [Stand up a research library your whole team queries](https://veridive.com/mcp/use-cases/company-research-library.md) — Curate once, query forever: shared imports become a common brain with citations instead of link-dump Slack threads.

---

Part of the veridive MCP use-case library: https://veridive.com/mcp/use-cases.md
Server docs for agents: https://veridive.com/mcp.md