Finding API and capability reference

Use the reference published by the Cedros site you are connecting to. Its running version, enabled extensions, and your permissions determine which operations you can use. A tool or endpoint described on another site may have a different contract.

The links below open Cedros's own references. For another Cedros installation, use the corresponding paths on that site's origin. Keep development and production connections clearly separated.

Choose the reference for your task

• Explore the platform: start with the discovery guide. It links to operating guides, authoring material, schemas, and machine-readable discovery.
• Operate a site through MCP: use your authenticated session's tools and resource schemas. These describe the operations available to that connection.
• Build a direct HTTP integration: use the site's OpenAPI specification for documented methods, paths, request bodies, and responses.
• Understand an admin page: use the page-guide index, select a section, then open the specific page guide.
• Build an extension: use the extension authoring reference and the schemas for your package and supported host interface.

These references serve different purposes. OpenAPI is the lower-level HTTP specification; it is not a replacement for the MCP admin tool catalog. An extension manifest describes a package's contributions and requirements; it is not a list of operations your account may execute.

Find an MCP tool and read its schema

If you have not connected a client, follow Connecting a development tool to Cedros through MCP.

With an authenticated site-tools connection:

1. Let the client initialize, then inspect the resources advertised by resources/list.
2. Read cedros://admin/areas to find the relevant area.
3. Follow that area's resource link, then choose the narrowest section matching your task. The section provides exact tool schemas; the higher-level lists provide navigation.
4. Read the chosen tool's description and input schema. Check required fields, allowed values, target identifiers, permissions, and any confirmation or review prerequisite.
5. Start with the appropriate read operation to identify the target and its current state before preparing a change.

For example, page work follows the content area to its pages section. Follow the returned links rather than constructing a tool name from the page's label. Your client may also expose the authenticated tools/list catalog directly.

MCP resource URIs beginning with cedros:// are read through the connected client's resource interface; they are not ordinary browser links. If your client loads tools on demand, use its tool search or discovery controls to load the returned operation.

Read the effect of the operation as well as its field types. Saving a setting, sending a message, and publishing a document have different consequences. MCP permissions and publishing controls explains access, review requirements, confirmations, and paid AI actions.

Discover operations supplied by extensions

An installed extension can expose capabilities through the shared extension tools without creating a separate top-level MCP tool for every operation.

Call cedros.extension_capabilities.list to read the installed capability metadata and schemas. For the operation you need, inspect its extension ID, capability ID, description, input schema, and output schema. Check whether it reads state or changes something before executing it.

For example, Cedros Pay exposes catalog operations through this discovery path. Failing to find a top-level product tool does not establish that product management is unavailable; inspect the installed capability list.

When execution is authorized, use the current schema for cedros.extension_capabilities.execute. It accepts the selected capabilityId, an input object matching that capability's schema, and the required confirmation. The current confirmation format is execute:<capabilityId>; use the exact discovered ID.

Listing capabilities does not execute them. A listed capability still requires the caller's permissions and any extension-specific prerequisites. Inspect returned errors and resulting state rather than treating discovery, a confirmation string, or an HTTP success status as proof that the requested action completed.

Use OpenAPI for direct HTTP clients

Open the site's OpenAPI JSON in an editor or API tool. Find the documented path and method, then follow any schema references for its request and response. Check authentication requirements, required headers, pagination, and error responses for that operation.

An operation's name does not determine its HTTP method. For example, the documented entry-query operation uses POST /entries/query with a JSON request body. Do not turn an MCP name into a guessed URL or assume every read uses GET.

Use the authentication mechanism documented for the HTTP endpoint. A working MCP connection does not establish that its credential is accepted by every other API. Keep credentials out of URLs, example files, screenshots, and support logs.

For an extension-owned operation, use its published capability or route contract. If the required operation is absent from the relevant reference, confirm support with the extension publisher or site administrator before building around an undocumented route.

Look up a specific admin workflow

The page-guide index groups guides by section. Each section entry includes a publicPath for browsers and a resourceUri for MCP clients. Open one section, match the page title or admin path, then follow the guide it returns.

For example, the Site section reference contains the guide for the Docs admin page, as well as separate editing guides. Choose the overview when you need to find an article and the editing guide when you need to change it.

In MCP, the equivalent starting point is cedros://admin/page-docs. Section and page resource templates are advertised by resources/templates/list. Substitute a section key or slug returned by discovery, rather than guessing one from a navigation label.

A page guide explains a workflow; it does not grant access or guarantee that the page is enabled on your site. Use it alongside the current interface and authenticated tool schemas.

Find extension schemas and runtime contracts

Use the extension manifest schema to validate package metadata such as identity, compatibility, declared surfaces, and requested access. For runtime behavior, follow the authoring reference for the specific server, storage, provider, or UI contract you use.

The Extension Context schema describes the shared authoring and handoff document used during extension development. It is not the authenticated identity object passed to a server route. Use the server backend reference for that request context.

For reproducible builds, record the authoring kit version, relevant schema or interface version, and the host you tested. A latest reference can change; retain the matching kit and compatibility information with your release. A valid manifest alone does not prove that its declared features are implemented or available on the target host.

Resolve a missing or changed operation

The tool is absent: confirm the site connection, refresh authenticated discovery, and inspect the client's tool filters. Check your credential's scope and whether the required extension or feature is enabled. Public discovery can describe more than your session is permitted to use.

The schema differs from an example: use the current target site's contract and check the version associated with the example. Do not remove an unknown field or add a guessed one just to get past validation; understand which behavior the current operation supports.

The request is denied: review the required permission and ask the administrator to confirm the intended access. A generic data endpoint or another account's key is not a workaround for a denied operation.

The result is uncertain: read the target's current state before retrying a write. A timeout can occur after work has completed, especially when another service is involved.

When requesting help, include the site, tool or endpoint, relevant version, exact error, and intended result. Remove credentials and private record contents. This gives the administrator or publisher enough context to distinguish a connection problem, an access restriction, and an unsupported contract.