Skip to main content
Glama
AlyssonM

HiveAuth MCP Server

by AlyssonM

evaluate_presentation

Check credentials against presentation definitions using DIF Presentation Exchange to verify compliance and match requirements.

Instructions

Evaluate credentials against a presentation definition using DIF Presentation Exchange Protocol. Tests credential compliance and matching.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
presentationDefinitionYesDIF PEX Presentation Definition
credentialsYes

Implementation Reference

  • The main execution logic for the 'evaluate_presentation' tool. Validates input using the schema, sends credentials and presentation definition to the HiveAuth API for DIF PEX evaluation, formats detailed results with status indicators and JSON output.
    export async function evaluatePresentation(args: any): Promise<CallToolResult> {
      // Validate and sanitize input
      const validation = validateAndSanitizeInput(EvaluatePresentationInputSchema, args, 'evaluate_presentation');
      
      if (!validation.success) {
        return createValidationErrorResult(validation.error!);
      }
    
      const data = validation.data!;
      const { presentationDefinition, credentials } = data;
    
      const HIVEAUTH_API_BASE_URL = process.env.HIVEAUTH_API_BASE_URL || 'http://localhost:3000';
      const EVALUATE_ENDPOINT = `${HIVEAUTH_API_BASE_URL}/api/presentation/evaluate`;
    
      try {
        const response = await fetch(EVALUATE_ENDPOINT, {
          method: 'POST',
          headers: {
            'Content-Type': 'application/json',
          },
          body: JSON.stringify({ 
            presentationDefinition, 
            credentials 
          }),
        });
    
        if (!response.ok) {
          const errorData = await response.json().catch(() => ({ message: response.statusText }));
          throw new Error(`Failed to evaluate presentation: ${errorData.message}`);
        }
    
        const result = await response.json();
    
        const details = [
          `• Definition ID: ${presentationDefinition.id}`,
          `• Credentials Evaluated: ${credentials.length}`,
          `• Evaluation Status: ${result.canSubmit ? '✅ Can Submit' : '❌ Cannot Submit'}`,
          ''
        ];
    
        if (result.inputDescriptorResults) {
          details.push('Input Descriptor Results:');
          result.inputDescriptorResults.forEach((descriptorResult: any) => {
            const status = descriptorResult.canSubmit ? '✅' : '❌';
            details.push(`  • ${descriptorResult.inputDescriptor.id}: ${status} ${descriptorResult.canSubmit ? 'Satisfied' : 'Not satisfied'}`);
            
            if (descriptorResult.matchingCredentials) {
              details.push(`    - Matching credentials: ${descriptorResult.matchingCredentials.length}`);
              descriptorResult.matchingCredentials.forEach((match: any, index: number) => {
                const credId = match.credential?.id || `Credential ${index + 1}`;
                details.push(`      • ${credId}`);
              });
            }
    
            if (descriptorResult.errors && descriptorResult.errors.length > 0) {
              details.push(`    - Errors: ${descriptorResult.errors.length}`);
              descriptorResult.errors.forEach((error: string) => {
                details.push(`      • ${error}`);
              });
            }
            details.push('');
          });
        }
    
        if (result.errors && result.errors.length > 0) {
          details.push('Overall Errors:');
          result.errors.forEach((error: string) => {
            details.push(`  • ${error}`);
          });
        }
    
        return {
          content: [
            {
              type: 'text',
              text: `Presentation Evaluation Result:\n\n${details.join('\n')}`
            },
            {
              type: 'text',
              text: `\`\`\`json\n${JSON.stringify(result, null, 2)}\n\`\`\``
            }
          ]
        };
      } catch (error: any) {
        return {
          content: [
            {
              type: 'text',
              text: `Failed to evaluate presentation: ${error.message}`
            }
          ],
          isError: true
        };
      }
    }
  • Zod schema defining the input structure for the evaluate_presentation tool: a presentationDefinition (DIF PEX) and an array of credentials (at least one required).
    export const EvaluatePresentationInputSchema = z.object({
      presentationDefinition: PresentationDefinitionSchema,
      credentials: z.array(CredentialSchema).min(1, 'At least one credential is required')
    });
  • src/index.ts:98-99 (registration)
    Handler dispatch registration in the main MCP server request handler switch statement, routing 'evaluate_presentation' calls to the evaluatePresentation function.
    case 'evaluate_presentation':
      return await evaluatePresentation(args);
  • MCP Tool registration definition including name, description, and input schema reference, used by createMCPTools() to generate the Tool[] for the server.
    {
      name: 'evaluate_presentation',
      description: 'Evaluate credentials against a presentation definition using DIF Presentation Exchange Protocol. Tests credential compliance and matching.',
      inputSchema: TOOL_SCHEMAS.evaluate_presentation
    },
Behavior2/5

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

No annotations are provided, so the description carries full burden for behavioral disclosure. It states the tool 'tests credential compliance and matching,' which implies a read-only validation operation, but doesn't clarify whether this is a pure check or has side effects, what permissions are required, what happens with invalid credentials, or what the output format is. For a tool with complex nested parameters and no annotations, this leaves significant behavioral gaps.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

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

The description is extremely concise with two sentences that directly state the tool's function and protocol. Every word earns its place, with no redundant information. It's front-loaded with the core purpose, making it easy to scan and understand quickly.

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?

Given the complexity (2 nested parameters, 50% schema coverage, no annotations, no output schema), the description is insufficient. It doesn't explain what the tool returns, error conditions, or how results should be interpreted. For a validation/evaluation tool in a domain with many sibling tools, more context is needed to guide proper usage and integration.

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 50%, with two complex nested parameters. The description mentions 'credentials' and 'presentation definition' but adds minimal semantic context beyond the schema's property names. It doesn't explain what constitutes valid inputs, the relationship between these parameters, or typical use cases. The baseline is 3 because the schema provides some documentation, but the description doesn't compensate for the coverage gap.

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 tool's purpose: 'Evaluate credentials against a presentation definition using DIF Presentation Exchange Protocol. Tests credential compliance and matching.' It specifies the action (evaluate/test), resources (credentials and presentation definition), and protocol (DIF PEX). However, it doesn't explicitly distinguish this tool from sibling tools like 'validate_presentation_definition' or 'verify_presentation', which likely involve similar concepts.

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 sibling tools related to credentials and presentations (e.g., 'validate_presentation_definition', 'verify_presentation', 'submit_presentation'), there's no indication of this tool's specific context or prerequisites. The description mentions the protocol but doesn't explain when this evaluation step fits in a workflow.

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/AlyssonM/hiveauth-mcp'

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