Skip to main content
Glama
code-rabi

Mews MCP

by code-rabi

getAllTasks

Retrieve enterprise tasks from Mews MCP using filters like IDs, dates, or departments, with pagination support for large datasets.

Instructions

Returns all tasks of the enterprise, filtered by identifiers or other filters. REQUIRED: At least one filter must be provided (TaskIds, DepartmentIds, ServiceOrderIds, CreatedUtc, ClosedUtc, or DeadlineUtc). LIMITATIONS: Date range filters (CreatedUtc, ClosedUtc, DeadlineUtc) have a maximum interval of 3 months and 1 day. Array filters (TaskIds, DepartmentIds, ServiceOrderIds) are limited to 1000 items each. The Limitation parameter with Count is mandatory for pagination.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
TaskIdsNoFilter by specific task IDs
DepartmentIdsNoFilter by department IDs
ServiceOrderIdsNoFilter by service order IDs (reservations or product service orders)
CreatedUtcNoDate range filter for task creation (max 3 months)
ClosedUtcNoDate range filter for task closure (max 3 months)
DeadlineUtcNoDate range filter for task deadlines (max 3 months)
LimitationYesPagination settings with cursor support

Implementation Reference

  • The main handler function that validates input parameters (date ranges max 3 months, arrays max 1000), calls the Mews API endpoint '/api/connector/v1/tasks/getAll', processes the response, and returns a formatted markdown list of tasks with pagination info.
    async execute(config: any, args: GetAllTasksParams) {
      try {
        // Validate date ranges (max 3 months)
        const validateDateRange = (range: DateRange | undefined, rangeName: string) => {
          if (!range || !range.StartUtc || !range.EndUtc) return;
          
          const start = new Date(range.StartUtc);
          const end = new Date(range.EndUtc);
          const diffMonths = (end.getTime() - start.getTime()) / (1000 * 60 * 60 * 24 * 30);
          
          if (diffMonths > 3) {
            throw new Error(`${rangeName} date range cannot exceed 3 months`);
          }
        };
    
        validateDateRange(args.CreatedUtc, 'CreatedUtc');
        validateDateRange(args.ClosedUtc, 'ClosedUtc');
        validateDateRange(args.DeadlineUtc, 'DeadlineUtc');
    
        // Validate array limits
        if (args.TaskIds && args.TaskIds.length > 1000) {
          throw new Error('TaskIds cannot exceed 1000 items');
        }
        if (args.DepartmentIds && args.DepartmentIds.length > 1000) {
          throw new Error('DepartmentIds cannot exceed 1000 items');
        }
        if (args.ServiceOrderIds && args.ServiceOrderIds.length > 1000) {
          throw new Error('ServiceOrderIds cannot exceed 1000 items');
        }
    
        const response = await mewsRequest<GetAllTasksParams, GetAllTasksResponse>(
          config,
          '/api/connector/v1/tasks/getAll',
          args
        );
    
        const taskCount = response.Tasks?.length || 0;
        const hasMore = !!response.Cursor;
    
        return {
          content: [{
            type: 'text',
            text: `Retrieved ${taskCount} task${taskCount !== 1 ? 's' : ''}${hasMore ? ' (more available)' : ''}:\n\n` +
              response.Tasks.map((task: Task) => 
                `šŸ“‹ **${task.Name}** (${task.State})\n` +
                `   ID: ${task.Id}\n` +
                `   Created: ${new Date(task.CreatedUtc).toLocaleString()}\n` +
                `   Department: ${task.DepartmentId || 'Not assigned'}\n` +
                `   Service Order: ${task.ServiceOrderId || 'None'}\n` +
                `   Deadline: ${task.DeadlineUtc ? new Date(task.DeadlineUtc).toLocaleString() : 'Not set'}\n` +
                `   Description: ${task.Description || 'No description'}\n`
              ).join('\n') +
              (hasMore ? `\nšŸ“„ **Pagination:** Use cursor "${response.Cursor}" to get more results` : '')
          }]
        };
      } catch (error) {
        return {
          content: [{
            type: 'text',
            text: `Error retrieving tasks: ${error instanceof Error ? error.message : 'Unknown error occurred'}`
          }]
        };
      }
    }
  • JSON Schema defining the input parameters for the getAllTasks tool, including optional filters (TaskIds, DepartmentIds, ServiceOrderIds, date ranges) and required Limitation for pagination, with constraints like maxItems:1000 and date range notes.
    inputSchema: {
      type: 'object',
      properties: {
        TaskIds: {
          type: 'array',
          items: { type: 'string' },
          maxItems: 1000,
          description: 'Filter by specific task IDs'
        },
        DepartmentIds: {
          type: 'array',
          items: { type: 'string' },
          maxItems: 1000,
          description: 'Filter by department IDs'
        },
        ServiceOrderIds: {
          type: 'array',
          items: { type: 'string' },
          maxItems: 1000,
          description: 'Filter by service order IDs (reservations or product service orders)'
        },
        CreatedUtc: {
          type: 'object',
          properties: {
            StartUtc: { type: 'string', description: 'Start of creation date range (ISO 8601)' },
            EndUtc: { type: 'string', description: 'End of creation date range (ISO 8601)' }
          },
          description: 'Date range filter for task creation (max 3 months)'
        },
        ClosedUtc: {
          type: 'object',
          properties: {
            StartUtc: { type: 'string', description: 'Start of closure date range (ISO 8601)' },
            EndUtc: { type: 'string', description: 'End of closure date range (ISO 8601)' }
          },
          description: 'Date range filter for task closure (max 3 months)'
        },
        DeadlineUtc: {
          type: 'object',
          properties: {
            StartUtc: { type: 'string', description: 'Start of deadline date range (ISO 8601)' },
            EndUtc: { type: 'string', description: 'End of deadline date range (ISO 8601)' }
          },
          description: 'Date range filter for task deadlines (max 3 months)'
        },
        Limitation: {
          type: 'object',
          properties: {
            Count: { type: 'number', description: 'Maximum number of tasks to return' },
            Cursor: { type: 'string', description: 'Pagination cursor for next page' }
          },
          required: ['Count'],
          description: 'Pagination settings with cursor support'
        }
      },
      required: ['Limitation'],
      additionalProperties: false
    },
  • Registration of the getAllTasksTool in the central allTools array, which is used for MCP tool registry and toolMap lookup.
    // Task tools
    getAllTasksTool,
    addTaskTool,
  • Import statement that brings the getAllTasksTool into the index for registration.
    import { getAllTasksTool } from './tasks/getAllTasks.js';
  • TypeScript interface defining the expected API response structure for typing the mewsRequest.
    interface GetAllTasksResponse {
      Tasks: Task[];
      Cursor?: string;
    }
