That is the question anyone asks about connecting a vault to an assistant, and the answer here is structural rather than a promise. Passwords are generated and rotated inside Secret Server and only metadata comes back; when a value genuinely has to move, the server hands you a shell script that moves it locally. update_secret_fields refuses password-marked fields unless you say otherwise. bulk_user_response is the other piece worth noticing — the incident scenarios are named and confirm-gated with a required audit comment, so a compromise response is one deliberate call instead of a dozen improvised ones.
Delinea's MCP server for Secret Server and the Delinea Platform identity directory, with an optional StrongDM backend. The design decision that shapes it: password operations are done server-side and return only sanitized metadata, so the value never reaches the model that requested the change.
- Secrets and folders — get_secret, get_folder, search_secrets, search_folders and folder_management for creating, updating and deleting folders
- Password work that keeps the value away from the model — create_secret_with_generated_password and update_secret_generated_password generate and rotate server-side, returning metadata only
- update_secret_fields, which reads the template, changes non-password fields and verifies the result, and refuses password-marked fields unless you explicitly allow them
- get_secret_environment_variable and set_secret_field_environment_variable, which emit a shell script you run locally — the value moves between your machine and Secret Server without passing through the conversation
- Access requests and inbox — get_pending_access_requests, handle_access_request, get_inbox_messages and mark_inbox_messages_read
- Reporting — run_report for a temporary report from SQL, list_example_reports for sample queries and table information, and ai_generate_and_run_report which writes the SQL from a description when Azure OpenAI is configured
- Platform identity — user_management, search_users, platform_role_management and platform_user_role_management, with secretserver_local_user_management and search_secretserver_local_users for Secret Server-only deployments
- bulk_user_response, an incident combinator over bulk user operations with named scenarios — compromise, offboard, unlock, reenable and force_logout — which previews unless you confirm and requires an audit comment
- Secret Server roles and groups — role_management, user_role_management, group_management, user_group_management and group_role_management
- Templates — check_secret_template, check_secret_template_field and get_secret_template_field, plus health_check for service status
- search and fetch, a unified pair for clients that expect that shape, with the object types they can reach set in config and limited to secrets by default
- Every tool publishes read-only and destructive hints, so a client can treat them differently
- An experimental StrongDM backend — sdm_search, sdm_audit_access, sdm_grant_access for time-boxed just-in-time grants, sdm_revoke_access, sdm_user_management, sdm_role_management, sdm_access_requests, sdm_resource_health, sdm_activity_report and sdm_network_status — which the README says has not been verified against a live organization
A Secret Server instance and credentials — DELINEA_BASE_URL, DELINEA_USERNAME and DELINEA_PASSWORD. The Platform user and role tools need PLATFORM_HOSTNAME, PLATFORM_TENANT_ID and PLATFORM_SERVICE_ACCOUNT with PLATFORM_SERVICE_PASSWORD; without them those tools return guidance rather than failing. StrongDM is an optional extra needing SDM_API_ACCESS_KEY and SDM_API_SECRET_KEY, and AI-generated reports need Azure OpenAI configured. A Dockerfile is provided. The server speaks streamable HTTP; its embedded OAuth authorization server is described as a development convenience, so read the security notes before exposing it.
One command plus a key — pip install "delinea-mcp[strongdm]", then supply credentials