Skip to main content
Glama
marco-looy

Pega DX MCP Server

by marco-looy

perform_case_action

Execute workflow actions on Pega cases to update data and progress business processes using case-specific operations and field modifications.

Instructions

Perform an action on a Pega case, updating case data and progressing the workflow. Takes the case ID and action ID as parameters, along with optional content, page instructions, and attachments. If no eTag is provided, automatically fetches the latest eTag from the case action. For manual eTag management, provide an eTag value from a previous get_case_action call. The API handles pre-processing logic, merges request data into the case, performs the action, and validates the results.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
caseIDYesCase ID. Example: "MYORG-APP-WORK C-1001". Complete identifier including spaces."ON6E5R-DIYRecipe-Work-RecipeCollection R-1008". a complete case identifier including spaces and special characters.
actionIDYesAction ID for case/stage action (Example: "pyUpdateCaseDetails", "pyApproval"). CRITICAL: Action IDs are CASE-SENSITIVE and have no spaces even if display names do ("Edit details" → "pyUpdateCaseDetails"). Use get_case to find correct ID from availableActions array - use "ID" field not "name" field.
eTagNoOptional. Auto-fetched if omitted. For faster execution, use eTag from previous response.
contentNoOptional map of scalar and embedded page values to be set to the fields included in the case action's view. Only fields that are part of the submitted case action's view can be modified. Field names should match the property names defined in the Pega application. Example: {"CustomerName": "John Doe", "Priority": "High", "Status": "InProgress"}. Values will overwrite any settings made from pre-processing Data Transforms.
pageInstructionsNoOptional list of page-related operations for embedded pages, page lists, or page groups. Required for setting embedded page references. Only pages included in the case action's view can be modified.
attachmentsNoOptional list of attachments to be added to or deleted from specific attachment fields included in the case action's view. Each attachment entry specifies the operation (add/delete) and attachment details. Only attachment fields included in the case action's view can be modified.
viewTypeNoType of UI resources to return in the response. "none" returns no UI resources (default), "form" returns form UI metadata in read-only review mode without page-specific metadata, "page" returns full page UI metadata in read-only review mode. Use "form" or "page" when you need UI structure information for displaying the results.none
skipRoboticAutomationNoWhen set to true, post processing robotic automation is skipped while submitting the form. When set to false, post processing robotic automation is considered while submitting the form. Default: false. Use true when robotic automation failures are preventing form submission.
originChannelNoOptional origin channel identifier for this service request. Indicates the source of the request for tracking and audit purposes. Examples: "Web", "Mobile", "WebChat". Default value is "Web" if not specified.
sessionCredentialsNoOptional session-specific credentials. If not provided, uses environment variables. Supports two authentication modes: (1) OAuth mode - provide baseUrl, clientId, and clientSecret, or (2) Token mode - provide baseUrl and accessToken.
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden and does well by disclosing key behavioral traits: it describes automatic eTag fetching, manual eTag management, pre-processing logic, data merging, action execution, and result validation. It also mentions the API's handling of these processes, though it could elaborate more on error conditions or 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.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is appropriately sized and front-loaded with the core purpose. Each sentence adds value: explaining parameters, eTag behavior, and API processing. While efficient, it could be slightly more structured with bullet points for complex behaviors, but remains clear without wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (10 parameters, workflow mutation, no output schema, no annotations), the description is adequate but has gaps. It explains the action well but doesn't detail response format, error handling, or specific prerequisites beyond eTags. For a mutation tool with rich parameters, more completeness would be beneficial.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents all 10 parameters thoroughly. The description adds some context about eTag auto-fetching and manual management, but doesn't provide significant additional parameter meaning beyond what's in the schema. This meets the baseline for high schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose with specific verbs ('perform an action', 'updating case data', 'progressing the workflow') and identifies the resource ('Pega case'). It distinguishes this from sibling tools like 'update_case' by emphasizing workflow progression and action execution rather than simple data updates.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context about when to use this tool ('updating case data and progressing the workflow') and mentions prerequisites like fetching eTags from 'get_case_action'. However, it doesn't explicitly contrast when to use this versus alternatives like 'perform_assignment_action' or 'change_to_next_stage', which are also workflow-related sibling tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/marco-looy/pega-dx-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server