Skip to content

Allow project-scoped retrieval of completed items (project_uuid on get_logbook, project/stop_date on search_advanced) #58

Description

@willhains

Summary

There's no way to retrieve completed items for a specific project. get_todos accepts project_uuid but is incomplete-only; get_logbook and search_advanced can return completed items but accept no project filter. The only workaround is to pull the whole Logbook (or all completed-in-window items) and filter client-side, which is slow, unwieldy, and — for an LLM client — burns a large amount of context.

Why it matters

Per-project completed history is a common need for review and reporting workflows — for example, listing everything finished for a long-running project (say, a "Kitchen Reno" or a recurring "Weekly Ops" project) over the last few months, since the closed items live in the Logbook. Today the client must retrieve the entire Logbook — which can hold thousands of unrelated completed items — and discard nearly all of it to find the handful that belong to the project.

Root cause

get_logbook already fetches the entire completed set and filters by completion date in Python:

all_completed = things.tasks(status='completed', include_items=True) or []
# ...filter by stop_date in Python

The expensive full scan already happens; it just isn't narrowed by project before returning. The underlying library (things-py >= 0.0.15) already supports SQL-level project and stop_date filters in database.get_tasks, so the data can be narrowed at the source.

Proposed change (minimal)

  1. get_logbook — add an optional project_uuid, and pass it through:

    async def get_logbook(period="7d", limit=50, offset=0, project_uuid=None):
        ...
        all_completed = things.tasks(
            status='completed', include_items=True, project=project_uuid
        ) or []

    project=None preserves current behaviour; a UUID narrows the scan to one project (and items under its headings) at the SQL layer, then the existing stop_date filter applies to that small set.

  2. search_advanced — add project (it already splats search_params into things.tasks/things.todos, so this is just adding the param and one dict entry). Optionally also add stop_date, which things-py already validates and SQL-filters, to enable completion-date-bounded queries (the same creation-vs-completion distinction get_logbook filters by creation date instead of completion date, causing most completed tasks to be invisible #46 fixed for get_logbook, generalised).

Backward compatibility

All new parameters default to None/absent, so existing calls are unchanged.

Environment

  • things-mcp v0.8.1
  • things-py >= 0.0.15, macOS Things 3

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions