Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@mcp-kintone-lite Show me the 5 most recent records from app 123"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Simple and lightweight Kintone MCP server for connecting AI assistants to Kintone applications and data. Perfect for automating workflows and integrating Kintone with AI tools.
📦 Install from PyPI: pip install mcp-kintone-lite
🔗 PyPI Package: https://pypi.org/project/mcp-kintone-lite/
📚 GitHub Repository: https://github.com/luvl/mcp-kintone-lite
See the MCP Kintone Lite server in action with Claude Desktop:
The demo shows Claude Desktop using the MCP server to interact with Kintone data - querying apps, retrieving records, and performing CRUD operations seamlessly.
Related MCP server: kintone MCP Server (Python3)
This MCP (Model Context Protocol) server provides AI assistants like Claude with secure access to Kintone applications and data. It implements the MCP standard to enable seamless integration between AI applications and Kintone's business process platform.
🔐 Secure Kintone authentication via Basic Authentication (username/password)
📊 Access to all Kintone apps (based on user permissions)
🔍 Query execution with filtering and pagination
📝 CRUD operations on Kintone records
🛡️ Built-in security and validation
🚀 Easy setup and configuration
# Install the package
pip install mcp-kintone-lite
# Use with Claude Desktop (recommended)
uvx --from mcp-kintone-lite mcp-kintone-lite
# Or run directly
mcp-kintone-liteWorks with: Claude Desktop, any MCP-compatible AI assistant
The easiest way to use this MCP server is to install it directly from PyPI and configure it with Claude Desktop.
Add the following configuration to your Claude Desktop settings file:
Configuration File Location:
macOS/Linux: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
Configuration:
{
"mcpServers": {
"kintone-lite": {
"command": "uvx",
"args": [
"--from",
"mcp-kintone-lite",
"mcp-kintone-lite"
],
"env": {
"KINTONE_SUBDOMAIN": "your-subdomain",
"KINTONE_USERNAME": "your-username",
"KINTONE_PASSWORD": "your-password"
}
}
}
}Replace the environment variables in the configuration:
KINTONE_SUBDOMAIN: Your Kintone subdomain (e.g., mycompany for mycompany.cybozu.com)
KINTONE_USERNAME: Your Kintone username
KINTONE_PASSWORD: Your Kintone password
After saving the configuration, restart Claude Desktop. You should see a hammer icon indicating that tools are available.
Try asking Claude:
"List available Kintone apps"
"Get form fields for app 123"
"Get records from app 456 with status 'Active'"
Python 3.10 or higher
Kintone account with username and password
Kintone subdomain (e.g., yourcompany.cybozu.com)
If you want to modify or contribute to this MCP server, follow these development setup instructions.
# Install uv if you haven't already
brew install uv # macOS
# or
curl -LsSf https://astral.sh/uv/install.sh | sh # Linux/macOS
# Clone and install the server
git clone https://github.com/luvl/mcp-kintone-lite.git
cd mcp-kintone-lite
uv syncgit clone https://github.com/luvl/mcp-kintone-lite.git
cd mcp-kintone-lite
poetry installCreate a .env file in the project root:
KINTONE_SUBDOMAIN=your-subdomain
KINTONE_USERNAME=your-username
KINTONE_PASSWORD=your-passwordFirst, make sure you have your Kintone credentials configured in your .env file.
# Run the server directly
python src/mcp_kintone_lite/server.py# Run with Poetry
poetry run python src/mcp_kintone_lite/server.py# Run with UV
uv run python src/mcp_kintone_lite/server.pyIf you have the MCP CLI installed, you can test your server:
# Test with MCP Inspector
mcp inspector
# Or run in development mode
mcp dev src/mcp_kintone_lite/server.pyTest on TestPyPI first:
# Build the package
uv build
# or: poetry build
# Upload to TestPyPI
twine upload --repository testpypi --config-file .pypirc dist/*
# Test install from TestPyPI
pip install --index-url https://test.pypi.org/simple/ --extra-index-url https://pypi.org/simple/ mcp-kintone-litePublish to Production PyPI:
# Upload to production PyPI
twine upload --repository pypi --config-file .pypirc dist/*
# Test install from production PyPI
pip install mcp-kintone-liteTo publish a new version:
Update the version in pyproject.toml
Rebuild: uv build or poetry build
Upload: twine upload --repository pypi --config-file .pypirc dist/*
Create a new record in a Kintone app with field validation. ⚠️ Use 'kintone_list_apps' first to get available app IDs.
| Name | Required | Description | Default |
|---|---|---|---|
| app_id | Yes | The ID of the Kintone app (use kintone_list_apps to see available app IDs) | |
| record_data | Yes | Record data as key-value pairs where keys are field codes and values are field values. Each field value should be an object with 'value' property. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description only mentions 'field validation' but does not disclose error handling, idempotency, return values, or authentication requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose and a critical warning, no superfluous text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite low complexity, missing behavioral details and no output schema or annotations; leaves agent without information on return values, errors, or permissions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
High schema coverage (100%) results in baseline 3; description reinforces app_id prerequisite but adds no new meaning beyond schema descriptions for parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it creates a new record in a Kintone app with field validation, distinct from sibling tools like update or delete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises using kintone_list_apps first to obtain app IDs, providing clear prerequisite context. Lacks when-not or alternative tool guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a record from a Kintone app by ID with safety confirmation. ⚠️ Use 'kintone_list_apps' first to get available app IDs.
| Name | Required | Description | Default |
|---|---|---|---|
| app_id | Yes | The ID of the Kintone app (use kintone_list_apps to see available app IDs) | |
| record_id | Yes | The ID of the record to delete | |
| revision | No | Record revision number for optimistic locking (optional but recommended) | |
| confirm | Yes | Confirmation flag to prevent accidental deletions (must be true) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It adds safety confirmation but does not disclose side effects, reversibility, or required permissions for deletion. The description is minimal on behavior beyond the basic operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core action, and includes a useful prerequisite hint with no extraneous text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete tool with no output schema and no annotations, the description provides sufficient context: what it does, safety flag, and a prerequisite step. It does not explain return values or error handling, but the tool's simplicity makes this acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% description coverage for all 4 parameters. The description reiterates safety confirmation but adds no new meaning beyond what the schema provides. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete a record') and the resource ('from a Kintone app by ID'). It distinguishes from siblings like create, update, and get by specifying deletion and safety confirmation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises using 'kintone_list_apps' first to get app IDs, providing a helpful prerequisite. It does not explicitly state when not to use it or compare with alternatives, but the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about a single Kintone app. ⚠️ Use 'kintone_list_apps' first to get available app IDs.
| Name | Required | Description | Default |
|---|---|---|---|
| app_id | Yes | The ID of the Kintone app (use kintone_list_apps to see available app IDs) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full burden. It only states 'Get detailed information' without disclosing read-only nature, error handling, or data scope. For a get tool, minimal behavioral context is given.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with a warning emoji, front-loading the purpose. No redundant information, highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with one parameter, the description is adequate but lacks specifics on what 'detailed information' includes. Siblings like get_record suggest potential confusion, so more detail would help completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and already describes the parameter's purpose. The description does not add new semantics beyond what the schema provides, so baseline score applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get detailed information about a single Kintone app', specifying verb and resource. It also includes a hint to use kintone_list_apps first, distinguishing the workflow from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises to use kintone_list_apps first to obtain app IDs, providing clear prerequisite guidance. It does not mention when to avoid the tool, but the inference is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
⭐ ESSENTIAL: Get field definitions, types, display names, and validation rules for a Kintone app. ⚠️ Use 'kintone_list_apps' first to get available app IDs.
| Name | Required | Description | Default |
|---|---|---|---|
| app_id | Yes | The ID of the Kintone app (use kintone_list_apps to see available app IDs) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the tool retrieves definitions but does not mention idempotency, safety, authentication needs, or rate limits. As a read operation, minimal behavioral disclosure is acceptable but could be improved.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first provides purpose, second gives usage hint. Every sentence adds value, no fluff. Well front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with one parameter and no output schema, the description covers essential purpose and a usage prerequisite. Lacks behavioral context that annotations would provide, but is largely sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and already includes the same prerequisite hint. The tool description adds no new parameter-specific details beyond what the schema provides, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description explicitly states 'Get field definitions, types, display names, and validation rules for a Kintone app.' It includes a specific verb and resource, and clearly distinguishes from sibling tools like kintone_get_app and kintone_get_form_layout.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a clear prerequisite: 'Use 'kintone_list_apps' first to get available app IDs.' This guides the agent on proper usage. No explicit when-not-to-use or alternatives, but the guideline is valuable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get form layout information for a Kintone app. ⚠️ Use 'kintone_list_apps' first to get available app IDs.
| Name | Required | Description | Default |
|---|---|---|---|
| app_id | Yes | The ID of the Kintone app (use kintone_list_apps to see available app IDs) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears the full burden. It states the tool gets form layout information, which is adequate for a simple read operation, but it does not mention any behavioral traits (e.g., permissions, rate limits) beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with a cautionary note, no unnecessary words, and front-loads the core action. It is highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get tool with one parameter and no output schema, the description covers the purpose and parameter adequately. It could provide more about the output (form layout structure), but it is mostly complete given the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers the single parameter (app_id) with a description that matches the one in the tool description. Since schema description coverage is 100%, the description adds no new meaning beyond the schema, earning the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and resource ('form layout information for a Kintone app'), and distinguishes itself from sibling tools like kintone_get_form_fields (fields) and kintone_get_app (app settings).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises using 'kintone_list_apps' first to get available app IDs, providing a prerequisite step. It does not specify when not to use the tool, but the guidance is clear for proper usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a single record from a Kintone app by record ID. ⚠️ Use 'kintone_list_apps' first to get available app IDs.
| Name | Required | Description | Default |
|---|---|---|---|
| app_id | Yes | The ID of the Kintone app (use kintone_list_apps to see available app IDs) | |
| record_id | Yes | The ID of the record to retrieve |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the basic operation but does not disclose behavioral traits such as authentication requirements, rate limits, error handling (e.g., missing record), or that it performs a read-only operation. The warning about using list_apps is helpful but not about the tool's own behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no fluff. The core purpose is in the first sentence, and the prerequisite hint is in the second. It is appropriately sized and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with two required parameters and no output schema or annotations, the description provides the basic function and a prerequisite hint. However, it lacks details on error handling, return format, and any limitations. Adequate but with gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% description coverage for both parameters, already explaining them. The description adds marginal value by reiterating the hint for app_id. Schema provides sufficient semantics, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get a single record from a Kintone app by record ID.' It uses a specific verb ('Get') and resource ('record'), and distinguishes itself from siblings like 'kintone_get_records' (multiple records) and 'kintone_create_record' (create).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a prerequisite hint: 'Use kintone_list_apps first to get available app IDs.' This guides the user on a necessary step before using the tool. However, it does not explicitly mention when not to use it or alternatives, though siblings make it implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get multiple records from a Kintone app with query filtering, pagination, and field selection. ⚠️ Use 'kintone_list_apps' first to get available app IDs.
| Name | Required | Description | Default |
|---|---|---|---|
| app_id | Yes | The ID of the Kintone app (use kintone_list_apps to see available app IDs) | |
| query | No | Query string for filtering records (optional). Use Kintone query syntax like 'status = "Active"' | |
| fields | No | List of field codes to retrieve (optional). If not specified, all fields are returned | |
| limit | No | Maximum number of records to retrieve (default: 100, max: 500) | |
| offset | No | Number of records to skip for pagination (default: 0) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions read-like operations (get, query, pagination) but does not disclose additional behavioral traits such as rate limits, response format, or error handling. The description is adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences that are concise and front-loaded with the core purpose. The warning emoji effectively highlights a key prerequisite without extra fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description covers the main functionality and parameters adequately. It might benefit from hints about return structure or error conditions, but it is still sufficiently informative for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and all parameters have individual descriptions. The description adds a summary ('query filtering, pagination, and field selection') but does not provide meaning beyond what the schema already offers. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it gets multiple records with query filtering, pagination, and field selection. This distinguishes it from sibling tools like kintone_get_record (single record) and kintone_list_apps (app listing).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises using kintone_list_apps first to get available app IDs, providing valuable prerequisite guidance. However, it does not explicitly differentiate when to use this tool versus other sibling query tools, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get app view configurations for a Kintone app. ⚠️ Use 'kintone_list_apps' first to get available app IDs.
| Name | Required | Description | Default |
|---|---|---|---|
| app_id | Yes | The ID of the Kintone app (use kintone_list_apps to see available app IDs) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries the full burden. It only says 'Get', implying read-only, but doesn't disclose other behavioral traits like authentication needs, error handling, or whether it alters state. For a simple read operation, more explicit safety information would be helpful.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences front-load the purpose and include a useful warning. Every word serves a purpose; no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter, so the description is adequate. However, it does not explain the return structure or error scenarios, which could improve completeness given no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the description adds no new parameter meaning beyond what the schema already provides. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool retrieves app view configurations, with a specific verb ('Get') and resource ('app view configurations'). The prerequisite hint distinguishes it from siblings like kintone_get_form_fields or kintone_get_form_layout, which handle different parts of an app.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to use 'kintone_list_apps' first, which is a clear when-to-use guideline. However, it does not mention when to avoid this tool or suggest alternatives for other purposes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
🔍 START HERE: List available Kintone apps with pagination support. Use this first to get app IDs for other operations.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of apps to retrieve (default: 100, max: 100) | |
| offset | No | Number of apps to skip for pagination (default: 0) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses pagination support but omits details like rate limits, authentication needs, or empty result behavior. Adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two effective sentences. The 'START HERE' and emoji add helpful emphasis without waste, though the emoji is slightly informal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description hints at return data ('get app IDs') which is sufficient for a list tool. Sibling tools provide complementary context, making this complete enough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the description adds minimal value beyond the schema. It reinforces pagination context but does not explain parameter usage beyond what's already in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and the resource 'Kintone apps' with pagination. It distinguishes itself from sibling tools by instructing users to use it first to get app IDs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'START HERE' and 'Use this first to get app IDs for other operations,' providing clear context for when to use. It lacks explicit when-not-to-use, but the guidance is strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update an existing record in a Kintone app with revision control. ⚠️ Use 'kintone_list_apps' first to get available app IDs.
| Name | Required | Description | Default |
|---|---|---|---|
| app_id | Yes | The ID of the Kintone app (use kintone_list_apps to see available app IDs) | |
| record_id | Yes | The ID of the record to update | |
| record_data | Yes | Record data to update as key-value pairs where keys are field codes and values are field values. Each field value should be an object with 'value' property. | |
| revision | No | Record revision number for optimistic locking (optional but recommended) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It mentions revision control (optimistic locking) but doesn't detail side effects (e.g., field overwrite, event triggers). The parameter description for revision adds some context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no extraneous information. The warning emoji and imperative instruction are efficient and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters, nested objects, and no output schema, the description is fairly comprehensive. It covers purpose, prerequisite, and key parameter details. Missing details about return value or behavior without revision are minor gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by explaining the record_data format (key-value pairs with 'value' property) and the purpose of the revision parameter for optimistic locking.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Update an existing record in a Kintone app with revision control,' specifying the action and resource. It distinguishes from siblings by mentioning revision control and instructing to use kintone_list_apps first.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises using kintone_list_apps first to get app IDs. While it doesn't explicitly state when not to use the tool, the sibling context implies this is for updating existing records.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0kintone_create_recordkintone_delete_recordkintone_get_appkintone_get_form_fieldskintone_get_form_layoutkintone_get_recordkintone_get_recordskintone_get_viewskintone_list_appskintone_update_recordEach tool targets a distinct Kintone resource or operation—app listing, app details, records, form fields, layout, views, and CRUD for records. There is no overlap; descriptions clarify the purpose of each tool.
All tools follow the consistent pattern 'kintone_verb_noun' (e.g., kintone_create_record, kintone_get_record, kintone_list_apps). No mixing of cases or inconsistent verb forms.
With 10 tools, the set is well-scoped for a Kintone integration: covers app discovery, record CRUD, and metadata retrieval (fields, layout, views). This is appropriate for a 'lite' server.
The server covers the core workflow: listing apps, getting app details, record CRUD, and essential metadata (fields, layout, views). Minor gaps like bulk operations or file handling are acceptable for a lite version.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
MCP server that lets AI assistants use all OneSchema features exposed via the public API.
MCP server unifying ERPs, CRMs, APIs and knowledge base for Claude, ChatGPT and Gemini.
MCP server connecting AI agents to 100+ apps (Gmail, Slack, Notion, GitHub) via one-click OAuth.
MCP server exposing klokin time-tracking operations (employees, time entries, stores) to AI clients.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/luvl/mcp-kintone-lite'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
