Skip to main content
Glama

select_page

Selects the active Firefox browser tab by index, URL, or title to control web automation workflows.

Instructions

Select active tab by index, URL, or title. Index takes precedence.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pageIdxNoTab index (0-based, most reliable)
urlNoURL substring (case-insensitive)
titleNoTitle substring (case-insensitive)

Implementation Reference

  • The main execution handler for the 'select_page' tool. It selects the active tab in Firefox by priority: index, URL substring, or title substring. Uses Firefox DevTools to refresh tabs, find matching tab, validate, and select it.
    export async function handleSelectPage(args: unknown): Promise<McpToolResponse> {
      try {
        const { pageIdx, url, title } = args as { pageIdx?: number; url?: string; title?: string };
    
        const { getFirefox } = await import('../index.js');
        const firefox = await getFirefox();
    
        // Refresh tabs to get latest list
        await firefox.refreshTabs();
        const tabs = firefox.getTabs();
    
        let selectedIdx: number;
    
        // Priority 1: Select by index
        if (typeof pageIdx === 'number') {
          selectedIdx = pageIdx;
        }
        // Priority 2: Select by URL pattern
        else if (url && typeof url === 'string') {
          const urlLower = url.toLowerCase();
          const foundIdx = tabs.findIndex((tab) => tab.url?.toLowerCase().includes(urlLower));
          if (foundIdx === -1) {
            throw new Error(`No page matching URL "${url}"`);
          }
          selectedIdx = foundIdx;
        }
        // Priority 3: Select by title pattern
        else if (title && typeof title === 'string') {
          const titleLower = title.toLowerCase();
          const foundIdx = tabs.findIndex((tab) => tab.title?.toLowerCase().includes(titleLower));
          if (foundIdx === -1) {
            throw new Error(`No page matching title "${title}"`);
          }
          selectedIdx = foundIdx;
        } else {
          throw new Error('Provide pageIdx, url, or title');
        }
    
        // Validate the selected index
        if (!tabs[selectedIdx]) {
          throw new Error(`Page [${selectedIdx}] not found`);
        }
    
        // Select the tab
        await firefox.selectTab(selectedIdx);
    
        return successResponse(`✅ selected [${selectedIdx}]`);
      } catch (error) {
        return errorResponse(error as Error);
      }
    }
  • The tool schema definition for 'select_page', including name, description, and input schema allowing optional pageIdx (number), url (string), or title (string).
    export const selectPageTool = {
      name: 'select_page',
      description: 'Select active tab by index, URL, or title. Index takes precedence.',
      inputSchema: {
        type: 'object',
        properties: {
          pageIdx: {
            type: 'number',
            description: 'Tab index (0-based, most reliable)',
          },
          url: {
            type: 'string',
            description: 'URL substring (case-insensitive)',
          },
          title: {
            type: 'string',
            description: 'Title substring (case-insensitive)',
          },
        },
        required: [],
      },
    };
  • src/index.ts:111-111 (registration)
    Maps the 'select_page' tool name to its handler function (handleSelectPage) in the MCP server's toolHandlers Map, enabling tool execution.
    ['select_page', tools.handleSelectPage],
  • src/index.ts:155-155 (registration)
    Includes the selectPageTool schema in the allTools array, which is returned by the MCP list_tools request.
    tools.selectPageTool,
Behavior3/5

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

With no annotations provided, the description carries the full burden. It discloses the precedence behavior (index over URL/title), which is useful context. However, it lacks details on error handling, what happens if no match is found, or any side effects like page loading or focus changes.

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 with zero waste. It's front-loaded with the core action and includes the critical precedence rule, making it highly concise and well-structured for quick understanding.

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

Completeness3/5

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

Given no annotations and no output schema, the description is adequate for a simple selection tool but lacks completeness. It doesn't explain return values, error cases, or behavioral nuances like what 'select' entails (e.g., focus change, page activation). For a tool with 3 parameters and no structured safety hints, it should do more.

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%, so the schema already documents all parameters thoroughly. The description adds minimal value by mentioning the precedence rule, but doesn't provide additional syntax, format, or usage details beyond what's in the schema descriptions.

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 ('select') and resource ('active tab'), specifying it's for browser tab selection. It doesn't explicitly differentiate from sibling tools like 'close_page' or 'list_pages', but the action is specific enough to understand its distinct function.

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?

The description implies usage through the precedence rule ('Index takes precedence'), suggesting when to use different parameter types. However, it doesn't provide explicit guidance on when to use this tool versus alternatives like 'close_page' or 'list_pages', nor does it mention prerequisites or exclusions.

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/mozilla/firefox-devtools-mcp'

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