It comes from DingTalk itself and is split into capability groups, so an assistant that only needs contacts and calendar loads those two rather than the whole workplace API.
The MCP server published by DingTalk, run with npx dingtalk-mcp. Capability groups are switched on individually through ACTIVE_PROFILES, and each group maps to the DingTalk API permissions your app has to hold.
- Contacts searched and members read, and the department list with its members
- Messages and DING alerts sent through a robot
- Calendar events read and written, and to-dos read and written
- Check-in records read, and work notices sent
- Company culture honors, work reports, and the service window
- Teambition project and task read and write
- Each group loaded separately through ACTIVE_PROFILES, or all of them with ALL
A DingTalk developer account and an app, which give you DINGTALK_Client_ID and DINGTALK_Client_Secret. ACTIVE_PROFILES selects which groups load — contacts and robot messaging are on by default. Robot messaging also needs the robot's own code or access token, work notices need the app's agent id, and each group requires its own DingTalk API permissions on the app.
One command plus a key — npx -y dingtalk-mcp@latest, then supply credentials