kintone MCP Server (Python3)

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation4/5
Most tools have distinct purposes targeting specific resources and actions, such as add_record vs. update_record or get_record vs. get_records. However, get_all_records and get_records could cause confusion as both retrieve records, though the former handles pagination automatically, which is a subtle but potentially ambiguous distinction for agents.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern with clear, descriptive verbs like add, get, update, download, and upload. The naming is uniform across all 17 tools, using snake_case throughout without any deviations or mixed conventions.
Tool Count4/5
With 17 tools, the count is slightly high but reasonable for a kintone server covering CRUD operations, file handling, comments, and app management. It feels comprehensive without being overly bloated, though it borders on the upper limit of a well-scoped set.
Completeness5/5
The tool set provides complete coverage for the kintone domain, including full CRUD for records (add, get, update), batch operations, file upload/download, comment management, app and form field retrieval, and status updates. There are no obvious gaps, and agents can handle typical workflows without dead ends.
Average 2.9/5 across 17 of 17 tools scored. Lowest: 2.2/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure but only states the basic action ('Get app information'). It doesn't reveal whether this is a read-only operation, requires authentication, has rate limits, returns structured data, or handles errors—critical gaps for a tool with potential data access.
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 extremely concise ('Get app information'), consisting of three words with no wasted text. However, it's overly brief to the point of under-specification, slightly reducing its effectiveness despite efficient phrasing.
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 no annotations and no output schema, the description is incomplete for a tool that likely returns app details. It doesn't explain what 'app information' includes (e.g., metadata, configuration), how results are structured, or error conditions, leaving significant gaps in understanding the tool's behavior and output.
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% description coverage, with the single parameter 'id' documented as 'The app ID'. The description adds no additional meaning beyond this, such as format examples or sourcing details, but the schema adequately covers the parameter, meeting the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get app information' restates the tool name 'get_app' with minimal elaboration, making it tautological. It specifies the resource ('app') but lacks a clear, specific verb beyond 'get' and doesn't distinguish this tool from its sibling 'get_apps' (which likely lists 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 Guidelines1/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 like 'get_apps' (for listing apps) or 'get_record' (for generic records). The description offers no context, exclusions, or prerequisites, leaving usage entirely ambiguous.
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 carries the full burden of behavioral disclosure. 'Get comments for a record' implies a read-only operation, but it doesn't specify authentication needs, rate limits, error handling, pagination behavior (beyond what's hinted in parameters), or the return format (e.g., list of comment objects). For a tool with 5 parameters and no output schema, this leaves significant gaps in understanding how it behaves.
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 at four words, with zero wasted language. It's front-loaded with the core action ('Get comments'), making it easy to scan. Every word earns its place by directly stating the tool's purpose without redundancy or fluff.
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's complexity (5 parameters, no annotations, no output schema), the description is incomplete. It doesn't address behavioral aspects like pagination, authentication, or error handling, nor does it provide usage context. While the schema covers parameters well, the lack of output schema means the description should ideally hint at return values, but it doesn't, leaving users with insufficient information 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?
The description adds no meaning beyond what the input schema provides. Since schema description coverage is 100%, with clear descriptions for all parameters (e.g., 'app ID', 'record ID', 'sort order'), the baseline score is 3. The description doesn't explain parameter interactions, defaults beyond 'order', or constraints like the 'limit' max of 10, but the schema adequately covers these details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get comments for a record' clearly states the verb ('Get') and resource ('comments for a record'), making the basic purpose understandable. However, it lacks specificity about what 'Get' entails (e.g., listing, retrieving, fetching) and doesn't distinguish this tool from potential siblings like 'get_record' or 'get_all_records' in terms of scope or granularity, leaving it somewhat vague.
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 versus alternatives. It doesn't mention prerequisites (e.g., needing an app and record ID), exclusions, or comparisons to sibling tools like 'get_record' (which might include comments) or 'add_comment'. Without such context, users must infer usage from the tool name and parameters alone.
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. While 'Add a comment' implies a write/mutation operation, it doesn't disclose important behavioral traits like required permissions, whether comments are editable/deletable, rate limits, or what happens on success/failure. The description is minimal and lacks crucial operational context.
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 at just 5 words, front-loading the core purpose with zero wasted words. Every word earns its place in communicating the essential function.
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 this is a mutation tool with no annotations and no output schema, the description is insufficiently complete. It doesn't explain what the tool returns, error conditions, or important behavioral constraints. For a tool that modifies data, more contextual information is needed 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?
With 100% schema description coverage, all parameters are documented in the schema itself. The description adds no additional parameter semantics beyond what's already in the schema descriptions. This meets the baseline expectation when schema coverage is complete.
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 ('Add a comment') and target resource ('to a record'), providing a specific verb+resource combination. However, it doesn't differentiate from sibling tools like 'get_comments' or explain how it differs from other comment-related operations that might exist.
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 versus alternatives like 'update_record' (which might also handle comments) or 'get_comments'. There's no mention of prerequisites, context, or exclusions for using this tool.
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 carries the full burden of behavioral disclosure. It states the tool adds a record but doesn't cover critical aspects like required permissions, whether the operation is idempotent, error handling (e.g., for invalid app IDs or record data), or what happens on success (e.g., returns a record ID). For a mutation tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.
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, efficient sentence that front-loads the core purpose without unnecessary words. Every part earns its place by specifying 'single record' (distinguishing from bulk operations) and 'kintone app' (providing context). There's no redundancy or fluff, making it easy to parse quickly.
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's complexity (a mutation operation with nested objects in parameters), lack of annotations, and no output schema, the description is insufficiently complete. It doesn't address behavioral traits like side effects, authentication needs, or return values, which are critical for safe and effective use. The high schema coverage helps with parameters, but overall context for invocation is lacking.
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 input schema fully documents both parameters ('app' as an integer ID and 'record' as an object with field codes). The description adds no additional semantic context beyond implying the 'app' parameter refers to a kintone app. Since the schema does the heavy lifting, the baseline score of 3 is appropriate, though the description doesn't compensate with examples or formatting details.
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 ('Add') and resource ('a single record to a kintone app'), making the purpose immediately understandable. It distinguishes from sibling tools like 'add_records' (plural) and 'update_record' by specifying single-record creation. However, it doesn't explicitly contrast with other siblings like 'upload_file' or 'add_comment', leaving some ambiguity about scope boundaries.
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 about when to use this tool versus alternatives. The description doesn't mention prerequisites (e.g., needing an existing app), compare it to 'add_records' for bulk operations, or indicate scenarios where 'update_record' might be more appropriate. Without this context, users must infer usage from the tool name alone.
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 but offers minimal behavioral context. It mentions a constraint ('max 100 records') but doesn't disclose permissions required, whether the operation is idempotent, error handling, response format, or side effects. This is inadequate for a write operation tool.
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, efficient sentence with no wasted words. It front-loads the core purpose and includes a key constraint directly, making it easy to parse quickly.
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?
For a write operation tool with no annotations and no output schema, the description is insufficient. It lacks details on permissions, response structure, error cases, and how it differs from similar tools like 'add_record'. Given the complexity of batch operations, more context is needed 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 schema already documents both parameters ('app' and 'records'). The description adds the 'max 100 records' constraint for the 'records' parameter, providing some extra context, but doesn't elaborate on data format or validation rules beyond what the schema implies.
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 ('add multiple records') and target resource ('to a kintone app'), with a specific constraint ('max 100 records'). It distinguishes from 'add_record' (singular) but doesn't explicitly differentiate from other sibling tools like 'update_records' or 'get_records'.
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 like 'add_record' (for single records) or 'update_records' (for modifying existing records). The description mentions a maximum record limit but doesn't specify prerequisites, error conditions, or typical use cases.
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, the description carries full burden but provides minimal behavioral context. It doesn't disclose whether this requires authentication, has rate limits, what happens if the file_key is invalid, or if the save_path must be writable. The description is too basic for a tool that performs I/O operations.
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, efficient sentence with no wasted words. It's front-loaded with the core purpose, making it easy to scan and understand quickly.
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 no annotations and no output schema, the description is incomplete for a tool that downloads files. It lacks information on error handling, return values (e.g., success confirmation or file metadata), and operational constraints, leaving significant gaps for an AI agent to use it 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?
Schema description coverage is 100%, so the schema already documents both parameters. The description doesn't add any meaning beyond what the schema provides, such as explaining what a 'file_key' is in kintone context or how the 'save_path' is interpreted. Baseline 3 is appropriate given high schema coverage.
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 ('Download') and resource ('a file from kintone'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'upload_file' beyond the obvious verb difference, missing explicit comparison.
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. For example, it doesn't mention if this is for retrieving files uploaded via 'upload_file' or other operations, nor does it specify prerequisites like needing a valid file_key from another tool.
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 but offers minimal behavioral information. It mentions filtering but doesn't describe return format, pagination behavior, error conditions, authentication requirements, or rate limits. For a tool with 6 parameters and no annotation coverage, this is insufficient.
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, efficient sentence that communicates the core functionality without unnecessary words. It's appropriately sized for a retrieval tool and front-loads the essential information.
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?
For a tool with 6 parameters, no annotations, and no output schema, the description is inadequate. It doesn't explain what information is returned, how results are structured, or important behavioral aspects like pagination defaults. The agent would struggle to use this tool effectively without trial-and-error.
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 schema fully documents all 6 parameters. The description adds minimal value beyond the schema by mentioning 'name or other filters' but doesn't provide additional context about parameter interactions, precedence, or combined usage. Baseline 3 is appropriate when schema does the heavy lifting.
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') and resource ('kintone apps information'), and specifies filtering capabilities ('by name or other filters'). However, it doesn't explicitly differentiate from sibling tools like 'get_app' (singular vs plural), which could cause confusion about when to use each.
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 versus alternatives like 'get_app' (singular) or 'get_all_records'. There's no mention of prerequisites, context for filtering, or comparison with sibling tools that might retrieve similar data.
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 the full burden of behavioral disclosure. It states it's a read operation ('Get'), implying safety, but doesn't cover aspects like authentication needs, error handling (e.g., if the record doesn't exist), rate limits, or response format. This is inadequate for a tool with no annotation coverage.
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, efficient sentence that directly states the tool's purpose without unnecessary words. It's front-loaded with the core action and resource, making it easy to parse quickly. Every part of the sentence contributes essential information.
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 complexity of a read operation with no annotations and no output schema, the description is incomplete. It doesn't explain what the return value includes (e.g., record data, fields), error conditions, or how it differs from sibling tools like 'get_records'. For a tool in this context, more detail is needed to guide the agent 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?
The input schema has 100% description coverage, clearly documenting both parameters ('app' as app ID and 'id' as record ID). The description adds no additional parameter semantics beyond what the schema provides, such as format examples or constraints. This meets the baseline score when schema coverage is high.
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 verb ('Get') and resource ('a single record from a kintone app'), making the purpose immediately understandable. However, it doesn't explicitly distinguish this tool from sibling tools like 'get_records' or 'get_all_records', which would require mentioning the single-record focus versus batch retrieval.
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 versus alternatives. It doesn't mention scenarios like retrieving a specific known record ID, contrast with 'get_records' for multiple records, or prerequisites such as needing app and record IDs. This leaves the agent without usage context.
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 carries full burden for behavioral disclosure. While 'Get' implies a read operation, the description doesn't mention authentication requirements, rate limits, error conditions, or what the return format looks like. For a tool with 5 parameters and no output schema, this leaves significant behavioral gaps.
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, efficient sentence that states the core purpose without unnecessary words. It's appropriately sized for a straightforward retrieval tool and gets directly to the point.
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 has 5 parameters, no annotations, and no output schema, the description is insufficiently complete. It doesn't explain what 'records' contain, how they're structured, what happens when no records match, or any limitations beyond what's implied by the parameter schema. For a data retrieval tool in a system with multiple similar tools, more context is needed.
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 all parameters are documented in the schema. The description doesn't add any meaningful parameter semantics beyond what's already in the schema descriptions. The baseline of 3 is appropriate when the schema does all the parameter documentation work.
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 verb ('Get') and resource ('records from a kintone app'), making the tool's purpose immediately understandable. However, it doesn't distinguish this tool from sibling tools like 'get_record' (singular) or 'get_all_records', leaving some ambiguity about scope and differentiation.
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 versus alternatives. With siblings like 'get_record' (singular), 'get_all_records', and 'get_app' available, there's no indication of when this filtered/queryable retrieval is preferred over other record-fetching tools.
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 the full burden of behavioral disclosure. It states this is an update operation, implying mutation, but fails to mention critical aspects like authentication requirements, error handling, rate limits, or whether changes are reversible. For a mutation tool with zero annotation coverage, this is a significant gap in 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, direct sentence that efficiently conveys the core purpose without unnecessary words. It is front-loaded with essential information ('Update a single record'), making it easy for an agent to parse quickly and accurately.
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 complexity of a mutation tool with 5 parameters, no annotations, and no output schema, the description is incomplete. It lacks details on behavioral traits (e.g., side effects, error responses), usage context relative to siblings, and output expectations, leaving the agent with insufficient information for reliable invocation.
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 schema description coverage is 100%, meaning all parameters are documented in the schema itself. The description adds no additional semantic context beyond what's in the schema (e.g., it doesn't explain field code formats or update_key structure). This meets the baseline score of 3, as the schema adequately handles parameter documentation.
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 ('Update') and resource ('a single record in a kintone app'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'update_records' or 'update_status', which would require explicit comparison to achieve a perfect score.
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 versus alternatives like 'update_records' for multiple records or 'update_status' for status changes. It also lacks information about prerequisites, such as required permissions or app configuration, leaving the agent with insufficient context for optimal tool selection.
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 the full burden of behavioral disclosure. It states this is an update operation (implying mutation) and mentions a batch limit, but doesn't cover critical aspects like required permissions, whether updates are atomic, what happens on partial failures, or response format. For a mutation tool with zero annotation coverage, this leaves significant behavioral gaps.
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, efficient sentence that communicates the core purpose and key constraint without any wasted words. It's appropriately front-loaded with the main action and resource, making it easy for an agent to parse quickly. Every element serves a clear purpose.
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?
For a mutation tool with no annotations and no output schema, the description is insufficiently complete. It doesn't explain what the tool returns, error handling, authentication requirements, or how it differs from similar tools like 'update_record'. The batch limit is mentioned but not explained, leaving important contextual gaps for proper tool invocation.
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 schema already documents both parameters ('app' and 'records') thoroughly. The description adds minimal value by mentioning the 'max 100 records' constraint, which relates to the 'records' array parameter. However, it doesn't explain the structure of update data or provide context beyond what the schema already specifies, meeting the baseline for high schema coverage.
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 ('Update multiple records') and specifies the resource ('in a kintone app'), making the purpose immediately understandable. It distinguishes from the sibling 'update_record' by indicating bulk capability, though it doesn't explicitly contrast them. The description avoids tautology by providing meaningful context beyond the tool name.
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 versus alternatives like 'update_record' or 'update_status'. It mentions a constraint ('max 100 records') but doesn't explain why this limit exists or what happens if exceeded. There are no prerequisites, error conditions, or explicit alternatives mentioned, leaving the agent to infer usage context.
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 states this is an update operation, implying mutation, but doesn't mention permissions needed, whether changes are reversible, side effects, or response format. This is a significant gap for a mutation tool with zero annotation coverage.
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, efficient sentence with zero wasted words. It's appropriately sized for a simple tool and front-loads the core purpose immediately.
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?
For a mutation tool with 5 parameters, no annotations, and no output schema, the description is incomplete. It doesn't explain what happens after the update, error conditions, or behavioral nuances. Given the complexity and lack of structured data, more context would be helpful.
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 schema already documents all 5 parameters. The description adds no additional meaning about parameters beyond what's in the schema (e.g., what 'action' represents, how 'revision' works). Baseline 3 is appropriate when the schema does the heavy lifting.
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 verb ('update') and resource ('status of a record'), making the purpose immediately understandable. It doesn't explicitly distinguish from siblings like 'update_record' or 'update_statuses', but the focus on 'status' provides some differentiation.
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 versus alternatives like 'update_record' or 'update_statuses'. There's no mention of prerequisites, constraints, or typical use cases, leaving the agent with minimal context for selection.
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 carries the full burden of behavioral disclosure. It states it's an update operation (implying mutation) and mentions a batch limit of 100, but doesn't cover critical aspects like required permissions, whether changes are reversible, error handling for invalid inputs, or what the response looks like (e.g., success/failure indicators). For a mutation tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.
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, efficient sentence that front-loads the core action ('Update the status of multiple records') and includes a practical constraint ('max 100'). There is no wasted wording, repetition, or unnecessary elaboration, making it easy to parse quickly for an agent.
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's complexity (batch mutation with nested objects in 'records'), lack of annotations, and no output schema, the description is insufficiently complete. It doesn't explain the expected output format, error conditions, or how status updates interact with the system (e.g., triggering workflows). For a mutation tool handling multiple records, more context is needed to ensure safe and effective use by an agent.
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 adds no parameter-specific information beyond what's in the input schema, which has 100% coverage with clear descriptions for both parameters ('app' and 'records'). It implies batch processing via 'multiple records (max 100)', but this doesn't clarify individual parameter semantics like the meaning of 'action' or 'assignee' in the records array. With high schema coverage, the baseline is 3, as the description doesn't compensate with additional insights.
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 verb ('Update') and resource ('status of multiple records'), specifying it handles multiple records with a maximum batch size of 100. It distinguishes from sibling tools like 'update_status' (singular) and 'update_record'/'update_records' (general updates vs. status-specific). However, it doesn't explicitly mention what system or context these records belong to (e.g., database, workflow), leaving some ambiguity.
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 versus alternatives. It doesn't mention prerequisites, when to choose it over 'update_status' (for single records) or 'update_records' (for broader updates), or any specific scenarios where status updates are appropriate. The lack of context makes it hard for an agent to decide between similar tools without trial and error.
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 mentions 'upload' which implies a write operation, but fails to describe critical behaviors like authentication requirements, rate limits, error conditions, or what happens after upload (e.g., returns a file ID). This leaves significant gaps for agent understanding.
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, efficient sentence with zero wasted words. It's front-loaded with the core action and resource, making it immediately scannable and appropriately sized for a simple tool.
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 this is a write operation tool with no annotations and no output schema, the description is incomplete. It doesn't explain what the tool returns, error handling, or behavioral constraints. For a mutation tool in this context, more information is needed for proper agent usage.
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% description coverage, with the single parameter 'file_path' clearly documented. The description adds no additional parameter information beyond what the schema provides, so it meets the baseline score of 3 where schema does the heavy lifting.
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 ('upload') and target resource ('a file to kintone'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'download_file' or specify what type of files can be uploaded, which prevents a perfect score.
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 versus alternatives like 'add_record' or 'download_file', nor does it mention any prerequisites (e.g., authentication, file size limits). It simply states what the tool does without context for selection.
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 carries full burden. It states 'Get' implying a read operation, but lacks details on permissions, rate limits, error handling, or response format. For a tool with no annotations, this leaves significant behavioral gaps.
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, efficient sentence with no wasted words. It's front-loaded and directly states the tool's purpose, making it easy to parse quickly without unnecessary elaboration.
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 no annotations, no output schema, and 2 parameters with full schema coverage, the description is minimally adequate. It covers the basic purpose but lacks details on behavior, usage context, or output, leaving room for improvement in completeness for effective tool selection.
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 schema already documents both parameters (app ID and language code). The description adds no additional meaning beyond the schema, such as explaining what 'form fields configuration' includes or how parameters affect the output, meeting the baseline for high coverage.
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 'Get form fields configuration' clearly states the action (get) and resource (form fields configuration), making the purpose understandable. However, it doesn't differentiate this tool from sibling tools like 'get_app' or 'get_records' that also retrieve data, missing specific scope clarification.
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 versus alternatives. With siblings like 'get_app' or 'get_records' that might retrieve related data, there's no indication of context, prerequisites, or exclusions for selecting this specific tool.
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 carries full burden. It states what the tool does but doesn't disclose behavioral traits like whether this requires authentication, rate limits, response format, or if it's a read-only operation. For a tool with zero annotation coverage, this is a significant gap in behavioral disclosure.
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, efficient sentence that directly states the tool's purpose without any wasted words. It's appropriately sized for a zero-parameter documentation retrieval tool and is perfectly front-loaded with the essential information.
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 zero parameters, no annotations, and no output schema, the description provides adequate basic purpose but lacks important context. For a documentation retrieval tool, it should ideally describe the format of returned documentation (HTML, markdown, structured data) or any prerequisites. The description is complete enough for the simplest case but leaves gaps for practical implementation.
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?
The tool has zero parameters with 100% schema description coverage, so the baseline is 4. The description appropriately doesn't discuss parameters since none exist, and the schema already fully documents this. No additional parameter semantics are needed or provided.
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 tool's purpose with a specific verb ('Get') and resource ('comprehensive documentation about kintone query language syntax'). It distinguishes itself from siblings by focusing on documentation retrieval rather than data operations like get_records or update_record. However, it doesn't explicitly contrast with similar documentation tools since none exist among siblings.
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 implies usage when documentation about the query language is needed, but provides no explicit guidance on when to use this versus alternatives. There are no similar documentation tools among siblings, so no comparative guidance is possible. The context is clear but lacks explicit when/when-not instructions.
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 the full burden. It discloses the automatic pagination behavior, which is valuable context beyond the input schema. However, it doesn't cover other behavioral aspects like rate limits, authentication needs, error handling, or what the return format looks like (e.g., JSON structure).
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, efficient sentence that front-loads the core purpose ('Get all records') and adds a key behavioral detail ('handles pagination automatically'). There is no wasted wording, and it's appropriately sized for the tool's complexity.
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 no annotations and no output schema, the description provides basic completeness by stating the purpose and pagination behavior. However, for a tool that retrieves data, it lacks details on return values, error cases, or performance considerations, leaving gaps in contextual understanding.
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 schema already documents all three parameters (app, query, fields) with their types and optionality. The description adds no additional meaning about parameters beyond what's in the schema, such as examples or constraints, meeting the baseline for high coverage.
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 verb 'Get' and resource 'all records from a kintone app', making the purpose specific and understandable. However, it doesn't explicitly distinguish this tool from sibling tools like 'get_record' or 'get_records', which likely retrieve single or multiple records with different parameters or behaviors.
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 implies usage by mentioning 'handles pagination automatically', suggesting this tool is preferred for bulk retrieval without manual pagination. However, it lacks explicit guidance on when to use this versus alternatives like 'get_records' or 'get_record', and doesn't specify prerequisites or exclusions.
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:

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

Score Badge

Copy to your README.md:

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

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/r3-yamauchi/kintone-mcp-server-python3'

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