What can you do with this server?

This server provides MCP tools for interacting with Woffu time tracking, allowing you to manage workday clock-ins/outs, view summaries, and handle time entries. * Clock In/Out: Start or end your workday with woffu_clock_in / woffu_clock_out. * Status: Get today's work status (hours worked, schedule, clock state) via woffu_status. * Summaries: Retrieve monthly or weekly worked hours with woffu_month_summary / woffu_week_summary. * Day Details: Get detailed clock events for a specific day with woffu_day_detail. * Pending Days: List workdays without logged hours using woffu_pending_days. * Schedule: View your assigned work schedule with woffu_schedule. * Complete Past Days: Fill in or edit time slots for past dates using woffu_complete_day. * Confirm/Unconfirm Days: Confirm (woffu_confirm_day) or unconfirm (woffu_unconfirm_day) workday diaries to accept or unlock records for editing.

How do I use woffu-mcp?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@woffu-mcp clock me in" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

woffu-mcp

by iflorit

Overview Schema Source Related Servers Discussions Admin

JavaScript

Remote

MCP Woffu Server

A Model Context Protocol (MCP) server for Woffu time tracking integration. This server allows AI assistants like Claude to interact with your Woffu account for clock-in/out operations and time tracking management.

Features

Clock In/Out: Start and end your workday with simple commands
Today's Status: Check your current work status, hours worked, and schedule
Week/Month Summary: Get a comprehensive overview of your worked hours
Complete Past Days: Fill in missing time entries for past dates
Pending Days: View days without logged hours
Confirm Days: Confirm (accept) workday diaries

Related MCP server: WorkTracker MCP Server

Installation

Using npx from GitHub (recommended)

npx github:iflorit/mcp-woffu-server

Installing globally from GitHub

npm install -g github:iflorit/mcp-woffu-server
mcp-woffu-server

From source

git clone https://github.com/iflorit/mcp-woffu-server.git
cd mcp-woffu-server
npm install
npm run build

Configuration

The server requires the following environment variables:

Variable	Description	Required
`WOFFU_TOKEN`	JWT Bearer token for Woffu API	Yes
`WOFFU_USER_ID`	Your Woffu user ID	Yes
`WOFFU_BASE_URL`	Woffu instance URL (e.g., `https://mycompany.woffu.com`)	No (defaults to `https://app.woffu.com`)

How to get your Woffu JWT Token

