Problem

ecs_troubleshooting_tool documents and exposes start_time/end_time parameters on three actions — fetch_task_failures, fetch_service_events, and fetch_task_logs. Because MCP serializes all tool arguments as JSON, these values always arrive as ISO-8601 strings, never datetime objects. The documented parameters are therefore completely unusable: any call that supplies them crashes with AttributeError: 'str' object has no attribute 'tzinfo'.

Root cause

awslabs/ecs_mcp_server/utils/time_utils.py::calculate_time_window assumed its start_time/end_time arguments were datetime objects and accessed .tzinfo directly:

actual_end_time = end_time if end_time.tzinfo else end_time.replace(tzinfo=datetime.timezone.utc)

When a string is passed, the first attribute access raises. The per-action transformers in api/ecs_troubleshooting.py forward params.get("start_time") / params.get("end_time") straight through, so the string reaches calculate_time_window unconverted.

Fix

Add a small _ensure_datetime(value) helper in time_utils.py and call it on both start_time and end_time at the very top of calculate_time_window, before the existing tz-awareness logic. The helper:

• returns None for None,
• passes datetime objects through unchanged,
• parses strings via datetime.fromisoformat, first normalizing a trailing "Z" to "+00:00" (Python 3.10 — the project's minimum — doesn't accept the Z suffix), and re-raises a clear ValueError on malformed input.

This is a single boundary fix that covers all three calling sites without modifying the transformers. Naive strings (no timezone) are coerced to UTC, matching the function's existing behavior for naive datetime objects.

Testing

Added 7 unit tests in tests/unit/utils/test_time_utils.py: Z-suffix strings, explicit +00:00 offset, naive-string→UTC coercion, start-only-as-string, end-only-as-string, malformed-string→ValueError, and a regression test confirming datetime objects still work. time_utils tests: 6 → 13, all passing. Lint/format/type checks (ruff, ruff-format, mypy, pyright) pass.

Backward compatibility

Fully backward compatible. Existing datetime callers are unaffected — _ensure_datetime passes datetime objects through untouched, covered by a dedicated regression test.

Fixes #2858

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of the project license.