MCP servers

Bizisy runs two MCP servers. Every action is a tool on the server of its audience, so an AI assistant can do in Bizisy what its person can do, with their permissions, and nothing else.

Addresses#

Both use the Streamable HTTP transport. Signing in is the way for people (no key to copy, nothing to paste but the address); keys suit apps that can't sign in, and your own agents.

What the servers give an assistant#

• Tools: one per action the person's role allows, named like the action with underscores (org.people.hire → org_people_hire). The list is filtered per caller: a viewer's assistant never sees org_people_hire. Write tools take dry_run. See Tools.
• Skills: procedures written for assistants (setting up a company, managing people, webhooks, …), served as MCP resources such as skill://org/setup-company. See Skills.
• Instructions: read platform_whoami first, read before writing, preview every change with dry_run, show it and commit only after the person agrees, and show the person the link to check it in Bizisy.

Results#

Tool results are JSON with the action's output and, for changes and previews, view_url: the change's entry in Activity on the company address. The text ends with "View in Bizisy: " so the assistant can offer it. Errors come back as tool errors with the same code, message and hint as the REST API.

The same rules as everywhere#

• Each tool call counts against the rate limit of the key or connection.
• An assistant is a machine: no other people's private or pay data, and approving, pay and a few settings stay in the web app.
• Every change, preview and failed attempt is recorded in Activity with the app's or key's name.