MCP
Model Context Protocol
Connect Claude, ChatGPT, Cursor or any MCP client to Pixelbase and let it work in your business — customers, orders, catalog, staff and the ledger — with exactly the permissions you give it.
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, sign in when it asks, and it can read and work in your companies as part of a conversation — no copy-paste, no export.
https://www.pxb.app/mcp
It reads, and it can change what you let it. list_* tools and
get_api_resource read. The rest — create_customer, send_invoice_email,
void_invoice — change real data as you, and an assistant only sees them for
the permissions you gave it. Writes that delete, void or archive are marked so
your client asks you before running them.
Some things it can't do at all, whatever you grant: move money out of the company, change the card Pixelbase bills, buy a domain, add a billed location or mailbox, hire an AI agent, invite someone into the company, change who can reach the API, send a campaign to a whole audience, or file a legal entity. Those happen in the console, where you can see what you're agreeing to.
You decide what it can reach. Connecting an assistant opens a Pixelbase page where you choose which of your companies it may reach and how much it may do there: Read-only (it can look things up, nothing more), Can make changes (it can also create, update and send — only what you can do yourself, and never the sensitive things like access, billing or money out), or Custom, which opens the full list of permissions to pick from. It starts on Read-only, and you're only ever offered what you hold at that company. The server builds its tool list from that, so an assistant you gave customers alone is never even shown the ledger. If it later needs more, it asks you for exactly that — you don't have to hunt for settings.
Three things worth knowing before you connect:
- Calls act as you, and your own per-location access applies on top of what you granted. Lose a permission and the assistant loses it with you; leave a company and it can no longer reach that company at all.
- Your company decides whether assistants may connect at all: an admin can turn it off for everyone, and every connection to that company stops.
- Change what an assistant can do, or disconnect it, under Dev Tools → MCP. Changes apply on its next request.
- Every tool call is a public API request, so it counts toward your API usage and rate limit like any other.
Quick start
Add the server, then authenticate. Your browser opens on Pixelbase to choose which of your companies the assistant may reach and what it may do in each.
bash
claude mcp add --transport http pxb https://www.pxb.app/mcp
# then /mcp → pxb → AuthenticateClaude.ai, Cursor and other clients are on Connect an assistant.
What an assistant can read
One tool per collection, and each one appears only when you granted 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 catalog, not who is enrolled. `_count.employeeBenefits` says how many people are enrolled 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_build_deployments | Recent Vercel deployments of the platform and portals projects, newest first — every branch push, not only Builder’s. `state` is Vercel’s lifecycle word (BUILDING, READY, ERROR…); a still-building row has `buildingAt` and no `durationMs`. Pixelbase engineers only. | builder:engineer | — |
| list_build_sessions | Builder sessions — one agent working one change to the Pixelbase repository, usually from a ticket. `progress` says what it is doing in words (`phrase`) and whether the next move is yours (`awaitingReply`); `deployment` is the branch’s preview build with `elapsedMs` ticking while it builds; `pullRequests` carry state and checks health. Engineers see every session, everyone else their own and the bot’s; pass `ticketId` to get_api_resource on build-sessions to see a ticket’s whatever its owner. Read the transcript at build-sessions/<id>/messages. | builder:read | — |
| 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. Each row carries the person's own read state: `unreadCount` (what the Threads badge shows; thread replies included), `markedUnread`, `lastReadAt`, `unreadThreadCount` (threads with replies they have not opened), `isMuted`, `isFavorite`. Pass unread=true for what needs catching up on (muted conversations never count), and type, favorite or isArchived to narrow. Read one with get_conversation, its messages with list_conversation_messages, and send with send_conversation_message. | 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 whether email runs on each. | domains:read | — |
| list_email_addresses | Company mailboxes — the addresses staff send and receive from. | email:addresses:read | — |
| list_emails | Mail in the person's own mailboxes — sent to or from an address assigned to them, and nothing else; the result names the mailboxes it searched, so pass `mailbox` to pick one (support@, say) and check `searchedMailboxes` when a page is empty. Rows are summaries: who it is between, the subject, a ~300-character `snippet`, `unread`, `direction`, `threadId`. `includeText` adds the body; HTML and raw headers never come in a list. Read one message in full with get_email, or a whole back-and-forth with get_email_thread. | email:messages:read | — |
| list_email_drafts | Mail written but not sent, held in the person's Drafts. This is how an assistant writes mail: create_email_draft proposes it, the person reads it (here or in the console), and only send_email_draft — a step marked as reaching outside the company — puts it in somebody's inbox. A draft can be changed any number of times first. | email:messages:read | — |
| list_email_folders | Where mail is filed and where it arrives: the four system folders (inbox, archive, junk, trash — pass the id back as `folder` on list_emails), the company's custom folders, and `mailboxes`, the addresses assigned to this person with how much is unread in each. A mailbox missing here is one nobody has assigned them. | 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_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. Whether the list is enforced at all is the `enabled` flag beside it, not whether it is empty. | 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 address state and EIN status. A company has at most one. | 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_milestones | A themed body of work inside one project, and the level the roadmap is plotted at. Read this to name the theme a ticket belongs to; a ticket can also sit outside every milestone. | projects:read | — |
| list_newsletter_subscriptions | People who subscribed to the company newsletter. | newsletter:subscriptions:read | Required |
| list_notifications | What the platform has flagged for this person, their company and the locations they reach — the dashboard's notifications. `unread` means nobody has handled it yet. `source.kind` says which part of the product raised it (support, thread, task, order…), `source.link` opens it, and `audience` says who it was raised for. Pass `unread=true` for what still needs doing, `type` for one kind. | 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 catalog, with prices and stock. | products:read | Required |
| list_projects | The containers the company's work is filed in — one per initiative, client, release or season. A project holds its own tickets, milestones and goals; its `key` prefixes every ticket id in it (APOLLO-14). The work itself is `tickets`. | projects:read | — |
| list_tickets | The company's tracked work — what is planned, who it sits with, and where it has got to. There is one level of it: a ticket's breakdown is a checklist on the record (`subtaskCount`), not more tickets. One with a null `goalId` is in its project's backlog. Use it to answer what someone is working on or what is overdue. | projects:read | — |
| list_project_labels | Each project's own tag vocabulary. Every label names its `projectId`; pass one to list a single project's. Read it to interpret the labels on a ticket. | 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. Anything beyond weight and volume — counts, readings, pass/fail tests — is the plant's own, and hangs off the check rather than sitting on it. | quality:checks: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:actions: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:checks: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:specs: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_conversations | Every customer company's Support channel — the line between them and Pixelbase — for the support rota. `status` is whose turn it is, read off the last message: `awaiting-reply` means a customer spoke last and we owe them, `awaiting-customer` means we spoke last, `quiet` means nobody has yet, `closed` means archived. Pass `status=awaiting-reply` for the queue. Read one with get_support_conversation, which returns every message marked ours or theirs. Pixelbase staff only. | internal:support: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 `startsAt` covers only that window (in its `timezone`) rather than whole days. 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:admin | — |
| 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:admin | — |
| 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:admin | — |
| 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 | — |
| list_unread_threads | Threads this token’s employee follows that have replies they have not read — the Threads Catch-up list, most recent reply first, across every conversation they are in (muted and archived ones never appear). Each row is the thread’s root message with its `conversationId`, `replyCount`, `lastReplyAt` and `unreadReplyCount`. Read one with get_message_thread, and clear it with mark_thread_read. | threads:read | — |
| get_build_session | Builder sessions — one agent working one change to the Pixelbase repository, usually from a ticket. `progress` says what it is doing in words (`phrase`) and whether the next move is yours (`awaitingReply`); `deployment` is the branch’s preview build with `elapsedMs` ticking while it builds; `pullRequests` carry state and checks health. Engineers see every session, everyone else their own and the bot’s; pass `ticketId` to get_api_resource on build-sessions to see a ticket’s whatever its owner. Read the transcript at build-sessions/<id>/messages. | builder:read | — |
| get_conversation | 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. Each row carries the person's own read state: `unreadCount` (what the Threads badge shows; thread replies included), `markedUnread`, `lastReadAt`, `unreadThreadCount` (threads with replies they have not opened), `isMuted`, `isFavorite`. Pass unread=true for what needs catching up on (muted conversations never count), and type, favorite or isArchived to narrow. Read one with get_conversation, its messages with list_conversation_messages, and send with send_conversation_message. | threads:read | — |
| get_email | Mail in the person's own mailboxes — sent to or from an address assigned to them, and nothing else; the result names the mailboxes it searched, so pass `mailbox` to pick one (support@, say) and check `searchedMailboxes` when a page is empty. Rows are summaries: who it is between, the subject, a ~300-character `snippet`, `unread`, `direction`, `threadId`. `includeText` adds the body; HTML and raw headers never come in a list. Read one message in full with get_email, or a whole back-and-forth with get_email_thread. | email:messages:read | — |
| get_email_draft | Mail written but not sent, held in the person's Drafts. This is how an assistant writes mail: create_email_draft proposes it, the person reads it (here or in the console), and only send_email_draft — a step marked as reaching outside the company — puts it in somebody's inbox. A draft can be changed any number of times first. | email:messages:read | — |
| get_email_thread | One back-and-forth in full, oldest first, each message as text: who spoke last (`lastDirection`) says whose turn it is. | email:messages:read | — |
| get_ticket | The company's tracked work — what is planned, who it sits with, and where it has got to. There is one level of it: a ticket's breakdown is a checklist on the record (`subtaskCount`), not more tickets. One with a null `goalId` is in its project's backlog. Use it to answer what someone is working on or what is overdue. | projects:read | — |
| get_support_conversation | Every customer company's Support channel — the line between them and Pixelbase — for the support rota. `status` is whose turn it is, read off the last message: `awaiting-reply` means a customer spoke last and we owe them, `awaiting-customer` means we spoke last, `quiet` means nobody has yet, `closed` means archived. Pass `status=awaiting-reply` for the queue. Read one with get_support_conversation, which returns every message marked ours or theirs. Pixelbase staff only. | internal:support:read | — |
| list_ticket_comments | The discussion on one ticket, oldest first — the thread a person would read before replying. Mentions are inline as <@employeeId>, and mentionedEmployeeIds repeats them. Attachment urls are short-lived: read them now rather than keeping them. ticketId is the ticket’s id from list_tickets or get_ticket, not its APOLLO-14 key. To reply, comment_on_ticket. | projects:read | — |
| list_conversation_messages | A conversation’s top-level messages — a channel’s, a DM’s or a group’s. Newest first by default; pass before=<nextCursor> to go further back. To read forward from what this person has not seen, pass unreadOnly=true (starts after their own lastReadAt) or after=<messageId>; those come back oldest first, with nextCursor to hand back as after. Thread replies are not included: a message with replyCount above zero has them (read with get_message_thread), and its unreadReplyCount says how many are new to this person. Reading does not mark anything read — mark_conversation_read does. | threads:read | — |
| get_message_thread | One thread: the root message and its replies, oldest first, with when this person last read it (lastReadAt). messageId is the root’s id — a top-level message from list_conversation_messages or list_unread_threads — and the conversation must be the one it belongs to. Reading does not mark it read — mark_thread_read does. To reply in it, send_conversation_message with parentMessageId set to the root’s id. | threads:read | — |
Plus whoami, which reports the companies and what each allows, and get_api_resource, which reads a single record or any API path without a tool of its own.
What an assistant can change
One tool per write the API implements, each listed only where you granted its scope. Destructive ones are marked so your client asks before running them. Generated from the same registry as the server's catalog.
| Tool | Does | Scope |
|---|---|---|
| update_appointment_status | Update appointment status | appointments:write |
| create_appointment_availability | Create availability window | appointments:write |
| delete_appointment_availabilitydestructive | Delete availability window | appointments:write |
| create_appointment_service | Create appointment service | appointments:write |
| update_appointment_service | Update appointment service | appointments:write |
| delete_appointment_servicedestructive | Delete appointment service | appointments:write |
| create_benefit | Create a benefit | hr:write |
| update_benefit | Update a benefit | hr:write |
| delete_benefitdestructive | Delete a benefit | hr:write |
| create_blog_post | Create a blog post | blog:write |
| update_blog_post | Update a blog post | blog:write |
| delete_blog_postdestructive | Delete a blog post | blog:write |
| create_build_session | Start a build session | builder:write |
| delete_build_sessiondestructive | Delete a build session | builder:engineer |
| message_build_session | Message the agent | builder:write |
| interrupt_build_session | Stop the agent | builder:write |
| retry_build_session_start | Retry starting the agent | builder:write |
| archive_build_sessiondestructive | Archive a build session | builder:write |
| reopen_build_session | Reopen an archived session | builder:engineer |
| approve_build_session_plan | Approve the plan | builder:write |
| set_build_session_auto_mode | Set auto mode | builder:write |
| create_calendar_event | Create a calendar event | calendar:write |
| update_calendar_event | Update a calendar event | calendar:write |
| delete_calendar_eventdestructive | Delete a calendar event | calendar:write |
| rsvp_calendar_event | Answer a calendar invitation | calendar:write |
| create_call_script | Create a call script | call-scripts:write |
| update_call_script | Update a call script | call-scripts:write |
| delete_call_scriptdestructive | Delete a call script | call-scripts:write |
| create_campaign | Create a campaign | campaigns:write |
| update_campaign | Update a campaign | campaigns:write |
| delete_campaigndestructive | Delete a campaign | campaigns:write |
| update_company_settings | Update company settings | settings:write |
| submit_contact_inquiry | Send the Pixelbase team a request | inquiries:write |
| send_conversation_message | Send a message | threads:write |
| mark_conversation_read | Mark a conversation read | threads:write |
| mark_conversation_unread | Mark a conversation unread | threads:write |
| mark_thread_read | Mark a thread read | threads:write |
| create_customer | Create a customer | customers:write |
| update_customer | Update a customer | customers:write |
| set_customer_custom_fieldsdestructive | Set customer custom field values | customer:custom-fields:write |
| create_customer_custom_field | Create a customer custom field | customer:custom-fields:write |
| update_customer_custom_field | Update a customer custom field | customer:custom-fields:write |
| delete_customer_custom_fielddestructive | Delete a customer custom field | customer:custom-fields:write |
| create_department | Create a department | company-structure:write |
| update_department | Update a department | company-structure:write |
| delete_departmentdestructive | Delete a department | company-structure:write |
| create_deal | Create a deal | deals:write |
| update_deal | Update a deal | deals:write |
| delete_dealdestructive | Archive a deal | deals:write |
| move_deal | Move a deal to another stage | deals:write |
| close_dealdestructive | Win, lose or re-open a deal | deals:write |
| delete_email_addressdestructive | Delete an email address | email:addresses:write |
| update_email | Update an email | email:messages:write |
| create_email_draft | Create an email draft | email:messages:write |
| update_email_draft | Update an email draft | email:messages:write |
| delete_email_draftdestructive | Delete an email draft | email:messages:write |
| send_email_draft | Send an email draft | email:messages:write |
| create_email_folder | Create an email folder | email:messages:write |
| delete_gallery_photodestructive | Delete a gallery photo | gallery:write |
| create_invoice | Create an invoice | invoices:write |
| delete_invoicedestructive | Delete an invoice | invoices:write |
| void_invoicedestructive | Void an invoice | invoices:write |
| send_invoice_email | Email an invoice | invoices:write |
| create_job_title | Create a job title | company-structure:write |
| update_job_title | Update a job title | company-structure:write |
| delete_job_titledestructive | Delete a job title | company-structure:write |
| create_lead | Create a lead | leads:write |
| update_lead | Update a lead | leads:write |
| delete_leaddestructive | Delete a lead | leads:write |
| convert_lead | Convert a lead to a customer | leads:write |
| set_location_hoursdestructive | Update location hours | location:hours:write |
| update_location | Update a location | locations:write |
| archive_locationdestructive | Archive a location | locations:admin |
| create_meeting_room | Create a meeting room | meetings:write |
| update_meeting_room | Update a meeting room | meetings:write |
| delete_meeting_roomdestructive | Delete a meeting room | meetings:write |
| create_milestone | Create a milestone | projects:write |
| update_milestone | Update a milestone | projects:write |
| delete_milestonedestructive | Delete a milestone | projects:admin |
| delete_newsletter_subscriptiondestructive | Remove a newsletter subscription | newsletter:subscriptions:write |
| handle_notification | Mark notification as handled | notifications:write |
| update_notification_preferences | Update notification preferences | notifications:write |
| create_performance_review | Write a performance review | hr:write |
| create_product | Create a product | products:write |
| update_product | Update a product | products:write |
| delete_productdestructive | Delete a product | products:write |
| create_project | Create a project | projects:admin |
| update_project | Update a project | projects:admin |
| delete_projectdestructive | Delete a project | projects:admin |
| create_ticket | Create a ticket | projects:write |
| update_ticket | Update a ticket | projects:write |
| delete_ticketdestructive | Delete a ticket | projects:admin |
| comment_on_ticket | Comment on a ticket | projects:write |
| create_project_label | Create a project label | projects:admin |
| delete_project_labeldestructive | Delete a project label | projects:admin |
| create_qa_check | Record a QA line check | quality:checks:write |
| create_qa_corrective_action | Open or update a corrective action | quality:actions:write |
| create_qa_spec | Create or update a QA product spec | quality:specs:write |
| create_shift | Create a shift | schedule:write |
| update_shift | Update a shift | schedule:write |
| delete_shiftdestructive | Delete a shift | schedule:write |
| update_tax_filing | Update a tax filing | taxes:write |
| create_time_clock_entry | Clock in | hr:write |
| clock_out_time_clock_entry | Clock out | hr:write |
| create_time_off_request | Request time off | hr:write |
| review_time_off_request | Approve or deny time off | hr:write |
| cancel_time_off_requestdestructive | Withdraw a time-off request | hr:write |
| create_vault_document | Create a Vault document or folder | vault:admin |
| update_vault_document | Update a Vault document | vault:admin |
| delete_vault_documentdestructive | Archive or delete a Vault document | vault:admin |
| create_transaction | Record a transaction | transactions:write |
| update_transaction | Update a transaction | transactions:write |
| delete_transactiondestructive | Void a transaction | transactions:admin |
| mark_transaction_paid | Mark a transaction paid | transactions:write |
Never offered, whatever you grant — these happen in the console:
email.create— sends an email with no draft for the person to read firstpayout.create— moves money out of the companypayment-method.set-default— changes the card Pixelbase billsdomain.create— buys a domainlocation.create— adds a monthly location feeemail-address.create— adds a billed mailboxagent.create— hires an agent that bills by the houragent.update— changes an agent’s billed hoursagent.delete— removes a hired agentip-whitelist.create— changes who can reach the APIip-whitelist.delete— changes who can reach the APIemployee-invitation.create— invites somebody into the companyemployee-invitation.delete— withdraws an invitationcampaign.send— messages a whole audience of customerslegal-entity.create— files a legal entitylegal-entity.amend— amends a legal filing
Topics
Connect an assistant
Setup for Claude Code, Claude.ai, Cursor, and anything else that speaks MCP.
Tools
How the tools are shaped: reads, writes, and the two that are neither.
Asking for more access
The permission modes, and the one link an assistant hands you when it needs more.
Search mode
Starting with a few tools that find the rest, instead of every schema.
Builder
Driving the agent that works the Pixelbase repository, for Pixelbase staff.
Support
Watching the support inbox, the Support channels and the dashboard for the rota.
Threads
Reading channels, DMs and group chats, catching up on unread, and marking them read.
Locations
Why some tools ask which location, and when they stop asking.
When Pixelbase can’t do it
Sending the Pixelbase team a request instead of dead-ending.
Limits and cost
Rate limits, token lifetime, and what a tool call costs.
Errors
What the failures mean.
For agents
The whole reference as one document, so an agent can read it in a single fetch.
bash
curl https://www.pxb.app/docs/mcp/docs.md
curl https://www.pxb.app/docs/mcp/docs.json