Kintone
Manage users, departments, groups, memberships, service assignments, and login codes in a Kintone tenant through the User API.
Verdict
Common use cases
- Onboard new hires in batch with login credentials
- Audit group membership before quarterly access reviews
- Restructure departments after a company merger
- Provision service accounts for automation workflows
- Delete offboarded contractors from all groups at once
Integration
- Vendor
- Kintone
- Category
- developer-tools
- Auth
- API_KEY
- Tools
- 16
- Composio slug
kintone
Tools
- Change User Login Codes
Irreversibly change the login codes of up to 100 Kintone users in one batch. Warning: this changes user identities and cannot be undone automatically.
- Create Departments
Create 1 to 100 Kintone departments in one batch. Submit parent departments before their children when creating a hierarchy.
- Create Groups
Create 1 to 100 static or dynamic Kintone groups in one batch. Each group requires a unique code, name, and membership type.
- Create Users
Create 1 to 100 Kintone tenant users in one batch with a login code, password, and display name for each user.
- Delete Users, Departments, or Groupsdestructive
Permanently delete a non-empty batch of Kintone users, departments, or groups by exact code. Deleted resources cannot be recovered by this tool. Deleting a department may also delete all of its child departments and requires explicit cascad
- Get User Access
Get one user's department memberships, group memberships, and Kintone service assignment in one read.
- List Department or Group Members
List users belonging to a Kintone department or group, one page at a time.
- List Departments or Groups
List or filter Kintone departments or groups, one page at a time.
- List Users
List or filter tenant users by ID or login code, one page at a time.
- Replace Group Users
Replace a Kintone static group's complete user membership list. The submitted list is a complete replacement: omitted existing users are removed, and an empty list removes all.
- Replace User Departments
Replace the complete department membership lists for one to 100 Kintone users. Each submitted list is a complete replacement: omitted existing department memberships are removed, and an empty list removes all.
- Replace User Groups
Replace a Kintone user's complete static-group membership list. The submitted list is a complete replacement: omitted existing group memberships are removed, and an empty list removes all.
- Set User Service Assignments
Replace Kintone service access for one to 100 users. An empty services array disables access, so omitted existing assignments are removed.
- Update Departments
Update mutable fields for 1 to 100 existing Kintone departments, identified by exact department code.
- Update Groups
Update the name and optional description of 1 to 100 existing Kintone groups, identified by exact group code. Group type cannot be changed.
- Update Users
Update editable profile and primary-organization fields for 1 to 100 existing Kintone tenant users identified by login code.
Setup
Setup guide
- 11. In Switchy, open your workspace settings and navigate to the Integrations page. 2. Find Kintone in the MCP directory and click Connect. 3. You'll be prompted to enter your Kintone subdomain (the part before .kintone.com) and an API token with User Administration permissions—generate this token in your Kintone admin console under API Tokens. 4. Paste the subdomain and token into Switchy, then click Authorize. 5. Switchy will verify the credentials and confirm the connection. 6. Open any Project, type '@Kintone list departments' in the chat, and send—if you see a paginated list of departments, the integration is live. 7. You can now invoke any of the 16 tools by @mentioning Kintone and describing the task in plain English.
What teammates see: by default, memories from Kintone are scoped to the Project (PROJECT visibility) - you can mark any memory PRIVATE or share it ORG-wide.
Works well with
Top models
Compatibility data appears once enough Projects have used this MCP together with a given model.
How Switchy teams use it
Starter prompts
Onboard New Cohort
@Kintone create 5 users with login codes employee001 through employee005, display names matching their email prefixes, and the temporary password Welcome2024.
Map Org Structure
@Kintone list all departments and show which ones have parent departments so I can draw the org chart.
Audit Group Access
@Kintone list all members of the Engineering group and tell me if any are contractors or external users.
Offboard Departures
@Kintone delete users with login codes contractor042 and contractor043, then confirm they're removed from all groups.
Create Project Teams
@Kintone create a group called ProjectAlpha with code proj-alpha, add users alice, bob, and carol, and make it a static group.
Example outputs
Illustrative - representative of the model's voice and quality, not literal recordings.
@kintone list all departments in the Engineering org and show me how many users are in each one
Found 4 departments under Engineering: • Engineering-Frontend (code: eng-fe) — 12 users • Engineering-Backend (code: eng-be) — 18 users • Engineering-QA (code: eng-qa) — 7 users • Engineering-DevOps (code: eng-devops) — 5 users Total: 42 users across Engineering departments. Each department code can be used to retrieve full member lists or create child departments in the hierarchy.
This example demonstrates read-only department discovery. The MCP paginates large result sets automatically. Your API key must have user-management read permissions. No data is modified; safe to run in production tenants.
@kintone create a new group called 'Q1-Launch-Team' with members from both Frontend and Backend departments, then confirm the group was created
Created group 'Q1-Launch-Team' (code: q1-launch-team) as a static group. Added 8 members: • 4 users from Engineering-Frontend • 4 users from Engineering-Backend Group is now active and visible in the Kintone admin console. Members can be modified later using the group code. Note: static groups require manual membership updates; consider a dynamic group if membership should auto-sync with department changes.
This example shows group creation with cross-department membership. The MCP writes directly to your Kintone tenant — the group is immediately live. Requires user-management write permissions. Static groups need manual updates when team composition changes.
@kintone get the full access profile for user 'sarah.chen' and summarize which services she can use and which groups she belongs to
Access profile for sarah.chen (Sarah Chen): **Services:** Kintone platform access enabled. Can create and manage apps within assigned spaces. **Departments:** Engineering-Frontend (primary), Product-Design (secondary) **Groups:** Q1-Launch-Team, Frontend-Leads, All-Engineering Sarah has standard developer access with cross-functional group memberships spanning engineering and product. Her dual-department assignment suggests a bridge role between frontend implementation and design collaboration.
This example pairs the MCP's user-access read with AI synthesis to explain organizational context. Useful for auditing permissions or onboarding. The MCP returns raw membership data; the AI interprets it. Requires read access to user records.
Use-case deep-dives
When Kintone MCP beats manual user provisioning for contract teams
A 12-person agency onboards 8-15 contractors every quarter for client projects, each needing Kintone access scoped to specific groups and departments. The Kintone MCP's batch user creation tool handles up to 100 users at once, so the ops lead runs a single prompt in Switchy to provision the entire cohort with login codes, passwords, and group assignments in under two minutes. The trade-off: if your onboarding workflow requires approval gates or conditional logic (like different access tiers based on NDA status), you'll still need a scripted pipeline—this MCP is a read-write API wrapper, not a workflow engine. If you onboard fewer than 5 people per month, the manual Kintone UI is faster than writing the prompt. Use this when your batch size justifies the setup and your access rules are stable enough to template.
Why Kintone MCP is the wrong tool for offboarding workflows
A 6-person HR team at a SaaS company needs to offboard departing employees and document every access removal for SOC 2 audit trails. The Kintone MCP's delete tool is irreversible and returns no confirmation artifact—once you delete a user, department, or group by code, it's gone with no recovery path and no audit log export. Switchy can run the deletion, but you're responsible for capturing the before-state separately (via the list or get-access tools) and storing it outside Kintone. If your compliance framework requires tamper-proof logs or rollback capability, use Kintone's native admin UI or a dedicated identity provider integration instead. This MCP wins for bulk cleanup of test accounts or deprecated groups where audit requirements are light, not for regulated offboarding.
When dynamic group management justifies the Kintone MCP
A 20-person consulting firm rotates 4-6 team members across client Kintone workspaces every week as project assignments shift. The Kintone MCP's group creation and membership tools let the project coordinator update dynamic groups in Switchy by pasting a roster from Notion—no need to click through Kintone's admin UI for each change. The 16-tool scope includes department hierarchy management, so you can mirror your org chart in Kintone and keep group memberships in sync with reporting lines. The boundary: if your rotation logic depends on external data (like Harvest timesheets or Salesforce opportunity owners), you'll need a separate automation to feed the MCP—it doesn't pull context from other systems. Use this when your access changes are frequent enough that manual updates cost more than 10 minutes per week.
Frequently asked
What does the Kintone MCP let me do in Switchy?
It provisions and manages Kintone tenant users, departments, and groups at scale. You can create up to 100 users in one batch, assign them to departments or groups, and change login codes or delete resources when people leave. Think of it as programmatic user lifecycle management for your Kintone workspace, not a way to read or write app records.
Do I need admin access to connect Kintone?
Yes. The MCP uses an API key that requires Kintone administrator privileges to generate. Without admin rights you won't be able to create the key or perform any of the user, department, or group operations the integration exposes. Ask your Kintone workspace owner to provision the key if you don't have admin access yourself.
Can the Kintone MCP read or update app records?
No. This integration only manages users, departments, and groups—the identity and org-chart layer of Kintone. If you need to query or write records in Kintone apps, use Kintone's REST API directly or build a custom MCP that wraps those endpoints. This one won't help with data workflows.
Why use this instead of Kintone's admin console?
The console works fine for one-off changes, but the MCP shines when you're onboarding dozens of users, syncing org structure from HR systems, or scripting repetitive admin tasks. Batch operations let you create 100 users in one call instead of clicking through forms. If you only touch Kintone admin once a quarter, stick with the console.
Who on the team should connect this integration?
Whoever holds the Kintone admin role and owns user provisioning. That's usually IT or ops, not individual contributors. Because tools like Change User Login Codes are irreversible and Delete Users is permanent, you want tight access control. Don't hand the connection to someone who just needs to read app data.