How do I use roo-activity-logger?

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., "@roo-activity-logger Record the file operation I just did" 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.

roo-activity-logger

by annenpolka

Overview Schema Source Related Servers Discussions Admin

TypeScript

Local

Roo Activity Logger

日本語版はこちら | 中文版

TL;DR

What is it? — This is an MCP server that automatically logs AI coding assistant activities such as command executions and code generation (supports Roo Code, Cline, Claude Code, etc.).
What does it do? — It saves activity history as JSON files, which you can search and analyze later.
How do I use it? — Add it to your Claude Code, Cline, or Roo-Code settings to enable automatic activity logging.

Related MCP server: repro-mcp

Overview

Roo Activity Logger is an MCP (Model Context Protocol) server that automatically records AI coding assistant development activities — including command executions, code generation, file operations, and more. It supports Claude Code, Cline, Roo-Code, and other MCP-compatible AI assistants. All logs are saved in JSON format, making it easy to search, analyze, and restore context at any time.

How activity logging works

flowchart TD
    A[Roo's Action] --> B[Select Activity Type]
    B --> C[Log via log_activity]
    C --> D[Provide Log Info<br>- Summary<br>- Details<br>- Intention<br>- Context]
    D --> E[Specify Save Directory]
    E --> F[Save as JSON file]

How to search logs and restore context when resuming a task

flowchart TD
    G[Resume Task] --> H[Search with search_logs]
    H --> I[Set Search Filters<br>- Type<br>- Date Range<br>- Text]
    I --> J[Retrieve Related Activities<br>- Parent/Child<br>- Sequence<br>- Related IDs]
    J --> K[Restore Context & Resume<br>- Review Past Intentions<br>- Understand Progress]

Sample Log Entry

Here is an example of a file_operation log entry saved as JSON:

{
  "id": "75add15d-8d5b-4e60-b327-fde785050c86",
  "timestamp": "2025-04-10T01:58:02.905Z",
  "type": "file_operation",
  "level": "info",
  "summary": "Inserted mermaid diagram into README.md",
  "details": {
    "file": "README.md",
    "operation": "insert_content",
    "insertedLines": "mermaid code block",
    "position": "after overview section"
  },
  "intention": "To visually explain the flow of saving and retrieving activities",
  "context": "Improving documentation for Roo Activity Logger",
  "parentId": "98280366-1de1-48e0-9914-b3a3409599b4"
}

Each log contains:

Log level (debug, info, warn, error)
Summary
Details (any structured data)
Intention / Purpose
Context information
Parent activity ID (for hierarchy)
Sequence number (for ordering)
Related activity IDs (for grouping)

Logs are:

Saved as date-based JSON files
Searchable by type, level, date, text, etc.
Customizable — you can specify different save directories per activity

Features

Logs various activity types:
- Command executions (command_execution)
- Code generation (code_generation)
- File operations (file_operation)
- Errors (error_encountered)
- Decisions (decision_made)
- Conversations (conversation)
Each activity log includes:
- Unique ID
- Timestamp
- Activity type
- Summary, details, intention, context, and optional metadata

Usage (Recommended: via `npx`)

You can run Roo Activity Logger directly without cloning the repository by using npx.

Add this to your Cline, Roo-Code, or Claude Code configuration:

{
  "mcpServers": {
    "roo-activity-logger": {
      "command": "npx",
      "args": ["-y", "github:annenpolka/roo-logger"],
      "env": {},
      "disabled": false
    }
  }
}

Then, add prompts to your rule files (for Cline/Roo-Code) or CLAUDE.md (for Claude Code) to ensure logging, for example:

## Important

Always log activities using roo-activity-logger according to the logging rules.

## Preparation

Check the current context with `git status`.

Then, use roo-activity-logger's `search_logs` to review existing logs and identify current tasks.

Be sure to perform the logging steps.

## Logging

- Always use roo-activity-logger for all logs
- Include stack traces and execution context
- Record intention and context

For Developers: Local Setup

To develop or customize locally, clone the repository and build:

# Clone the repo
git clone https://github.com/annenpolka/roo-logger.git
cd roo-logger

# Install dependencies
npm install

# Build
npm run build

Example configuration to use your local build:

{
  "mcpServers": {
    "roo-activity-logger": {
      "command": "node",
      "args": ["/path/to/your/local/roo-logger/dist/index.js"], // adjust path accordingly
      "env": {},
      "disabled": false
    }
  }
}

Notes

The specified directory will be created automatically if it does not exist.

MCP Tools

`log_activity` — Record an activity

A tool to record an activity.

Basic example

{
  "type": "command_execution",
  "summary": "Run npm command",
  "intention": "Update project dependencies",
  "context": "Preparing for new feature development",
  "logsDir": "/absolute/path/to/logs/activity"
}

Parameters

Name	Required	Type	Description
`type`	Yes	string	Activity type (`command_execution`, `code_generation`, `file_operation`, `error_encountered`, `decision_made`, `conversation`)
`summary`	Yes	string	Short summary of the activity
`intention`	Yes	string	Purpose or intention
`context`	Yes	string	Context information
`logsDir`	Yes	string	Save directory (absolute path only)
`level`	No	string	Log level (`debug`, `info`, `warn`, `error`). Default: `info`
`details`	No	object	Additional details (any JSON)
`parentId`	No	string	Parent activity ID
`sequence`	No	number	Sequence number
`relatedIds`	No	string[]	Related activity IDs

Detailed example

{
  "type": "file_operation",
  "summary": "Update README file",
  "intention": "Clarify documentation and improve usability",
  "context": "Improvements based on user feedback",
  "level": "info",
  "details": {
    "file": "README.md",
    "operation": "update",
    "changedLines": 15
  },
  "logsDir": "/absolute/path/to/logs/activity",
  "sequence": 3,
  "relatedIds": ["11223344-5566-7788-99aa-bbccddeeff00"]
}

`get_log_files` — List saved log files

Lists saved log files recursively. You can specify the maximum search depth.

Basic example

{
  "logsDir": "/absolute/path/to/logs"
}

Parameters

Name	Required	Type	Description
`logsDir`	Yes	string	Directory to search (absolute path only)
`limit`	No	number	Max files to retrieve (default: 10)
`offset`	No	number	Number of files to skip (default: 0)
`logFilePrefix`	No	string	Log file prefix (default: `"roo-activity-"`)
`logFileExtension`	No	string	Log file extension (default: `".json"`)
`maxDepth`	No	number	Max directory depth (default: 3)

`search_logs` — Search saved logs

Searches saved logs with various filters.

Basic example

{
  "logsDir": "/absolute/path/to/logs"
}

{
  "logsDir": "/absolute/path/to/logs",
  "type": "command_execution"
}

Parameters

Name	Required	Type	Description
`logsDir`	Yes	string	Log directory (absolute path only)
`logFilePrefix`	No	string	Log file prefix (default: `"roo-activity-"`)
`logFileExtension`	No	string	Log file extension (default: `".json"`)
`type`	No	string	Filter by activity type (`command_execution`, `code_generation`, `file_operation`, `error_encountered`, `decision_made`, `conversation`)
`level`	No	string	Filter by log level (`debug`, `info`, `warn`, `error`)
`startDate`	No	string	Start date (YYYY-MM-DD)
`endDate`	No	string	End date (YYYY-MM-DD)
`searchText`	No	string	Search text in summary or details
`limit`	No	number	Max logs to retrieve (default: 50)
`offset`	No	number	Number of logs to skip (default: 0)
`parentId`	No	string	Filter by parent activity ID
`sequenceFrom`	No	number	Sequence number lower bound
`sequenceTo`	No	number	Sequence number upper bound
`relatedId`	No	string	Filter by related activity ID
`relatedIds`	No	string[]	Filter by any of related activity IDs

License

MIT

Available Tools

3 tools

get_log_filesC

Get a paginated list of available log files in the specified directory with filtering options

ParametersJSON Schema

Name	Required	Default
`logsDir`	Yes
`limit`	No
`offset`	No
`logFilePrefix`	No	roo-activity-
`logFileExtension`	No	.json
`maxDepth`	No

TDQS

C2.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 transparency burden. It reveals pagination and filtering but omits important details such as ordering, error handling for invalid directories, or the structure of the returned list. The description is adequate but not thorough.

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 single sentence is concise and front-loaded with key information. Every part contributes to the purpose, though it could be split for clarity. No wasted words.

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

Completeness2/5

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

The description is insufficient for a tool with six parameters and no output schema. It does not explain the return format, pagination behavior, or filtering mechanics. Given the complexity, more detail is needed to allow correct invocation.

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

Parameters2/5

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

Schema coverage is 0%, so the description must explain parameters. It mentions 'specified directory' (matching 'logsDir') and 'filtering options' but does not elaborate on 'limit', 'offset', 'logFilePrefix', 'logFileExtension', or 'maxDepth'. The description adds minimal meaning beyond the parameter names.

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'), the resource ('available log files'), and key features ('paginated list', 'filtering options'). It distinguishes from sibling tools like 'search_logs' which implies searching content rather than listing files, and 'log_activity' which likely logs actions. However, it does not explicitly contrast with these tools.

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 siblings. There is no mention of prerequisites, directory existence requirements, or alternative tools for different use cases. The description is purely operational.

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

log_activityB

Record an activity log entry with structured data for tracking development activities, decisions, and context

ParametersJSON Schema

Name	Required	Default
`type`	Yes
`summary`	Yes
`intention`	Yes
`context`	Yes
`logsDir`	Yes
`level`	No	info
`details`	No
`parentId`	No
`sequence`	No
`relatedIds`	No

TDQS

B3.2/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 the basic action without disclosing behavioral traits such as whether it appends or overwrites, permissions needed, error handling, or side effects.

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 a single concise sentence with no unnecessary words. However, it could be more structured to include key details without sacrificing conciseness.

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

Completeness2/5

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

Given the tool's complexity (10 parameters, nested objects, no output schema), the description is insufficient. It does not cover return values, error conditions, or logging behavior, leaving the agent without critical context.

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

Parameters2/5

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

Schema description coverage is 0%, and the description does not elaborate on any of the 10 parameters. It lacks individual parameter explanations, which is a significant gap for a tool with many required fields.

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 tool records an activity log entry with structured data for tracking development activities, decisions, and context. It uses a specific verb and resource, and naturally distinguishes from sibling tools (get_log_files, search_logs) which are for retrieval.

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 does not explicitly state when to use this tool, when not to, or mention alternatives. Usage is implied as the write counterpart to the read-focused siblings, but no direct guidance is provided.

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

search_logsC

Search and filter activity logs with various criteria including date ranges, text search, and activity relationships

ParametersJSON Schema

Name	Required	Default
`logsDir`	Yes
`logFilePrefix`	No	roo-activity-
`logFileExtension`	No	.json
`type`	No
`level`	No
`startDate`	No
`endDate`	No
`searchText`	No
`limit`	No
`offset`	No
`parentId`	No
`sequenceFrom`	No
`sequenceTo`	No
`relatedId`	No
`relatedIds`	No

TDQS

C2.8/5.0

Behavior2/5

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

With no annotations provided, the description must disclose behavioral traits. It only states basic purpose, omitting details on read-only nature, performance, authentication, or side effects, leaving 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.

Conciseness3/5

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

The description is a single sentence, concise but not optimally structured. It lacks front-loading of key information such as the required 'logsDir' parameter.

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

Completeness2/5

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

Given 15 parameters, no output schema, and no annotations, the description is incomplete. It does not explain return values, pagination (limit/offset), or the hierarchy of activity relationships, which are crucial for proper tool usage.

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

Parameters2/5

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

Schema has 15 parameters with 0% description coverage. The description mentions 'date ranges, text search, and activity relationships', which hints at some parameters (startDate, endDate, searchText, parentId, relatedId), but fails to explain most parameters or their format (e.g., logsDir, logFilePrefix, limit, offset). The compensation is insufficient.

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 uses the verb 'search and filter' on 'activity logs', clearly stating the tool's purpose. However, it does not explicitly differentiate from sibling tools 'get_log_files' and 'log_activity', leaving some ambiguity.

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 searching logs with criteria like date ranges and text search, but provides no explicit guidance on when to use this tool versus alternatives, nor 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.

Tool Schema Changelog

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

3 tool updatesv0.2.0May 29, 2026
- First observedget_log_files
- First observedlog_activity
- First observedsearch_logs

Deploy Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.5/5.0

Scored 2026-05-29 08:15 across 3 tools

Disambiguation5/5

Each tool has a clear, distinct purpose: listing log files, recording an activity, and searching logs. There is no overlap or ambiguity between them.

Naming Consistency5/5

All tool names follow a consistent verb_noun snake_case pattern (get_log_files, log_activity, search_logs), making them predictable and easy to understand.

Tool Count5/5

Three tools is an appropriate scope for an activity logger, covering the essential operations: listing available files, recording entries, and searching. Not too few or too many.

Completeness4/5

The tool surface covers the core activities of logging and retrieval, but lacks update/delete functionality or a way to view raw log file contents. Minor gap, but functional for basic use.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

Foam Observability
io.github.foam-ai
Query application logs, traces, and metrics from your AI coding assistant via Foam's MCP server.
Observability Monitoring Developer Tools
2
LLMemoryOAuth
io.github.meir-may
Search your AI chat history (ChatGPT, Claude, Codex) from any MCP client. Remote, private, read-only
Search Knowledge & Memory
2
gread A
io.github.NitroRCr
An MCP server that gives your AI access to the source code and docs of all public github repos
Version Control Code Analysis Documentation Access
5361
mcp-aichatOAuth
io.github.AceDataCloud
MCP server for AI dialogue using various LLM models via AceDataCloud
AI & Machine Learning
2

Related MCP Servers

Vibe Coder MCP
Developer Tools Code Execution Autonomous Agents
freshtechbro
A
license
B
quality
C
maintenance
An MCP server that supercharges AI assistants with powerful tools for software development, enabling research, planning, code generation, and project scaffolding through natural language interaction.
Updated a year ago (2025-08-21 03:06 UTC)
11
32
103
MIT
repro-mcp
Research & Data Developer Tools
ABindoff
A
license
Not graded
quality
D
maintenance
An MCP server that logs AI-assisted scientific computing sessions, capturing prompts, responses, decisions, and environment snapshots to human-readable markdown files for reproducibility.
Updated 4 months ago (2026-05-21 04:39 UTC)
MIT
journey-log
Note Taking Developer Tools Documentation Access
ALPHAbilal
A
license
Not graded
quality
D
maintenance
This MCP server integrates with Journey Log to automatically document development journeys, enabling AI assistants to create, update, and retrieve documents, capture conversations, and manage code snippets.
Updated a year ago (2025-07-30 23:07 UTC)
6
MIT
logbook-mcp
Note Taking Monitoring
aether-technologies
A
license
Not graded
quality
D
maintenance
A local MCP server for AI agents to log activities, query logs, and leave notes for each other, featuring a web UI and REST API.
Updated 5 months ago (2026-03-27 17:02 UTC)
MIT

Roo Activity Logger

TL;DR

Overview

How activity logging works

How to search logs and restore context when resuming a task

Sample Log Entry

Features

Usage (Recommended: via npx)

For Developers: Local Setup

Notes

MCP Tools

log_activity — Record an activity

Basic example

Parameters

Detailed example

get_log_files — List saved log files

Basic example

Parameters

search_logs — Search saved logs

Basic example

Parameters

License

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

Usage (Recommended: via `npx`)

`log_activity` — Record an activity

`get_log_files` — List saved log files

`search_logs` — Search saved logs