MCP server
Let AI assistants work in a Dashly workspace through the Model Context Protocol.
Dashly runs a Model Context Protocol server at:
https://mcp.usedashly.comAny MCP client can connect to it: Claude, ChatGPT, Cursor, Claude Code, Codex, or your own agent. Once connected, the assistant can read and write the agency's data (clients, deals, projects, tickets, time logs…) and run the product's actions, with exactly the rights of the person or key that connected it.
How it works
- JSON-RPC 2.0 over HTTP. You
POSTa JSON-RPC request to the URL above and get a JSON response back. The server is stateless: every request carries its own credentials and no session is kept between requests, so there is no SSE stream to hold open. - Supported protocol versions:
2025-06-18(latest),2025-03-26and2024-11-05. The server answers in the version your client proposes when it supports it. - Methods:
initialize,ping,tools/list,tools/call,prompts/list,prompts/get,resources/list,resources/read, and notifications. - Request bodies are capped at 1 MiB (larger bodies are refused with HTTP 413).
Built on the REST API
The MCP server has no direct access to the database. Every tool call becomes a call to the REST API with the caller's credential, which means:
- Same scopes. A connector can do what its key or member can do through the API, and nothing more.
- Same limits. Calls draw on the agency's monthly token allowance and burst limits, exactly like API calls. See Rate limits.
- Same audit trail. Writes are recorded like any other API write, and marked as coming from the MCP server, so an agency can see what an assistant did.
- Same tenant isolation. A public id from another agency answers 404.
The tools are generic: rather than one tool per resource, each tool takes the resource
as an argument (list_records on clients, create_record on tickets…). When a resource
is added to the API, the MCP server exposes it immediately, with no new tool to learn.
How an agent should discover the workspace
The server tells connected clients this in its initialize instructions, and it is the
order that works best:
Read the context resources first. dashly://catalog lists every resource with its
fields, filters, sorts and relations; dashly://fields lists the agency's custom fields
and how to fill customFields; dashly://conventions gives this agency's own
vocabulary (workflow columns, pipelines and stages, people). See
Prompts and resources.
List the verbs once. Call list_actions with no argument to see every action the
product offers, then call it again with a resource to get the exact body one expects.
Prefer a prompt over improvising. Recurring procedures (the weekly client update, preparing a meeting, reviewing the pipeline…) are offered as prompts.
Then read and write with the record and action tools.
Three rules an agent cannot guess:
- Records are addressed by their public id (such as
hsbftmp3f5), never by an internal UUID, in paths and in links (clientId,projectId…) alike. - Much of the product is verbs, not field edits: converting a lead, merging deals,
freezing a deck, importing a CSV. Computed figures (the agency overview, a member's day,
a client's site statistics) are read-only verbs run with
read_action. update_recordmerges the fields you send, exceptcustomFields, which it replaces wholesale. Read, merge, then write.
Calling it by hand
With an API key you can call the server with plain curl:
curl -s https://mcp.usedashly.com \
-H "Authorization: Bearer $DASHLY_API_KEY" \
-H "Content-Type: application/json" \
-d '{"jsonrpc":"2.0","id":1,"method":"tools/call","params":{"name":"get_account","arguments":{}}}'A GET on the endpoint with a credential returns a short description of the server
(name, protocol versions, authentication options, tool and resource names).