nc-mcp-server

get_activity

Read-onlyIdempotent

Retrieve recent activity for the current Nextcloud user, covering file changes, shares, and calendar events. Filter by type, object, or time to monitor what happened.

Instructions

Get the recent activity feed for the current Nextcloud user.

Activities track what happened across Nextcloud: file changes, shares, calendar events, comments, and more.

Filters include "all", "self" (your actions), "by" (others' actions), "files", "files_sharing", "files_favorites", "calendar", "comments" and more, depending on the installed apps; list_activity_filters lists them.

To get activities for a specific file or object, provide both object_type and object_id (e.g., object_type="files", object_id=742), and leave activity_filter at "all". This also clears the returned activities' notifications, as the web interface does when it shows a file's activity.

Args: activity_filter: Activity filter id (default: "all"). limit: Maximum number of activities to return (1-200, default: 30). since: Activity ID to paginate from. Use the "since" value from the previous call's pagination to fetch the next page. Default 0 = newest. object_type: Filter by object type (e.g., "files"). Must be used together with object_id. object_id: Filter by object ID. Must be used together with object_type. sort: Sort order: "desc" (newest first, default) or "asc" (oldest first). search: Only activities whose file path contains this text (2-255 characters after trimming, case-insensitive), which leaves out activities without a file. start: Only activities at or after this time: an ISO 8601 date (from its start, UTC) or a time with a time zone. end: Only activities at or before this time: an ISO 8601 date (to its end, UTC) or a time with a time zone. actor: Only activities done by this user ID. search, start, end and actor need Nextcloud 35 (Activity 8); on older servers they are refused rather than ignored.

Returns: JSON object with "data" (list of activities) and "pagination" (count, has_more, since). Use since value for the next page.

Input Schema

TableJSON Schema

Name	Required	Default
`end`	No
`sort`	No	desc
`actor`	No
`limit`	No
`since`	No
`start`	No
`search`	No
`object_id`	No
`object_type`	No
`activity_filter`	No	all

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedv0.9.0Oct 1, 2026

addedInput schema / properties / actor

Added value: +{
+  "default": "",
+  "title": "Actor",
+  "type": "string"
+}

addedInput schema / properties / end

Added value: +{
+  "default": "",
+  "title": "End",
+  "type": "string"
+}

addedInput schema / properties / search

Added value: +{
+  "default": "",
+  "title": "Search",
+  "type": "string"
+}

addedInput schema / properties / start

Added value: +{
+  "default": "",
+  "title": "Start",
+  "type": "string"
+}

First observedv0.7.0Sep 21, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Reveals a non-obvious side effect (returning file activities clears their notifications, as the web UI does) and version-gating behavior ('search, start, end and actor need Nextcloud 35; on older servers they are refused rather than ignored'), which goes well beyond the readOnly/idempotent annotations.

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?

Front-loaded summary followed by filters, object targeting, args, and returns; every section adds information. The Args block is long but each entry is needed given 10 undocumented parameters.

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?

For a 10-parameter list tool with no schema descriptions, the definition covers filtering, pagination, sorting, version constraints, side effects, and return shape, leaving no ambiguity for correct invocation.

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?

With 0% schema description coverage, the description carries the full burden and does: it documents ranges (limit 1-200), the pagination 'since' round-trip, sort values, ISO 8601 semantics for start/end, case-insensitive path search length, and the interdependency of object_type/object_id.

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?

States a specific verb and resource ('Get the recent activity feed for the current Nextcloud user') and immediately scopes what activities are, distinguishing it from list_activity_filters and get_activity_counts which appear as siblings.

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 explains when to use the object_type/object_id pair, the required companion argument, and that activity_filter should be 'all' in that case, plus points to list_activity_filters for enumerating filter ids. It does not explicitly contrast with get_activity_counts, but the contextual routing is otherwise strong.

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

Deploy Server