Shared Mockarty

Every Space in Mockarty Cloud has a home on the shared Mockarty: a full Mockarty engine where your Space is a namespace of its own. You reach it from the cabinet in one click and work there with your cabinet identity — there is no second password.

Open Mockarty

1. Select the Space.
2. Open Mockarty in the cloud. The Your Mockarty card shows the namespace, the modules and the seats your plan grants, and the sync status.
3. Press Open Mockarty. Mockarty opens in a new tab, already signed in and switched to your Space’s namespace.

The same button is also the first step on the Overview tab and sits on the Mockarty in the cloud card under Runtime.

The button hands the browser a one-time sign-in code that lives for 60 seconds. Who you are travels between the cabinet and Mockarty server to server, never in the address bar, so the link cannot be copied to somebody else and a used link cannot be reused.

What follows your plan

• Members. Everyone in the Space is a member of its namespace. Owners and admins administer the namespace, editors work in it, viewers and billing managers read.
• Modules. Work in a module requires both the Space’s current plan and the member’s own current licence. A Free guest in a Pro Space keeps Free modules; a Pro guest in a Free Space cannot raise that Space’s plan.
• Seats. Personal Spaces follow their current host cap. A paid Team uses one purchased package of 5, 10 or 20 named Seats across all its Spaces. Joining another Space of the same Team does not consume another Seat. A removed or suspended Team member cannot use that Team’s shared node.

When payment, membership or a role changes, the cabinet applies the difference to Mockarty within a minute. A new sign-in waits for the current state to be applied, so it cannot open using an older paid grant. The card shows Ready, Being prepared or Sync failed; an inactive Team subscription closes access to its shared namespaces while retaining their data.

Module access on the shared node is refreshed by the Cloud frequently. If that connection stays unavailable, paid module access ends after a short grant window even in a session that is already open; reconnecting restores it when the subscription is still active.

Mock stock

Your plan gives the Space a fixed number of places for live mocks — the mock stock. Creating or importing a mock takes one place; how many places the plan holds is described in Cloud Spaces.

Deleting a mock gives its place back at once. The mock moves to the recycle bin, and the freed place is immediately available to a new mock — created on the shared node, sent by Desktop sync, or made by any other client working in the Space. Deleting a mock folder frees every mock that was inside it in one step.

Restoring works the other way round: every mock you bring back from the recycle bin needs a free place at that moment. When the account has none left, Mockarty refuses the restore, nothing is reopened, and the mocks stay in the recycle bin.

When the limit is full

If a change is refused because the mock stock is full, Mockarty shows a message saying that the account’s mock limit is full and nothing else can be added. Two ways out:

• free places — delete mocks you no longer need; a deleted mock frees its place immediately, even while it still sits in the recycle bin;
• move to a plan with more places in the cabinet — see Cloud Spaces.

Mocks synchronised from Desktop share the same stock, so a mock sent from Desktop is refused the same way when the plan is full. See Desktop sync.

Team work is the same everywhere

In a Team Space, the tracker, the wiki, boards and discussions on the shared Mockarty are the same as in every member’s Desktop. A task, page or message created here reaches the members’ Desktops, and what they write in Desktop appears here — usually within a minute. Each person keeps the names and roles they have in the cabinet: a message written by a member in Desktop shows here with their name, and direct messages and closed channels are visible only to their members, here and in Desktop. When the same object was changed in two places, the newer change is kept.

Usage shown from the runtime

Because a shared Space’s work lives on the node, the cabinet’s Usage view reads the mock count straight from it over an encrypted channel and marks the number measured by the runtime — advisory. It is a real count of what the Space holds, not a locally enforced figure: if it ever disagrees with the plan’s ceiling, the plan gate, not the reading, decides what is refused. When the node cannot be reached, the row says the number is unavailable instead of showing zero.

Two Spaces, one person

Within one paid Team, your named Seat covers all its Spaces that you may access. A Personal Space keeps its own identity and rights, separate from your Team. Switching Spaces is the same click: select the other Space in the cabinet and press Open Mockarty again.

Leaving and archiving

A member removed from a Space loses its namespace membership. Leaving or being removed from a Team ends its shared-node rights in every Team Space. An emptied or deleted Space is archived on Mockarty: its data remains and the namespace can reopen when access is restored.

Passwords and recovery

Your identity on the shared Mockarty has no password of its own: sign in only through the cabinet. Password recovery happens in the cabinet — see Account security.

AI profiles and credits

Shared Mockarty can offer several Mockarty-hosted model profiles, for example a faster economical profile and a more capable profile for difficult work. Each profile has its own published AI-credit burn rate. Cloud reserves credits before the provider call and settles the actual tokens afterwards; an exhausted balance blocks the call before model I/O.

For scheduled semantic indexing through a shared hosted model, and security knowledge indexing in a paid Team or Personal Pro Space, an operator must approve a time-limited background grant for embedding_tokens. The grant names the exact published profile, provider and model and applies only to that Space. A Personal Pro grant is bound to its Space owner. If the grant expires or is revoked, those background vectors stop updating; text search remains available. Admitted hosted embedding calls use the Team’s shared AI credits or the Personal owner’s credits. A namespace-owned embedding endpoint with its own credential must be reachable over public HTTPS to run as BYOK on a shared node.

If the endpoint uses its own default model and no model name is configured, publish its rate and grant under external-default. This is the stable accounting name for that endpoint’s default model.

Global security reference documents have no customer payer, so shared Cloud indexes them for text search only. The security AI status diagnostic reports this as global_reference_has_no_paid_payer with a document count; it also reports tenant embedding failures for the selected namespace. Customer documents with a valid grant can still use dense search.

Your Space may also use a namespace-owned profile with its own provider key (BYOK). That traffic follows the Space’s provider account and does not draw from the Cloud AI-credit wallet. Prompts, answers and provider keys stay outside the wallet ledger. See Cloud promotions and rewards.

Connect an AI agent over MCP

Mockarty in the cloud is also an MCP server. An AI agent in your IDE (Claude Code, Cursor and others) works with your Space’s mocks, tests and reports through the same tools as in Mockarty Desktop.

1. Open Mockarty with Open Mockarty in the cabinet.
2. In the account menu (top right) choose API Tokens and create a token.
3. Add the server to your agent’s MCP settings. The address is your Mockarty in the cloud (the one that opened in the browser) with /mcp at the end. The Space’s namespace is shown on the Your Mockarty card in the cabinet.

{
  "mcpServers": {
    "mockarty": {
      "type": "http",
      "url": "https://<your Mockarty in the cloud>/mcp",
      "headers": {
        "X-API-Key": "<your-api-token>",
        "X-Mockarty-Namespace": "<Space namespace>"
      }
    }
  }
}

The agent reaches only your Spaces’ namespaces: a call into anyone else’s namespace is refused. Without a token the server answers 401. When the token is no longer needed, revoke it in the same API Tokens list.

For operators

Running a shared node installation is administrator work, not part of working in a Space: the node is attached to the cloud with deployment configuration, its licence is managed centrally, and its capacity follows the Spaces it serves. The node-side settings are described in the administration guide; the cloud-side settings of a Mockarty Cloud installation are the operator’s concern and are not covered in this user guide.