Behavior4/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. It discloses key behavioral traits: the requirement for at least one filter, limitations on date range filters (max 3 months and 1 day), array filter limits (1000 items each), and pagination requirements (Limitation parameter with Count is mandatory). This covers constraints and operational details, though it could mention potential performance impacts or error handling.

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 appropriately sized and front-loaded, starting with the core purpose followed by requirements and limitations. Each sentence adds necessary information without redundancy. It could be slightly more structured with bullet points for clarity, but it remains efficient and easy to parse.

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?

Given the complexity (7 parameters, nested objects, no output schema, and no annotations), the description is fairly complete. It covers purpose, usage rules, and behavioral constraints. However, it lacks details on output format or error responses, which would be helpful since there's no output schema. For a tool with rich input schema and no annotations, it does well but has minor gaps in output 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 thoroughly. The description adds value by clarifying that at least one filter is required and specifying limitations (e.g., max interval for date filters, item limits for arrays), which are not in the schema. However, it does not provide additional meaning beyond these constraints, aligning with the baseline of 3 when schema coverage is high.

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: 'Returns all tasks of the enterprise, filtered by identifiers or other filters.' It specifies the verb ('Returns') and resource ('tasks of the enterprise'), but does not explicitly differentiate from sibling tools like 'getAllReservations' or 'getAllCompanies', which follow a similar pattern. The filtering aspect is mentioned, which adds specificity.

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

Usage Guidelines4/5

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

The description provides clear context for usage: 'REQUIRED: At least one filter must be provided' and lists the specific filters (TaskIds, DepartmentIds, etc.). It implies when to use this tool (for retrieving tasks with filters) but does not explicitly state when not to use it or name alternatives among siblings, such as if there's a simpler 'getTask' tool. The guidance is practical but lacks explicit exclusion criteria.

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/code-rabi/mews-mcp'

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