Skip to main content
Glama
marco-looy

Pega DX MCP Server

by marco-looy

get_case_view

Retrieve view details and metadata for a specific case using its ID and view name, with customizable logic from pyUpgradeOnOpen Data Transform.

Instructions

Get view details based on case ID and view name. Returns view metadata with customizable logic from pyUpgradeOnOpen Data Transform.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
caseIDYesCase ID. Example: "MYORG-APP-WORK C-1001". Complete identifier including spaces.
viewIDYesName of the view to retrieve
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.

Implementation Reference

  • The execute method implements the core logic of the get_case_view tool: parameter validation, session initialization, API call to pegaClient.getCaseView, error handling, and response formatting.
    async execute(params) {
      const { caseID, viewID } = params;
      let sessionInfo = null;
    
      try {
        // Initialize session configuration if provided
        sessionInfo = this.initializeSessionConfig(params);
    
        // Validate required parameters using base class
        const requiredValidation = this.validateRequiredParams(params, ['caseID', 'viewID']);
        if (requiredValidation) {
          return requiredValidation;
        }
    
        // Execute with standardized error handling
        return await this.executeWithErrorHandling(
          `Case View Details: ${viewID} for ${caseID}`,
          async () => await this.pegaClient.getCaseView(caseID.trim(), viewID.trim()),
          { caseID, viewID, sessionInfo }
        );
      } catch (error) {
        return {
          content: [{
            type: 'text',
            text: `## Error: Get Case View\n\n**Unexpected Error**: ${error.message}\n\n${sessionInfo ? `**Session**: ${sessionInfo.sessionId} (${sessionInfo.authMode} mode)\n` : ''}*Error occurred at: ${new Date().toISOString()}*`
          }]
        };
      }
    }
  • The getDefinition static method defines the tool name, description, and input schema for validation.
    static getDefinition() {
      return {
        name: 'get_case_view',
        description: 'Get view details based on case ID and view name. Returns view metadata with customizable logic from pyUpgradeOnOpen Data Transform.',
        inputSchema: {
          type: 'object',
          properties: {
            caseID: {
              type: 'string',
              description: 'Case ID. Example: "MYORG-APP-WORK C-1001". Complete identifier including spaces.'
            },
            viewID: {
              type: 'string',
              description: 'Name of the view to retrieve'
            },
            sessionCredentials: getSessionCredentialsSchema()
          },
          required: ['caseID', 'viewID']
        }
      };
    }
  • Custom formatSuccessResponse method provides tailored markdown output including case info, UI resources summary, and session details.
    formatSuccessResponse(operation, data, options = {}) {
      const { caseID, viewID, sessionInfo } = options;
    
      let response = `## ${operation}\n\n`;
    
      response += `*Operation completed at: ${new Date().toISOString()}*\n\n`;
    
      // Session Information (if applicable)
      if (sessionInfo) {
        response += `### Session Information\n`;
        response += `- **Session ID**: ${sessionInfo.sessionId}\n`;
        response += `- **Authentication Mode**: ${sessionInfo.authMode.toUpperCase()}\n`;
        response += `- **Configuration Source**: ${sessionInfo.configSource}\n\n`;
      }
      
      // Display case data if available
      if (data.data) {
        response += '### Case Data\n';
        
        // Handle case info
        if (data.data.caseInfo) {
          const caseInfo = data.data.caseInfo;
          response += `- **Case Type**: ${caseInfo.caseTypeName || 'N/A'}\n`;
          response += `- **Status**: ${caseInfo.status || 'N/A'}\n`;
          response += `- **Stage**: ${caseInfo.stage || 'N/A'}\n`;
          response += `- **Step**: ${caseInfo.step || 'N/A'}\n`;
          response += `- **Urgency**: ${caseInfo.urgency || 'N/A'}\n`;
          response += `- **Last Updated**: ${caseInfo.lastUpdateTime || 'N/A'}\n`;
          
          // Display content if available
          if (caseInfo.content && Object.keys(caseInfo.content).length > 0) {
            response += '\n#### Case Content\n';
            for (const [key, value] of Object.entries(caseInfo.content)) {
              if (value !== null && value !== undefined) {
                response += `- **${key}**: ${value}\n`;
              }
            }
          }
        }
    
        // Display any other data properties
        const otherDataKeys = Object.keys(data.data).filter(key => key !== 'caseInfo');
        if (otherDataKeys.length > 0) {
          response += '\n#### Additional Data\n';
          otherDataKeys.forEach(key => {
            const value = data.data[key];
            if (value !== null && value !== undefined) {
              if (typeof value === 'object') {
                response += `- **${key}**: ${JSON.stringify(value, null, 2)}\n`;
              } else {
                response += `- **${key}**: ${value}\n`;
              }
            }
          });
        }
      }
    
      // Display UI resources if available
      if (data.uiResources) {
        response += '\n### UI Resources\n';
        response += '- View metadata loaded successfully\n';
        
        if (data.uiResources.root) {
          response += `- **Root Component Type**: ${data.uiResources.root.type || 'Unknown'}\n`;
          
          if (data.uiResources.root.config) {
            response += '- **Component Configuration**: Available\n';
          }
          
          if (data.uiResources.root.children && data.uiResources.root.children.length > 0) {
            response += `- **Child Components**: ${data.uiResources.root.children.length} components\n`;
          }
        }
    
        // Display view configuration if available
        if (data.uiResources.config) {
          response += '- **View Configuration**: Available\n';
        }
    
        // Display resources summary
        const resourceKeys = Object.keys(data.uiResources).filter(key => key !== 'root' && key !== 'config');
        if (resourceKeys.length > 0) {
          response += `- **Additional Resources**: ${resourceKeys.join(', ')}\n`;
        }
      }
    
      response += '\n### Processing Details\n';
      response += '- **Data Transform**: pyUpgradeOnOpen executed successfully\n';
      response += '- **View Type**: Read-only view (or form if used in modal pop-up)\n';
      
      return response;
    }
  • PegaClient.getCaseView method proxies the request to the appropriate version-specific client (v1 or v2). This is the direct API call used by the tool.
    async getCaseView(caseID, viewID) {
      return this.client.getCaseView(caseID, viewID);
    }
