Skip to main content
Glama

dhis2_get_permission_info

Retrieve current user permissions and available tools to manage access and functionality within DHIS2 health information systems.

Instructions

Get detailed information about current user permissions and available tools

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Implementation Reference

  • Handler for the dhis2_get_permission_info tool. Generates a comprehensive permission report including user details, permission level, allowed/restricted operations, available tools count by category, and authority count.
          case 'dhis2_get_permission_info':
            const filteredTools = PermissionSystem.filterToolsByPermissions(tools, userPermissions);
            const permInfo = PermissionSystem.getPermissionSummary(userPermissions);
            
            auditLogger.log({
              toolName: name,
              parameters: {},
              outcome: 'success',
              dhis2Instance: dhis2Client?.baseURL,
              userId: currentUser?.username,
              executionTime: Date.now() - startTime
            });
            
            return {
              content: [{
                type: 'text',
                text: `šŸ” Permission Information
    
    šŸ‘¤ **User Details:**
      • Name: ${currentUser?.displayName || 'Unknown'}
      • Username: ${currentUser?.username || 'Unknown'}
      • User Groups: ${currentUser?.userGroups?.map((g: any) => g.name).join(', ') || 'None'}
    
    šŸŽÆ **Permission Level:** ${permInfo.level}
    šŸ“ **Description:** ${permInfo.description}
    
    āœ… **Allowed Operations:**
    ${permInfo.allowedOperations.map(op => `  • ${op}`).join('\n')}
    
    ${permInfo.restrictedOperations.length > 0 ? `ā›” **Restricted Operations:**
    ${permInfo.restrictedOperations.map(op => `  • ${op}`).join('\n')}` : ''}
    
    šŸ› ļø **Available Tools:** ${filteredTools.length} of ${tools.length} total
      • Configuration: ${filteredTools.filter(t => t.name.includes('configure')).length}
      • Data Management: ${filteredTools.filter(t => t.name.includes('list') || t.name.includes('get')).length}
      • Creation Tools: ${filteredTools.filter(t => t.name.includes('create')).length}
      • Analytics: ${filteredTools.filter(t => t.name.includes('analytics')).length}
      • Development: ${filteredTools.filter(t => t.name.includes('init') || t.name.includes('generate')).length}
    
    šŸ”‘ **DHIS2 Authorities:** ${userPermissions.authorities.length} authorities assigned`
              }]
            };
  • Core helper function that categorizes user permissions into levels (read-only, data-entry, metadata-manager, system-admin, developer) and provides descriptions of allowed and restricted operations. Used by the tool handler.
    static getPermissionSummary(permissions: UserPermissions): {
      level: 'read-only' | 'data-entry' | 'metadata-manager' | 'system-admin' | 'developer';
      description: string;
      allowedOperations: string[];
      restrictedOperations: string[];
    } {
      if (permissions.isReadOnly) {
        return {
          level: 'read-only',
          description: 'Read-only access to DHIS2 data and metadata',
          allowedOperations: ['View data', 'List metadata', 'Run analytics'],
          restrictedOperations: ['Create', 'Update', 'Delete', 'Import operations']
        };
      }
    
      if (permissions.canManageSystem) {
        return {
          level: 'system-admin',
          description: 'Full system administration capabilities',
          allowedOperations: ['All operations', 'User management', 'System configuration'],
          restrictedOperations: []
        };
      }
    
      if (permissions.canConfigureApps && permissions.canDebugApplications) {
        return {
          level: 'developer',
          description: 'Development and debugging capabilities',
          allowedOperations: ['App development', 'Debugging tools', 'Mobile development', 'UI tools'],
          restrictedOperations: permissions.canDeleteMetadata ? [] : ['Metadata deletion']
        };
      }
    
      if (permissions.canCreateMetadata) {
        return {
          level: 'metadata-manager',
          description: 'Metadata management and configuration',
          allowedOperations: ['Create/update metadata', 'Manage programs', 'Configure system'],
          restrictedOperations: permissions.canDeleteMetadata ? [] : ['Delete operations']
        };
      }
    
      return {
        level: 'data-entry',
        description: 'Data entry and basic operations',
        allowedOperations: ['Enter data', 'View reports', 'Basic analytics'],
        restrictedOperations: ['Metadata management', 'System configuration', 'Delete operations']
      };
    }
  • Helper function that filters available tools based on user permissions. Used in both ListTools response and the permission info tool to count available tools.
    static filterToolsByPermissions(tools: Tool[], permissions: UserPermissions): Tool[] {
      if (permissions.isReadOnly) {
        // In read-only mode, only allow viewing operations
        return tools.filter(tool => 
          !tool.name.includes('create') && 
          !tool.name.includes('update') && 
          !tool.name.includes('delete') &&
          !tool.name.includes('import') &&
          (tool.name.includes('list') || tool.name.includes('get') || tool.name === 'dhis2_configure')
        );
      }
    
      return tools.filter(tool => {
        const requiredPermissions = this.TOOL_PERMISSIONS.get(tool.name);
        if (!requiredPermissions) {
          // If no specific permission is defined, allow by default
          return true;
        }
    
        if (Array.isArray(requiredPermissions)) {
          // All permissions in the array must be satisfied
          return requiredPermissions.every(permission => permissions[permission]);
        } else {
          // Single permission must be satisfied
          return permissions[requiredPermissions];
        }
      });
  • src/index.ts:104-111 (registration)
    ListTools handler that registers all tools by returning the filtered list including dhis2_get_permission_info based on permissions.
    server.setRequestHandler(ListToolsRequestSchema, async () => {
      // Filter tools based on user permissions
      const filteredTools = PermissionSystem.filterToolsByPermissions(tools, userPermissions);
      
      return {
        tools: filteredTools,
      };
    });
  • Type definition for UserPermissions interface used throughout the permission system, serving as schema for permission checks.
    export interface UserPermissions {
      // Core permissions
      canCreateMetadata: boolean;
      canUpdateMetadata: boolean;
      canDeleteMetadata: boolean;
      canViewMetadata: boolean;
      
      // Data permissions
      canEnterData: boolean;
      canViewData: boolean;
      canImportData: boolean;
      canExportData: boolean;
      canDeleteData: boolean;
      
      // System permissions
      canManageUsers: boolean;
      canManageSystem: boolean;
      canViewSystemInfo: boolean;
      canRunAnalytics: boolean;
      canManageDashboards: boolean;
      
      // Program permissions
      canManagePrograms: boolean;
      canEnrollTEI: boolean;
      canViewTEI: boolean;
      canManageTrackerData: boolean;
      
      // Mobile/Android permissions
      canUseMobileFeatures: boolean;
      canConfigureMobile: boolean;
      
      // UI/Development permissions
      canUseUITools: boolean;
      canConfigureApps: boolean;
      canDebugApplications: boolean;
      
      // Special permissions
      isReadOnly: boolean;
      authorities: string[];
    }
Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool retrieves information, implying it's a read-only operation, but doesn't specify authentication requirements, rate limits, error conditions, or the format of the returned data. For a tool that likely interacts with user permissions in a system like DHIS2, this omission is significant, as the agent lacks critical context about security and response behavior.

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 a single, efficient sentence that directly states the tool's purpose without unnecessary words. It is front-loaded with the core action ('Get detailed information'), making it easy to parse. Every part of the sentence contributes essential information, and there is no redundancy or fluff.

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 tool's complexity (likely involving user permissions in a DHIS2 system) and the absence of both annotations and an output schema, the description is insufficient. It doesn't explain what 'detailed information' includes (e.g., permission levels, tool lists, metadata), how the data is structured, or potential limitations. For a tool that could be critical for access control decisions, this leaves the agent under-informed about its capabilities and outputs.

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

Parameters4/5

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

The tool has 0 parameters, and the schema description coverage is 100% (since there are no parameters to describe). The description doesn't need to add parameter semantics, as there are none to explain. A baseline score of 4 is appropriate because the description accurately reflects the lack of inputs, though it doesn't explicitly state 'no parameters required', which could slightly enhance clarity.

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: 'Get detailed information about current user permissions and available tools'. It specifies the verb ('Get'), resource ('detailed information'), and scope ('current user permissions and available tools'), making the function unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'dhis2_get_server_info' or 'dhis2_get_audit_log', which prevents a perfect score.

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. It doesn't mention prerequisites (e.g., authentication state), use cases (e.g., checking access before performing operations), or comparisons to siblings like 'dhis2_get_server_info' (which might return general server metadata). This lack of contextual direction leaves the agent to infer usage scenarios.

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/Dradebo/dhis2-mcp'

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