Log in to your Woffu web portal (e.g., https://mycompany.woffu.com)
Open browser Developer Tools (F12)
Go to the Application tab (Chrome) or Storage tab (Firefox)
In the left panel, expand Cookies
Click on your Woffu domain (e.g., https://mycompany.woffu.com)
Find the cookie named woffu.token
Copy the value - this is your WOFFU_TOKEN

Alternative via Console:

document.cookie.split(';').find(c => c.trim().startsWith('woffu.token=')).split('=')[1]

Note: JWT tokens expire periodically. You may need to refresh the token when it expires.

How to find your User ID

The User ID is embedded in the JWT token. You can decode it at jwt.io and look for the UserId field in the payload.

Alternatively:

In the browser Developer Tools, go to Network tab
Perform any action in Woffu
Look at any API request URL - it often contains your user ID (e.g., /api/users/1234567/...)

Usage

With Claude Desktop

Add the following to your Claude Desktop configuration file:

macOS: ~/Library/Application Support/Claude/claude_desktop_config.json Windows: %APPDATA%\Claude\claude_desktop_config.json

{
  "mcpServers": {
    "woffu": {
      "command": "npx",
      "args": ["-y", "github:iflorit/mcp-woffu-server"],
      "env": {
        "WOFFU_TOKEN": "your-jwt-token-here",
        "WOFFU_USER_ID": "your-user-id",
        "WOFFU_BASE_URL": "https://mycompany.woffu.com"
      }
    }
  }
}

With Claude Code

claude mcp add woffu --env WOFFU_TOKEN=your-token --env WOFFU_USER_ID=your-id --env WOFFU_BASE_URL=https://mycompany.woffu.com -- npx -y github:iflorit/mcp-woffu-server

Or add to your .claude.json:

{
  "mcpServers": {
    "woffu": {
      "command": "npx",
      "args": ["-y", "github:iflorit/mcp-woffu-server"],
      "env": {
        "WOFFU_TOKEN": "your-jwt-token-here",
        "WOFFU_USER_ID": "your-user-id",
        "WOFFU_BASE_URL": "https://mycompany.woffu.com"
      }
    }
  }
}

Running the Server Directly

# With environment variables
export WOFFU_TOKEN="your-token"
export WOFFU_USER_ID="your-user-id"
export WOFFU_BASE_URL="https://mycompany.woffu.com"

# Run the server
npx github:iflorit/mcp-woffu-server

Available Tools

`woffu_clock_in`

Clock in to start your workday.

Parameters: None

Example response:

{
  "status": "success",
  "action": "clock_in",
  "timestamp": "2024-01-15T09:00:00",
  "signEventId": "12345"
}

`woffu_clock_out`

Clock out to end your workday.

Parameters: None

Example response:

{
  "status": "success",
  "action": "clock_out",
  "timestamp": "2024-01-15T18:00:00",
  "signEventId": "12346"
}

`woffu_status`

Get today's work status including schedule and hours worked.

Parameters: None

Returns: Detailed workday information including:

Current clock status
Hours worked today
Expected hours
Break times

`woffu_month_summary`

Get a summary of worked hours for a specific month.

Parameters:

year (optional): Year (defaults to current year)
month (optional): Month 1-12 (defaults to current month)

Returns: Monthly presence summary with daily breakdowns.

`woffu_week_summary`

Get a weekly summary of worked hours.

Parameters:

date (optional): Any date within the desired week in YYYY-MM-DD format

Returns: Weekly presence summary with daily breakdowns.

`woffu_day_detail`

Get detailed information for a specific day.

Parameters:

date (optional): Date in YYYY-MM-DD format (defaults to today)

Returns: Detailed day information including all clock events.

`woffu_pending_days`

Get days without completed hours.

Parameters:

year (optional): Year (defaults to current year)
month (optional): Month 1-12 (defaults to current month)

Returns: List of workdays where no hours have been logged.

`woffu_schedule`

Get the user's assigned work schedule.

Parameters: None

Returns: Schedule information including work hours and office details.

`woffu_complete_day`

Complete or edit time entries for a past day.

Parameters:

date: Date in YYYY-MM-DD format
slots: List of time slots with in_time and out_time (HH:MM format)
confirm (optional, default false): confirm (accept) the day right after filling it. Confirmation requires registered time unless forced.
force (optional, default false): fill even if the day is a weekend, holiday, calendar event, or has absences/vacations (refused otherwise)

Example:

{
  "date": "2024-01-10",
  "slots": [
    {"in_time": "09:00", "out_time": "14:00"},
    {"in_time": "15:00", "out_time": "18:00"}
  ]
}

`woffu_confirm_day`

Confirm (accept) one or more workday diaries, marking the day's records as reviewed by the employee. Already-confirmed days are skipped.

Refuses days without registered time unless force: true.

Parameters:

dates: List of dates in YYYY-MM-DD format
force (optional, default false): confirm even with no time registered

Example:

{
  "dates": ["2024-01-10", "2024-01-11"]
}

`woffu_unconfirm_day`

Unconfirm (revert acceptance of) one or more workday diaries, unlocking them for editing again. Confirmed days are locked: woffu_complete_day refuses them until unconfirmed.

Parameters:

dates: List of dates in YYYY-MM-DD format

Example Conversations with Claude

"Clock me in to Woffu"

"What's my work status for today?"

"Show me my hours for November 2024"

"I forgot to clock in yesterday. Can you fill in 9:00-14:00 and 15:00-18:00 for 2024-01-14?"

"Show me my pending days this month"

Development

Setup

git clone https://github.com/iflorit/mcp-woffu-server.git
cd mcp-woffu-server
npm install

Building

npm run build

Running in development

npm run dev

Security Notes

Never commit your JWT token to version control
Use environment variables or secure secret management
JWT tokens expire - refresh the token from the woffu.token cookie when needed
The server only accepts local connections by default

License

MIT License - see LICENSE file for details.

Contributing

Contributions are welcome! Please feel free to submit a Pull Request.

Acknowledgments

Built with the Model Context Protocol SDK
Integrates with Woffu time tracking

Available Tools

9 tools

woffu_clock_inA

Clock in (fichar entrada) to Woffu. Use when user wants to start workday.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.9/5.0

Behavior2/5

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

No annotations provided. Description lacks details on side effects, requirements, or post-action state, which is critical for a mutation 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.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence, front-loaded, no wasted words. Perfectly concise for the action described.

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?

Minimal but functional for a 0-param, no-output-schema tool. Lacks behavioral context but meets basic needs. Could mention if time/date is auto-recorded.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

No parameters exist (0 param count). Baseline 4 per instructions. Description adds nothing beyond schema but that's acceptable as schema covers all.

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 clearly states the verb 'Clock in' and resource 'Woffu', and distinguishes from siblings like woffu_clock_out by its name and usage hint.

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?

Explicitly says 'Use when user wants to start workday', providing clear context. Does not list exclusions but name and sibling differentiation suffice.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

woffu_clock_outA

Clock out (fichar salida) from Woffu. Use when user wants to end workday.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.9/5.0

Behavior2/5

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

No annotations, so description must disclose behavior. Only states basic action; does not mention prerequisites (e.g., must be clocked in), potential idempotency, or side effects. Significant gap.

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?

Two short sentences with no extraneous words; perfectly front-loaded and efficient.

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?

Simple tool with no params or output schema, so minimal description might suffice. However, lacks context on error handling, state requirements, or confirmation, making it slightly incomplete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

No parameters in schema resulting in 100% coverage. Baseline for 0 params is 4; description adds no param info but none needed.

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?

Clearly states the tool clocks out from Woffu and explains it ends the workday, distinguishing it from siblings like woffu_clock_in.

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?

Explicitly says to use when user wants to end workday, providing clear context. Lacks mention of when not to use or alternatives, but adequate for simple tool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

woffu_complete_dayA

Fill time entries for a past day. Cannot be used for today until after 17:00.

ParametersJSON Schema

Name	Required	Description	Default
`date`	Yes	Date (YYYY-MM-DD)
`slots`	Yes	Time slots: [{in_time: 'HH:MM', out_time: 'HH:MM'}, ...]

TDQS

A3.9/5.0

Behavior3/5

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

With no annotations, the description carries the full burden. It mentions a timing constraint but does not disclose whether the tool overwrites existing entries, requires any state, or has side effects. It provides basic behavioral context but lacks depth.

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 extremely concise: two sentences, front-loaded with the action and immediately followed by a key constraint. Every sentence adds value with no redundancy.

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?

Considering the complexity (2 params, no output schema, and multiple sibling tools), the description covers the core functionality and usage constraint. However, it omits any information about the return value or outcome, which is a notable gap for a construction tool.

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?

Input schema has 100% coverage with clear descriptions for both parameters (date and slots). The description adds minimal extra meaning (just 'Fill time entries'), but the schema itself is sufficient. Baseline 3 is appropriate.

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 clearly states the tool's purpose: 'Fill time entries for a past day.' It specifies the resource (time entries) and the action (fill), and distinguishes from siblings like clock_in/out which handle individual slots. The added constraint about today after 17:00 further clarifies scope.

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 explicit guidance: 'Cannot be used for today until after 17:00,' indicating when to use (past days, or today after 17:00). However, it does not explicitly compare with alternatives like woffu_day_detail or woffu_status, leaving some ambiguity about relative use cases.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

woffu_day_detailA

Get detailed info for a specific day including all clock events.

ParametersJSON Schema

Name	Required	Description	Default
`date`	No	Date (YYYY-MM-DD). Default: today.

TDQS

A3.5/5.0

Behavior2/5

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

No annotations are provided, so the description carries the burden. It states 'including all clock events' but does not disclose behavior such as what happens if the day has no clock events, whether errors occur for invalid dates, or any side effects. Being a read operation, mutability is not an issue, but absence of error/edge-case handling reduces 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 sentence with 12 words, front-loading the core purpose. Every word is necessary; no fluff or repetition.

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?

With no output schema, the description gives a general idea of return content ('detailed info...including all clock events') but lacks specifics on the data structure or additional fields. For a simple single-parameter tool, this is adequate but not fully comprehensive.

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%: the single parameter 'date' has a clear description and default value. The tool description adds no additional meaning beyond the schema, meeting the baseline for high coverage.

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?

Description clearly states the verb 'Get', the resource 'detailed info for a specific day', and specifies inclusion of 'all clock events', which distinguishes it from siblings like woffu_month_summary or woffu_week_summary that cover broader time periods.

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 for a specific day, but lacks explicit guidance on when to use this tool versus alternatives (e.g., woffu_month_summary for month view, woffu_clock_in for individual events). No when-not-to-use or conditions provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

woffu_month_summaryA

Get monthly summary of worked hours with daily breakdowns.

ParametersJSON Schema

Name	Required	Description	Default
`year`	No	Year (default: current)
`month`	No	Month 1-12 (default: current)

TDQS

A3.5/5.0

Behavior2/5

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

No annotations are provided, so the description carries full burden. It only states it returns a summary with daily breakdowns, but does not disclose behavioral traits like read-only nature, authentication needs, or what happens with missing parameters.

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 of 8 words, with no fluff. It is appropriately sized and front-loaded.

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?

For a simple retrieval tool with good schema coverage and no output schema, the description is adequate but lacks details on authentication or response format. It meets the minimum viable standard.

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 coverage is 100% with both 'year' and 'month' having descriptions about defaults. The description adds no further meaning beyond what the schema already provides, so baseline 3 is appropriate.

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 clearly states the tool gets a monthly summary of worked hours with daily breakdowns. It uses a specific verb ('Get') and resource, and distinguishes from siblings like woffu_week_summary and woffu_day_detail.

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 the tool is for monthly summaries but does not explicitly state when to use it over siblings or any exclusions. No guidance on prerequisites or alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

woffu_pending_daysA

Get workdays without logged hours (pending days).

ParametersJSON Schema

Name	Required	Description	Default
`year`	No	Year (default: current)
`month`	No	Month 1-12 (default: current)

TDQS

A3.5/5.0

Behavior2/5

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

No annotations are provided, so the description must convey behavioral traits. It only states the basic purpose, omitting details like read-only nature, authentication requirements, or what happens if no pending days exist.

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?

A single sentence with no wasted words, accurately conveying the tool's function.

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?

No output schema exists, yet the description does not explain the return format (e.g., list of dates, count). For a simple tool this might suffice, but more context would improve completeness.

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 coverage is 100% with both parameters already described. The description adds no additional meaning beyond what the schema provides, so baseline 3 is appropriate.

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 clearly states the verb 'Get' and the resource 'workdays without logged hours (pending days)', which distinguishes it from sibling tools like woffu_day_detail (general day info) and woffu_clock_in (time tracking actions).

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?

No explicit guidance on when to use this tool versus alternatives like woffu_day_detail or woffu_month_summary. The purpose is implied but not contrasted with sibling tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

woffu_scheduleB

Get the user's assigned work schedule.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

B3.2/5.0

Behavior2/5

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

The description only implies read-only behavior through the verb 'Get'. With no annotations, it does not disclose any side effects, permissions, or other traits.

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?

One sentence, front-loaded, no wasted words. It is appropriately concise for a simple tool.

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 parameters or output schema, the description tells the core function but lacks details on scope (e.g., current user, date range). Minimal but adequate.

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?

There are no parameters, so the schema coverage is 100%. The description adds no extra meaning, but baseline is 3 due to high coverage.

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 clearly states the action 'Get' and the resource 'user's assigned work schedule'. It distinguishes from siblings like woffu_clock_in and woffu_day_detail by focusing on schedule retrieval.

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?

No guidance is provided on when to use this tool versus alternatives or any prerequisites. The description is minimal without context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

woffu_statusA

Get today's work status: hours worked, schedule, clock state.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.4/5.0

Behavior4/5

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

Despite no annotations, the description list outputs and implies a read-only operation. Provides good insight into what the tool returns.

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?

Single sentence, front-loaded purpose, no wasted words. Appropriate for a simple tool.

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

Completeness5/5

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

Given no parameters and no output schema, the description fully describes what the tool returns. Adequate for agent understanding.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

No parameters exist, so no additional meaning needed. The input schema is empty, and description does not need to compensate.

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?

Description clearly states 'Get today's work status' with specific outputs (hours worked, schedule, clock state). Distinguishes well from sibling tools like woffu_clock_in, woffu_day_detail, etc.

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?

No explicit guidance on when to use vs alternatives. Implied usage from purpose, but no when-not-to or alternative mention.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

woffu_week_summaryA

Get weekly summary of worked hours.

ParametersJSON Schema

Name	Required	Description	Default
`date`	No	Any date in the week (YYYY-MM-DD). Default: current week.

TDQS

A3.5/5.0

Behavior3/5

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

With no annotations, the description carries full burden. It indicates a read operation (summary), but does not disclose return format, aggregation details, or timezone handling. Minimal but not misleading.

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?

One short, front-loaded sentence with no waste. Every word earns its place.

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 one optional parameter and no output schema, the description is minimal. It does not specify what the summary contains (e.g., total hours, breakdown), leaving the agent underinformed about the return value.

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%, and the schema already documents the date parameter with format and default. The description adds no extra meaning beyond the schema, so baseline score of 3 is appropriate.

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 'weekly summary of worked hours', clearly distinguishing from siblings like woffu_day_detail (daily) and woffu_month_summary (monthly).

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?

No guidance on when to use this tool versus alternatives like woffu_day_detail or woffu_month_summary. The context signals list siblings but the description does not differentiate usage scenarios.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

9 tool updatesv0.1.0Jun 25, 2026
- First observedwoffu_clock_in
- First observedwoffu_clock_out
- First observedwoffu_complete_day
- First observedwoffu_day_detail
- First observedwoffu_month_summary
- First observedwoffu_pending_days
- First observedwoffu_schedule
- First observedwoffu_status
- First observedwoffu_week_summary

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.9/5.0

Scored 2026-06-25 03:01 across 9 tools

Disambiguation5/5

Each tool targets a distinct aspect of time tracking: clock in/out, filling past days, viewing day/month/week details, summary, pending days, schedule, and status. No overlap in functionality.

Naming Consistency5/5

All tools follow the pattern 'woffu_verb_noun' or 'woffu_noun' consistently, making it easy to predict tool purposes from names.

Tool Count5/5

9 tools cover the core attendance tracking operations without being too many or too few. Each tool serves a clear need.

Completeness4/5

Covers clock in/out, filling past entries, summaries, schedule, and status. Minor gap: no direct edit or delete for clock events, but complete_day may handle corrections.

Maintenance

ActivitySlowing

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

TimequipOAuth
com.timequip
Manage Timequip projects, tasks, comments, members, and dashboards through MCP.
Project Management Workplace & Productivity
1
mcp-serverOAuth
io.klokin
MCP server exposing klokin time-tracking operations (employees, time entries, stores) to AI clients.
Workplace & Productivity Project Management
2
cloudtime API
io.github.julysoft
MCP server providing attendance data queries via the CloudTime API.
Workplace & Productivity
2
REPSLogOAuth
com.reps-log
Log and read REPS time logs, properties, and categories via MCP. Requires REPSLog Premium.
Project Management Workplace & Productivity
1

Related MCP Servers

Timesheet MCP Serverofficial
Project Management Workplace & Productivity
timesheetIO
A
license
B
quality
B
maintenance
Enables natural language control of the Timesheet API for timer management, task tracking, and project management through MCP tools.
Updated 15 days ago (2026-09-06 13:34 UTC)
50
49 npm
MIT
WorkTracker MCP Server
Project Management Workplace & Productivity
SkyTechNerds
A
license
Not graded
quality
B
maintenance
Enables natural language time tracking and booking for WorkTracker via MCP tools, allowing users to assign time, list projects, and manage daily schedules through conversational commands.
Updated a month ago (2026-08-14 12:45 UTC)
MIT
WeDaka MCP Server
Workplace & Productivity
keith-hung
A
license
A
quality
D
maintenance
Enables employee time tracking with clock-in/out, workday checking, and time log retrieval via MCP tools.
Updated 10 months ago (2025-11-27 03:16 UTC)
4
1
MIT
leave-manager-mcp
ERP Systems Workplace & Productivity
git-akki
F
license
Not graded
quality
D
maintenance
Enables AI assistants to manage employee leave by checking balances, applying for leave, and viewing history via MCP tools.
Updated 8 months ago (2026-01-16 09:50 UTC)
-

MCP Woffu Server

Features

Installation

Using npx from GitHub (recommended)

Installing globally from GitHub

From source

Configuration

How to get your Woffu JWT Token

How to find your User ID

Usage

With Claude Desktop

With Claude Code

Running the Server Directly

Available Tools

woffu_clock_in

woffu_clock_out

woffu_status

woffu_month_summary

woffu_week_summary

woffu_day_detail

woffu_pending_days

woffu_schedule

woffu_complete_day

woffu_confirm_day

woffu_unconfirm_day

Example Conversations with Claude

Development

Setup

Building

Running in development

Security Notes

License

Contributing

Acknowledgments

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

Timesheet MCP Serverofficial

`woffu_clock_in`

`woffu_clock_out`

`woffu_status`

`woffu_month_summary`

`woffu_week_summary`

`woffu_day_detail`

`woffu_pending_days`

`woffu_schedule`

`woffu_complete_day`

`woffu_confirm_day`

`woffu_unconfirm_day`