Skip to main content
Glama

get_current_app

Retrieve the package name of the foreground Android application to identify active apps for automation or monitoring purposes.

Instructions

Get the package name of the currently focused/foreground Android application.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
device_idNoDevice serial number

Implementation Reference

  • The actual implementation of the get_current_app logic using adb dumpsys.
    export async function getCurrentApp(deviceId?: string): Promise<string> {
      const resolved = await deviceManager.resolveDeviceId(deviceId);
    
      const result = await adbShell([
        'dumpsys', 'window', 'displays', '|', 'grep', '-E', 'mCurrentFocus|mFocusedApp',
      ], resolved);
    
      // Parse the package name from output like: mCurrentFocus=Window{... com.example.app/...}
      const match = result.stdout.match(/([a-zA-Z][a-zA-Z0-9_]*(?:\.[a-zA-Z][a-zA-Z0-9_]*)+)\//);
      return match ? match[1] : 'unknown';
    }
  • The MCP tool registration for get_current_app.
    server.registerTool(
      'get_current_app',
      {
        description: 'Get the package name of the currently focused/foreground Android application.',
        inputSchema: {
          device_id: z.string().optional().describe('Device serial number'),
        },
      },
      async ({ device_id }) => {
        return await metrics.measure('get_current_app', device_id || 'default', async () => {
          const app = await getCurrentApp(device_id);
          return {
            content: [{
              type: 'text' as const,
              text: JSON.stringify({ success: true, current_app: app }, null, 2),
            }],
          };
        });
      }
Behavior3/5

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

With no annotations provided, description carries burden of disclosing behavior. It clarifies specific return value type (package name vs. app label or activity) and target state (focused/foreground). However, omits read-only safety confirmation, error conditions (no device connected), or return format details.

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?

Single sentence (11 words) with zero waste. Front-loaded with action verb and resource identifier. No redundant or filler text.

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

Completeness4/5

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

Appropriate for simple single-parameter tool. Specifies return value concept (package name) despite lack of output schema. Could marginally improve by indicating return type (string) or null behavior when no foreground app exists, but sufficient for tool 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 coverage is 100% ('Device serial number'), establishing baseline 3. Description adds no parameter context, but none is required given complete schema documentation. Does not clarify device_id selection when multiple devices present, though this is minor.

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?

Description uses specific verb 'Get' with clear resource 'package name of the currently focused/foreground Android application'. Effectively distinguishes from siblings like 'list_apps' (all apps) and 'get_device_info' (hardware) by specifying 'currently focused/foreground' scope.

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

Usage Guidelines3/5

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

Provides implied usage context through 'currently focused/foreground' qualifier, suggesting use when identifying active applications. However, lacks explicit when-to-use guidance comparing it to alternatives like 'get_ui_tree' or 'analyze_screen', and no prerequisites 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/divineDev-dotcom/android_mcp'

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