feat: add native sprint & backlog support, advanced WP filters, and improved error handling

[MacherelR]

Summary

This branch brings the MCP server up to date with OpenProject 17.3+ by adding
native sprint and backlog integration, and includes two quality-of-life
improvements that were already on this fork: advanced work package filtering
and richer API error messages.

What changed

New: Sprint & Backlog tools (src/tools/sprints.py)

• list_sprints — list sprints for a project or globally, filterable by
  status (in_planning / active / completed)
• get_sprint — fetch a single sprint by ID
• list_sprint_work_packages — list all work packages in a sprint, with
  total story point count in the header
• list_backlog_work_packages — list the product backlog (work packages not
  assigned to any sprint), filterable by type and priority

Updated: Sprint & story point fields on work packages (src/tools/work_packages.py,
src/client.py)

• create_work_package — new sprint_id and story_points params
• update_work_package — new sprint_id, remove_from_sprint, and
  story_points params; setting remove_from_sprint=true returns a WP
  to the product backlog
• list_work_packages — new sprint_ids filter (comma-separated) and
  backlog_only boolean flag

Updated: Advanced work package filters (src/tools/work_packages.py)

• Multi-value filters: priority_ids, type_ids, status_ids, version_ids
• Date filters: due_before, due_after, created_after, updated_after
• Boolean shortcuts: unassigned_only, overdue_only, no_parent_only
• Percentage range: percentage_done_min / percentage_done_max
• Convenience tools: list_overdue_work_packages, list_work_packages_due_soon,
  list_unassigned_work_packages, list_work_packages_created_recently,
  list_high_priority_work_packages, list_work_packages_nearly_complete

Updated: Improved API error messages (src/client.py)

• Error responses now extract OpenProject's message field and
  _embedded.details.attribute validation errors from the JSON body instead
  of surfacing the raw response string
• Added hint text for HTTP 409 (conflict) and 422 (validation) codes

API surface (OpenProject 17.3+)

Method	Endpoint	Used by
GET	/api/v3/projects/{id}/sprints	list_sprints
GET	/api/v3/sprints	list_sprints (global)
GET	/api/v3/sprints/{id}	get_sprint
WP field	storyPoints	create / update / list
WP link	_links.sprint	create / update / list filter

Breaking changes

None. All new parameters are optional and default to their previous behaviour.
The version_id parameter on create/update is unchanged; sprint_id is
additive.

Test plan

• list_sprints returns sprints for a project with the Backlogs module
  enabled, and respects the status filter
• list_sprint_work_packages returns WPs for a sprint and shows the total
  story point sum in the header
• list_backlog_work_packages returns only WPs without a sprint assigned
• create_work_package with sprint_id creates the WP inside that sprint
• update_work_package with remove_from_sprint=true moves the WP back
  to the backlog
• update_work_package with story_points=5 sets the storyPoints field
• On a 422 validation error, the error message shows the field-level detail
  rather than the raw JSON blob
• All existing tools continue to work unchanged (no regression)

🤖 Generated with the help of Claude Code

[AndreaV-Lsi]

Thanks for this, @MacherelR — your PR (and #20) are what put the OpenProject 17.3+ sprint API on our radar.

For transparency: LS Instruments maintains an actively developed downstream fork of this project (https://github.com/LS-Instruments/openproject-mcp-server) for day-to-day agentic project management on OpenProject, maintained independently for now given the current upstream review cadence.

We've implemented native sprint & backlog tools there, but as a clean, from-scratch implementation rather than a port — no code was taken from this PR, so there's no licensing entanglement; your work is acknowledged as inspiration in our NOTICE. One finding worth sharing from our live testing on 17.5.1: story points do not round-trip through the API v3 (no storyPoints attribute or filter), so we scoped our tools to the read paths that are actually exposed and left story points out.

Our implementation is on our main branch: LS-Instruments@136cbcd.

Happy to compare notes if you're still working in this area. Thanks again.