MCP prompts

MCP prompts are reusable workflow guides that an MCP client can invoke by name, distinct from tools (which act) and resources (which expose data). Each Alpacon prompt returns static guidance text—arguments only scope the context inside it—that walks an AI agent through the discipline required to operate Alpacon safely: every infrastructure action happens inside an approved Work Session, approval always routes to a human because an agent has no MFA presence, and denials are structured so the agent self-corrects instead of retrying blindly. The four prompts mirror Alpacon’s access model, ACCESS→EXECUTION→AUDIT.

Summary

work_session_workflow

Invoke this prompt before any infrastructure action, to scope and open a Work Session. Given a goal (intent) and optionally a list of target server UUIDs (servers), it walks the agent through:

1. Declaring the goal as the session description and calling work_session_create with the required workspace, scopes, servers, and expires_at, scoped to the specific target servers rather than the whole workspace. It clarifies which scopes an agent can request directly (command, webftp, tunnel) versus sudo (always routes to human approval) and which are unavailable to agents entirely (websh, editor, which require MFA presence).
2. Handling the result by status: a pending_approval session means the agent must surface the request to a human and wait rather than retry—explain_approval_decision can relay why a human must act out-of-band. An error with a gate code means reading next_action, narrowing the scope, and retrying deliberately.
3. Once the session is active (confirmed via work_session_get), handing off to the guarded_execution prompt for the actual work.

Use it whenever a user’s request implies touching infrastructure—running a command, transferring a file, or opening a tunnel—and no Work Session is open yet.

guarded_execution

Invoke this prompt once a Work Session (work_session_id) is active, to run commands and file transfers inside it correctly. It walks the agent through:

1. Confirming the session is active via work_session_get, reading data.status rather than the top-level call-result status, before doing anything.
2. Passing work_session_id on every scoped call: execute_command, execute_command_multi_server, or webftp_download_file (webftp_upload_file is local-mode only and returns remote_mode_unsupported over remote/OAuth).
3. Expecting a risk verdict on every action—HIGH-risk commands and any sudo invocation route to human-in-the-loop, and the agent cannot self-approve.
4. Reading the structured code/next_action on denial and self-correcting instead of re-running the same denied command.
5. Calling work_session_close once the work is done, which also triggers the AI security analysis over the session.

Use it for every command or file transfer that happens right after a Work Session becomes active.

incident_response

Invoke this prompt when responding to an alert or reported incident, to make sure triage happens before any remediation. Given an optional server_id or workspace, it walks the agent through:

1. Read-only triage that needs no Work Session: active alerts, server overview and CPU/memory usage, and recent events, to identify the likely cause first.
2. If remediation requires running commands, opening a Work Session through the work_session_workflow prompt, scoped to the affected servers only with the command scope, instead of executing directly.
3. Running the remediation under guarded_execution, expecting risky steps (restarts, sudo, destructive commands) to route to human approval.
4. Closing the session with work_session_close once the incident is resolved, to complete the audit trail.

Use it when a user reports a problem with a server or asks the agent to investigate an alert.

security_audit

Invoke this prompt when a user asks an audit or forensic question about privileged activity, to pick the right lens instead of guessing which tool to call. Given an optional work_session_id or server_id as anchor, it maps five question types to the tools that answer them:

• Session forensic (“what happened in this session?”): work_session_timeline.
• Event forensic, cross-session (“every sudo call”, “every transfer of /etc/*”): list_server_logs, list_webftp_logs, search_events.
• Decision audit (“who approved this, when was it revoked?”): list_approval_requests, get_approval_request.
• Mutation audit (“what changed in roles, tokens, or policy?”): list_activity_logs, get_activity_log.
• AI-derived analysis (attack patterns, MITRE ATT&CK mapping): list_session_analyses, get_session_analysis_detail.

It also directs the agent to link findings back to the Work Session that contains each event, since the session is the primary unit of the audit story.

Use it for any “what happened,” “who approved,” or “was this suspicious” question about workspace activity.

Related

• Work Session tools: the tools these prompts orchestrate, including work_session_create, work_session_get, and work_session_close
• Audit log tools: the tools behind the security_audit lenses
• Getting started: connect your MCP client and see how it surfaces prompts and resources