Skip to main content
Glama
Lucid-Drone-Technologies

Paylocity MCP Server

get_pay_statements

Retrieve employee pay statement data including gross/net pay, hours, taxes, deductions, and earnings for a specific year, with optional filtering by check date.

Instructions

Get pay statement data for an employee by year. Returns both summary (gross pay, net pay, hours, direct deposit amounts) and line-item details (each tax, deduction, and earning). Optionally filter to a specific check date.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
companyIdNoPaylocity company ID (defaults to PAYLOCITY_COMPANY_ID env var)
employeeIdYesPaylocity employee ID
yearYesTax year (e.g. 2025)
checkDateNoCheck date YYYY-MM-DD (optional — omit for all checks in the year)

Implementation Reference

  • Registration and handler implementation for the "get_pay_statements" tool in src/server.ts. It fetches both summary and details from the Paylocity API for the specified employee and year, then redacts the output.
    server.tool(
      "get_pay_statements",
      `Get pay statement data for an employee by year. Returns both summary
    (gross pay, net pay, hours, direct deposit amounts) and line-item details
    (each tax, deduction, and earning). Optionally filter to a specific check date.`,
      {
        companyId: companyIdParam,
        employeeId: z.string().describe("Paylocity employee ID"),
        year: z.string().describe("Tax year (e.g. 2025)"),
        checkDate: z
          .string()
          .optional()
          .describe("Check date YYYY-MM-DD (optional — omit for all checks in the year)"),
      },
      async ({ companyId, employeeId, year, checkDate }) => {
        try {
          const cid = resolveCompanyId(companyId);
          const suffix = checkDate ? `/${year}/${checkDate}` : `/${year}`;
          const base = `/v2/companies/${cid}/employees/${employeeId}/paystatement`;
    
          const [summary, details] = await Promise.all([
            client.get(`${base}/summary${suffix}`),
            client.get(`${base}/details${suffix}`),
          ]);
    
          return ok(redact({ summary, details }));
        } catch (e) {
          return err(e);
        }
      }
    );
Behavior4/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 effectively discloses the return payload structure—specifying both summary fields (gross/net pay, hours) and line-item details (taxes, deductions, earnings)—which compensates for the missing output_schema. However, it does not explicitly confirm this is read-only/safe or describe error cases (e.g., invalid year).

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 consists of three efficiently structured sentences: purpose (sentence 1), return value details (sentence 2), and optional filtering capability (sentence 3). There is no redundant or wasted text; every clause adds specific value about functionality or return structure.

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 absence of an output schema, the description adequately compensates by detailing the return structure (summary vs. line-item data). With 100% schema coverage for inputs and clear required parameter indication, the definition is complete for invocation, though it could benefit from mentioning data availability constraints or error scenarios.

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, documenting all four parameters including the optional nature of checkDate and companyId default behavior. The description reinforces the year-based retrieval and optional date filtering, but does not add semantic meaning beyond what the schema already provides, warranting the baseline score.

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?

The description uses a specific verb ('Get') and resource ('pay statement data') and clearly scopes it to 'by year'. It effectively distinguishes from siblings like get_direct_deposit (which retrieves setup/configuration, not pay statements) and get_employee (profile data) by specifying it returns payroll details including 'gross pay, net pay, hours' and line-item breakdowns.

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 mentions the optional checkDate filter ('Optionally filter to a specific check date'), implying when to use that parameter. However, it lacks explicit guidance on when to choose this over get_direct_deposit or prerequisites like requiring an existing employeeId from get_employee/search_employees.

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/Lucid-Drone-Technologies/paylocity-mcp'

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