Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@thales-cdsp-csm-mcp-server migrate hardcoded secrets from my Flask app"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Simple MCP server for Thales CipherTrust Secrets Management, powered by Akeyless.
š¹ Part I: Usage & Functionality - Watch on YouTube
This video demonstrates:
Setting up Cursor AI integration
Creating and managing secrets and DFC Keys through AI chat
Security compliance workflows
Example prompts and functionality
š¹ Part II: Deployment & Installation - Watch on YouTube
This video covers:
Step-by-step installation process
Configuration and setup
Deployment options
Related MCP server: @1claw/mcp
The server includes a powerful prompt that automatically determines whether you want to:
Create a NEW app with built-in CipherTrust integration
Secure an EXISTING app by migrating hardcoded secrets to CipherTrust
For New Apps:
Generates complete Python implementations with CipherTrust integration
Uses the get_api_reference tool for native API integration
Provides production-ready code with proper error handling
For Existing Apps:
Scans codebase for hardcoded secrets using intelligent detection
Categorizes secrets by type (key-value pairs vs standalone)
Uses manage_secrets MCP tool to create CipherTrust secrets
Generates migration reports and updated code
Provides testing and validation instructions
Secret Type Classification:
Key-Value Pairs/JSON format: AWS credentials, database configs, OAuth tokens
Standalone Secrets (Text format): Single passwords, individual tokens, certificates
Before you begin, ensure you have the following installed on your system:
Python 3.8+: Required for running the MCP server
uv: Modern Python package manager (recommended) or pip
git: For cloning the repository
dotenv: Environment variable management
fastmcp: MCP server framework
Thales CipherTrust Manager access
Valid Akeyless credentials
# Check if Python is installed
python --version
# or
python3 --version
# Install Python (Ubuntu/Debian)
sudo apt update && sudo apt install python3 python3-pip
# Install Python (macOS)
brew install python
# Install Python (Windows)
# Download from https://python.org# Install uv
pip install uv
# Verify installation
uv --version# Check if git is installed
git --version
# Install git (Ubuntu/Debian)
sudo apt update && sudo apt install git
# Install git (macOS)
brew install git
# Install git (Windows)
# Download from https://git-scm.com# Check if python-dotenv is installed
python -c "import dotenv; print('dotenv available')"
# Install python-dotenv
pip install python-dotenv
# Verify installation
python -c "import dotenv; print(f'dotenv version: {dotenv.__version__}')"# Check if fastmcp is installed
python -c "import fastmcp; print('fastmcp available')"
# Install fastmcp
pip install fastmcp
# Verify installation
python -c "import fastmcp; print(f'fastmcp version: {fastmcp.__version__}')"Secrets Management: Create, read, update, delete secrets
DFC Key Management: DFC encryption keys (AES, RSA)
Account Management: Get Akeyless account details
Analytics: Fetch analytics data
Authentication Methods: Manage Authentication Methods
App Development & Security: Intelligent app creation and secret migration
Roles: Manage Roles
Targets: Manage Targets
Security: Guidelines and best practices
MCP Protocol: Model Context Protocol compliance
git clone https://github.com/sanyambassi/thales-cdsp-csm-mcp-server
cd thales-cdsp-csm-mcp-server
pip install -r requirements.txt# Install uv if you don't have it
pip install uv
# Clone and setup
git clone https://github.com/sanyambassi/thales-cdsp-csm-mcp-server
cd thales-cdsp-csm-mcp-server
# Install dependencies (creates .venv automatically)
uv syncCreate .env file:
AKEYLESS_ACCESS_ID=your_access_id
AKEYLESS_ACCESS_KEY=your_access_key
AKEYLESS_API_URL=https://your-ciphertrust-manager/akeyless-api/v2
LOG_LEVEL=INFO
AKEYLESS_VERIFY_SSL=false# stdio mode
python main.py
# HTTP mode
python main.py --transport streamable-http --host localhost --port 8000# stdio mode
uv run python main.py
# HTTP mode
uv run python main.py --transport streamable-http --host localhost --port 8000Tool | Description |
| Create static secrets, get static secret values, update, delete secrets (static, dynamic, rotated) with type filtering and dynamic secret creation |
| Manage encryption keys |
| Authentication and access control |
| Secret rotation policies |
| Enhanced security features |
| Security best practices |
| List and get role information |
| List, get, and create targets |
| Get analytics and monitoring data |
| Get account settings and licensing |
| Get API reference for native Akeyless integrations (generic workflows + S3 example) |
# Run tests
python tests/run_tests.py
python.exe tests\test_mcp_protocol.py
# Test health endpoint (HTTP mode)
curl http://localhost:8000/healthTRANSPORT_MODES.md - How to run
TOOLS.md - What tools do
TESTING.md - Complete testing guide
AI Assistant Configs - MCP json examples for AI Assistants
AI Assistants: Claude Desktop, Cursor AI
Web Applications: REST API integration
Automation: CI/CD, scripts, tools
Enterprise: Secrets management, compliance
{
"mcpServers": {
"thales-csm": {
"command": "python",
"args": ["main.py", "--transport", "stdio"],
"env": {
"AKEYLESS_ACCESS_ID": "your_access_id_here",
"AKEYLESS_ACCESS_KEY": "your_access_key_here",
"AKEYLESS_API_URL": "https://your-ciphertrust-manager/akeyless-api/v2",
"LOG_LEVEL": "INFO"
}
}
}
}{
"mcpServers": {
"thales-csm": {
"command": "python",
"args": ["main.py", "--transport", "stdio"],
"env": {
"AKEYLESS_ACCESS_ID": "your_access_id_here",
"AKEYLESS_ACCESS_KEY": "your_access_key_here",
"AKEYLESS_API_URL": "https://your-ciphertrust-manager/akeyless-api/v2",
"LOG_LEVEL": "INFO"
}
}
}
}env: Environment variables for Akeyless authentication and logging
command: Python executable to run the server
args: Command line arguments for the server
Full Path Required: args must include the full absolute path to main.py
Windows Paths: Use double backslashes \\ in Windows paths (e.g., C:\\thales-cdsp-csm-mcp-server\\main.py)
Unix Paths: Use forward slashes / in Unix/Linux paths (e.g., /home/user/thales-cdsp-csm-mcp-server/main.py)
config/mcp-config-uv.json - UV package manager setup
config/mcp-config.json - Basic configuration template
Issues: GitHub Issues
Documentation: Check the docs folder above
This project is licensed under the MIT License - see the LICENSE file for details.
API REFERENCE TOOL - Generate production-ready code examples and integration patterns
SUPPORTED ENDPOINTS: ā¢ workflow: Complete integration patterns and best practices ā¢ auth: Authentication flows and token management ā¢ create-secret: Secret creation and management APIs ā¢ get-secret-value: Secret retrieval and access patterns ā¢ list-items: Item listing and discovery APIs ā¢ delete-item: Item deletion and cleanup operations ā¢ list-roles: Role management and access control ā¢ list-targets: Target management and configuration
INTEGRATION FEATURES: ā¢ Production-ready code examples with authentication ā¢ Complete error handling and retry logic ā¢ Best practices for secure integration patterns ā¢ Multi-language support (Python, JavaScript, etc.) ā¢ Token management and session handling
USE CASES: ā¢ Building custom applications and integrations ā¢ CI/CD pipeline integration and automation ā¢ Microservice authentication and configuration ā¢ Native client development and SDK creation ā¢ Production system integration and deployment
Example: Generate complete Python client code for secret management
| Name | Required | Description | Default |
|---|---|---|---|
| language | No | Target programming language for code examples and implementation details | python |
| api_endpoint | Yes | API endpoint or integration pattern to get reference for. SUPPORTED: 'workflow' (complete integration patterns), 'auth' (authentication flows), 'create-secret' (secret creation), 'get-secret-value' (secret retrieval), 'list-items' (item listing), 'delete-item' (item deletion), 'list-roles' (role management), 'list-targets' (target management) | |
| include_auth | No | Include complete authentication workflow and token management examples | |
| include_error_handling | No | Include production-ready error handling, retry logic, and exception management |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the transparency burden. It discloses several behavioral aspects: generates code with authentication, error handling, retry logic, token management, and multi-language support. It implies a read-only reference nature but does not explicitly state there are no side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections for supported endpoints, integration features, use cases, and an example. While somewhat verbose, every section serves a purpose and the content is organized with bullet points, making it easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the rich output schema and 100% parameter coverage, the description thoroughly covers purpose, supported endpoints, generated features, and usage scenarios. It is complete for an AI agent to understand how and when to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with detailed parameter descriptions for language, api_endpoint, include_auth, and include_error_handling. The tool description adds context by elaborating on endpoint-specific integration patterns, but this complements rather than significantly extends the schema. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: generate production-ready code examples and integration patterns. It lists supported endpoints and integration features, distinguishing it from sibling manage_* tools that handle resource management rather than API reference.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a dedicated 'USE CASES' section with scenarios like building custom applications, CI/CD integration, microservice auth, and SDK development. It gives clear context for when to use the tool but does not explicitly state when not to use it or name alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ACCOUNT ADMINISTRATION TOOL - Manage organizational settings and governance
SUPPORTED ACTIONS: ā¢ get: Retrieve complete account configuration, licensing details, and system-wide policies
ACCOUNT INFORMATION PROVIDED: ā¢ Organizational details and company profile ā¢ Licensing and subscription tier information ā¢ Service tier, SLA level, and feature availability ā¢ Usage quotas, capacity limits, and billing details ā¢ System configuration and security policies ā¢ Governance, compliance, and audit settings ā¢ Multi-tenant configuration and access controls
USE CASES: ā¢ Account setup and initial configuration ā¢ Compliance and audit preparation ā¢ License management and planning ā¢ Security policy review and updates ā¢ Service tier evaluation and upgrades ā¢ Multi-tenant administration
Example: Review account licensing and compliance configuration
| Name | Required | Description | Default |
|---|---|---|---|
| json | No | Return structured JSON format for administrative reporting and configuration management. Use TRUE for automated compliance reporting and system integration | |
| action | Yes | Account administration action to perform. SUPPORTED ACTIONS: 'get' (retrieve complete account configuration, licensing details, organizational settings, and system-wide policies) | |
| uid_token | No | Universal identity authentication token. Only required when using universal_identity authentication instead of standard API key authentication |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It describes the categories of information returned, but does not explicitly state that the 'get' action is read-only with no side effects, nor does it mention authentication requirements or potential errors. The verb 'get' implies safety, but explicit disclosure is missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections and bullet points, but is somewhat verbose. The 'USE CASES' list partially overlaps with the 'ACCOUNT INFORMATION PROVIDED' list, and the opening line repeats the tool name. It could be trimmed to be more concise without losing value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-action tool with an output schema, the description comprehensively covers the information returned and common use cases. The only notable gap is the missing explicit read-only disclosure, but the 'get' action and detailed data categories sufficiently orient the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for all three parameters, so the baseline applies. The description adds a usage example ('review account licensing and compliance configuration') but does not provide further parameter semantics beyond the schema. The schema descriptions for 'json' and 'uid_token' already give clear meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as an account administration tool with an explicit supported action 'get' and enumerates the resource scope (organizational settings, licensing, policies, etc.). This distinguishes it from sibling admin tools that focus on analytics, auth, roles, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description lists concrete use cases (account setup, compliance, license management, security policy review, service tier evaluation, multi-tenant admin) that signal when to invoke this tool. It does not explicitly name alternatives, but the context is clear enough for an agent to select it appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ANALYTICS & MONITORING TOOL - Comprehensive infrastructure monitoring and reporting
SUPPORTED ACTIONS: ā¢ get: Retrieve comprehensive monitoring data, usage statistics, and performance metrics
ANALYTICS COVERAGE: ā¢ Usage statistics and item counts by type (Secrets, Targets, Roles, Keys) ā¢ Geographic distribution of access requests and client patterns ā¢ Security risk analysis and certificate expiry tracking ā¢ Authentication method usage and access control compliance ā¢ Multi-region usage distribution and product-specific metrics ā¢ Resource utilization, capacity planning, and audit summaries
FILTERING OPTIONS: ā¢ Filter by item type (Targets, Static Secrets, Dynamic Secrets, DFC Keys, etc.) ā¢ Filter by risk level (Expired, Healthy, Expiring Soon certificates) ā¢ Filter by product component (Secrets Management, Advanced Data Protection, etc.)
USE CASES: ā¢ Security operations center (SOC) dashboards ā¢ Compliance reporting and audit preparation ā¢ Capacity planning and resource optimization ā¢ Risk assessment and vulnerability management ā¢ Executive reporting and KPI tracking
Example: Get security risk analysis for certificate expiry management
| Name | Required | Description | Default |
|---|---|---|---|
| json | No | Return structured JSON format for programmatic analysis and dashboard integration. Use TRUE for automated reporting and data processing | |
| action | Yes | Analytics and monitoring action to perform. SUPPORTED ACTIONS: 'get' (retrieve comprehensive monitoring data, usage statistics, and performance metrics for the entire infrastructure) | |
| uid_token | No | Universal identity authentication token. Only required when using universal_identity authentication instead of standard API key authentication | |
| filter_by_risk | No | Filter certificate and security risk analysis. OPTIONS: 'Expired' (certificates past expiry), 'Healthy' (certificates within validity), 'Expiring Soon' (certificates near expiry) | |
| filter_by_type | No | Focus on specific item categories. SUPPORTED TYPES: 'Targets', 'Static Secrets', 'Dynamic Secrets', 'DFC Key', 'Roles', 'Auth Methods', 'Rotated Secrets', 'Certificates'. Use exact match for filtering | |
| filter_by_product | No | Filter by Akeyless product components. OPTIONS: 'sm' (Secrets Management), 'adp' (Advanced Data Protection), 'sra' (Secure Remote Access). Essential for multi-product environments |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It describes what data is retrieved and the filtering options, but it does not explicitly state that the tool is read-only or non-mutating, nor does it mention pagination, rate limits, or error behavior. The 'get' action implies a safe read operation, but this is not explicitly disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (SUPPORTED ACTIONS, ANALYTICS COVERAGE, FILTERING OPTIONS, USE CASES, Example). While somewhat verbose, each section provides useful information and the example adds practical clarity. No significant redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (6 params, output schema), the description covers all major elements: supported actions, data coverage, filtering, use cases, and a usage example. It doesn't explain whether filters can be combined or specify output format, but the output schema is available. This is sufficient for tool selection and basic usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by elaborating on filter options with examples, noting that filter_by_type uses exact match, and that filter_by_product is essential for multi-product environments. It also explains the 'get' action in context, going beyond the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies 'ANALYTICS & MONITORING TOOL' and defines the supported action 'get' as retrieving comprehensive monitoring data, usage statistics, and performance metrics. This distinguishes it from sibling management tools by focusing on analytics and reporting rather than resource management.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'USE CASES' section lists SOC dashboards, compliance reporting, capacity planning, risk assessment, and executive reporting, providing clear when-to-use context. It doesn't explicitly exclude alternatives but the analytics focus is unique among the sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
AUTHENTICATION METHODS MANAGEMENT TOOL - Create, manage, and secure authentication methods
SUPPORTED ACTIONS: ā¢ create_api_key: Create API key authentication methods with IP restrictions and expiration ā¢ create_email: Create email-based authentication methods with MFA support ā¢ list: List all authentication methods with filtering and pagination ā¢ get: Retrieve detailed authentication method configuration and status ā¢ update: Modify authentication method properties, credentials, and settings ā¢ delete: Delete individual authentication methods with proper cleanup ā¢ delete_auth_methods: Bulk delete authentication methods within a specific path
SECURITY FEATURES: ā¢ IP address restrictions and CIDR whitelisting ā¢ Access expiration and JWT TTL management ā¢ Multi-factor authentication (MFA) support ā¢ Audit logging and compliance tracking ā¢ Delete protection and access control
Example: Create a secure API key for application authentication
| Name | Required | Description | Default |
|---|---|---|---|
| json | No | Set output format to JSON | |
| name | No | Authentication method name (required for create_api_key, update, delete, get) | |
| path | No | Path for bulk operations (required for delete_auth_methods) | |
| tags | No | List of tags attached to this object | |
| type | No | Auth method types to filter by [api_key, azure_ad, oauth2/jwt, saml2, ldap, aws_iam, oidc, universal_identity, gcp, k8s, cert] | |
| No | Email address for email authentication method | ||
| action | Yes | Authentication method management action to perform. SUPPORTED ACTIONS: 'create_api_key' (create API key authentication), 'create_email' (create email authentication), 'list' (list all authentication methods), 'get' (retrieve specific auth method details), 'update' (modify auth method properties), 'delete' (delete individual auth method), 'delete_auth_methods' (bulk delete auth methods by path) | |
| filter | No | Filter by auth method name or part of it | |
| jwt_ttl | No | JWT TTL | |
| mfa_type | No | Enable two-factor-authentication via [email/auth app] | |
| new_name | No | New name for the authentication method (for update action) | |
| bound_ips | No | CIDR whitelist for IP restrictions | |
| enable_mfa | No | Enable MFA for this authentication method [True/False] | |
| description | No | Auth Method description | |
| gw_bound_ips | No | CIDR whitelist for Gateway IP restrictions | |
| product_type | No | Product type for auth method [sm, sra, pm, dp, ca] | |
| accessibility | No | Accessibility level | regular |
| access_expires | No | Access expiration date in Unix timestamp (0 for no expiry) | |
| force_sub_claims | No | Enforce role-association must include sub claims | |
| pagination_token | No | Next page reference | |
| audit_logs_claims | No | Subclaims to include in audit logs | |
| delete_protection | No | Protection from accidental deletion [true/false] | |
| expiration_event_in | No | Days before expiration to be notified |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses destructive actions (delete, delete_auth_methods) and mentions delete protection, access control, and audit logging. However, it does not specify permission requirements or whether deletions are reversible, leaving some behavioral ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections for supported actions and security features, and it is front-loaded with the tool's purpose. It is somewhat verbose but appropriate for a complex multi-action tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (23 parameters, multiple actions) and the presence of an output schema, the description covers the main actions, security features, and an example. It lacks explicit prerequisites or error handling, but it is sufficient for most usage scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds context by mapping actions to the 'action' parameter and highlighting security-related parameters, but it does not explain each parameter in detail beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'AUTHENTICATION METHODS MANAGEMENT TOOL - Create, manage, and secure authentication methods' and enumerates all supported actions (create_api_key, create_email, list, get, update, delete, delete_auth_methods), making purpose explicit and distinguishing it from sibling tools like manage_roles or manage_secrets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context through SUPPORTED ACTIONS and SECURITY FEATURES, but it does not explicitly state when not to use this tool or name alternative tools. However, the tool's scope is well-defined, so an agent can infer when to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
CUSTOMER FRAGMENT MANAGEMENT TOOL - Manage customer fragment encryption and security
SUPPORTED ACTIONS: ā¢ list: List customer fragments with path filtering and pattern matching ā¢ export: Export customer fragments with optional JSON format ā¢ download: Download customer fragments (alias for export action)
SECURITY FEATURES: ā¢ Customer fragment encryption for enhanced security ā¢ Access control and audit trails ā¢ Enterprise-grade fragment management ā¢ Compliance and security reporting
USE CASES: ā¢ Customer fragment inventory and management ā¢ Security compliance and audit preparation ā¢ Fragment backup and export operations ā¢ Enhanced encryption key management
Example: List and export customer fragments for security audit
| Name | Required | Description | Default |
|---|---|---|---|
| json | No | Set output format to JSON (for export action) | |
| path | No | Path to list fragments from (for list action) | |
| action | Yes | Customer fragment management action to perform. SUPPORTED ACTIONS: 'list' (list customer fragments with filtering), 'export' (export customer fragments), 'download' (download customer fragments - alias for export) | |
| filter_by | No | Filter fragments by pattern (for list action) |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the supported actions and mentions security features like encryption and audit trails. It also clarifies that 'download' is an alias for 'export'. However, it does not detail side effects, permissions, whether actions are read-only or mutating, or error behaviors. The description is partially transparent but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is overly verbose and filled with marketing fluff like 'ENTERPRISE-GRADE', 'COMPLIANCE AND SECURITY REPORTING', and redundant phrasing. The 'USE CASES' and 'SECURITY FEATURES' sections contain aspirational statements that do not help an AI agent invoke the tool. It could be reduced to a few concise sentences without losing essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists and parameters are fully covered, the description does not need to explain return values. It covers the main actions, use cases, and security context, which is sufficient for an agent to select the tool for tasks like audit or backup. It lacks some behavioral details like permissions, but overall it is complete enough for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description does not add significant meaning beyond the schema; it restates that 'list' uses path/filter_by and 'export' uses json. The action parameter description in the schema already covers the action details. Thus, the description adds minimal value beyond structured data.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it manages customer fragments, with specific actions (list, export, download) and a resource focus. The verb 'Manage' is somewhat generic, but the action list and context make the purpose clear. It does not explicitly differentiate from sibling tools like manage_dfc_keys or manage_secrets, but the 'customer fragments' resource is distinct enough.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'USE CASES' section provides clear context for when to use this tool (e.g., inventory, audit, backup). It does not explicitly state when not to use it or name alternatives, so it misses the full 5-level guidance. However, the use cases are specific enough to guide an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
DFC KEY MANAGEMENT TOOL - Advanced encryption key management and lifecycle
SUPPORTED ACTIONS: ā¢ create: Create new DFC keys with encryption algorithms (AES128GCM, AES256GCM, RSA2048, etc.) ā¢ update: Modify DFC key properties, tags, and metadata ā¢ delete: Delete DFC keys with proper cleanup ā¢ list: List DFC keys in directory with filtering ā¢ set_state: Enable/disable DFC keys for access control ā¢ rotate: Rotate DFC keys on demand with new certificates and key data
ADVANCED FEATURES: ā¢ Auto-rotation with configurable intervals (7-365 days) ā¢ Customer fragment encryption for enhanced security ā¢ Self-signed certificate generation with X.509 support ā¢ Split levels (3 or 4 fragments) for key distribution ā¢ Expiration and rotation event notifications ā¢ Comprehensive metadata and configuration support
SECURITY CAPABILITIES: ā¢ Enterprise-grade key management with audit trails ā¢ Access control and delete protection ā¢ Customer fragment integration ā¢ Certificate lifecycle management ā¢ Compliance and governance reporting
Example: Create an AES256GCM DFC key with auto-rotation for application encryption
| Name | Required | Description | Default |
|---|---|---|---|
| json | No | Set output format to JSON | |
| name | No | DFC key name/path (required for create, update, delete, set_state) | |
| path | No | Path to list keys from (for list action) | |
| tags | No | List of tags attached to this DFC key | |
| action | Yes | DFC key management action to perform. SUPPORTED ACTIONS: 'create' (create new DFC keys with encryption algorithms), 'update' (modify DFC key properties), 'delete' (delete DFC keys), 'list' (list DFC keys in directory), 'set_state' (enable/disable DFC keys), 'rotate' (rotate DFC keys on demand) | |
| rm_tags | No | Tags to remove (for update) | |
| version | No | Version to delete (-1 for all versions) | |
| add_tags | No | Tags to add (for update) | |
| key_type | No | š ENCRYPTION KEY MANAGEMENT: Encryption algorithm (AES128GCM, AES256GCM, RSA2048, etc.) - choose based on your security requirements | AES256GCM |
| metadata | No | Additional metadata in JSON format | |
| new_name | No | New name for the key (for update) | |
| filter_by | No | Filter keys by pattern (for list action) | |
| auto_rotate | No | Enable auto-rotation (None = use API default, 'true'/'false') | |
| description | No | Human-readable description of the key | |
| split_level | No | Number of fragments (3 or 4) | |
| max_versions | No | Maximum number of versions (for update) | |
| new_key_data | No | New base64 encoded value for classic keys (bring-your-own-key) | |
| accessibility | No | Accessibility level | regular |
| desired_state | No | Desired state: 'Enabled' or 'Disabled' (capitalized, for set_state) | |
| conf_file_data | No | Configuration file data | |
| delete_in_days | No | Soft delete retention period in days | |
| protection_key | No | Customer fragment ID (full UUID or partial - system automatically searches for full match) | |
| certificate_ttl | No | Certificate TTL in days (1-365) | |
| delete_protection | No | Protection from accidental deletion | |
| new_cert_pem_data | No | New PEM encoded certificate for classic keys (bring-your-own-key) | |
| rotation_event_in | No | Days before rotation to notify | |
| rotation_interval | No | Days between rotations (7-365, only used if auto_rotate is 'true') | |
| certificate_format | No | Certificate format (PEM, DER, etc.) | |
| delete_immediately | No | Delete immediately (bypass soft delete) | |
| certificate_country | No | Certificate country code | |
| expiration_event_in | No | Days before expiration to notify | |
| certificate_locality | No | Certificate locality/city | |
| certificate_province | No | Certificate province/state | |
| certificate_common_name | No | Certificate common name | |
| certificate_digest_algo | No | Certificate digest algorithm (for RSA keys, only 'sha256' is supported) | |
| certificate_organization | No | Certificate organization | |
| generate_self_signed_certificate | No | Whether to generate a self signed certificate with the key. If set, certificate_ttl must be provided. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the transparency burden. It discloses several behavioral traits like auto-rotation, soft delete, delete protection, and audit trails, but does not explain side effects (e.g., irreversibility of delete, access-control impact of set_state) or required permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Structured into clear sections and bullet points, but it is verbose with marketing-like phrases ('Enterprise-grade key management with audit trails', 'Compliance and governance reporting') and all-caps headings that add noise. The supported actions list partially duplicates the action parameter's schema description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite 37 parameters, the schema has 100% coverage and an output schema exists, so the description need not explain return values. The description covers major capabilities (auto-rotation, self-signed certificates, split levels, notification events) adequately, giving an agent enough context to operate the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds value by giving concrete algorithm examples (AES128GCM, AES256GCM, RSA2048), rotation interval range (7-365 days), and clarifying concepts like split levels and customer fragments, which supplement the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description states it is a 'DFC KEY MANAGEMENT TOOL' and enumerates concrete actions (create, update, delete, list, set_state, rotate), clearly specifying the resource (DFC keys) and the lifecycle scope. This distinguishes it from sibling manage_* tools like manage_secrets or manage_roles.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool: for DFC key lifecycle management, with a concrete example and list of supported actions. It does not explicitly mention alternatives or when-not-to-use, but the title and action list make the scope obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
GATEWAY MANAGEMENT TOOL - Monitor and manage gateway infrastructure
SUPPORTED ACTIONS: ā¢ list: List available gateways with detailed information and filtering
GATEWAY INFORMATION PROVIDED: ā¢ Gateway configuration and status ā¢ Connection details and endpoints ā¢ Performance metrics and health status ā¢ Access control and security settings ā¢ Integration and routing information
USE CASES: ā¢ Gateway infrastructure monitoring ā¢ Connection troubleshooting and diagnostics ā¢ Performance analysis and optimization ā¢ Security configuration review ā¢ Gateway inventory and management
Example: List all gateways to monitor infrastructure health
| Name | Required | Description | Default |
|---|---|---|---|
| json | No | Set output format to JSON | |
| path | No | Path to list gateways from (for list action) | |
| action | Yes | Gateway management action to perform. SUPPORTED ACTIONS: 'list' (list available gateways with detailed information and filtering) | |
| filter_by | No | Filter gateways by pattern (for list action) |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden of behavioral disclosure. It mentions 'manage gateway infrastructure' but the only supported action is 'list', which is a significant discrepancy. The description does not explicitly state that the tool is read-only, nor does it disclose potential side effects, authentication needs, or limitations beyond the supported action. The listed 'GATEWAY INFORMATION PROVIDED' adds some value, but the internal contradiction between 'manage' and 'list' undermines transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description uses all-caps headings and bullet lists, making it structured and easy to scan, but it is longer than necessary. Some content, such as the 'GATEWAY INFORMATION PROVIDED' and 'USE CASES' sections, is informative, but phrases like 'GATEWAY MANAGEMENT TOOL' and the repeated references to 'list' and 'manage' add redundancy. It is reasonably concise for the amount of context it provides, but not exceptionally so.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema, so return value details are not required from the description. The description covers use cases, an example, and the supported action, which is adequate for a simple list tool. However, the tool name 'manage_gateways' suggests broader capabilities, and the description does not clarify why only 'list' is available or whether the tool is read-only. Without annotations, the completeness is reasonable but somewhat incomplete for a tool with a misleading name.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the schema already documents each parameter (action, path, filter_by, json) with descriptive text. The description adds only a general mention of 'filtering' and 'list action', which does not meaningfully go beyond the schema. According to the baseline for high schema coverage, a score of 3 is appropriate; the description does not hinder understanding but does not enhance it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the primary action 'list' with the specific resource 'available gateways' and mentions filtering, which distinguishes it from sibling tools. However, the opening line 'Monitor and manage gateway infrastructure' overstates the scope since the only supported action is list, creating mild ambiguity about the tool's actual purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit use cases such as 'Gateway infrastructure monitoring', 'Connection troubleshooting', and 'Performance analysis', giving clear context for when to use the tool. It does not explicitly mention alternatives or exclusions, but the use cases are specific enough to guide appropriate usage, and the sibling tools are largely resource-specific rather than direct alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ROLE MANAGEMENT TOOL - Discover and analyze role-based access control
SUPPORTED ACTIONS: ā¢ list: Discover all roles with advanced filtering and pagination ā¢ get: Retrieve comprehensive role details including permissions, access rules, and policies
ROLE INFORMATION PROVIDED: ā¢ Permission sets and access rules ā¢ Associated policies and restrictions ā¢ User/group assignments and mappings ā¢ Resource access configurations ā¢ Audit and compliance information
USE CASES: ā¢ Security audits and compliance reporting ā¢ Access permission troubleshooting ā¢ Role-based access control planning ā¢ Identity and access management (IAM) integration ā¢ Permission inheritance analysis
Example: Check what permissions the 'database-admin' role has
| Name | Required | Description | Default |
|---|---|---|---|
| json | No | Return structured JSON output instead of human-readable format. Use TRUE for programmatic processing or when integrating with other tools | |
| name | No | Exact role name or path (REQUIRED for 'get' action). Examples: 'admin-role', '/production/database-admin', 'read-only-secrets' | |
| action | Yes | Role management action to perform. SUPPORTED ACTIONS: 'list' (discover all roles with filtering and pagination), 'get' (retrieve detailed role information including permissions, access rules, and policies) | |
| filter | No | Pattern to filter role names (for 'list' action). Supports wildcards and partial matches. Examples: 'admin*', '*database*', 'prod-' | |
| uid_token | No | Universal identity authentication token. Only required when using universal_identity authentication method instead of API key authentication | |
| pagination_token | No | Continuation token for retrieving next page of results when listing large numbers of roles. Returned in previous response's metadata |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses read-only behavior via 'Discover and analyze' and the list/get actions, and details the information returned (permissions, access rules, policies). It does not discuss side effects or auth requirements, but for a list/get tool, this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections for actions, provided information, and use cases. It is a bit longer than necessary, but every section adds value, especially the example. It is front-loaded with the tool's purpose and supported actions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only role management tool with two actions, the description is complete: it lists actions, role information categories, use cases, and an example. It fully prepares the agent to use the tool correctly, even without an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage with detailed parameter docs (e.g., name required for get, filter wildcards). The description adds some context by reinforcing role info and providing an example, but it doesn't go beyond the schema's parameter semantics, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Discover and analyze role-based access control' with two specific actions, list and get. This distinguishes it from sibling manage_* tools by focusing on RBAC discovery and analysis.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a dedicated USE CASES section and an example, providing clear context for when to use the tool. It does not explicitly mention when not to use it or name alternatives, but the use cases and example are enough for practical guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ROTATION SETTINGS MANAGEMENT TOOL - Automate secret and key rotation for security compliance
SUPPORTED ACTIONS: ā¢ set_rotation: Set rotation settings for secrets and keys with scheduling ā¢ update_settings: Update existing rotation configurations and parameters ā¢ list_rotation: List items with rotation settings and status ā¢ get_rotation_status: Get detailed rotation status and history information
ROTATION FEATURES: ā¢ Auto-rotation with configurable intervals (7-365 days) ā¢ Rotation event notifications and scheduling ā¢ Advanced rotation windows and cron-based scheduling ā¢ Rotate after disconnect settings for security ā¢ Comprehensive rotation status tracking and reporting
SECURITY BENEFITS: ā¢ Automated security through intelligent rotation scheduling ā¢ Enterprise-grade rotation with access control and audit trails ā¢ Compliance with security policies and regulations ā¢ Reduced manual intervention and human error ā¢ Proactive security through regular credential updates
Example: Set up automated rotation for database credentials every 30 days
| Name | Required | Description | Default |
|---|---|---|---|
| json | No | Set output format to JSON | |
| path | No | Path to list rotation settings from (for list_rotation action) | |
| action | Yes | Rotation settings management action to perform. SUPPORTED ACTIONS: 'set_rotation' (set rotation settings for secrets and keys), 'update_settings' (update existing rotation configurations), 'list_rotation' (list items with rotation settings), 'get_rotation_status' (get detailed rotation status information) | |
| filter_by | No | Filter items by pattern (for list_rotation action) | |
| item_name | No | Item name to manage rotation for (required for set_rotation, update_settings, get_rotation_status) | |
| auto_rotate | No | Enable auto-rotation | |
| rotation_window | No | Rotation window (e.g., '30d', '1w') | |
| rotation_event_in | No | Rotation event notifications | |
| rotation_interval | No | Rotation interval in days (7-365) | |
| rotation_schedule | No | Rotation schedule (cron format) | |
| rotate_after_disconnect | No | Rotate after disconnect setting |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full disclosure burden. It mentions configurable intervals, cron scheduling, and notifications, but omits critical behavioral traits such as whether updates are irreversible, permissions required, or if rotation occurs immediately. The 'security benefits' section is marketing language rather than operational transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is verbose, padded with a 'SECURITY BENEFITS' section that adds little operational value. It could convey the same core information in half the length. The structure is organized, but all-caps formatting and repetitive marketing phrases hurt readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a complex tool with 11 parameters and 4 actions, yet the description does not specify which parameters are required for each action or explain parameter interplays like rotation_interval vs rotation_schedule. The output schema exists, but the agent needs more action-level guidance to invoke correctly; the example is illustrative but insufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for all 11 parameters, so the baseline is 3. The description adds some context by grouping features like 'Auto-rotation with configurable intervals (7-365 days)' which maps to rotation_interval, but it largely duplicates schema descriptions. It does not clarify action-specific parameter dependencies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as a rotation settings manager for secrets and keys, enumerating four supported actions (set_rotation, update_settings, list_rotation, get_rotation_status). It differentiates itself from sibling tools by focusing specifically on rotation rather than general secret management, though it does not explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied through the listed actions and an example (setting rotation for database credentials every 30 days), giving some context. However, there is no explicit guidance on when to use this tool versus manage_secrets or other siblings, nor any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
SECRETS MANAGEMENT TOOL - Create, retrieve, update, and delete secrets
SUPPORTED ACTIONS:
ā¢ create_static_secret: Create text/JSON secrets with metadata
ā¢ get_static_secret_value: Retrieve secret values securely
ā¢ update: Modify secret properties and values
ā¢ delete: Delete individual secrets (smart detection)
ā¢ delete_items: Bulk delete multiple secrets or directories
ā¢ list: List secrets in directory with type filtering
ā¢ list_dynamic_secrets: List all dynamic secrets globally
ā¢ create_dynamic_secret_ldap: Create LDAP dynamic secrets
ā¢ create_dynamic_secret_mysql: Create MySQL dynamic secrets
ā¢ create_dynamic_secret_mongodb: Create MongoDB dynamic secrets
ā¢ list_shared_items: List shared secrets and items
DELETE OPERATIONS: ā¢ Individual: delete(name="/secret1") ā¢ Multiple: delete_items(items=["/secret1", "/secret2"]) ā¢ Directory: delete_items(path="/directory/")
Example: Create a database password secret
| Name | Required | Description | Default |
|---|---|---|---|
| ssl | No | Enable/Disable SSL for MySQL dynamic secrets | |
| ttl | No | Time to live in seconds (for dynamic secrets) | |
| json | No | Set output format to JSON | |
| name | No | Secret/directory name/path (required for create_static_secret, get_static_secret_value, update, delete) | |
| path | No | Path to list secrets from (for list action only - not used for list_dynamic_secrets) | |
| tags | No | Tags to attach to the dynamic secret | |
| items | No | List of item names to delete (for bulk delete). Must be an array of strings, e.g., ['/item1', '/item2'] | |
| value | No | Secret value (required for create_static_secret, optional for update) | |
| action | Yes | Secret management action to perform. SUPPORTED ACTIONS: 'create_static_secret' (create text/JSON secrets), 'get_static_secret_value' (retrieve secret values), 'update' (modify secret properties), 'delete' (smart delete individual items), 'delete_items' (bulk delete multiple items or directories), 'list' (list secrets in directory with type filtering), 'list_dynamic_secrets' (list all dynamic secrets globally), 'create_dynamic_secret_ldap' (create LDAP dynamic secrets), 'create_dynamic_secret_mysql' (create MySQL dynamic secrets), 'create_dynamic_secret_mongodb' (create MongoDB dynamic secrets), 'list_shared_items' (list shared secrets/items) | |
| format | No | Secret format: 'text', 'json', 'key-value' | text |
| bind_dn | No | Bind DN for LDAP dynamic secrets | |
| user_dn | No | User DN for LDAP dynamic secrets | |
| version | No | Version to delete (-1 for all versions) | |
| group_dn | No | Group DN for temporary user addition | |
| ldap_url | No | LDAP Server URL for dynamic secrets | |
| metadata | No | Additional metadata in JSON format | |
| new_name | No | New name for the secret (for update action) | |
| password | No | Password for the secret | |
| user_ttl | No | User TTL for dynamic secrets (default: 60m) | 60m |
| username | No | Username for the secret | |
| filter_by | No | Filter secrets by pattern (for list action only - not used for list_dynamic_secrets) | |
| inject_url | No | Website context URLs | |
| mysql_host | No | MySQL host for dynamic secrets | 127.0.0.1 |
| mysql_port | No | MySQL port for dynamic secrets | 3306 |
| auto_rotate | No | Enable auto-rotation (for rotated secrets) | |
| description | No | Secret description | |
| secret_type | No | Secret type: 'static' (for create_static_secret action only). For dynamic secrets, use specific actions: create_dynamic_secret_ldap/mysql/mongodb | static |
| target_name | No | Target name to associate with dynamic secret | |
| change_event | No | Trigger an event when a secret value changed | |
| custom_field | No | Custom key-value pairs | |
| dynamic_type | No | Dynamic secret type (for dynamic secrets) | |
| ldap_ca_cert | No | CA Certificate File Content for LDAP | |
| max_versions | No | Maximum number of versions to keep | |
| mongodb_name | No | MongoDB name for dynamic secrets | |
| mysql_dbname | No | MySQL database name for dynamic secrets | |
| secret_types | No | Filter by secret types within the specified directory. Options: ['static-secret', 'dynamic-secret', 'rotated-secret']. Leave empty to include all types. Note: This filters within the specified path, unlike 'list_dynamic_secrets' which searches globally. | |
| accessibility | No | Accessibility level | regular |
| host_provider | No | Host provider type [explicit/target] | explicit |
| mongodb_roles | No | MongoDB roles (default: []) | [] |
| provider_type | No | Provider type for LDAP dynamic secrets | |
| db_server_name | No | Server name for certificate verification | |
| delete_in_days | No | Soft delete retention period in days | |
| mysql_password | No | MySQL password for dynamic secrets | |
| mysql_username | No | MySQL username for dynamic secrets | |
| protection_key | No | Protection key name | |
| user_attribute | No | User attribute for LDAP dynamic secrets | |
| multiline_value | No | Whether the provided value is multiline | |
| password_length | No | Length of password to be generated for dynamic secrets | |
| ssl_certificate | No | SSL connection certificate for MySQL | |
| bind_dn_password | No | Bind DN Password for LDAP dynamic secrets | |
| mongodb_password | No | MongoDB server password | |
| mongodb_username | No | MongoDB server username | |
| token_expiration | No | Token expiration for LDAP dynamic secrets | |
| delete_protection | No | Protection from accidental deletion [true/false] | |
| external_username | No | Use externally provided username [true/false] | |
| mongodb_host_port | No | MongoDB server host and port | |
| rotation_interval | No | Rotation interval in seconds (for rotated secrets) | |
| secure_access_web | No | Enable Web Secure Remote Access (for database dynamic secrets) | |
| delete_immediately | No | Delete immediately (bypass soft delete) | |
| mongodb_server_uri | No | MongoDB server URI | |
| secure_access_host | No | Target servers for connections | |
| mongodb_custom_data | No | MongoDB custom data | |
| mongodb_uri_options | No | MongoDB server URI options | |
| secure_access_delay | No | Delay duration in seconds (0-120) after generating credentials | |
| secure_access_enable | No | Enable/Disable secure remote access [true/false] | |
| db_server_certificates | No | DB server certificates for verification | |
| mongodb_default_auth_db | No | MongoDB default authentication database | |
| custom_username_template | No | Custom username template using go template syntax | |
| fixed_user_claim_keyname | No | Key-name of IdP claim for external username | ext_username |
| mongodb_atlas_project_id | No | MongoDB Atlas project ID | |
| mysql_creation_statements | No | MySQL creation statements | |
| mysql_revocation_statements | No | MySQL revocation statements | |
| mongodb_atlas_api_public_key | No | MongoDB Atlas API public key | |
| producer_encryption_key_name | No | Dynamic producer encryption key name | |
| mongodb_atlas_api_private_key | No | MongoDB Atlas API private key | |
| secure_access_certificate_issuer | No | Path to SSH Certificate Issuer for Secure Access |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It offers minimal insight into side effects, permissions, reversibility, or safety risks (e.g., no warning that 'delete' might be permanent or require special privileges). The phrase 'smart detection' and 'securely retrieve' add some context, but the overall transparency is weak for a tool with such destructive operations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is verbose and largely redundant with the schema's action parameter description, which repeats the same action list verbatim. While the section headers (SUPPORTED ACTIONS, DELETE OPERATIONS) provide some structure, the content is not appropriately sized for the value it addsāmany sentences simply restate what the schema already documents.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 76 parameters and 11 actions, the description provides a comprehensive action list and some delete examples, but it lacks per-action parameter mapping, prerequisites, or warnings. The output schema exists, so return values are covered, but the description does not fully compensate for the tool's complexity in navigating correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100% and the individual parameter descriptions are detailed, so the baseline is 3. The tool description adds a few usage examples (e.g., 'delete(name="/secret1")') and groups delete-related parameters, but it does not systematically explain which action requires which parameters or add meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create, retrieve, update, and delete secrets' and lists all supported actions, making the tool's purpose unambiguous. However, it does not explicitly differentiate this tool from sibling tools like manage_auth_methods or manage_targets, though the domain is evident from the name and content.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage through its 'SUPPORTED ACTIONS' list and delete examples, but it never explicitly states when to use this tool versus alternatives or provides exclusion criteria. It lacks a clear 'use this when...' statement, leaving the agent to infer context from the action names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
TARGET MANAGEMENT TOOL - Manage external system connections and integrations
SUPPORTED ACTIONS: ā¢ list: Discover all configured targets with filtering ā¢ get: Retrieve detailed target configuration and credentials ā¢ create: Create new database or LDAP targets ā¢ delete: Delete individual target with version control ā¢ delete_targets: Bulk delete targets within a specific path
SUPPORTED TARGET TYPES: ā¢ Database: MySQL, PostgreSQL, MSSQL, Oracle, Snowflake, MongoDB, Cassandra, HanaDB, Redshift, Redis ā¢ LDAP: OpenLDAP, Active Directory ā¢ Cloud: AWS, Azure, GCP
Example: Create a MySQL database target for application connections
| Name | Required | Description | Default |
|---|---|---|---|
| pwd | No | Password (REQUIRED for database targets) | |
| ssl | No | Enable/Disable SSL connection to database | |
| host | No | Host address or endpoint (REQUIRED for database targets) | |
| json | No | Return structured JSON output for programmatic processing. Use TRUE when integrating with automation scripts or other tools | |
| name | No | Exact target name or identifier (REQUIRED for 'get' and 'create' actions). Examples: 'prod-mysql-db', 'aws-production', 'k8s-cluster-west' | |
| path | No | Path to delete targets from (for delete_targets action) | |
| port | No | Port number (optional, uses default if not specified) | |
| action | Yes | Target management action to perform. SUPPORTED ACTIONS: 'list' (discover all targets with filtering), 'get' (retrieve detailed target configuration), 'create' (create new database/LDAP targets), 'delete' (delete individual target), 'delete_targets' (bulk delete targets by path) | |
| filter | No | Pattern to filter target names (for 'list' action). Supports wildcards. Examples: 'prod-*', '*database*', 'aws-*' | |
| bind_dn | No | Bind DN (REQUIRED for LDAP targets) | |
| db_name | No | Database name (REQUIRED for database targets) | |
| db_type | No | Database type for database targets. Supported values: 'mysql', 'mssql', 'hanadb', 'postgres', 'mongodb', 'snowflake', 'oracle', 'cassandra', 'redshift', 'redis' | |
| ldap_url | No | LDAP Server URL (REQUIRED for LDAP targets) | |
| uid_token | No | Universal identity authentication token. Only required when using universal_identity authentication instead of standard API key authentication | |
| user_name | No | Username (REQUIRED for database targets) | |
| description | No | Description of the target for documentation and management purposes | |
| server_type | No | LDAP server type. Options: 'OpenLDAP', 'ActiveDirectory' | OpenLDAP |
| target_type | No | Type of target to create (REQUIRED for 'create' action). Examples: 'database', 'ldap', 'aws', 'azure', 'gcp', 'k8s', 'ssh' | |
| cluster_mode | No | Enable cluster mode for high availability (database targets) | |
| ldap_ca_cert | No | CA Certificate File Content for LDAP | |
| max_versions | No | Maximum number of versions to keep for the target | |
| target_types | No | Filter by specific target types. SUPPORTED: ['mysql', 'postgres', 'mongodb', 'aws', 'azure', 'gcp', 'k8s', 'ssh', 'ldap', 'github', 'dockerhub', 'artifactory', 'salesforce', 'snowflake', 'redshift', 'mssql', 'cassandra', 'hanadb', 'rabbitmq', 'venafi', 'chef', 'web', 'gke', 'eks', 'oracle']. Use multiple types as array. | |
| mongodb_atlas | No | Enable MongoDB Atlas specific configuration | |
| show_versions | No | Include complete version history and configuration changes for the target (for 'get' action). Essential for audit trails and rollback scenarios | |
| db_server_name | No | Server name for certificate verification | |
| force_deletion | No | Enforce deletion (bypass protection) | |
| protection_key | No | Protection key name for encrypting target secrets (uses account default if not specified) | |
| target_version | No | Target version (for 'get' action: retrieve specific version, for 'delete' action: delete specific version). Use 0 for latest, positive integers for specific versions, or omit for current active version | |
| azure_client_id | No | Azure client ID for cloud identity authentication | |
| azure_tenant_id | No | Azure tenant ID for cloud identity authentication | |
| connection_type | No | Type of connection to database. Options: 'credentials', 'cloud-identity', 'wallet', 'parent-target' | credentials |
| ssl_certificate | No | SSL connection certificate data | |
| bind_dn_password | No | Bind DN Password (REQUIRED for LDAP targets) | |
| pagination_token | No | Continuation token for large result sets. Automatically provided in previous response metadata when more results are available | |
| token_expiration | No | Token expiration for LDAP | |
| snowflake_account | No | Snowflake account identifier | |
| parent_target_name | No | Name of the parent target (required when connection-type is 'parent-target') | |
| azure_client_secret | No | Azure client secret for cloud identity authentication | |
| mongodb_uri_options | No | MongoDB server URI options | |
| oracle_service_name | No | Oracle database service name | |
| cloud_service_provider | No | Cloud service provider (currently supports Azure) | |
| db_server_certificates | No | Database server certificates for verification | |
| mongodb_default_auth_db | No | MongoDB server default authentication database | |
| mongodb_atlas_project_id | No | MongoDB Atlas project ID | |
| oracle_wallet_login_type | No | Oracle Wallet login type (password/mtls) | |
| snowflake_api_private_key | No | Snowflake RSA private key (base64 encoded) | |
| oracle_wallet_p12_file_data | No | Oracle wallet p12 file data in base64 | |
| oracle_wallet_sso_file_data | No | Oracle wallet sso file data in base64 | |
| mongodb_atlas_api_public_key | No | MongoDB Atlas API public key | |
| mongodb_atlas_api_private_key | No | MongoDB Atlas API private key | |
| snowflake_api_private_key_password | No | Snowflake private key passphrase |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full burden of disclosing behavioral traits, but it only mentions version control for delete and high-level actions. It does not disclose safety implications, permission requirements, side effects of create/delete, or any special behaviors like pagination or credential handling, which are critical for a tool handling external connections.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections for actions and target types, and it is front-loaded with the tool purpose. It avoids excessive wordiness while providing an informative overview, though the uppercase heading and repetitive formatting could be slightly tighter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema and rich parameter descriptions, the description lacks critical context for a high-complexity tool. It does not clarify which parameters apply to which actions, omits safety/versioning details beyond a mention, and creates ambiguity by stating create supports database/LDAP while the schema includes cloud types. This leaves gaps that could confuse an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3 since parameter details are already well-documented within the schema. The description adds limited value by listing target types and an example, but it does not deepen understanding of parameter relationships or action-specific requirements beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as managing targets (external system connections/integrations) and lists specific supported actions (list, get, create, delete, delete_targets). While 'manage' is a generic verb, the action list provides concrete functionality and distinguishes it from other management tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by framing targets as external connections and listing actions/types, but it does not explicitly state when to use this tool versus alternatives like manage_secrets or manage_account. There are no exclusions or comparative guidance, leaving usage partially implied rather than clearly directed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
SECURITY GUIDELINES TOOL - Comprehensive security guidance and compliance management
SUPPORTED ACTIONS: ā¢ get_guidelines: Get security best practices and guidelines by category ā¢ validate: Validate secrets and configurations for security compliance ā¢ audit: Perform comprehensive security audits and assessments ā¢ compliance_check: Check compliance with industry standards (SOC2, ISO27001, GDPR, HIPAA)
SECURITY CATEGORIES: ā¢ best_practices: Security best practices and recommendations ā¢ compliance: Compliance frameworks and requirements ā¢ audit: Security audit procedures and checklists ā¢ encryption: Encryption standards and key management
COMPLIANCE STANDARDS: ā¢ SOC2: Service Organization Control 2 compliance ā¢ ISO27001: Information security management systems ā¢ GDPR: General Data Protection Regulation ā¢ HIPAA: Health Insurance Portability and Accountability Act
SECURITY FEATURES: ā¢ Enterprise-grade security with access control and audit trails ā¢ Automated security validation and compliance checking ā¢ Comprehensive audit procedures and reporting ā¢ Industry-standard compliance framework support
Example: Perform security audit and compliance check for SOC2 requirements
| Name | Required | Description | Default |
|---|---|---|---|
| json | No | Set output format to JSON | |
| action | Yes | Security guidance action to perform. SUPPORTED ACTIONS: 'get_guidelines' (get security best practices and guidelines), 'validate' (validate secrets and configurations for security), 'audit' (perform comprehensive security audits), 'compliance_check' (check compliance with industry standards) | |
| context | No | Context for validation/audit | |
| category | No | Category: 'best_practices', 'compliance', 'audit', 'encryption' | best_practices |
| audit_path | No | Path to audit (for audit action) | |
| audit_type | No | Audit type: 'security', 'compliance', 'access' | security |
| secret_name | No | Secret name to validate (for validate action) | |
| secret_value | No | Secret value to validate (for validate action) | |
| compliance_standard | No | Compliance standard: 'SOC2', 'ISO27001', 'GDPR', 'HIPAA' |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions enterprise-grade security, access control, and audit trails, but does not explicitly state whether actions are read-only or have side effects. The actions listed all appear to be read-only queries, but this is never clarified, leaving room for ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections for actions, categories, standards, and features, and ends with a practical example. It is somewhat longer than necessaryāparticularly the 'SECURITY FEATURES' section, which partly repeats capabilities already statedābut the organization makes it easy to scan and the content is largely non-redundant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (9 parameters, 4 actions, multiple categories and standards), the description covers all major aspects: supported actions, categories, compliance standards, and an example. An output schema exists, so the lack of explicit return-value details is acceptable. The description is complete enough for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers all 9 parameters with descriptions, so the baseline is 3. The description adds value by elaborating on the meaning of 'category' values (e.g., 'best_practices: Security best practices and recommendations') and explaining each compliance standard (SOC2, ISO27001, GDPR, HIPAA), which goes beyond the schema's simple enum lists.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a clear statement of purpose: 'Comprehensive security guidance and compliance management', then enumerates four distinct actions (get_guidelines, validate, audit, compliance_check). This clearly distinguishes the tool from siblings that manage secrets or auth methods, as it focuses on guidance, validation, and compliance rather than operational management.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description lists supported actions and categories, and includes an example ('Perform security audit and compliance check for SOC2 requirements'), which provides clear context for when to use the tool. However, it does not explicitly state when not to use it or mention alternative tools, such as manage_secrets, for related but different tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0get_api_referencemanage_accountmanage_analyticsmanage_auth_methodsmanage_customer_fragmentsmanage_dfc_keysmanage_gatewaysmanage_rolesmanage_rotation_settingsmanage_secretsmanage_targetssecurity_guidelinesScored across 12 tools
Each tool targets a distinct resource area, from secrets and keys to account, analytics, and security guidelines. Even closely related tools like manage_secrets and manage_dfc_keys are clearly separated by their resource types and actions.
The naming is largely consistent with a 'manage_<resource>' pattern for 10 of 12 tools, but 'get_api_reference' and 'security_guidelines' deviate. This is a minor inconsistency that does not obscure the tools' purposes.
With 12 tools, the server is well-scoped for a secrets and key management platform. Each tool covers a meaningful subdomain without redundancy, fitting comfortably within the ideal 3-15 tool range.
Core lifecycle operations are covered for secrets, DFC keys, auth methods, and targets, with rotation and security guidelines included. Minor gaps exist: manage_targets lacks an update action, manage_account is read-only, and dynamic secret support covers only LDAP, MySQL, and MongoDB, but these can be worked around.
Governed MCP gateway: one endpoint for your tools, with credential custody and audit log.
MCP server for Appcircle mobile CI/CD platform.
Authenticated MCP server for ClearPolicy policy and compliance workflows.
MCP server for mandates, delegation, policy-gated execution, credential grants, and audit.
