Join the Waitlist
Guide

How to Choose an MCP Capability Preset for Your AI Assistant

5 stepsUpdated AUG 2026AI

Summary

DAVE's MCP integration exposes 34 tools across four capability presets. The preset you select when generating an MCP key determines exactly what your AI assistant can do in your workspace. This guide explains the decision framework, the least-privilege principle behind the preset system, and how to change your selection if you get it wrong.

The steps

  1. Understand what a capability preset controls

    A capability preset is a named bundle of MCP tool permissions. When you generate an MCP key, you select a preset. That preset determines which of DAVE's 34 MCP tools the key can access. The preset is enforced on every request: if your AI assistant tries to call a tool outside its preset, the request is rejected at the API level, regardless of how the request is framed.

    DAVE offers four presets. Each one grants access to a different subset of the 34 tools, matched to a specific use case. The presets follow a least-privilege model: the narrowest preset grants the fewest tools, and each broader preset adds more capability on top of the previous one.

    The preset is set at key creation and cannot be changed on an existing key. If you need a different preset, you generate a new key with the correct preset and revoke the old one. Revocation takes effect within minutes, even on open AI assistant sessions.

    Do this
    • Before generating an MCP key, write down the specific tasks you want your AI assistant to perform in DAVE. Be concrete: "read workflow definitions", "create workflow instances", "read agent configurations", "complete tasks".
    • Review the four preset options available in the key generation dialog. Match your task list against the tool categories each preset covers.
    • Select the preset whose tool coverage matches your task list exactly, or the next preset up if your list spans two categories. Do not select a broader preset just because it is available.
    Example

    A developer who wants Claude Code to read workflow definitions and describe agent configurations, but not create or modify anything, should select the narrowest read-oriented preset. A developer who also needs Claude Code to trigger workflow instances should select the next preset up that includes instance creation tools.

    Best practice

    The least-privilege principle is the right default for AI assistant access. Start with the narrowest preset that covers your intended use. If you find the assistant cannot do something you need, generate a new key with a broader preset and revoke the old one. It is easier to expand access deliberately than to reduce it after the fact.

  2. Map your use case to the right preset

    The four presets cover different operational surfaces of the DAVE platform. The right way to choose is to identify which surface your AI assistant needs to interact with, then select the preset that covers it.

    DAVE's 34 MCP tools span the platform's core operational areas: workflow management, agent configuration, task interaction, workspace data, and administrative functions. The four presets bundle these areas in a least-privilege progression. The specific preset names and their exact tool lists are documented in the dedicated MCP help documentation: the decision framework here applies regardless of the exact names.

    Use the following questions to identify which preset fits your use case:

    • Does your AI assistant only need to read and describe things? Workflow definitions, agent configurations, task details, workspace structure. If yes, the narrowest read-oriented preset is appropriate. The assistant can observe and report but cannot create, modify, or delete anything.
    • Does your AI assistant need to trigger or interact with workflows? Creating instances, submitting task responses, advancing workflow steps. If yes, you need a preset that includes instance and task interaction tools, in addition to read access.
    • Does your AI assistant need to create or modify platform objects? Creating agents, editing workflow definitions, managing prompt library entries. If yes, you need a broader preset that includes write access to platform configuration objects.
    • Does your AI assistant need administrative access? Managing users, roles, API keys, or tenant settings. If yes, you need the broadest preset. This should be reserved for AI assistants operated by platform Admins for specific administrative automation tasks, not for general-purpose coding assistants.

    Most developers connecting Claude Code for day-to-day workflow development will find that a read-plus-instance preset covers their needs. Full administrative access is rarely appropriate for an AI assistant and should be treated with the same caution as granting a human user the Admin role.

    Do this
    • Answer the four questions above for your specific use case. Write down which surfaces your assistant needs: read-only, instance interaction, platform object writes, or administrative access.
    • Match your answers to the four presets in the key generation dialog. The preset descriptions in the dialog will confirm which tool categories each one covers.
    • If your use case spans exactly two adjacent categories (for example, read plus instance interaction), select the preset that covers both. Do not select a preset that covers more than you need.
    • If you are unsure, start with the narrowest preset. You can always generate a new key with a broader preset later.
    Example

    A content operations team uses Claude Code to inspect their DAVE workflows and suggest improvements to the workflow graph. They do not need Claude Code to run instances or modify any configuration. The narrowest read-oriented preset is the right choice: Claude Code can describe every workflow and agent in the workspace, but cannot change anything. The team's governance policy is that all workflow changes go through a human using the DAVE visual editor.

    Best practice

    Document your preset choice and the reasoning behind it in your team's internal admin log. When the key is rotated or a new team member generates their own key, the documented reasoning makes the right choice obvious without having to re-derive it. Include the date the key was generated, the preset selected, and the specific tasks it was intended to support.

  3. Generate the key with the chosen preset

    MCP keys are generated in the API Management section of the Admin panel. The key generation dialog presents the four preset options and asks you to name the key. Both choices, the preset and the name, are set at creation and affect how the key appears in the audit log and key list for its entire lifetime.

    After you click Generate, DAVE displays the key value once, in full. Copy it immediately to a secure location such as a password manager. The key value is not shown again after you close the dialog. If you lose it, you must revoke the key and generate a new one.

    Do this
    • Navigate to Admin, then API Management and locate the MCP Keys section.
    • Click the button to generate a new MCP key.
    • In the key generation dialog, select the preset you identified in Step 2.
    • Give the key a descriptive name that identifies the person and the AI assistant: for example, "Claude Code - Jane Smith" or "VS Code - Dev Team Bot". A clear name makes the key identifiable in the audit log and key list without ambiguity.
    • Click Generate (or Create).
    • Copy the key value immediately and store it in a secure location. It will not be shown again.
    • Close the dialog. The key appears in the MCP Keys list with its preset, creation date, and last-used timestamp.
    Example

    A developer generates an MCP key for Claude Code, selects the read-plus-instance preset, and names it "Claude Code - Alex Chen". Three months later, a security review identifies the key in the audit log. The name makes it immediately clear whose assistant generated the events, and the preset confirms the scope of access that was granted. No investigation is needed to understand what the key could have done.

    Best practice

    Generate one key per person per AI assistant. Do not share keys between users or between different AI assistants (Claude Code, Claude Desktop, VS Code, JetBrains). Per-user, per-assistant keys mean the audit log can attribute every MCP action to a specific person's specific tool. Shared keys make the audit trail ambiguous and complicate incident investigation.

  4. Verify the preset is enforced correctly

    After connecting your AI assistant using the new key, verify that the preset is enforced as expected. The most direct test is to ask the AI assistant to perform an action that is outside the preset's scope and confirm it is rejected. This confirms that the enforcement is working and that the key does not have broader access than intended.

    Every MCP action, whether successful or rejected, is recorded in the DAVE audit log. The audit log entry shows the tool called, the acting key, and the response status. A rejected request (due to insufficient preset permissions) appears as a failed event. Checking the audit log after a test confirms both that the enforcement is working and that the audit trail is capturing MCP activity correctly.

    Do this
    • Connect your AI assistant using the new key (following the connection guide for your specific assistant).
    • Ask the AI assistant to perform a task that is within the preset's scope. Confirm it succeeds and returns real data from your DAVE workspace.
    • Ask the AI assistant to perform a task that is outside the preset's scope (for example, if you selected a read-only preset, ask it to create a workflow instance). Confirm it is rejected.
    • Navigate to Admin, then Settings and click the Audit Log tab.
    • Find the MCP events from your test. Confirm the successful action appears with the correct tool name and your key as the actor. Confirm the rejected action appears as a failed event.
    • If the rejected action succeeded instead of failing, the preset selection may not have been saved correctly. Revoke the key and generate a new one with the correct preset.
    Example

    A developer generates a read-only MCP key for Claude Code and connects it. They ask Claude Code to list active workflows (expected to succeed) and then ask it to create a new workflow instance (expected to fail). The list request succeeds. The instance creation request is rejected with a permissions error. Both events appear in the DAVE audit log. The preset is confirmed working correctly.

    Best practice

    Run the out-of-scope test immediately after connecting, not weeks later. If you discover the preset is wrong after the AI assistant has been in use for some time, you need to review the audit log for the period it was active to understand what it was able to do. Catching a misconfigured preset on day one is far simpler than auditing weeks of activity.

  5. Change the preset by revoking and regenerating

    If your use case changes and you need a different preset, the process is: revoke the existing key, generate a new key with the correct preset, and update the AI assistant's configuration with the new key. There is no in-place preset change on an existing key.

    Revocation takes effect within minutes, even on open AI assistant sessions. After revocation, any MCP request using the old key is rejected. The key remains visible in the MCP Keys list with a revoked status, so the audit trail for the old key is preserved.

    Do this
    • Navigate to Admin, then API Management and locate the MCP Keys section.
    • Find the key you want to replace in the list.
    • Use the revoke or delete action on the key. Confirm the action when prompted.
    • Wait a few minutes for revocation to propagate.
    • Generate a new key with the correct preset, following Step 3 above.
    • Update your AI assistant's MCP configuration with the new key value.
    • Restart the AI assistant or reload its MCP server list.
    • Verify the new preset is enforced correctly, following Step 4 above.
    Example

    A developer who started with a read-only preset now needs Claude Code to be able to trigger workflow instances as part of a new development workflow. They revoke the old read-only key, generate a new key with the read-plus-instance preset, update Claude Code's configuration, and run the verification test from Step 4. The whole process takes under ten minutes.

    Best practice

    When you revoke a key and generate a replacement, use a new name that reflects the date or version: for example, "Claude Code - Jane Smith (Aug 2026)". This makes it easy to correlate audit log events to the correct key when reviewing historical activity. The revoked key's audit history is preserved and remains searchable in the audit log even after revocation.

