Skip to main content
Glama

motion_schedules

Retrieve weekly working hours and time zone schedules from Motion's AI-powered calendar platform to manage team availability and scheduling.

Instructions

Get all schedules showing weekly working hours and time zones. The Motion API returns all schedules with no filtering options.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
operationNoOperation to perform

Implementation Reference

  • The ScheduleHandler class implements the tool logic. The handle method receives MotionSchedulesArgs (unused since only 'list' operation is supported) and calls handleList() which retrieves schedules from the Motion API service and formats them using formatScheduleList.
    import { BaseHandler } from './base/BaseHandler';
    import { McpToolResponse } from '../types/mcp';
    import { MotionSchedulesArgs } from '../types/mcp-tool-args';
    import { formatScheduleList } from '../utils';
    
    export class ScheduleHandler extends BaseHandler {
      async handle(_args: MotionSchedulesArgs): Promise<McpToolResponse> {
        try {
          return await this.handleList();
        } catch (error: unknown) {
          return this.handleError(error);
        }
      }
    
      private async handleList(): Promise<McpToolResponse> {
        const schedules = await this.motionService.getSchedules();
        return formatScheduleList(schedules);
      }
    }
  • The getSchedules() method in MotionApiService fetches all schedules from the Motion API endpoint /schedules. It uses caching (scheduleCache), validates the response against SchedulesListResponseSchema, and handles both array and wrapped response formats.
    async getSchedules(): Promise<MotionSchedule[]> {
      const cacheKey = 'schedules:all';
    
      return this.scheduleCache.withCache(cacheKey, async () => {
        try {
          mcpLog(LOG_LEVELS.DEBUG, 'Fetching schedules from Motion API', {
            method: 'getSchedules'
          });
    
          const response: AxiosResponse<ListResponse<MotionSchedule>> = await this.requestWithRetry(() => this.client.get('/schedules'));
    
          // Validate response against schema
          const validatedResponse = this.validateResponse(
            response.data,
            SchedulesListResponseSchema,
            'getSchedules'
          );
    
          // Handle both wrapped and unwrapped responses
          const schedules = Array.isArray(validatedResponse)
            ? validatedResponse
            : validatedResponse.schedules || [];
          const schedulesArray = Array.isArray(schedules) ? schedules : [];
    
          mcpLog(LOG_LEVELS.INFO, 'Schedules fetched successfully', {
            method: 'getSchedules',
            count: schedulesArray.length
          });
    
          return schedulesArray;
        } catch (error: unknown) {
          mcpLog(LOG_LEVELS.ERROR, 'Failed to fetch schedules', {
            method: 'getSchedules',
            error: getErrorMessage(error),
            apiStatus: isAxiosError(error) ? error.response?.status : undefined,
            apiMessage: isAxiosError(error) ? error.response?.data?.message : undefined
          });
          throw this.formatApiError(error, 'fetch', 'schedule');
        }
      });
    }
  • The HandlerFactory.registerHandlers() method maps TOOL_NAMES.SCHEDULES (which is 'motion_schedules') to the ScheduleHandler class, enabling tool instantiation when requested.
    private registerHandlers(): void {
      this.handlers.set(TOOL_NAMES.TASKS, TaskHandler);
      this.handlers.set(TOOL_NAMES.PROJECTS, ProjectHandler);
      this.handlers.set(TOOL_NAMES.WORKSPACES, WorkspaceHandler);
      this.handlers.set(TOOL_NAMES.USERS, UserHandler);
      this.handlers.set(TOOL_NAMES.SEARCH, SearchHandler);
      this.handlers.set(TOOL_NAMES.COMMENTS, CommentHandler);
      this.handlers.set(TOOL_NAMES.CUSTOM_FIELDS, CustomFieldHandler);
      this.handlers.set(TOOL_NAMES.RECURRING_TASKS, RecurringTaskHandler);
      this.handlers.set(TOOL_NAMES.SCHEDULES, ScheduleHandler);
      this.handlers.set(TOOL_NAMES.STATUSES, StatusHandler);
    }
  • The schedulesToolDefinition defines the MCP tool interface with name 'motion_schedules', description, and input schema that accepts an 'operation' parameter (enum: ['list']).
    export const schedulesToolDefinition: McpToolDefinition = {
      name: TOOL_NAMES.SCHEDULES,
      description: "Get all schedules showing weekly working hours and time zones. The Motion API returns all schedules with no filtering options.",
      inputSchema: {
        type: "object",
        properties: {
          operation: {
            type: "string",
            enum: ["list"],
            description: "Operation to perform"
          }
        },
        additionalProperties: false
      }
    };
  • The formatScheduleList() helper function formats the array of MotionSchedule objects into a user-readable MCP response, displaying schedule name, timezone, and working days count.
    export function formatScheduleList(schedules: MotionSchedule[]): CallToolResult {
      // Add null safety check for the array itself
      if (!schedules || !Array.isArray(schedules) || schedules.length === 0) {
        return formatMcpSuccess("No schedules found.");
      }
      
      const scheduleFormatter = (schedule: MotionSchedule) => {
        // Defensive programming for nested schedule object
        if (!schedule) {
          return '- Invalid schedule entry';
        }
        
        const name = schedule.name || 'Unnamed';
        const timezone = schedule.timezone || 'Unknown timezone';
        
        // Count working days if schedule details are available
        let workingDays = '';
        if (schedule.schedule && typeof schedule.schedule === 'object') {
          const days = ['monday', 'tuesday', 'wednesday', 'thursday', 'friday', 'saturday', 'sunday'];
          const activeDays = days.filter(day => 
            Array.isArray(schedule.schedule[day as keyof MotionScheduleDetails]) && 
            schedule.schedule[day as keyof MotionScheduleDetails]!.length > 0
          );
          workingDays = activeDays.length > 0 
            ? ` | Working days: ${activeDays.length}/7` 
            : ' | No working hours defined';
        } else {
          workingDays = ' | Schedule details unavailable';
        }
        
        return `- ${name} (${timezone})${workingDays}`;
      };
      
      return formatListResponse(schedules, `Found ${schedules.length} schedule${schedules.length === 1 ? '' : 's'}`, scheduleFormatter);
    }
