Once configured, you can use natural language to explore your GUIDEcx data and take actions, including these examples:

The MCP server runs locally and communicates with GUIDEcx over the v3 API. Read more in our API documentation here: https://api.guidecx.com/docs/#overview

You will need:

GUIDEcx's API is REST-based, accepts JSON request bodies, returns JSON responses, and uses standard HTTP methods and status codes.

The architecture is simple:

Your MCP server holds the GUIDEcx credential locally and adds it to API requests as a Bearer token.

The token should live only in a local .env file:

Your .env file should always be excluded from source control.

Keeping the MCP server local means you do not need to expose your own MCP endpoint publicly. The server can communicate with the model over a local stdio connection while making authenticated HTTPS requests to GUIDEcx.

One important distinction: your API token can remain local, but GUIDEcx data returned by an MCP tool may be provided to the model as context when you ask it to work with that data. Follow your organization's policies for using customer or project data with AI tools.

Quick note on Privacy: Most free tiers, or even minor paid plans for popular models like Claude, Codex, and Gemini, have varying degrees of security outlined in their Privacy Policies. We would highly recommend reading through the privacy of the model of your choice before beginning setup.

Create a new local directory for the integration and open it as your model workspace.

Then give the model the following prompt exactly as written:

Your model should inspect the current v3 API documentation as it builds the server rather than relying on assumptions about endpoint paths or request schemas.

After the model creates the project, create the local .env file described in the generated README.

It should look like:

Do not add the token to .env.example.

Your .gitignore should contain:

For additional protection on macOS or Linux, you can restrict access to the credential file:

Before making any GUIDEcx request, the server should verify that the token exists without ever printing its value.

If you find the value for your API token is visible, we’d recommend deleting it, creating a new one, and verifying in your setup that it is not printed.

A simple project request is a good first API test:

A successful request returns a 2xx response. A 401 usually indicates an authentication problem, while 403 means the authenticated token does not have access to the requested resource. GUIDEcx also uses 400, 404, 422, 429, and standard 5xx responses for other error conditions.

The MCP project's automated test suite should use mocked API responses, not your production GUIDEcx workspace.

Run the test command your model adds to the project's README before connecting the server to live data.

After the server builds successfully, register it with your model as a local MCP server.

The exact Node entry point depends on the project your model generated. A typical compiled Node.js server would be registered like this:

For example: Codex supports registering local stdio MCP servers using the codex mcp add <name> -- <command> pattern.

Then verify that the model sees it:

Use the absolute path to your server rather than relying on the directory from which the model happens to launch.

Your implementation should also load .env relative to the MCP server's own directory rather than assuming the current shell directory contains the file.

Restart your model after changing the MCP configuration if necessary.

Start with read-only requests:

Once those work, test a controlled write:

Then explicitly authorize it:

For project messages, the MCP implementation should default to internal-only unless you specifically request a customer-visible message.

A reliable MCP implementation should account for a few behaviors documented in the GUIDEcx v3 API.

Pagination. GUIDEcx uses limit and offset parameters when returning collections. Responses include metadata containing the total number of records, limit, and offset.

Your MCP server should paginate when necessary rather than assuming the first response contains every project, task, member, or other record.

Rate limits. GUIDEcx uses rate limiting and returns X-RateLimit-Limit, X-RateLimit-Remaining, and X-RateLimit-Reset headers. If the API returns 429 Too Many Requests, the server should honor the Retry-After header and retry conservatively. GUIDEcx also recommends exponential backoff, caching frequently accessed data, and avoiding unnecessary individual requests.

Errors. GUIDEcx API errors use a consistent response containing a code, message, and HTTP status. Your MCP server should return useful errors to your model without dumping complete HTTP headers, environment variables, or authentication credentials into its output.

Keep the MCP server intentionally narrow.

The GUIDEcx API token identifies your workspace or user access and grants API access accordingly, so anyone who obtains it should be treated as having the same API privileges as that credential.

Once connected, your model can combine GUIDEcx API operations with its ability to reason over structured data.

That means a request can go beyond a single API call. For example:

Or:

For any workflow that writes to GUIDEcx, review the proposed action before approving it.

For the complete API reference and current request schemas, use the GUIDEcx v3 API documentation provided above.