Behavior2/5

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

With no annotations provided, the description carries full burden for behavioral disclosure. While it mentions 'Returns view metadata with customizable logic from pyUpgradeOnOpen Data Transform,' this is vague about what the tool actually does behaviorally. It doesn't specify whether this is a read-only operation, what permissions are required, whether it's idempotent, or how errors are handled. The mention of 'customizable logic' is insufficient without explaining what that entails.

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 concise at two sentences. The first sentence clearly states the core functionality, while the second adds context about the return value. There's no wasted verbiage, though the 'customizable logic' phrase could be more specific. The structure is front-loaded with the essential information.

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

Completeness2/5

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

For a tool with 3 parameters (including a complex nested object), no annotations, and no output schema, the description is inadequate. It doesn't explain what 'view metadata' contains, what 'customizable logic' means, or how the sessionCredentials object should be used. The agent would struggle to understand the tool's behavior, return format, or proper usage context given the complexity.

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%, providing comprehensive documentation for all parameters. The description adds minimal value beyond the schema, only implying that caseID and viewID are required inputs. It doesn't explain relationships between parameters, provide usage examples, or clarify the 'customizable logic' mentioned. Baseline 3 is appropriate given the schema does the heavy lifting.

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

Purpose4/5

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

The description clearly states the verb ('Get') and resource ('view details'), specifying it's based on case ID and view name. It distinguishes from siblings like 'get_case' or 'get_case_attachments' by focusing specifically on view metadata. However, it doesn't explicitly contrast with similar view-related tools like 'get_case_view_calculated_fields' or 'get_data_view_metadata'.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives. With multiple view-related siblings (get_case_view_calculated_fields, get_data_view_metadata, get_list_data_view), there's no indication of which scenarios warrant this specific tool. No prerequisites, exclusions, or comparison to similar tools are mentioned.

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