MCP tools
Forty-six tools over the Model Context Protocol, the three things a call needs, and what MCP does not cover that REST does.
MCP is a second transport over the same product, not a second product. A tool calls the same service function as the REST operation beside it, resolves to the same action, and is refused for the same reasons.
Not the MCP this site serves
Two MCP servers exist in this product’s world, and conflating them is the first mistake to avoid.
| This documentation site | The product | |
|---|---|---|
| Endpoint | https://docs.taylorz.ai/mcp |
/mcp on the API host |
| Tools | 4 — search_docs, get_page, list_pages, get_navigation |
46, listed below |
| What it reaches | These documentation pages | A workspace’s CRM data |
| Authentication | None. It is public | OAuth, like every other endpoint here |
| Writes | Never | Yes, with the right scope |
If you want an agent that can answer questions about the API, point it at this site. If you want one that reads and writes records, read on.
Three things a call needs
A tool call passes the same four checks a REST request does, and three of them have to be arranged separately.
- The connection scope
mcp.access. A token names exactly one resource. A token minted for/api/v1does not work on/mcpand the reverse is also true, so an agent that uses both transports holds two tokens. - The action scope. Each tool requires one, listed below, exactly as its REST counterpart does.
- The tenant’s
mcpmodule. A workspace with it off refuses the whole transport withmcp_disabled.
The fourth check — the member’s role — needs no arranging, but it still applies. A viewer’s eight permitted actions are all reads, so a viewer holding records.write is refused on the role, not on the scope. Permissions has the full table.
Getting a token is the same flow as for REST, with mcp.access in place of api.access. See connect a client.
The tools
Forty-six tools across nineteen action scopes. The scope is what consent grants and what a refusal names.
Objects, fields and records
| Scope | Tools | Reads or writes |
|---|---|---|
objects.bootstrap |
crm_initialize_workspace |
writes |
objects.read |
crm_list_objects, crm_list_fields |
reads |
objects.manage |
crm_create_object, crm_update_object, crm_create_field, crm_update_field |
writes |
records.read |
crm_list_records, crm_get_record |
reads |
records.write |
crm_create_record, crm_update_record |
writes |
Commerce and CPQ
| Scope | Tools | Reads or writes |
|---|---|---|
prices.read |
crm_get_cpq_configuration, crm_get_commercial_policy, crm_list_products, crm_list_price_books, crm_list_purchase_costs |
reads |
prices.manage |
crm_create_product, crm_create_price_book, crm_assign_price_book, crm_import_prices, crm_create_purchase_cost |
writes |
quotes.read |
crm_list_quotes, crm_get_quote |
reads |
quotes.write |
crm_preview_quote, crm_create_quote, crm_revise_quote |
writes |
settings.manage |
crm_update_commercial_policy |
writes |
A tool’s MCP annotation is not its scope. crm_preview_quote is annotated as a read tool — it stores nothing — and still requires quotes.write, because the service behind it runs under that action. Twenty-three tools are annotated read and twenty-three write, and that split does not line up with the scopes in the tables above. An agent framework that decides what to allow from the annotation alone will ask for the wrong scopes.
One tool carries more than that. crm_decide_approval is the only one marked destructive, because a decision is irreversible: there is no tool to undo one, and only the assigned approver may make it.
Approvals
| Scope | Tools | Reads or writes |
|---|---|---|
approvals.read |
crm_list_approval_definitions, crm_list_approvals, crm_get_approval_log |
reads |
approvals.manage |
crm_define_approval |
writes |
approvals.submit |
crm_submit_approval, crm_withdraw_approval |
writes |
approvals.decide |
crm_decide_approval |
writes |
Reports
| Scope | Tools | Reads or writes |
|---|---|---|
reports.read |
crm_preview_report, crm_list_reports, crm_run_report, crm_list_dashboards, crm_get_dashboard_widgets |
reads |
reports.manage |
crm_create_report, crm_create_dashboard |
writes |
Documents
| Scope | Tools | Reads or writes |
|---|---|---|
documents.read |
crm_list_document_templates |
reads |
documents.manage |
crm_create_document_template |
writes |
documents.generate |
crm_generate_document, crm_get_document_status, crm_download_document |
writes, then reads |
documents.generate covers the whole cycle, so an agent that may fetch a finished document may also ask for one. Document generation explains why the download link needs care.
What MCP does not cover
REST exposes 56 operations and MCP has 46 tools. The gap is not arbitrary: archiving a record and converting a lead have no MCP tool. An agent that needs either has to use REST, which means a second token under api.access.
Two action scopes reach neither transport. marketing.read and marketing.manage can be granted at consent and have no external endpoint at all — their only callers are the web application’s own Meta connection and notification webhooks. Treat them as reserved rather than available.
Everything else is the same
Because a tool calls the same service function as its REST counterpart, every concept on this site applies unchanged. Revisions still have to be sent back and a stale one is still refused. Idempotency, money as a decimal string, cursor paging and the module gates behave identically. The concepts pages are written once for both transports, and the modules pages describe the same rules a tool obeys.
What differs is the envelope and the connection scope. Nothing about authorization is relaxed because the caller is an agent.