Skip to content

Put your whole product in your agent's reach.

ProductClient speaks the Model Context Protocol. Point Claude Code, Cursor, or any client that takes a URL and a header at your workspace, and it can ship a release, answer the feedback, fix the docs, and publish the status note.

Connect an agent See all 59 tools
Any MCP client
{
  "mcpServers": {
    "productclient": {
      "url": "https://productclient.com/api/mcp/pc",
      "headers": {
        "Authorization": "Bearer pc_live_..."
      }
    }
  }
}

Nothing to install. One endpoint, one header.

Two servers, one contract.

One for your workspace, behind your token. One open to the world, for anyone building on what you already published.

Your workspace

59 tools · Bearer token required

Everything the pc CLI can do, for the agent instead of your terminal: work feedback, ship releases, write docs, open and close incidents, publish a status note.

Endpoint for Your workspace
https://productclient.com/api/mcp/pc

Read-only, no auth

6 tools · no token

Your public product surfaces, readable by any agent with no token at all: listings, docs, releases, roadmap, and status. Drafts and unpublished pages are unreachable by design.

Endpoint for Read-only, no auth
https://productclient.com/api/mcp/product

Connected in three steps.

One command mints the token, one block of config points your client at us, and then you just ask.

  1. 1

    Mint a token

    Run pc login and approve the device code in the browser. The token belongs to your workspace, not to the machine, so give each agent its own.

    In your terminal
    pc login
  2. 2

    Point your client at us

    Add the server wherever your client keeps its MCP configuration, with your token as the Authorization header. Leave the header off to connect to the public server instead.

    MCP client configuration 
    {
  "mcpServers": {
    "productclient": {
      "url": "https://productclient.com/api/mcp/pc",
      "headers": {
        "Authorization": "Bearer pc_live_..."
      }
    }
  }
}
  3. 3

    Ask for something real

    Start with a question the workspace can actually answer, then let it act. Every answer comes from your data, and every change is one you could have made yourself in the dashboard.

    Try asking

    • “What did customers ask for this week, and which requests are leading?”
    • “Ship v1.4 from this PR and write the changelog entry.”
    • “Read the docs on the API keys page and report anything out of date.”

The job, not the API.

59 tools on the authenticated server, grouped the way you would actually ask for them.

Work the feedback

Read what came in, file what a customer asked for, look the customer up, reply in the thread, and move it along the roadmap.

  • feedback
  • file_feedback
  • customer_lookup
  • inbox
  • reply
  • triage

Ship the release

Match a change to a roadmap item, ship it, read how it landed, roll it back, or publish a coming-soon. Re-shipping the same version is idempotent.

  • roadmap
  • ship
  • ship_insights
  • rollback
  • coming
  • launch

Keep the status current

Draft the announcement, publish the note to the feed, and read the public status with its incident timeline.

  • announce
  • post_note
  • get_status
  • incident_updates

Fix the docs

Create or update a page in the workspace draft, and report a wrong or outdated page back to you instead of guessing.

  • docs_upsert_page
  • doc_feedback

Run the incident

Open an incident, post public updates as it moves, and close it with the note customers read.

  • incident_open
  • incident_update
  • incident_close

Know the workspace

Who the token belongs to, which products it reaches, who is on the team, which sessions are live, and what changed.

  • whoami
  • products
  • product_context
  • team_list
  • tokens
  • logout
  • diff
  • inspect

The public server needs no token at all.

Anyone can read what you already published: your product, your docs, your releases, your roadmap, your status. Drafts and unpublished pages stay out of reach by design, so pointing an agent here is safe to do before you trust it with a token.

Public endpoint
https://productclient.com/api/mcp/product
Public client configuration 
{
  "mcpServers": {
    "productclient-public": {
      "url": "https://productclient.com/api/mcp/product"
    }
  }
}
  • get_product
  • list_products
  • search_docs
  • list_releases
  • get_roadmap
  • get_status

Your agent, working on the product.

Mint a token and hand it the work you keep meaning to get to. Revoke it whenever you like.

Get started Read the API docs

Questions, answered.

The six things people ask before they hand an agent the keys.

A remote Model Context Protocol server for your workspace. Point an AI agent at our endpoint with your token and it can work the same surfaces you do: feedback, releases, roadmap, docs, incidents, and status. There are 59 tools on the authenticated server and 6 on the public read-only one.

No. There is no package, bridge process, or SDK to run. You give your client the endpoint and a token, and it talks to us directly.

Any client that can reach a remote MCP server over HTTP and send a custom Authorization header. The endpoint and header are all that is special about it.

Only the workspace your token belongs to, and only the products in it. Every tool re-checks ownership on each call, so another maker is unreachable even if the agent asks for one.

Yes. A token is read and write, exactly like signing in to the CLI. Give each agent its own token, keep a test product for new workflows, and revoke anything you are done with using the tokens and logout tools.

Use MCP inside an AI client and the CLI in your terminal. They share the same tokens, the same tools, and the same permissions, so a workflow you trust in one is safe in the other.

Same tokens, same tools, same permissions as the pc CLI.