Provides access to RescueTime productivity data, including daily summaries, activity tracking, productivity trends, category breakdowns, and hourly productivity analysis to monitor time usage across applications and websites.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@RescueTime MCP Server How productive was I yesterday compared to today?"
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.
An MCP (Model Context Protocol) server that provides Claude Desktop with access to your RescueTime productivity data, including daily summaries, activity tracking, and productivity trends.
Daily Summary: Get your productivity pulse, time logged, and productive vs distracting breakdown
Productivity Trends: Track your productivity score over the past week or more
Activity Data: See which applications and websites you spent time on
Category Breakdown: View time by category (Development, Communication, etc.)
Hourly Analysis: Identify your peak productivity hours
Related MCP server: Wakapi MCP Server
Python 3.11+
uv package manager
A RescueTime account (free or premium)
RescueTime API key
git clone https://github.com/JasonBates/rescuetime-mcp.git
cd rescuetime-mcp
uv syncSign in with your RescueTime account
Create a new API key or copy an existing one
Add the server to your Claude Desktop config at:
~/Library/Application Support/Claude/claude_desktop_config.json
{
"mcpServers": {
"rescuetime": {
"command": "uv",
"args": [
"--directory",
"/Users/YOUR_USERNAME/Projects/rescuetime-mcp",
"run",
"rescuetime-mcp"
],
"env": {
"RESCUETIME_API_KEY": "your_api_key_here"
}
}
}
}Replace YOUR_USERNAME with your actual username and add your API key.
Quit and reopen Claude Desktop. You should see "rescuetime" in the MCP servers list.
Once configured, you can ask Claude things like:
"How productive was I today?"
"Show me my productivity trend for the past week"
"What apps did I use most today?"
"What categories did I spend time on yesterday?"
"When was I most productive today?"
Tool | Description |
| Today's productivity pulse, time logged, and breakdown |
| Productivity score history (default 7 days) |
| Top applications/websites by time spent |
| Time spent by category |
| Productivity breakdown by hour |
Returns a complete daily overview including:
Productivity pulse (0-100 score)
Total time logged
Productive vs distracting percentages
Breakdown by productivity level (very productive → very distracting)
Shows daily productivity pulse with visual bars over multiple days. Useful for identifying patterns and weekly trends.
Lists specific applications and websites ranked by time spent. Each activity shows:
Productivity classification ([++] to [--])
Duration
Category
Groups time by high-level categories like Software Development, Communication, Reference & Learning, Social Networking, etc.
Reveals when during the day you were most/least productive. Helps identify peak hours for scheduling deep work.
Make sure your API key is correctly set in the Claude Desktop config's env section.
RescueTime needs to be running and logging data on your devices. Check that the RescueTime app is active.
The RescueTime API has rate limits. If you encounter errors, wait a few minutes before retrying.
# Install dev dependencies
uv sync --dev
# Run tests
uv run pytest
# Test with MCP Inspector
npx @modelcontextprotocol/inspector uv run rescuetime-mcpMIT
Get top activities/applications by time spent.
Args: date_str: Date to query - 'today', 'yesterday', or 'YYYY-MM-DD' limit: Maximum number of activities to show (default: 10)
Shows which specific applications and websites you spent time on, ranked by duration. Includes productivity classification for each.
| Name | Required | Description | Default |
|---|---|---|---|
| date_str | No | today | |
| limit | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the tool shows 'specific applications and websites you spent time on, ranked by duration' and includes 'productivity classification for each,' which adds behavioral context about output format and ranking. However, it doesn't mention permissions, rate limits, or data freshness, which are gaps for a tool with zero 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded with the core purpose, followed by parameter details and additional context. Every sentence adds value: the first states the purpose, the Args section clarifies parameters, and the last two sentences explain output details. No wasted words or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (2 parameters, no annotations, but with an output schema), the description is fairly complete. It covers purpose, parameter semantics, and output behavior (ranking, productivity classification). The output schema likely handles return values, so the description doesn't need to detail them. Minor gaps include lack of error handling or data source context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds meaningful semantics for both parameters: date_str specifies allowed values ('today', 'yesterday', or 'YYYY-MM-DD') and limit explains its purpose ('Maximum number of activities to show') with a default. This goes beyond the schema's basic type/default info, though it doesn't cover all possible edge cases.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('Get top activities/applications by time spent') and resources ('activities/applications'). It distinguishes from siblings by focusing on specific applications/websites ranked by duration, unlike category breakdowns, hourly productivity, trends, or summary tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage through its purpose statement but doesn't explicitly state when to use this tool versus alternatives like get_category_breakdown or get_today_summary. No explicit when-not or alternative guidance is provided, leaving usage context 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.
Get time spent by category.
Args: date_str: Date to query - 'today', 'yesterday', or 'YYYY-MM-DD'
Shows high-level categories like Software Development, Communication, Reference & Learning, etc. with time and productivity classification.
| Name | Required | Description | Default |
|---|---|---|---|
| date_str | No | today |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but provides minimal behavioral context. It mentions what data is shown (categories with time and productivity classification) but doesn't disclose important behavioral traits like whether this is a read-only operation, authentication requirements, rate limits, or what happens with invalid dates. The description doesn't contradict annotations since none exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded with the core purpose. The parameter documentation is structured clearly with 'Args:' section. While efficient, the second paragraph about categories could be more tightly integrated with the main purpose statement.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (single parameter, categorical analysis), the presence of an output schema, and the description's good parameter coverage, this is reasonably complete. The description explains what the tool returns (categories with time and productivity classification), which complements the output schema. However, more behavioral context would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage and only 1 parameter, the description fully compensates by providing complete parameter semantics. It explains the date_str parameter's purpose, format options ('today', 'yesterday', or 'YYYY-MM-DD'), and even provides a default value. This adds significant value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get time spent by category' with specific resource (time) and classification (by category). It distinguishes from siblings by focusing on categorical breakdown rather than hourly data, trends, or summaries. However, it doesn't explicitly contrast with each sibling tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context through the parameter explanation and examples of categories returned, but doesn't explicitly state when to use this tool versus alternatives like get_hourly_productivity or get_productivity_trend. No exclusions 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.
Get productivity breakdown by hour.
Args: date_str: Date to query - 'today', 'yesterday', or 'YYYY-MM-DD'
Shows when during the day you were most/least productive. Useful for identifying peak productivity hours and scheduling deep work.
| Name | Required | Description | Default |
|---|---|---|---|
| date_str | No | today |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions the tool 'Shows when during the day you were most/least productive' which gives some behavioral context about the output format. However, it doesn't disclose important behavioral traits like whether this is a read-only operation, what permissions might be required, whether data is real-time or cached, or any rate limits. For a tool with zero annotation coverage, this leaves significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly structured and concise. It begins with the core purpose, provides parameter documentation in a clear 'Args:' section, then adds usage context. Every sentence earns its place, with no wasted words or redundant information. The information is front-loaded with the most important details first.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there's an output schema (which handles return values), 1 parameter, and no annotations, the description does a reasonably complete job. It explains the tool's purpose, documents the parameter, and provides usage context. The main gap is the lack of behavioral transparency about permissions, data freshness, or operational constraints, which would be important for a productivity tracking tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explicitly documents the single parameter 'date_str' with its allowed values ('today', 'yesterday', or 'YYYY-MM-DD'), which adds crucial meaning beyond the schema's 0% description coverage. However, with only 1 parameter total, the baseline expectation is higher. The description compensates well for the schema's lack of documentation but doesn't provide additional context about parameter behavior beyond the basic format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get productivity breakdown by hour' specifies the verb ('Get') and resource ('productivity breakdown by hour'). It distinguishes from siblings like 'get_today_summary' by focusing on hourly granularity rather than daily summaries, though it doesn't explicitly contrast with all siblings like 'get_category_breakdown' or 'get_productivity_trend'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool: 'Useful for identifying peak productivity hours and scheduling deep work.' This gives practical application guidance. However, it doesn't explicitly state when NOT to use it or name specific alternatives among the sibling tools, which would be needed for a perfect score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get productivity pulse trend for the last N days.
Args: days: Number of days to look back (default: 7, max 14)
Shows the daily productivity pulse with visual bars and calculates averages. Useful for identifying patterns and trends over time.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 tool 'Shows the daily productivity pulse with visual bars and calculates averages,' adding behavioral context about output format and calculations. However, it lacks details on permissions, rate limits, or data sources, which are important 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.
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 parameter details and usage context. Each sentence adds value: the first defines the tool, the second explains the parameter, and the third describes output and utility. There's minimal waste, though it could be slightly more structured with bullet points.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has one parameter, no annotations, but an output schema exists, the description is fairly complete. It covers the purpose, parameter semantics, and output behavior ('Shows... visual bars and calculates averages'). The output schema likely handles return values, so the description doesn't need to detail them. However, it could improve by addressing sibling tool differentiation or authentication needs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant meaning beyond the input schema, which has 0% description coverage. It explains the 'days' parameter as 'Number of days to look back' with a default and max value, clarifying its purpose and constraints. Since there's only one parameter, this compensates well for the schema gap, though it could mention data types or validation rules.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get productivity pulse trend for the last N days.' It specifies the verb ('Get') and resource ('productivity pulse trend') with a temporal scope ('last N days'). However, it doesn't explicitly differentiate from sibling tools like 'get_hourly_productivity' or 'get_today_summary' beyond mentioning 'daily' productivity pulse.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by stating it's 'Useful for identifying patterns and trends over time,' which suggests when to use this tool. However, it doesn't provide explicit guidance on when to choose this over alternatives like 'get_today_summary' or 'get_hourly_productivity,' nor does it mention any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get today's complete RescueTime productivity summary.
This is the recommended daily check-in tool. Returns:
Productivity pulse (0-100 score)
Total time logged
Time breakdown by productivity level
Productive vs distracting percentages
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 describes what the tool returns (productivity pulse, total time, breakdowns, percentages), which adds useful context beyond the input schema. However, it lacks details on behavioral traits such as authentication needs, rate limits, or whether it's a read-only operation, leaving gaps for a mutation tool with zero 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded, starting with the main purpose and followed by a clear list of return values. Every sentence earns its place by providing essential information without waste, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (simple read operation), 0 parameters, and the presence of an output schema, the description is mostly complete. It explains the return values in detail, which compensates for the lack of annotations. However, it could be more complete by addressing potential behavioral aspects like data freshness or limitations, but the output schema likely covers return structure, so it's not a critical gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so the baseline is 4. The description doesn't need to add parameter information, and it doesn't introduce any confusion, making this appropriate for a no-param tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with the verb 'Get' and resource 'today's complete RescueTime productivity summary.' It distinguishes from siblings by specifying 'today's complete' summary rather than activity data, category breakdowns, hourly productivity, or trends. However, it doesn't explicitly contrast with each sibling tool, so it's not a perfect 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context with 'This is the recommended daily check-in tool,' which indicates when to use it. It implies usage for daily productivity overviews but doesn't explicitly state when not to use it or name alternatives like the sibling tools for more specific data, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
get_activity_dataget_category_breakdownget_hourly_productivityget_productivity_trendget_today_summaryEach tool has a clearly distinct purpose: get_activity_data focuses on specific applications/websites, get_category_breakdown on high-level categories, get_hourly_productivity on hourly patterns, get_productivity_trend on multi-day trends, and get_today_summary on a comprehensive daily overview. There is no overlap or ambiguity between these functions.
All tool names follow a consistent verb_noun pattern starting with 'get_' followed by a descriptive noun phrase (e.g., get_activity_data, get_category_breakdown). This uniformity makes the tool set predictable and easy to understand at a glance.
With 5 tools, this server is well-scoped for its purpose of providing RescueTime productivity insights. Each tool serves a unique and valuable function, covering key aspects like detailed activity data, category breakdowns, hourly analysis, trends, and daily summaries without being overwhelming or sparse.
The tool set covers the core productivity analysis domain comprehensively, including data retrieval, categorization, time-based patterns, and summaries. A minor gap is the lack of tools for modifying or configuring data (e.g., setting goals or adjusting classifications), but this is reasonable for a read-only analytics server focused on insights.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Read time entries, projects, clients, tasks and invoices; log and update tracked time.
Privacy-first work tracking with summaries, reports, coaching, and AI-ready long-term memory.
Read teams, spaces, lists and tasks; create, update and comment on tasks and track time.
Read wearables and lab health data — sleep, activity, workouts, timeseries, lab tests and orders.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/JasonBates/rescuetime-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