Why DAVE uses presets instead of per-tool selection

DAVE's MCP integration exposes 34 tools. Asking every developer to select individual tools from a list of 34 at key generation time would produce inconsistent, hard-to-audit configurations. Some developers would select too many tools out of convenience. Others would select too few and then request broader access later without a clear rationale. Neither outcome is good for governance.

Presets solve this by collapsing the 34-tool surface into four well-defined bundles, each matched to a recognizable use case. The person generating the key makes one choice, not 34. The choice is documented in the key record. The audit log shows which preset was active for every MCP event. Governance is built into the structure of the system, not dependent on individual developers making correct per-tool selections under time pressure.

The preset system also makes the least-privilege principle actionable. In a per-tool selection model, least privilege requires knowing which of 34 tools you need, which requires knowing what each tool does. In a preset model, least privilege means selecting the narrowest preset that covers your use case, which requires knowing your use case. The second question is much easier to answer correctly.

Finally, presets make revocation and rotation straightforward. When you rotate a key, you select the same preset as the old key (or a different one if requirements have changed). There is no need to reconstruct a per-tool selection from memory or documentation. The preset name is the complete specification of the key's access scope.

How preset enforcement works on every request

The capability preset is not just a label on the key record. It is enforced on every MCP request, at the API level, before the request reaches the tool implementation. When your AI assistant sends an MCP request, DAVE checks the key's preset against the tool being called. If the tool is not in the preset, the request is rejected immediately. The tool implementation is never reached.

