🔍 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...
Single-target operation
Part of the DataGen MCP server. Enforce policies on this tool with Intercept, the open-source MCP proxy.
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.
tools:
getDeploymentDetails:
rules:
- action: allowSee the full DataGen policy for all 20 tools.
Agents calling read-class tools like getDeploymentDetails have been implicated in these attack patterns. Read the full case and prevention policy for each:
Other tools in the Read risk category across the catalogue. The same policy patterns (rate-limit, allow) apply to each.
🔍 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.
Add a rule in your Intercept YAML policy under the tools section for getDeploymentDetails. You can allow, deny, rate-limit, or validate arguments. Then run Intercept as a proxy in front of the DataGen MCP server.
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 Intercept 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 Intercept 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). Intercept sits as a proxy in front of this server to enforce policies before tool calls reach the server.
Open source. One binary. Zero dependencies.
npx -y @policylayer/intercept