Behavior3/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 that the API returns all schedules without filtering, which is useful behavioral context, but it doesn't cover other traits like authentication requirements, rate limits, error handling, or response format. The description adds some value but leaves significant gaps in transparency for a tool with no annotation coverage.

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 concise with two sentences that are front-loaded with the core purpose. It avoids unnecessary details, but the second sentence could be slightly more integrated (e.g., 'This tool retrieves all schedules, including weekly working hours and time zones, with no filtering options available.'). Overall, it's efficient with minimal waste.

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 low complexity (1 parameter, no output schema, no annotations), the description is somewhat complete by stating what it does and a key limitation. However, it lacks details on output (e.g., format or structure of returned schedules) and doesn't fully address behavioral aspects like error cases or integration with siblings, making it adequate but with clear gaps for a tool with no structured support.

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, with the single parameter 'operation' documented as 'Operation to perform' and an enum of ['list']. The description doesn't add any meaning beyond this, such as explaining why the parameter exists or its implications. Since schema coverage is high, the baseline score of 3 is appropriate, as the description doesn't compensate but doesn't need to.

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 ('Get') and resource ('all schedules') with specific attributes ('weekly working hours and time zones'), making the purpose understandable. However, it doesn't explicitly differentiate this tool from potential sibling tools like 'motion_search' or 'motion_projects' that might also retrieve schedule-related data, preventing a perfect score.

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 minimal guidance by noting 'no filtering options,' which implies when not to use it for filtered queries, but it lacks explicit alternatives (e.g., 'use motion_search for filtered results') or context on when to prefer this tool over others like 'motion_workspaces' or 'motion_users' for schedule-related needs. No clear usage scenarios or prerequisites are 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/sergiolopez94/motion-mcp-server'

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