The shape is deliberately narrow — create_iteration walks the fields step by step, get_user_list supplies the participants and reviewers, and submit_complete_iteration files the result as one payload covering both the basic details and the code-review request — which makes it useful if your team already files iterations this way and irrelevant if it does not. Worth noticing before you plan around it: nothing in the surface reads an iteration back or amends one after filing, so this is a write path only.
A DingTalk-backed iteration filing client with 5 tools: a QR-code sign-in and a check on that session, a step-by-step collector for the iteration's details, a roster call for participants and reviewers, and a single submit that files the record with its code-review request attached.
- Sign-in handled inside the session rather than in a browser tab you forget about: login_dingtalk starts a QR-code sign-in and check_login_status reports whether the current session is authenticated before anything is filed.
- Details gathered a step at a time instead of as one large object: create_iteration takes the step being answered, the data collected so far and a workdir, so the assistant can ask only for what is still missing.
- Participants chosen from the real roster: get_user_list returns the users available to assign as iteration participants and as reviewers, rather than leaving names to be typed.
- A single filing step at the end: submit_complete_iteration takes the assembled record as a single iteration_data payload covering both the iteration's basic details and its code-review request.
A DingTalk account you can sign into by scanning a QR code, and membership of whatever workspace holds the roster get_user_list reads. No key is taken from the environment; check_login_status is how you find out whether the session is still live.
One command — npx -y @asthestarslept/iteration-mcp