kintone MCP Server

Official

by kintone

Overview Schema Related Servers Score Discussions

TypeScript

Remote

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.9.1
Disambiguation5/5
Each tool has a distinct purpose, covering app settings, form fields, layout, records, comments, statuses, deployment, and file download. No two tools overlap in functionality.
Naming Consistency5/5
All tools follow the pattern 'kintone-<verb>-<noun>' with snake_case, using consistent verbs like get, update, add, delete, deploy. Naming is predictable and uniform.
Tool Count5/5
20 tools is well-scoped for a kintone integration, covering app configuration, records, comments, statuses, and deployment without being overwhelming or insufficient.
Completeness4/5
The tool set covers most CRUD operations for records and form fields, plus comments, statuses, and deployment. Minor gaps exist (e.g., no file upload, no OR filtering for records), but the surface is largely complete for typical kintone workflows.
Average 4/5 across 20 of 20 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- 11 of 12 community issues answered or closed in the last 6 months
- 76 commits in the last 12 weeks
- Last stable release on August 19, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under Apache 2.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist; description only says 'get', implying read-only but lacks details on authentication, error handling, or behavior with invalid app IDs. The burden of disclosure is on the description, which does not fulfill it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no fluff. Could be slightly more descriptive without losing conciseness, but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool is simple with one param and output schema exists; description provides minimal context. Adequate for basic understanding but lacks detail on constraints like maximum apps or statuses returned.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% description coverage for the 'apps' parameter, so baseline is 3. The description adds no new semantic meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description states 'Get app deploy status from kintone' with a clear verb and resource. It distinguishes from sibling 'kintone-deploy-app' which is for deployment, not status retrieval. However, it could be more specific about the scope (multiple apps).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives (e.g., kintone-get-app for general info). No prerequisites or when-not-to-use hints provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for behavioral disclosure. It only says 'Get', implying a read operation, but does not mention permissions, rate limits, or any side effects. The schema's preview parameter includes permission details, but the description adds no extra transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the action and resource. No wasted words, and it is appropriately sized for the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists (not shown but present), the description does not need to explain return values. It adequately covers the tool's purpose. Minor gap: it does not mention that general settings include name, description, etc., but the output schema handles that.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description does not add additional meaning beyond what the schema provides for the parameters (app, lang, preview).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get general settings of a kintone app', identifying the verb and resource. However, it does not distinguish from sibling tools like kintone-get-app or kintone-get-form-fields, which also retrieve app information.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The sibling tool kintone-update-general-settings is for writing, but no explicit 'use for reading' or exclusion of other tools is mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits, but it only restates the purpose. It fails to mention that it is a read-only operation or any constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no unnecessary words. It is concise, though it could be slightly improved with more context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema and three parameters, the description is minimal and does not explain the purpose of process management settings or provide context for retrieval.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description adds no extra meaning beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'process management settings' from a kintone app. It is distinct from sibling tools like 'get-app' or 'get-form-fields'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool vs. alternatives (e.g., 'get-app' or 'get-form-fields') or any context for its use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It only mentions the count limit but fails to disclose that deletion is irreversible, require permissions, or describe how the revisions parameter affects deletion behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, very concise, and front-loaded with the key action. However, it sacrifices detail for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool performs a destructive operation with three parameters (including an optional revisions parameter), the description is insufficient. It does not address return values, error conditions, or permissions, despite the existence of an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameters with descriptions. The description adds no additional meaning beyond the schema, which is the baseline for such coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it deletes multiple records from a kintone app and mentions the maximum limit of 100 records, which distinctly separates it from sibling tools like update or add records.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates the maximum records per call but does not provide guidance on when to use this tool versus alternatives, nor does it specify prerequisites or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits. It only states a read operation, but does not mention idempotency, authorization needs, or any limitations. The agent has to infer safety from the name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no unnecessary words. It is efficiently concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, output schema exists), the description is minimally adequate. However, it could be improved by specifying what 'app settings' includes, though the output schema likely covers that. Not deficient but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents the required parameter appId with a clear description. The tool description adds no additional semantic value beyond what the schema provides, meeting the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get app settings from kintone' clearly states the verb 'Get' and the resource 'app settings', distinguishing it from sibling tools that handle form fields, records, or other resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives, such as 'kintone-get-form-fields' or 'kintone-get-records'. The description lacks context for optimal selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose key behaviors. It states that filters are AND-combined and OR is unsupported, which is a critical limitation. However, it does not mention authentication requirements, rate limits, or what happens on errors (e.g., invalid app ID). The behavioral disclosure is incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences front-load the purpose and immediately provide a crucial usage hint (use kintone-get-form-fields first). Every word adds value; no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the tool's complexity (6 parameters with nested objects, multiple filter types, an output schema), the description is minimal. It does not explain pagination behavior (offset/limit), maximum record limits, or error cases. The missing details leave the agent under-informed for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds no significant meaning beyond what the schema already provides for each parameter. It emphasizes 'structured filtering' but does not clarify parameter usage beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get multiple records') and resource ('kintone app') with 'structured filtering'. It implies the tool is for reading records, distinguishing it from mutation tools like kintone-add-records or kintone-update-records. However, it does not explicitly contrast with other retrieval tools like kintone-get-app or kintone-get-form-fields, though the names themselves differentiate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises using kintone-get-form-fields first to discover fields, and notes that OR conditions are not supported. This provides helpful context but does not specify when NOT to use this tool (e.g., for OR logic there is no alternative mentioned). It lacks guidance on pagination or handling large result sets.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It only mentions the one-comment-per-call constraint, but lacks details on success/failure responses, authorization requirements, or effects on existing comments. This insufficiently informs the agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two concise sentences, front-loading the primary action and then clarifying the API constraint. No unnecessary words, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the schema fully documents all 4 parameters and an output schema exists, the description is largely complete. It could mention that comments are appended and not overwritten, but this is not essential.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with detailed descriptions for each parameter, especially 'text' which explains mention rendering. The description adds no additional parameter information beyond the schema, 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool adds a single comment to a kintone record, distinguishing it from sibling tools like kintone-get-record-comments (reading) or kintone-update-records (updating records). It also specifies the API limitation, helping the agent understand the tool's scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains that the API accepts one comment per call and suggests calling repeatedly for multiple records. This provides clear usage context, though it does not explicitly mention alternatives or when not to use the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full burden. It discloses that certain fields cannot be registered (e.g., LOOKUP copies, STATUS, CALC). However, it omits details about error handling, authorization requirements, atomicity, or response behavior. The output schema likely covers return format, but the description lacks comprehensive behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—two sentences and a parenthetical list. The first sentence states the core action, the second provides a crucial prerequisite, and the note lists exceptions. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (2 parameters, including a potentially complex records array), the description covers the key points: action, prerequisite, and unsupported fields. The schema already documents parameter details and constraints (e.g., maxItems 100), and an output schema exists. It misses batch behavior or error context, but overall is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline 3. The description does not add new parameter-specific information beyond what the schema already provides. The mention of using get-form-fields is meta-advice, not parameter semantics. Hence, no improvement over baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool adds multiple records to a kintone app, using the specific verb 'Add' and resource 'records'. It distinguishes from siblings like kintone-update-records and kintone-delete-records by focusing on creation. The mention of unsupported fields further clarifies scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises using kintone-get-form-fields first to discover field codes and formats, and lists field types that cannot be registered. This gives clear prerequisite and limitation guidance. It does not explicitly contrast with alternatives like update or delete, but the action is distinct enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior. It correctly identifies the tool as asynchronous and directs to check status, but does not mention rate limits, permissions, or error scenarios. This is adequate but not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: the first defines the action and environment, the second gives essential usage guidance. No redundant information, front-loaded with purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (relieving the description of return value details), and the schema covers all parameters, the description adds necessary context for async behavior and a related tool. It is sufficient for the complexity level.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description does not add further parameter details beyond what the schema provides; thus, it meets but does not exceed expectations.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Deploy app settings from pre-live to production environment on kintone.' It also specifies it is asynchronous, distinguishing it from sibling tools like kintone-get-app-deploy-status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly mentions using the complementary tool 'kintone-get-app-deploy-status' to check progress, providing guidance on follow-up actions. However, it does not state when to avoid using this tool, though the context of sibling tools implies distinct use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses single-record operation, 10-comment limit, and pagination via offset, but lacks details on error cases, rate limits, 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise: three sentences covering purpose, scope limitation, and pagination. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (reducing need to describe return format), the description covers key aspects: what the tool does, single-record requirement, and pagination. It could mention error handling, but overall complete for a simple retrieval tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 minimal new meaning beyond the schema (e.g., pagination concept), but does not explain parameter formats or behaviors beyond what schema already defines.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets comments on a single kintone record, which is a specific verb-resource combination. It distinguishes from sibling tools like kintone-add-record-comment or kintone-get-records by focusing on comments and emphasizing single-record operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides guidance on pagination and multi-record usage ('call this tool repeatedly'), but does not explicitly compare to alternatives or specify when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully bears the burden of behavioral disclosure. It mentions the 100-record limit and the prerequisite, but omits details like error handling, idempotency, or behavior when revision validation fails.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (three sentences) and front-loaded with the purpose, then provides prerequisites and limits without unnecessary details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the high schema coverage and the existence of an output schema (so return values need not be described), the description covers key aspects: purpose, prerequisite, and limits. It is complete enough 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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not add any parameter meaning beyond the input schema, which has 100% coverage. Baseline of 3 is appropriate since the schema already provides adequate documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool updates status of multiple records in a kintone app, distinguishing it from similar tools like kintone-update-records by specifying 'status' and the prerequisite for process management.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear prerequisite (process management enabled) and a limit (max 100 records), giving good context for when to use the tool, though it does not explicitly mention when not to use it or alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses the response structure (properties object, revision string) and lists returned field details. It does not explicitly state it is a read-only, non-destructive operation, but the context implies it. Adding an explicit safety statement would raise the score.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four sentences, front-loaded with purpose, then return details, then usage guidance. It is efficient with no fluff, though slightly wordy. It earns a 4 for being clear and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 parameters, high schema coverage, and an output schema, the description adequately covers purpose, return structure (properties, revision), and usage context (live/pre-live). It lacks an explicit read-only declaration but is otherwise complete for an agent's decision-making.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds some value by mentioning 'Both live and pre-live app settings retrieval' for the preview parameter, but otherwise does not elaborate beyond the schema's existing descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it gets form field settings from a kintone app, enumerates return details (type, code, label, configuration), and distinguishes from sibling CRUD tools like add-form-fields and update-form-fields.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear when-to-use context: 'Essential for understanding current field structure before add/update/delete operations' and 'Use to verify lookup field configurations.' It does not explicitly say when not to use or offer alternatives, but the context is strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full burden. It discloses that the tool retrieves layout structure and supports both live and pre-live app settings. No misleading or missing behavior is noted; for a read-only tool, this is sufficient transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (4 sentences) and front-loaded with the core purpose. Every sentence adds value without redundancy or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (2 parameters, output schema exists), the description is complete. It explains what the layout includes and provides use cases. No critical information is missing for an agent to use it effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents both parameters. The description adds minimal meaning beyond the schema (e.g., 'pre-live' for preview), but does not provide additional syntax or format details. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('form layout from a kintone app'), clearly stating what the tool returns ('layout structure with rows, subtables, groups, and field positioning'). This distinguishes it from siblings like get-form-fields or update-form-layout.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: 'Use to understand current form arrangement before layout updates' and 'Essential when adding new fields that need specific positioning or when rearranging existing fields.' It does not explicitly state when not to use or mention alternatives, but the use cases are well-defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that certain fields cannot be updated, which is helpful. However, it does not mention authentication, rate limits, or partial update behavior. The revision field for optimistic locking is in the schema but not highlighted in the description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first clearly states purpose, second provides crucial guidance and limitations. No unnecessary words, information is front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 params, output schema present), the description covers the core usage and important constraints. The schema handles parameter details thoroughly. Could mention that updates are atomic per record, but not essential.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
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 recommending using kintone-get-form-fields to discover field codes and formats, which is crucial for constructing the 'records' parameter. It also lists non-updatable fields, aiding parameter construction.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Update multiple records in a kintone app' with a specific verb and resource. It distinguishes from sibling tools like kintone-add-records and kintone-delete-records by focusing on update.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It instructs to use kintone-get-form-fields first, providing a prerequisite. It also lists field types that cannot be updated (LOOKUP copies, STATUS, etc.), guiding when not to use this tool. However, it does not explicitly suggest alternative tools for those cases, like kintone-update-statuses for status updates.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the pre-live behavior and deployment requirement. It could mention that unspecified fields remain unchanged, but overall transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no waste. First sentence states purpose, second explains key behavioral nuance. Front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given tool complexity (14 parameters, nested objects) and presence of output schema, description covers main behavioral aspect. Could mention error handling or prerequisites, but sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline 3 is appropriate. The description does not add parameter-specific details beyond schema, but schema already explains each parameter well.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Update' and the resource 'general settings of a kintone app'. It also explains the pre-live environment, distinguishing it from sibling tools like get-general-settings and deploy tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly mentions that changes go to pre-live and instructs to use kintone-deploy-app to reflect changes to production. This provides clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries full burden. It discloses preview-only operation, permission requirements, field code constraints, option key matching, and the need for deployment. However, it does not mention idempotency, error behavior beyond revision mismatch, or rate limits. Still, for an additive tool, key behaviors are covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph that is front-loaded with the core purpose. Each sentence adds value: permissions, constraints, special rules, pre-check suggestion, deployment note. It could be more structured (bullets) but is not verbose. It earns its length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of the input schema (many field types, nested objects), the description provides high-level guidance and important workflow steps (pre-check, deploy). The output schema likely covers return values (not shown). It is fairly complete for an add tool, though some edge cases (e.g., error handling) are not detailed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, baseline 3. The description adds significant extra meaning: field code constraints (unique, max 128 chars, no leading numbers, only underscore), option requirements (keys must match labels, require label and index), lookup field type hints. These details are absent from the schema. However, not all parameters are elaborated (e.g., subtable fields structure is left to schema).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Add new fields to a kintone app (preview environment only)' and distinguishes from siblings by mentioning 'Use kintone-get-form-fields first to check existing fields' and implying that deployment is needed via kintone-deploy-app. The verb 'Add' and resource 'form fields' are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use (preview only), prerequisites (App Management permissions, check existing fields), constraints (field code uniqueness, length, allowed characters), special rules for selection and lookup fields, and post-requisite (deploy to apply). It clearly guides the agent on correct invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully carries the burden of behavioral disclosure. It reveals key traits: preview environment only, permission requirement, field code update restrictions, selection options deletion behavior, lookup field instability, and the need for deployment. This goes well beyond the input schema, which only defines parameter structure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is moderately long but every sentence provides useful information. It is well-structured with specific constraints and prerequisites. Some redundancy could be trimmed, but overall it is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of the tool (many field types, nested objects) and the presence of an output schema, the description covers essential pre-conditions and side effects. It mentions the preview environment, permission, deployment, and field-specific caveats. It could add a note about the revision parameter (error on mismatch), but the schema already covers that. Overall, it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds important parameter-level context: for selection fields, unspecified options will be deleted and option keys must match current names. This is not present in the schema and helps the agent understand the implications of setting the 'properties' parameter. The baseline of 3 is exceeded.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Update form field settings in a kintone app (preview environment only)', which is a specific verb-resource pair. It distinguishes itself from siblings like kintone-add-form-fields (adding new fields) and kintone-delete-form-fields by focusing on updating existing fields. The mention of preview environment further clarifies scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: requires App Management permissions, recommends using kintone-get-form-fields first, and notes that changes require deploy. It also warns about selection field option deletion and lookup field issues. However, it could explicitly state when not to use this tool (e.g., for adding fields, use the add tool), though this is implied by the sibling tool names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses key behaviors: preview-only operation, 100-field limit, prohibited field types (status, assignee, category), and deployment dependency. It does not detail error handling or return values, but an output schema exists to cover the latter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences efficiently convey purpose, constraints, usage tips, and related tools. It is front-loaded with the main action and avoids redundancy, though could be slightly more compact.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (deletion with restrictions, preview-only, deployment requirement), the description covers all essential aspects: environment, limits, prohibitions, workflow, and related tools. An output schema is present to document return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (3 parameters described), so baseline is 3. The description adds value by clarifying the maxItems constraint on fields and the revision checking behavior, plus listing prohibited field types not in schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool deletes form fields from a kintone app in preview environment only, specifying verb 'delete' and resource 'form fields', and distinguishes from sibling tools like add, update, or deploy.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises using kintone-get-form-fields first for verification, mentions the use case for recreating lookup fields, and notes that changes require kintone-deploy-app to apply to the live app, providing clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It discloses side effects (saving to download directory), required environment variable, permissions, and automatic extension detection. This provides clear behavioral expectations beyond what annotations might offer.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, each with a clear purpose: first describes the action and return, second lists requirements. No fluff, front-loaded with essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema (not shown), the description explains the return value. With only two parameters and clear prerequisites, the description covers all necessary context 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.
Parameters4/5
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 specifying that fileName should be provided without extension and that extension is auto-detected from MIME type. This clarifies usage beyond schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the verb (download), resource (file from kintone), and key inputs (fileKey). It also mentions the return value (absolute path). This distinguishes it from sibling tools, which are about app management, records, or form manipulation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description specifies prerequisites: KINTONE_ATTACHMENTS_DIR environment variable, record viewing permission, and field permission. It does not explicitly state when not to use, but no alternatives exist among siblings, so implicit usage context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 discloses that updates apply only to the preview environment, that field codes are case-sensitive, and provides a detailed example for SUBTABLE structure. It does not mention permissions or potential overwrite behavior, but the provided details are substantial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of three well-structured sentences plus a nested example. It front-loads the key purpose and limitation, then provides prerequisites and details. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers prerequisites, key behaviors, and provides a concrete example for a complex parameter. An output schema exists, so return values need not be described. Could mention error scenarios, but overall it is sufficiently complete 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.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds significant meaning beyond the schema. It explains the nested structure for SUBTABLE fields, emphasizes case-sensitivity, and gives an explicit example. This helps the agent understand how to construct the layout parameter correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Update' and the resource 'form layout settings in a kintone app', and adds a critical scope constraint '(preview environment only)'. It effectively distinguishes from sibling tools like kintone-update-form-fields by referencing prerequisites and the need for a deploy step.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to use kintone-get-form-fields and kintone-get-form-layout first, and notes that changes require kintone-deploy-app to apply to the live app. This gives clear when-to-use and post-usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![mcp-server MCP server](https://glama.ai/mcp/servers/kintone/mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/kintone/mcp-server)

Score Badge

Copy to your README.md:

[![mcp-server MCP server](https://glama.ai/mcp/servers/kintone/mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/kintone/mcp-server)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/kintone/mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server