🔍 Get comprehensive deployment details for easy copying to Clay or other tools. Retrieves complete information about a specific deployment including code, input examples, and ready-to-use curl commands for external integrations. Perfect for: - Getting curl commands for external API calls - Under...
Part of the DataGen server.
Free to start. No card required.
AI agents call getDeploymentDetails to retrieve information from DataGen without modifying any data. This is common in research, monitoring, and reporting workflows where the agent needs context before taking action. Because read operations don't change state, they are generally safe to allow without restrictions -- but you may still want rate limits to control API costs.
Even though getDeploymentDetails only reads data, uncontrolled read access can leak sensitive information or rack up API costs. An agent caught in a retry loop could make thousands of calls per minute. A rate limit gives you a safety net without blocking legitimate use.
Read-only tools are safe to allow by default. No rate limit needed unless you want to control costs.
{
"version": "1",
"default": "deny",
"tools": {
"getDeploymentDetails": {}
}
}See the full DataGen policy for all 20 tools.
These attack patterns abuse exactly the kind of access getDeploymentDetails gives an agent. Each links to the full case and the policy that stops it:
Other read tools across the catalogue. The same approach applies to each: allow, with a rate cap to control cost.
🔍 Get comprehensive deployment details for easy copying to Clay or other tools. Retrieves complete information about a specific deployment including code, input examples, and ready-to-use curl commands for external integrations. Perfect for: - Getting curl commands for external API calls - Understanding deployment input/output schemas - Integrating deployments into external systems Parameters: - deployment_uuid: UUID of the deployment - brief: (optional, default: false) Set to true to get only essential information for LLM understanding (name, description, input/output schemas, and example values) Returns: - Complete deployment metadata and code (when brief=false) - Ready-to-copy curl commands for sync and async execution - Input/output schemas with examples - API endpoint information for external use - When brief=true: Only name, description, input_vars, input_schema, output_schema, and default_input_vars 📊 Create Accessible Mermaid Flowchart from Code: After receiving the response, analyze the final_code field and create clear mermaid diagrams that help non-technical users understand and interact with the code: 🚨 CRITICAL SYNTAX REQUIREMENT: Always use double-quoted brackets for all nodes: A["Node Content"] NOT A[Node Content] Process Flow Structure: - Use top-to-bottom flowchart format (flowchart TD) - Show main workflow with clear start and end points - Include decision points (diamonds) for conditional logic - Use descriptive labels in plain English, avoiding technical jargon - Group related functions into logical sections with subgraphs when helpful Function Details: For each function/process box, include: - Function name in readable format (e.g., "Get Repository Data" instead of "mcp_GitHub_get_repo()") - Key arguments/inputs that users might want to modify - Purpose in simple terms (what it does, not how) - Format: A["Function Name<br/>Purpose: [what it accomplishes]<br/>Input: [key parameters]"] Data Classification - Use color coding and styling: - 📝 User inputs (blue/cyan boxes): Variables users can modify - ⚙️ Processing steps (green boxes): Data transformation and logic - 🔗 External calls (orange boxes): MCP tools, APIs, external services - 📊 Outputs (purple boxes): Final results and return values - 🔄 Decision points (yellow diamonds): Conditional logic and branching - ⚠️ Hardcoded values (red/pink boxes): Fixed data not user-configurable (URLs, API keys, constants) Code Analysis Requirements: - Parse the final_code to understand real processing workflow - Extract function calls especially MCP tool calls (starting with mcp_) - Identify control flow including if/else conditions, loops, try/catch blocks - Map data transformations showing how inputs become outputs - Detect service interactions between different tools and APIs - Identify hardcoded values that are embedded in code vs user-configurable - Make technical concepts accessible to non-technical users. It is categorised as a Read tool in the DataGen MCP Server, which means it retrieves data without modifying state.
Register the DataGen MCP server in PolicyLayer and add a rule for getDeploymentDetails: allow, deny, rate-limit, or require approval. Point your MCP client at the PolicyLayer proxy URL and the rule is enforced on every call, before it reaches DataGen. Nothing to install.
getDeploymentDetails is a Read tool with low risk. Read-only tools are generally safe to allow by default.
Yes. Add a rate_limit block to the getDeploymentDetails rule in your PolicyLayer policy. For example, setting max: 10 and window: 60 limits the tool to 10 calls per minute. Rate limits are tracked per agent session and reset automatically.
Set action: deny in the PolicyLayer policy for getDeploymentDetails. The AI agent will receive a policy violation error and cannot call the tool. You can also include a reason field to explain why the tool is blocked.
getDeploymentDetails is provided by the DataGen MCP server (kuoyusheng/datagendev). PolicyLayer sits as a proxy in front of this server to enforce policies before tool calls reach the server.
Deterministic rules across all 20 DataGen tools. Per-identity grants. Full audit log. Live in minutes. Nothing to install.
Free to start. No card required.
4,600+ MCP servers and 31,000+ tools scanned and risk-classified.