Choose your tools

critlab's MCP server has 118 tools in four groups. It loads one group by default, core, so an agent session starts small, and it loads the others only when you ask. This page is for the person who connects an agent: it says which tools the agent gets, how to change that, and what the agent does when it needs one it does not have.

What loads by default

The default is core: the 23 tools an agent needs to run the feedback loop. It publishes a prototype (the project's build output, not its source: What you can publish), lists open threads, pulls a thread with its screenshots, replies, resolves, reads the canvas, the code and the folder context, and publishes the fix. Adding to the folder context, folder and prototype settings, people, SSO, billing and AI review are not loaded.

The reason is size. A client that loads every tool up front carries all their definitions in every session: about 7k tokens for core and about 28k for all 118 (a rough estimate, bytes divided by four). Some clients cap the number of tools too: Windsurf at 100, VS Code at 128 including its own. Tool choice also gets less reliable as a model sees more tools.

Choose the groups

Name the groups when the server starts, in one of two places:

• the --tools flag: crit mcp --tools core,workspace;
• the CRITLAB_MCP_TOOLS environment variable: CRITLAB_MCP_TOOLS=core,workspace.

The flag wins over the environment variable. A blank value counts as unset. The value is a comma-separated list of group names, all for every group, and single tool names, which add to the groups: core,critlab_invite_member loads core and that one workspace tool. An unknown name stops the server before it starts, with the valid names on stderr, so a typo never silently loads the wrong set.

For Claude Code:

claude mcp add critlab -e CRITLAB_TOKEN=<your key> -e CRITLAB_API=https://critlab.example.com -e CRITLAB_MCP_TOOLS=core,workspace -- npx -y @critlab/cli mcp

For Claude Desktop, which has no shell, load workspace as well if you manage folders and people from there. In claude_desktop_config.json:

{
  "mcpServers": {
    "critlab": {
      "command": "npx",
      "args": ["-y", "@critlab/cli", "mcp"],
      "env": {
        "CRITLAB_API": "https://critlab.example.com",
        "CRITLAB_TOKEN": "crit_sk_xxxxxxxx",
        "CRITLAB_MCP_TOOLS": "core,workspace"
      }
    }
  }
}

The set is fixed for the life of the process. The server never adds or removes a tool while it runs, so restart the client after you change the setting. critlab_whoami prints which groups the session loaded, and whether AI review and the free beta are on for the instance.

The groups

Every tool is in exactly one group, and a test holds the groups to the full list.

• core: critlab_whoami, critlab_publish, critlab_list_prototypes, critlab_get_prototype, critlab_list_versions, critlab_share_prototype, critlab_search, critlab_list_open_threads, critlab_get_thread_bundle, critlab_create_thread, critlab_reply_to_thread, critlab_resolve_thread, critlab_react_to_comment, critlab_mark_threads_read, critlab_get_canvas, critlab_rebuild_canvas, critlab_list_files, critlab_read_file, critlab_diff_versions, critlab_download_version, critlab_get_folder_context, critlab_download_folder_context, critlab_list_folders
• workspace: critlab_add_external_target, critlab_rename_prototype, critlab_set_prototype_description, critlab_set_prototype_status, critlab_move_prototype, critlab_archive_prototype, critlab_delete_prototype, critlab_delete_version, critlab_star_prototype, critlab_list_prototype_activity, critlab_set_prototype_access, critlab_set_code_access, critlab_set_repo_link, critlab_update_site, critlab_update_thread_anchor, critlab_delete_comment, critlab_create_folder, critlab_edit_folder, critlab_rename_folder, critlab_move_folder, critlab_delete_folder, critlab_archive_folder, critlab_unarchive_folder, critlab_reorder_folders, critlab_star_folder, critlab_get_folder_access, critlab_add_folder_context, critlab_upload_folder_context, critlab_update_folder_context, critlab_remove_folder_context, critlab_list_members, critlab_invite_member, critlab_set_member_role, critlab_remove_member, critlab_grant_folder, critlab_revoke_folder, critlab_set_folder_grant, critlab_list_invitations, critlab_revoke_invitation, critlab_list_access_requests, critlab_approve_access_request, critlab_deny_access_request, critlab_set_workspace_defaults, critlab_list_api_keys, critlab_list_notifications, critlab_mark_notifications_read, critlab_export_my_data, critlab_delete_my_account
• admin: critlab_configure_storage, critlab_verify_storage, critlab_disconnect_storage, critlab_list_domains, critlab_add_domain, critlab_verify_domain, critlab_remove_domain, critlab_get_sso, critlab_configure_sso, critlab_set_sso_enforced, critlab_remove_sso, critlab_list_sso_domains, critlab_add_sso_domain, critlab_verify_sso_domain, critlab_remove_sso_domain, critlab_create_scim_token, critlab_revoke_scim_token, critlab_map_scim_group, critlab_list_integrations, critlab_add_webhook_integration, critlab_update_integration, critlab_test_integration, critlab_remove_integration, critlab_set_integration_target, critlab_list_integration_deliveries, critlab_create_issue, critlab_get_billing, critlab_set_seats, critlab_cancel_subscription, critlab_resume_subscription, critlab_get_billing_portal_link, critlab_export_audit, critlab_get_license, critlab_set_license
• review: critlab_run_review, critlab_list_reviews, critlab_get_review_run, critlab_cancel_review_run, critlab_dismiss_finding, critlab_undismiss_finding, critlab_list_dismissals, critlab_list_policies, critlab_create_policy, critlab_update_policy, critlab_delete_policy, critlab_get_credits, critlab_get_credit_pack_link

A group decides whether a tool exists in the session. The API key's scope decides whether a call to a tool that exists is allowed: a loaded workspace tool can still answer scope_required if the key was not created with workspace:write. Create a key with more scopes in Settings → API keys & agents.

Adding a link or a document to a folder's context needs both: the workspace group (critlab_add_folder_context, critlab_upload_folder_context) and a key with workspace:write. Context is inherited down the folder tree and every later agent reads it before it changes a prototype, while a reviewer, who may be an anonymous link visitor, can reach your agent through a comment. So the default loop cannot add context, and a card an API key added is marked [added by an agent] in the bundle.

Mentioning people

critlab_reply_to_thread and critlab_create_thread take an optional mentions list (an email, a user id or a person's exact name each), and crit reply and crit pin take --mention: the person is notified and lands on the thread. Only people who can see the prototype can be mentioned, an agent cannot be mentioned itself, and the thread bundle prints a Mentions: line per comment.

Attaching images

critlab_reply_to_thread and critlab_create_thread take an optional images list of local file paths, and crit reply and crit pin take --image <file> (repeatable): post your "after" screenshot with the reply that says what you changed. At most 4 images per comment, 8 MB and 25 megapixels each, PNG, JPEG, WebP or GIF, decided by the file's bytes (an SVG, a HEIC or any non-image is refused before it is sent). Metadata such as GPS is stripped on upload; a GIF is kept as it is. The thread bundle returns the images people attached as image blocks after the first comment's screenshots ("Image 1 of 2 from Tina"), inside the same size budget, and lists each one with its URL.

The text is optional when you attach an image: leave body out and crit reply <thread> --image ./after.png is a comment of pictures alone, like a voice note. With neither text nor an image (a mention counts as text) the call is refused before anything is sent, saying so. The thread bundle, the open-threads list and crit threads print such a comment as "(2 images)", and the images themselves come as the usual image blocks.

Links to a comment

Every comment and thread has an address: <share URL>?thread=<id>&comment=<id> (a thread's is the same without comment), written from the prototype's own share URL, so it uses the workspace's custom domain when there is one. Opening it shows the thread with its card scrolled to that comment. The prototype's access mode still decides who gets in: the link carries no token, and it tells a person who cannot open the prototype nothing about the comment. The thread bundle prints a Link: line under each comment, the open-threads list a link: line, and critlab_reply_to_thread, critlab_create_thread, crit reply and crit pin end with the link of the comment they created, so you can write "fixed here: …" in a message. crit link <comment id or thread id> prints one on its own. There is no separate tool, because the links are already in what you read.

When a tool is missing

An agent that needs a tool outside the loaded groups does not call it, because a tool that is not loaded does not exist in that session. The server's instructions and the critlab skill tell it what to do instead:

1. If it has a shell, it runs the same action with crit. Every tool has a command, and the CLI needs no group: crit --help lists them.
2. If it has no shell, it asks you to load the group, naming the group and what it needs it for ("I need workspace to file this prototype into a folder"). You change CRITLAB_MCP_TOOLS or --tools and restart the client.

What does not change

No tool is renamed or merged, so a tool keeps its name, its permission prompt and its row in the agent parity audit. The crit CLI keeps every command whichever groups the MCP server loads.