Model Context Protocol
Connect Claude, ChatGPT, Cursor or any MCP client to Pixelbase and let it read your business — customers, orders, catalogue, staff and the ledger — with an API token you control.
The Model Context Protocol is how an AI assistant connects to a system it wasn't built with. Point Claude, ChatGPT, Cursor or any other MCP client at the endpoint below, give it a Pixelbase API token, and it can read your company's data as part of a conversation — no copy-paste, no export.
https://www.pxb.app/api/mcp
Everything here is read-only. The tools list and fetch; none of them create, change, or delete anything. An assistant can tell you what last week's orders came to; it cannot issue a refund.
Access is exactly the access the token was granted. The server builds its tool list per connection from the token's scopes, so an assistant holding a customers-only token is never even shown the ledger. To narrow what an assistant can see, create an API client with fewer scopes — that is the whole control surface, and it is the same one the API and the CLI use.
Two things worth knowing before you connect:
- Calls act as the employee who created the API client, and that person's own per-location access applies on top of the token's scopes.
- Every tool call is a public API request, so it counts toward your API usage and rate limit like any other.
Quick start
Create an API client on the /dev-tools page, exchange its credentials for a token, and hand it to your assistant.
claude mcp add --transport http pixelbase https://www.pxb.app/api/mcp \
--header "Authorization: Bearer $PXB_TOKEN"Other clients, and how to get the token, are on Connect an assistant.
What an assistant can read
One tool per collection, and each one appears only when the token carries its scope. This table is generated from the same registry the server builds its tools from, so it can't fall out of step.
| Tool | Returns | Scope | Location |
|---|---|---|---|
| list_agents | The AI agents the company has hired, one per role at most. `minutesAccrued` is what each has worked this cycle. | agents:read | — |
| list_appointments | Booked appointments at one location — who is coming, for which service, and when. | appointments:read | Required |
| list_appointment_availability | The weekly windows a location accepts appointments in. Read this before reasoning about whether a time is bookable. | appointments:read | Required |
| list_appointment_services | The services a location can be booked for, with their duration and price. | appointments:read | Required |
| list_audit_logs | The security audit trail: who did what in this company and when. Reach for it to answer "who changed this" rather than to read the records themselves. | security:read | — |
| list_benefits | The benefits the company offers — the catalogue, not who is enrolled. `employeeCount` says how many people are in each. | hr:read | — |
| list_blog_posts | Posts on a location's public blog. An unpublished post is a draft and is not live on the site. | blog:read | Required |
| list_calendar_events | What is on the company's calendar — meetings, reviews and time blocks, with who was invited and whether they accepted. A recurring event is one record carrying its rule, not one per occurrence. | calendar:read | — |
| list_call_scripts | The branching scripts reps follow on a call at one location. `_count.runs` says how often each has actually been used. | call-scripts:read | Required |
| list_campaigns | Marketing sends — one message written once and sent to an audience of a location's customers. `status` says where it is between drafted and sent; an SMS one also waits on a carrier registration. | campaigns:read | Required |
| list_conversations | The channels, DMs and group chats this token's employee belongs to. Membership is the access rule, so this is their inbox rather than the company's — a channel they are not in is simply absent. | threads:read | — |
| list_customers | A location's customers — the people it sells to or serves. This is the CRM record: name, contact details, and status. | customers:read | Required |
| list_customer_custom_fields | The extra fields this location defines on its customers. Read it to interpret custom values on a customer record. | customer:custom-fields:read | Required |
| list_departments | How the company divides its staff — the departments employees belong to. | company-structure:read | — |
| list_deals | Potential sales moving through a location's pipeline — the cards on the kanban board. `value` is cents. Read `get_api_resource` on pipelines first if you need the stage ids. | deals:read | Required |
| list_domains | Domain names the company has registered or connected, and their status. | domains:read | — |
| list_email_addresses | Company mailboxes — the addresses staff send and receive from. | email:addresses:read | — |
| list_emails | Mail in the token employee's own mailboxes — sent to or from an address they own, and nothing else. `threadId` groups a back-and-forth. | email:messages:read | — |
| list_email_folders | The company's custom mail folders. The system ones — archive, junk, trash — are literal values on a message rather than rows here. | email:messages:read | — |
| list_employees | The people who work for the company, with their status and role. Not customers — those are `list_customers`. | employees:read | — |
| list_employee_invitations | Outstanding invitations to join the company as an employee. | employee:invitations:read | — |
| list_employee_onboardings | Where each new hire has got to in onboarding. | employee:onboardings:read | — |
| list_epics | The company's own named groupings of work. Read this to name the theme a piece of work belongs to; work can also sit outside every epic. | projects:read | — |
| list_gallery_photos | Photos published on a location's public page. | gallery:read | Required |
| list_invoices | Invoices the company has issued to its customers, with what each is for and whether it has been paid. `dueNowAmount` is the deposit collected on the first visit to the pay link. Not what the company owes — that is `list_payables`. | invoices:read | — |
| list_ip_whitelist_entries | The IP addresses allowed to reach this company on the API. An empty list means no restriction is in force. | security:read | — |
| list_job_titles | The job titles the company defines, which employees are assigned to. | company-structure:read | — |
| list_leads | Prospects a location has contact details for but no relationship with yet. A lead with an `accountId` has already become a customer; the customer record is the one to read from then on. | leads:read | Required |
| list_legal_entities | The registered companies behind the business — LLCs and corporations, with their formation state and EIN status. One company can own several. | settings:read | — |
| list_location_hours | One location's opening times for the week. | location:hours:read | Required |
| list_locations | The places the company operates from. Call this first: every location-scoped tool needs one of these ids. | locations:read | — |
| list_meeting_recordings | Recordings of meetings the token can reach, newest first. They live with the video provider rather than in the database, so this is a slower read than most. | meetings:read | — |
| list_meeting_rooms | Video meeting rooms — scheduled or recurring — with who is invited and where each stands. A HUDDLE room is a one-off call started from a conversation rather than a scheduled meeting. | meetings:read | — |
| list_newsletter_subscriptions | People who subscribed to the company newsletter. | newsletter:subscriptions:read | Required |
| list_notifications | Notifications raised for the company — what the platform has flagged recently. | notifications:read | — |
| list_orders | Sales orders placed at a location — what was bought, by whom, and what it came to. | orders:read | Required |
| list_payment_methods | The cards on file that Pixelbase bills this company on. Not the customer payment methods behind an order — those live on the order. | billing:read | — |
| list_payables | Bills the company still owes — expenses and deductions that have not settled. Reach for it to answer what is going out, and by when. | payables:read | — |
| list_payouts | Money moved out of a legal entity's Stripe balance to its bank account. Needs a `legalEntityId`: a payout only means something against the account it left. | payouts:read | — |
| list_performance_reviews | Performance reviews, kept as history so somebody's progress can be read across review dates. A DRAFT has not been shared with the person it is about. | hr:read | — |
| list_products | What a location sells: its catalogue, with prices and stock. | products:read | Required |
| list_projects | The company's tracked work — what is planned, who owns it, and where it has got to. A record with a `parentId` is a subtask of that project. Use it to answer what someone is working on or what is overdue. | projects:read | — |
| list_project_labels | The tag vocabulary projects are labelled with, shared company-wide. Read it to interpret the labels on a project. | projects:read | — |
| list_qa_checks | Quality line checks — the periodic measurements taken on a production line. `status` is computed against the shift session's spec, so OUT_OF_TOLERANCE means the spec said so. | quality:read | Required |
| list_qa_corrective_actions | What was done about a quality problem: the issue, the suspected cause, the action taken, and whether it is closed. `category` is what the Pareto of recurring failure modes counts. | quality:read | Required |
| list_qa_shift_sessions | One run of one production line against one product spec — the thing every line check hangs off. A SIGNED_OFF session takes no more checks. | quality:read | Required |
| list_qa_specs | Product specifications: the target weight and volume and the tolerance bands a line check is judged against. Read one before interpreting a check. | quality:read | Required |
| list_shifts | The planned work schedule: who is covering a location, and when. Not hours actually worked — that is `list_time_clock_entries`. | schedule:read | — |
| list_support_cases | Support cases the company has opened with Pixelbase, and where each one stands. | support:cases:read | — |
| list_tax_filings | Tax returns the company has prepared, and how far each has got — drafted, reviewed, filed, accepted. One per legal entity, year and form type. | taxes:read | — |
| list_time_clock_entries | Hours actually worked: clock-in and clock-out records. An entry with a null `clockOutAt` is somebody currently on the clock. | hr:read | — |
| list_time_off_requests | Who is away and when, plus what is still waiting on a decision. A request with a null `reviewedById` but an APPROVED status was auto-approved — the requester has no manager to wait on. | hr:read | — |
| list_vault_credentials | Stored passwords, cards, API keys and notes — metadata only. The secret itself is never in a list; fetch one by id to reveal it, which is audited. | vault:read | — |
| list_vault_documents | Files, folders, documents and spreadsheets in the company Vault. What comes back is filtered per item — a folder mirroring a Threads channel is visible only to its members — so a count here is what this token may actually open. | vault:read | — |
| list_vault_folders | Every Vault folder the token can reach, flat — assemble the tree from `parentId`. `systemType` marks the folders the platform manages itself. | vault:read | — |
| list_transactions | Money in and out — the ledger. Each record carries an amount in cents, a type, a status, and its IRS category. | transactions:read | — |
Plus whoami, which reports the company and the granted scopes, and get_api_resource, which reads a single record or any API path without a tool of its own.
Topics
For agents
The whole reference as one document, so an agent can read it in a single fetch.
curl https://www.pxb.app/docs/mcp/docs.md
curl https://www.pxb.app/docs/mcp/docs.json