Glossary

This glossary explains the key terms of the MCP-first approach as they are used in architecture, security model, and capability design.

Core concepts

• MCP, The Model Context Protocol; an open protocol that enables AI agents to call typed capabilities of a system (tools, resources, workflows) in a structured and permission-checked manner.

• MCP-first, Architecture principle in which software is first described as a fully controllable, machine-readable capability system; web app, mobile app, and admin UI are then built as secondary clients of this capability layer.

• Capability, A domain capability of the system that is structurally described, typed, permission-checked, and auditable; the actual core of the product, independent of any concrete interface.

• Action / Action Layer, A single executable capability (e.g. create_project, send_external_email) as the first layer below all interfaces; web app, agent, CLI, and worker all call the same action.

• Adapter, A layer (e.g. MCP server, web app backend, mobile app API) that receives requests, maps auth context, checks policies, and forwards calls to the action layer, but contains no business logic.

Building blocks

• Tool, A callable action in the MCP system with a typed input schema, output schema, risk level, and confirmation policy; corresponds to a capability from the agent’s perspective (example: contacts.create).

• Resource, A readable data point or context that an agent can retrieve (example: projects.list, contacts.get); delivers prepared context instead of raw database queries.

• Workflow / Prompt, A pre-built, multi-step sequence that guides an agent through a complex process; in the MCP context often modeled as a prompt template that coordinates resources and tools.

• Policy, A machine-readable rule that specifies who may call which tool under which conditions, what confirmation is required, and whether autonomous execution is permitted.

• Audit Event, A structured, immutable log entry for every executed MCP action; contains identities, risk level, confirmation ID, and timestamp to establish complete traceability.

• Risk Metadata, Machine-readable classification of a tool or resource with risk level (low / medium / high / critical / restricted) and further metadata such as reversibility and external side effects.

• Human Confirmation Gate, A mechanism whereby an agent must explicitly obtain the user’s consent before executing a risky tool; blocks autonomous execution until confirmation is given.

Identity & access

• Human User, A real, logged-in user of the system (e.g. admin, employee, project manager); starting point for permission checks and delegation chains.

• MCP Client, The application connected to the MCP server that makes requests on behalf of a user or agent (e.g. Claude Desktop, an internal AI app, or a worker process).

• Agent Identity, The concrete identity of an agent or automated workflow (e.g. sales-assistant, payroll-agent); managed separately from user identity and has its own scopes and restrictions.

• Delegated User Context, The mechanism by which an agent does not act with global system permissions, but exclusively within the permissions and context of a specific user or a configured service role.

• Service Identity, Identity for backend-to-backend processes without a human principal (e.g. import worker, scheduled job, sync worker); authenticates via mTLS or signed service tokens.

• Scope, A granular permission unit that precisely describes which action on which resource is permitted (example: contacts:read, emails:send, billing:write); tools and resources check scopes before execution.

• Tenant, A tenant in a multi-tenant system; every data access is tenant-bound (tenant:abc) so that agents can never act across tenants, even if their other scopes would technically permit it.

• Role, A bundle of scopes assigned to a user or agent identity (example: admin, manager, viewer); forms the first authorization level before tenant- and tool-specific scope checks.

Security & control

• Risk Level, Classification of a tool into low, medium, high, critical, or restricted; determines whether autonomous execution is permitted, whether confirmation is required, and whether step-up authentication is demanded.

• Protection Class, Categorization of every resource and tool by data sensitivity: Public (freely readable), Internal (logged-in users only), Confidential (explicit role required), Sensitive (restricted context sharing), Critical (no autonomous AI action), Forbidden for AI (may neither be read nor called by AI agents).

• Confirmation Policy, Per-tool rule specifying what type of consent is required before execution: no_confirmation_required, confirmation_required, step_up_auth_required, admin_approval_required, four_eyes_required, or not_allowed_for_ai.

• Step-up Authentication, An additional authentication requirement for particularly sensitive actions (e.g. password re-entry, TOTP, passkey) that goes beyond the current session; triggered for critical tools or privileged admin actions.

• Consent Ledger, A persistent record of all user approvals granted for agent actions; stores who, when, for which tool, with what scope, and with what method gave consent, the basis for audit and accountability.

• Human-in-the-loop, The principle by which an agent must actively obtain the user’s decision before acting on sensitive or risky actions; MCP-first means fully controllable, not fully automatic.

• Redaction / Context Filtering, Targeted cleansing or summarization of data before it enters the AI context; prevents agents from unnecessarily seeing sensitive fields (e.g. bankAccount, privateNotes), even if the user would generally have access.

• Dry Run, An execution mode of a tool where all inputs are validated and side effects are predicted, without the action actually being performed (example: emails.bulk_send(dryRun: true)); enables pre-checking before risky operations.

• Idempotency, The property of a tool to not produce an unnecessary duplicate when called repeatedly with the same parameters; important for retry logic and agentic workflows where an action can accidentally be triggered multiple times.

• Tool Discovery / Tool Visibility, The process by which an MCP client queries the available tools of a server; in an MCP-first system, tools are filtered already at discovery based on user, client, tenant, role, and scopes, not rejected only at call time.