Connect your development tool to a Cedros site through MCP (Model Context Protocol) so it can discover the site's supported tools, inspect current data, and make the changes you request. Use the authenticated connection's current tool schemas when developing a workflow.
This guide covers connection setup, discovery, and a read-only first request. For creating, replacing, or revoking access keys, use Connecting an external AI tool to Cedros.
Get the connection values for your site
Open Settings → Assistant → MCP on the site you intend to work with, then select Set up MCP. Choose the development client that will actually run the connection. Use Other MCP if it is not listed.
For site development, choose Site tools access. This allows the site tools covered by the key's permissions; it is not automatically read-only. The Assistant conversations option is for a different purpose and does not provide general site-editing access.
The setup supplies three values:
- MCP URL: the site's remote Streamable HTTP endpoint, ending in
/mcp. - Server name: the connection's name in your development client.
- Credential variable: the environment-variable name the client uses to obtain the key.
Copy the values from your own site's setup. Do not substitute the admin-page URL, another site's endpoint, or a variable name from an unrelated example. A local development checkout does not determine which live site the client will change.
Cedros's personal MCP-key connection uses a bearer credential. Configure the client for that authentication method rather than starting an OAuth sign-in for this connection. The key supplies its identity and permissions; do not add guessed user or organization headers.
Use a clearly labeled key for each machine or client. Keep its value outside chat, source control, logs, and screenshots. Cedros shows a newly created key only once; the key-management guide explains how to replace one you can no longer retrieve.
Configure the client that will run the work
Follow the generated instructions for your selected client. The site's /connect.md is its public connection reference; Cedros's connection reference shows the supported formats. Use the reference and connection values from the same site.
- Supply the key through the private prompt or secure credential mechanism shown in setup. Do this on the machine where the MCP client runs.
- Add the displayed configuration to the indicated file or client settings. Merge the named server entry while preserving existing connections and intentional tool restrictions.
- Make the credential available to the process that launches the client. A variable set in one terminal may not reach a desktop app, another session, or a remote development environment.
- Restart or reconnect the client, then inspect its MCP status and available tools. A valid configuration file alone does not prove the running client loaded it.
The generated configuration references the credential; the reference is not the key itself. If setup offers a terminal command that stores the credential, follow that path. Otherwise, arrange secure persistence in the environment that launches the client. Setting a variable for the current terminal does not automatically make it available tomorrow.
If the client helps configure itself, give it the setup prompt from Let the client configure itself and keep the credential step separate. It should confirm that the variable is present without printing its value.
Discover the site's current tools and schemas
Once connected, have the client read the site's /skill.md and its linked operator guide. The Cedros entry point explains the available paths; the Admin Site Operator guide describes live-site work.
Use the authenticated MCP connection for exact names, inputs, permissions, and available operations:
- Let the client initialize the MCP connection and inspect
resources/list. - For a site-tools connection, start with
cedros://admin/areaswhen it is listed. Read the area relevant to your task, then follow its link to the narrowest matching section. - Read that section's tool definitions and the relevant authenticated
tools/listentries. Use the returned input schema before calling a tool. - If you need help with an admin page, use the page-guide resources advertised by the server and select the relevant guide.
- Refresh discovery after changing credentials, permissions, installed extensions, or the deployed version, or when a call no longer matches the schema.
Some clients expose tools through search or deferred discovery rather than showing the entire catalog at once. Search the configured Cedros connection before treating a short tool list as missing functionality. If your client does not expose resources, use its tool discovery and the site's public operator guide for orientation.
Resource URIs beginning with cedros:// are read through MCP; they are not ordinary browser links. Read the URIs returned by discovery rather than inventing paths.
A public tool description does not grant access. The authenticated connection may have a narrower catalog because of permissions, key restrictions, enabled features, or installed extensions. A credential limited to a task or another specialized purpose is not a replacement for a site-tools key.
Extension operations can be exposed through cedros.extension_capabilities.list and cedros.extension_capabilities.execute. Discover their current schemas and returned capabilities; do not assume every extension has a separate top-level tool for each action.
Prove access with a read-only request
Begin with a small request whose result you can recognize. For example:
Use this Cedros connection to list the titles and routes of up to five published documentation articles. Read the current tool schema first. Do not create, edit, publish, send, or delete anything, and do not call AI generation or review tools.
When your connection exposes cedros.docs.overview.list with the matching schema, its arguments are:
{
"status": "published",
"limit": 5
}
This is the tool's arguments object, not an MCP client configuration file. Your client supplies it to the discovered tool. If the site has no published docs, an empty successful result is valid; use another permitted read operation to check recognizable site data if needed.
Check the returned status and any tool error, as well as the content. A transport connection or an HTTP success response alone does not establish that the requested tool succeeded. Confirm that the results belong to the intended site.
Back in Settings → Assistant → MCP, the key's last used time records authentication by a client. An open setup dialog can show MCP access confirmed. The initial “key created and accepted” check only verifies the new credential; it does not prove your development client is configured. Likewise, recent key use does not prove every tool is permitted.
The Coding sessions list is separate. A client can connect and read tools without registering a coding session, so an empty list is not evidence of a failed connection.
Move from inspection to deliberate changes
Read the target's current state before requesting an edit. Use its dedicated page or feature tools and follow the returned schema, review requirements, and confirmation fields. Review the saved result before a consequential release, then read back the actual outcome.
For content work, ask for a draft and inspect the saved preview before requesting publication. See Understanding drafts, previews, and publishing. Other operations, including sending a message or installing an extension, have their own effects; a client-side approval prompt does not make them drafts.
Keep development and production connections clearly named. Use a separate test site when testing new behavior or changes that affect data. Creating local files or committing code does not publish a page or install an extension on the connected site.
MCP access and AI services are separate. Your development client may charge for its own processing. Calling Cedros generation, assistant, or AI Review tools can also charge the site's configured provider. Tool discovery, direct reads, saved previews, and release-readiness checks do not require a fresh AI review.
Troubleshoot the failing layer
The connection asks for sign-in or returns an authentication error. Check the site's MCP URL, bearer configuration, credential-variable name, and key expiry or revocation. Confirm the variable exists in the launching process without printing it. Restart or reconnect after correcting the environment.
The client connects, but the tool is missing. Check the selected key access, the client's tool filters, and deferred discovery. Refresh the running session's catalog after a relevant change. Also check whether the feature or extension is available on that site. Preserve intentional restrictions.
The tool returns permission denied. Ask the site administrator to review the required permission and the key's granted access. Authentication and authorization are different checks. Do not switch to an unrelated credential or a broader tool to get around the denial.
Arguments are rejected. Read the tool's current input schema and compare required fields, names, and allowed values. Do not rely on a copied example from another site or version. Check whether the client is using stale discovery.
A configuration change seems to have no effect. Confirm which client, project, and machine are running the request. Reconnect or refresh its MCP status where supported. If the session still has the old configuration or catalog, start a fresh session and repeat the small read-only check.
When asking for help, include the client name and version, site address, connection name, key label, exact error, and whether a read-only call succeeded. Remove credentials and private response data from the evidence.