Kintone REST
Manage Kintone records and app settings with delegated OAuth access through the Kintone REST API.
Verdict
Common use cases
- Draft customer records from email threads
- Bulk-update project statuses before standup
- Add timestamped comments to support tickets
- Query inventory levels across warehouse apps
- Generate weekly reports from Kintone data
Integration
- Vendor
- Kintone REST
- Category
- other
- Auth
- OAUTH2
- Tools
- 50
- Composio slug
kintone_rest
Tools
- Add Comment
Add one comment to a Kintone record, optionally mentioning up to 10 users, groups, or organizations. The app's commenting feature must be enabled.
- Add Form Fields
Add typed fields to an app's pre-live form, including selections, lookups, related-record lists, groups, and nested tables. Deploy app settings separately to make them live.
- Add Preview App
Create a pre-live Kintone app and return its app ID and initial settings revision. Kintone provides no REST API to delete the created preview app, so this creation cannot be undone through the API. Deploy it separately when its settings are
- Create Record
Create one record in a Kintone app from field-code values and return its record ID and revision.
- Create Records
Create one to 100 records atomically in one Kintone app and return their record IDs and revisions in input order.
- Delete Commentdestructive
Permanently delete one comment from a Kintone record. With OAuth user authentication, only a comment created by that user can be deleted.
- Delete Form Fieldsdestructive
Delete up to 100 fields from an app's pre-live form. Deleting a group or table also deletes every field it contains. The deletion affects preview settings until deployed and returns the resulting revision.
- Delete Recordsdestructive
Permanently delete one to 100 explicitly identified records from a Kintone app. If revisions are supplied, Kintone deletes no records when any revision does not match.
- Deploy App Settings
Atomically apply the complete pre-live settings of up to 300 Kintone apps to their live apps. If one deployment fails, Kintone rolls every app in the request back to its pre-request state.
- Discard App Settings Changes
Permanently discard every pre-live settings change for up to 300 Kintone apps and restore each preview to its current live settings. This does not change the live apps. If one discard fails, Kintone rolls back the entire request.
- Download File
Download an attachment up to 100 MB using the file key returned by a record read. Files larger than 100 MB are rejected.
- Get Action Settings
Return deployed or unpublished record-copy action settings of an app, including destinations, mappings, availability, order, and revision.
- Get App
Gets general information of an App, including the name, description, related Space, creator and updater information. Use guest_space_id only when the target app belongs to a Kintone guest space.
- Get App Deploy Status
Get the deployment status of settings for up to 300 Kintone apps.
- Get App Permissions
Return deployed or unpublished app-level permissions and settings revision in priority order.
- Get App Settings
Return an app's deployed or unpublished name, description, title-field configuration, feature flags, theme, icon, and revision.
- Get Customization
Return deployed or unpublished desktop and mobile JavaScript and CSS customization files, scope, and revision for an app.
- Get Field Permissions
Return deployed or unpublished field permissions, including prioritized subjects and each field's access level.
- Get Form
Read a deployed or unpublished app form in Kintone's legacy property-array format. This reader omits Categories, Status, and Field Groups; inside Field Groups, it also omits system-generated fields, blank spaces, labels, and borders. Use GE
- Get Form Fields
Return deployed or unpublished field codes, types, labels, and settings so an agent can construct valid record values and queries.
- Get Form Layout
Return deployed or unpublished field layout information for an app form, including rows, groups, tables, fields, and sizes.
- Get General Notification Settings
Get an app's deployed or unpublished general-notification recipients, event conditions, commenter option, and revision.
- Get Graph Settings
Return deployed or unpublished graph definitions with their chart, aggregation, grouping, sorting, periodic-report settings, and revision.
- Get Per Record Notification Settings
Get an app's deployed or unpublished conditional per-record notifications, recipients, subjects, and revision.
- Get Process Management Settings
Return deployed or unpublished process-management enablement, statuses, assignee rules, transitions, branch conditions, and revision.
- Get Record
Retrieve one record from a Kintone app by its record ID.
- Get Record Permissions
Return deployed or unpublished record permission rules, preserving each query filter and prioritized subject list.
- Get Reminder Notification Settings
Get an app's deployed or unpublished reminder timing, filters, recipients, timezone, and revision.
- Get Views
Return deployed or unpublished list, calendar, custom, and built-in view settings, including filters, sorting, displayed fields, and revision.
- List Apps
Find apps visible to the connected Kintone user by name, ID, code, or space and return one offset-controlled page of app metadata.
- List Comments
Retrieve one offset-controlled page of up to 10 comments from a Kintone record. The app's commenting feature must be enabled.
- Search Records
Search an app's records with a Kintone query and return one offset-controlled page. OAuth searches cannot continue beyond offset 10,000.
- Update Action Settings
Replace the complete unpublished record-copy action map. Existing preview actions omitted from actions are deleted, so read preview action settings first and include every action to retain. Deploy app settings separately to make the replace
- Update App Permissions
Replace app-level permissions in priority order and deploy all pending app settings, not only permissions. This can immediately revoke app or record access for omitted or restricted entities; read the current and preview settings first when
- Update Assignees
Replace the assignees of one Kintone record whose app uses Process Management. An empty assignee list removes all assignees; the caller needs app-management and record-view permissions.
- Update Customization
Update unpublished desktop and mobile JavaScript and CSS customization. Deploy app settings separately to make changes live.
- Update Field Permissions
Replace field permissions and deploy all pending app settings, not only permissions. This can immediately revoke field access for omitted fields or entities and settings are applied to affected fields sequentially; read the current and prev
- Update Form Fields
Update typed field settings in an app's pre-live form. Supplying options replaces that field's complete option set and deletes omitted options. Deploy app settings separately to make changes live.
- Update Form Layout
Replace an app's complete pre-live form layout. Kintone requires every form field to be included in the request. Deploy app settings separately to make the layout live.
- Update General Notification Settings
Replace or selectively update an app's undeployed general-notification settings; deploy the app settings afterward to make them live.
- Update General Settings
Update unpublished general app settings such as name, description, icon, theme, feature flags, title field, and number precision. Deploy separately.
- Update Graph Settings
Replace the complete unpublished graph map. Existing preview graphs omitted from reports are deleted, so read preview graph settings first and include every graph to retain. Deploy app settings separately to make the replacement live.
- Update Per Record Notification Settings
Replace an app's undeployed per-record notification rules; deploy the app settings afterward to make them live.
- Update Preview App Permissions
Replace the complete unpublished app-level permission list in priority order without deploying it. Omitted or restricted entities may lose access when the preview settings are later deployed; read preview permissions first when preserving a
- Update Preview Field Permissions
Replace the complete unpublished field permission list without deploying it. Omitted fields or entities may lose access when the preview settings are later deployed; read preview field permissions first when preserving access.
- Update Preview Record Permissions
Replace the complete unpublished record permission rule list without deploying it. Omitted or restricted rules may revoke record access when the preview settings are later deployed; read preview record permissions first when preserving acce
- Update Process Management Settings
Update unpublished process-management settings. When states is supplied it is the complete desired preview status map: omitted statuses are deleted, so read preview process settings first and include every status to retain. Deploy app setti
- Update Record
Update selected fields of one Kintone record by record ID, optionally requiring an expected revision.
- Update Record Permissions
Replace record permission rules and deploy all pending app settings, not only permissions. This can immediately revoke record access for omitted or restricted rules and settings are applied to affected records sequentially; read the current
- Update Records
Update selected fields of one to 100 Kintone records atomically by record ID, optionally checking each revision. This tool does not select by unique key and never upserts.
Setup
Setup guide
- 11. In Switchy, open Settings → Integrations and click 'Connect' next to Kintone REST. 2. You'll be redirected to Kintone's OAuth consent screen; sign in with an account that has app-management permissions in your subdomain. 3. Grant the requested scopes: read records, write records, manage app settings, and add comments. 4. Switchy stores the access token and redirects you back; you'll see 'Connected' with your Kintone subdomain name. 5. Open any Project and type '@Kintone REST list my apps' to confirm the connection works. 6. To invoke a tool, @mention the integration in a message — for example, '@Kintone REST create a record in app 42 with Customer field set to Acme Corp and Status field set to New'. 7. The AI will map your natural-language request to the appropriate tool parameters and return the new record ID or confirmation.
What teammates see: by default, memories from Kintone REST 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
Create Customer Record
@Kintone REST create a record in app 15 with Company Name 'Acme Industries', Contact Email 'jane@acme.com', and Status 'Lead'. Use today's date for Created field.
Bulk Status Update
@Kintone REST update records 101, 102, 103 in app 8 to set Status field to 'In Review' and Reviewer field to 'Sarah Chen'.
Add Timestamped Comment
@Kintone REST add a comment to record 450 in app 22 saying 'Customer confirmed the bug is resolved' and mention user 'mike@company.com'.
Query Inventory Levels
@Kintone REST get records from app 30 where Location is 'Warehouse B' and Quantity is less than 50. Return Product Name and Quantity fields.
Weekly Report Summary
@Kintone REST get all records from app 12 created in the last 7 days. Summarize by Status field and count how many are 'Completed' versus 'In Progress'.
Example outputs
Illustrative - representative of the model's voice and quality, not literal recordings.
@kintone list all records in the Customer Feedback app where status is 'pending review' and priority is high, then summarize the top 3 themes
Retrieved 47 records matching your filters. The top three themes emerging from high-priority pending feedback are: (1) Mobile app login failures (18 mentions, mostly iOS users reporting timeout errors after the March update), (2) Invoice export formatting issues (12 mentions, primarily CSV column misalignment when exporting to accounting software), and (3) Notification delay complaints (9 mentions, users not receiving email alerts for status changes within the expected 5-minute window). The remaining 8 records cover isolated UI suggestions and feature requests.
This example shows the MCP's ability to query Kintone records with field-level filters and feed structured data to the AI for synthesis. Requires read permissions on the target app. Kintone's REST API returns up to 500 records per request by default; larger result sets require pagination, which the MCP handles but may increase response time.
@kintone create a new record in the Project Tracker app with title 'Q2 Marketing Site Redesign', owner set to sarah@company.com, status 'planning', and due date June 30
Created record ID 1847 in the Project Tracker app (revision 1). The record now appears with title 'Q2 Marketing Site Redesign', assigned to sarah@company.com, status set to 'planning', and due date 2025-06-30. The app's default field values were applied to any fields not explicitly set in this request, including the auto-calculated 'Days Until Due' field (now showing 89 days) and the empty 'Attachments' table.
This write operation demonstrates single-record creation with typed field values. The MCP maps your natural-language field names to Kintone's internal field codes, but you must have edit permissions on the app and the field codes must exist in the live app form. Side-effect: the record is immediately visible to all users with app access, and any configured process automation (notifications, status transitions) will trigger.
@kintone add a comment to record 1523 in the Bug Reports app saying 'Engineering confirmed this is a duplicate of issue #1401, closing as resolved' and mention the QA team
Added comment ID 89 to record 1523 in the Bug Reports app. The comment reads: 'Engineering confirmed this is a duplicate of issue #1401, closing as resolved' and mentions the QA team group. All members of the QA team will receive an in-app notification and email alert (depending on their notification preferences). The comment is now visible to anyone with read access to this record and appears in the record's activity timeline with your OAuth user identity as the author.
This action example shows the MCP's commenting capability with @mentions. The app's commenting feature must be enabled, and you need comment-add permissions. Important: with OAuth authentication, only comments created by your authenticated user can be later deleted via the API. Mentioning groups or organizations sends notifications to all members, which can be noisy for large teams.
Use-case deep-dives
When Kintone REST fits repeatable client intake at scale
A 6-person consulting firm runs client onboarding in Kintone—intake forms, contract milestones, first-touch notes. The team uses Switchy to auto-create records when a new client signs, pull contract status during kickoff calls, and post follow-up comments without opening the Kintone UI. The MCP's Create Record and Add Comment tools handle the happy path cleanly. The trade-off: OAuth2 setup takes 20 minutes the first time, and if your onboarding app has custom field validations or workflow triggers, you'll need to test record creation in preview mode first. This works when your Kintone app is the system of record and your team wants to interact with it from Switchy's shared context instead of switching tabs.
Kintone REST for mobile teams logging work in bulk
A 12-person field ops team logs service tickets in Kintone after site visits—photos, timestamps, equipment IDs. The crew lead uses Switchy at end-of-day to batch-create 20-40 records from a shared note thread, then adds manager mentions via Add Comment so dispatch sees the high-priority calls. The Create Records tool handles up to 100 records atomically, so the batch either succeeds or rolls back. The boundary: if your ticket app has lookup fields or related-record dependencies, you'll need to create parent records first in a separate call. This MCP wins when your logging volume justifies automation and your Kintone schema is flat enough to map from conversational input.
When Add Form Fields saves hours on Kintone app cloning
A 3-person product team maintains staging and production Kintone apps for feature requests. When they add a new field type—say, a lookup to a vendor table—they use Switchy with the Add Form Fields tool to replicate the schema change in preview mode, then deploy it once tested. The MCP exposes 50 tools, but this scenario leans on the form-field mutations and the preview-app workflow. The catch: Kintone has no API to delete preview apps, so failed experiments leave orphaned app IDs in your environment. Use this when your team changes Kintone schemas weekly and wants to script the replication instead of clicking through the UI twice.
Frequently asked
What does the Kintone REST MCP let me do in Switchy?
It connects your Kintone apps to Switchy's AI workspace so you can create, update, and delete records, manage form fields, add comments, and query data across your Kintone environment. The MCP exposes 50 tools covering record operations, app configuration, and comment threads. Your team can ask the AI to pull Kintone data or push changes without opening the Kintone web UI.
Do I need admin access to connect Kintone REST via OAuth?
You need permission to create OAuth clients in your Kintone environment and grant the scopes your use case requires. Kintone's OAuth flow lets you scope access per app or globally. Some operations—like adding form fields or deploying app settings—require app-admin or environment-admin rights. If you only read records, a standard user account with view permissions works fine.
Can the MCP delete a Kintone app I created by mistake?
No. Kintone's REST API provides no endpoint to delete apps, so the MCP can't either. If you use Add Preview App and regret it, you must delete the app manually in the Kintone web UI. The MCP can delete records, comments, and form fields from preview apps, but the app container itself stays until you remove it through Kintone's interface.
How does this compare to writing Kintone API calls myself?
The MCP handles OAuth token refresh, request formatting, and error parsing so you don't write boilerplate. In Switchy, your team describes what they want in plain language; the AI picks the right tool and parameters. If you already have a Node script calling Kintone's REST API, you'll get the same data—this just removes the scripting step for ad-hoc queries and bulk updates.
Who on my team should connect the Kintone MCP?
Whoever owns the OAuth client credentials and has the broadest Kintone permissions your workflows need. If your team only reads sales records, a sales-ops user works. If you're automating app configuration or cross-app record moves, connect it under an admin account. Every Switchy user in the workspace inherits the same Kintone access the connected account has.