Skip to main content
Glama

get_cards

Retrieve and list all tasks from a Focalboard with pagination support for organized project management.

Instructions

List all cards (tasks) in a board with pagination support.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
boardIdYesThe ID of the board to list cards from
pageNoPage number for pagination (default: 0)
perPageNoNumber of cards per page (default: 100)

Implementation Reference

  • The MCP tool handler for 'get_cards'. Extracts boardId, page, and perPage from input arguments, calls the focalboard client's getCards method, and returns the list of cards as formatted JSON text content.
    case 'get_cards': {
      const boardId = args?.boardId as string;
      const page = (args?.page as number) || 0;
      const perPage = (args?.perPage as number) || 100;
    
      if (!boardId) {
        throw new Error('boardId is required');
      }
    
      const cards = await focalboard.getCards(boardId, page, perPage);
      return {
        content: [
          {
            type: 'text',
            text: JSON.stringify(cards, null, 2)
          }
        ]
      };
    }
  • JSON schema defining the input parameters for the 'get_cards' tool: boardId (required), page and perPage (optional with defaults).
    inputSchema: {
      type: 'object',
      properties: {
        boardId: {
          type: 'string',
          description: 'The ID of the board to list cards from'
        },
        page: {
          type: 'number',
          description: 'Page number for pagination (default: 0)',
          default: 0
        },
        perPage: {
          type: 'number',
          description: 'Number of cards per page (default: 100)',
          default: 100
        }
      },
      required: ['boardId']
    }
  • src/index.ts:108-131 (registration)
    Registration of the 'get_cards' tool in the tools array, including name, description, and input schema. This array is used by the ListToolsRequestHandler.
    {
      name: 'get_cards',
      description: 'List all cards (tasks) in a board with pagination support.',
      inputSchema: {
        type: 'object',
        properties: {
          boardId: {
            type: 'string',
            description: 'The ID of the board to list cards from'
          },
          page: {
            type: 'number',
            description: 'Page number for pagination (default: 0)',
            default: 0
          },
          perPage: {
            type: 'number',
            description: 'Number of cards per page (default: 100)',
            default: 100
          }
        },
        required: ['boardId']
      }
    },
  • Helper method in FocalboardClient that performs the actual API request to retrieve cards from a board with pagination, called by the tool handler.
    async getCards(boardId: string, page: number = 0, perPage: number = 100): Promise<Card[]> {
      return this.makeRequest<Card[]>(
        `/boards/${boardId}/cards`,
        'GET',
        undefined,
        { page: page.toString(), per_page: perPage.toString() }
      );
    }
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 of behavioral disclosure. It mentions 'pagination support', which is a useful behavioral trait beyond basic listing. However, it does not cover other aspects like rate limits, authentication needs, error handling, or whether it's read-only (implied but not stated), leaving gaps in transparency.

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 front-loads the core action ('List all cards') and includes key context ('in a board with pagination support'). There is no wasted text, 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 the tool's moderate complexity (3 parameters, no output schema, no annotations), the description is minimally adequate. It covers the basic purpose and pagination behavior but lacks details on output format, error cases, or integration with sibling tools, which could help an agent use it more effectively in context.

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 ('boardId', 'page', 'perPage') with descriptions and defaults. The description adds no additional parameter semantics beyond what the schema provides, such as format details or constraints, meeting the baseline for high schema coverage.

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 ('List') and resource ('cards (tasks) in a board'), making the purpose specific and understandable. However, it does not explicitly differentiate from sibling tools like 'get_card' (singular) or 'search_boards', leaving room for ambiguity in tool selection.

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 by mentioning 'board' context and pagination, suggesting it's for retrieving multiple cards from a specific board. However, it lacks explicit guidance on when to use this versus alternatives like 'get_card' (for a single card) or 'search_boards' (for board-level queries), leaving usage somewhat inferred rather than clearly defined.

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/gmjuhasz/focalboard-mcp-server'

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