This enforcement model has three important properties for AI assistant governance.

It is not bypassable by prompt engineering. If Claude Code is instructed by a user prompt to perform an action outside its preset, the MCP request will be rejected regardless of how the instruction is framed. The enforcement happens at the API level, not in the AI assistant's reasoning. A cleverly worded prompt cannot expand the preset's scope.

It applies to every request, not just the first one. The preset is checked on every MCP call, not at connection time. If a key's preset is changed (which requires revocation and regeneration), the new preset applies from the first request using the new key. There is no session state that carries over from a previous preset.

Revocation takes effect within minutes on open sessions. If you revoke an MCP key while Claude Code has an active session, the revocation propagates quickly. Subsequent MCP requests from that session are rejected. The AI assistant does not need to be restarted for revocation to take effect, though the assistant may need to handle the resulting errors gracefully.

The combination of preset enforcement and full audit logging means that every MCP action is both constrained and recorded. Your AI assistant works within a defined boundary, and every action it takes within that boundary is visible in the audit trail.

Why one key per person per assistant matters for governance

DAVE's MCP keys are per-user credentials. The audit log records every MCP action against the key that performed it. If two developers share a key, the audit log cannot distinguish their actions. If one developer uses the same key for Claude Code and Claude Desktop, the audit log cannot distinguish which assistant performed each action.

Per-user, per-assistant keys are the foundation of attributable AI assistant governance. When the audit log shows an MCP action, it should be possible to answer: who authorized this action, and which tool performed it? A shared key makes both questions unanswerable.

The practical overhead of per-user, per-assistant keys is low. Each key takes under two minutes to generate. The key value is stored in the AI assistant's configuration file, not typed repeatedly. Rotation is infrequent for most teams. The governance benefit, a fully attributable audit trail for all AI assistant activity, is significant and ongoing.

Four AI assistants are supported for MCP connection: Claude Code, Claude Desktop, VS Code, and JetBrains. If a developer uses more than one of these, they should generate a separate key for each. The keys can have the same preset if the use cases are the same, but they should be named and tracked separately so the audit log remains attributable.

Frequently asked questions

Can I see the full list of tools in each preset before I choose?
The key generation dialog in DAVE shows the preset options with descriptions of the tool categories they cover. The dedicated MCP help documentation contains the complete preset-to-tool mapping. Review it before generating your key if you need to match specific tools to your use case.

What happens if I select a preset that is too narrow?
Your AI assistant will receive a permissions error when it tries to call a tool outside the preset. The error appears in the AI assistant's response and in the DAVE audit log as a failed MCP event. To fix it, revoke the key and generate a new one with a broader preset. There is no way to expand a key's preset without regenerating it.

What happens if I select a preset that is too broad?
Your AI assistant has access to more tools than it needs. This is not immediately harmful, but it violates the least-privilege principle and increases the blast radius if the key is ever compromised. To fix it, revoke the key and generate a new one with a narrower preset.

Can I change the preset on an existing key?
No. The preset is set at key creation and cannot be changed. To use a different preset, revoke the existing key and generate a new one. Revocation takes effect within minutes.

Does the preset affect what the AI assistant can see in my workspace, or only what it can do?
Both. Read tools (which return data about your workspace) and write tools (which create or modify records) are both covered by the preset. A read-only preset restricts both what the assistant can see and what it can do. A broader preset expands both.

Is the preset enforced even if the AI assistant has been connected for a long time?
Yes. Preset enforcement happens on every MCP request, not at connection time. The preset in effect is always the one associated with the key used for that request. There is no session state that carries a different preset.

How do I know which preset a key was generated with?
The MCP Keys list in Admin, then API Management shows the preset for each key. The audit log also records the preset associated with the acting key on each MCP event.

How to Choose an MCP Capability Preset in DAVE