Skip to main content
Glama
yusuferenkt

MCP JSON Database Server

by yusuferenkt

get_my_permissions

Lists user permissions from the MCP JSON Database Server to verify access rights for database operations using JWT authentication.

Instructions

Kullanıcının sahip olduğu yetkileri listeler

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
tokenYesJWT token

Implementation Reference

  • Handler function that extracts user information from the provided JWT token and retrieves the user's permissions based on their role using getUserPermissions.
    case 'get_my_permissions': {
      const { token } = args;
      
      try {
        const user = extractUserFromToken(token);
        if (!user) {
          return {
            content: [{
              type: 'text',
              text: JSON.stringify({ success: false, message: 'Geçersiz token' })
            }]
          };
        }
    
        const permissions = getUserPermissions(user.role);
        return {
          content: [{
            type: 'text',
            text: JSON.stringify({
              success: true,
              user: { id: user.userId, email: user.email, role: user.role },
              permissions: permissions,
              totalPermissions: permissions.length,
              roleDescription: {
                [ROLES.ADMIN]: 'Sistem yöneticisi - Tüm yetkilere sahip',
                [ROLES.MANAGER]: 'Yönetici - Çoğu yönetim yetkilerine sahip',
                [ROLES.EMPLOYEE]: 'Çalışan - Temel yetkilere sahip'
              }[user.role]
            }, null, 2)
          }]
        };
      } catch (error) {
        return {
          content: [{
            type: 'text',
            text: JSON.stringify({ success: false, message: error.message })
          }]
        };
      }
    }
  • src/index.js:120-130 (registration)
    Tool registration in the ListTools response, including name, description, and input schema.
    {
      name: 'get_my_permissions',
      description: 'Kullanıcının sahip olduğu yetkileri listeler',
      inputSchema: {
        type: 'object',
        properties: {
          token: { type: 'string', description: 'JWT token' }
        },
        required: ['token']
      }
    },
  • Helper function that returns the list of permissions associated with a given user role, based on the ROLE_PERMISSIONS matrix.
    export function getUserPermissions(userRole) {
      if (!userRole) return [];
      
      return ROLE_PERMISSIONS[userRole] || [];
    }
  • Helper function that decodes the JWT token and extracts user ID, email, and role.
    export function extractUserFromToken(token) {
        try {
            const decoded = verifyToken(token);
            return {
                userId: decoded.userId,
                email: decoded.email,
                role: decoded.role
            };
        } catch (error) {
            return null;
        }
    }
Behavior2/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool lists permissions but doesn't describe what 'listeler' entails—e.g., format (array of strings, structured objects), scope (current user only, as implied by 'my'), or any side effects (likely read-only, but not confirmed). For a tool with no annotation coverage, this minimal description leaves key behavioral traits unspecified.

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 a single, efficient sentence in Turkish that directly states the tool's purpose without fluff. It's appropriately sized for a simple tool, though it could be slightly more informative (e.g., adding context). There's no wasted verbiage, and it's front-loaded with the core action, earning a high score for conciseness.

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 (a read operation with one parameter) and lack of annotations or output schema, the description is incomplete. It doesn't explain the return value (e.g., what permissions look like), error conditions, or authentication requirements implied by the token. For a tool that likely involves user data and permissions, this leaves significant gaps for an AI agent to infer usage correctly.

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?

The input schema has 100% description coverage (the 'token' parameter is documented as a JWT token), so the baseline is 3. The description adds no additional meaning about parameters—it doesn't explain why a token is needed or how it relates to listing permissions. Since the schema already covers the parameter, the description doesn't compensate but doesn't detract either, meeting the minimum viable baseline.

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: 'Kullanıcının sahip olduğu yetkileri listeler' (Lists the permissions the user has). It specifies the verb 'listeler' (lists) and the resource 'yetkiler' (permissions), and distinguishes itself from sibling tools like get_user_by_id or get_my_audit_logs by focusing on permissions. However, it doesn't explicitly differentiate from potential permission-related siblings (none exist in the list), so it falls short of a perfect 5.

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 via token), use cases (e.g., checking access before an action), or exclusions (e.g., not for admin-level permissions). With sibling tools like get_user_by_id or get_my_audit_logs that might overlap in user context, the lack of differentiation is a clear gap.

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/yusuferenkt/mcp-database'

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