The notification tools are the reason to wire it up: one call reaches the whole organization, a workspace filtered by permission level, or a single group — which is enough to route an alert from an automation to exactly the people who should see it. Everything else is directory lookup: workspaces, groups, members, and the URL that gets someone into a workspace. Install is from the GitHub repository rather than a registry, and the author is explicit that this is an unofficial personal project.
An unofficial server over the oVice Public API v1, covering the directory side of an organization and the notification endpoints. Its author describes it as a personal experiment with no guarantee of operation.
- The organization's workspaces listed, and the users in one of them
- The organization's groups listed, and the members of one group
- A space's name resolved from its ID
- The access URL for a workspace, built from the workspace information the API returns
- A notification sent to the whole organization, with a service name and logo you can override per call
- A notification sent to one workspace, targeted at the permission levels you name — admin, member, visitor or guest
- A notification sent to a single group
oVice API credentials: OVICE_CLIENT_ID, OVICE_CLIENT_SECRET and OVICE_ORGANIZATION_ID are all required, and the client id and secret are sent as headers on every call. OVICE_DOMAIN defaults to api.ovice.com and needs changing for non-production environments. OVICE_SERVICE_NAME and OVICE_SERVICE_LOGO_URL set the branding that appears on notifications. It is run straight from the repository — npx github:cti1650/ovice-mcp-server — rather than from a published npm package. Calls go to https://{OVICE_DOMAIN}/api/public/v1/. Tool descriptions are in Japanese.
One command plus a key — npx github:cti1650/ovice-mcp-server, then supply credentials