Loading ToolBench
MCP server for interacting with Kintone, a database service for storing and managing enterprise data
This server exposes 12 tools for Kintone database operations with mixed quality. Naming is generally clear and action-verb-based (list, read, create, update, delete, download, upload). However, descriptions are minimal (averaging 40-60 chars, well below the 194-char baseline), parameter documentation is sparse, schemas are present but lack depth, and critical output structure is not documented. Error handling is basic with generic recovery guidance. Security relies on environment variable injection for credentials (correct pattern), but no per-tool permission declarations or audit logging patterns are evident. Composition is reasonable, tools map 1:1 to Kintone API operations, but descriptions lack context on when to use each tool vs. alternatives. The server is STDIO-only, which caps protocol readiness at 50. Overall, this is a functional but below-average implementation suitable for basic automation but not production-grade agentic use.
Create a new record in a Kintone app
Create a comment on a Kintone record
Delete a record from a Kintone app
Download an attachment file from a Kintone record
Execute an action in a Kintone process management workflow
List all Kintone apps
Read information about a specific Kintone app
Read comments on a Kintone record
Tool descriptions are critically short (25 - 40 characters) and lack actionable context. Descriptions should state WHAT the tool does, WHEN to use it vs. similar tools, and what it returns. Example: 'List all Kintone apps' (23 chars) does not explain when to call this vs. readAppInfo, what fields are returned, or whether pagination is automatic.
Output schemas are not documented anywhere in the visible code. Tools return data but LLMs cannot see field names, types, or whether nested structures exist. For example, readRecords likely returns an array of records, but the response structure (field names, pagination metadata, total count) is undocumented. This forces agents to guess.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 46 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Read records from a Kintone app
Update the assignee in a Kintone process management workflow
Update a record in a Kintone app
Upload an attachment file to Kintone
Parameter descriptions are missing or generic. For example, 'record':{'type':'object','description':'Record fields and values'} does not tell the LLM what fields exist, which are required, or what data types they hold. Similarly, 'query' in readRecords is just 'Query string to filter records', no examples of valid syntax or format.
No error recovery guidance in tool descriptions. When a tool fails (e.g., appID not found, record locked due to process state), the LLM sees only an error message but no hint about what to try next. Error descriptions like 'kintone server returned an error: 404' offer no recovery path.
Destructive operations (deleteRecord) lack confirmation or dry-run capability. An agent could inadvertently delete records. No pattern to prevent this or to require user confirmation before executing.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) are present in the tool definitions. The Kintone spec indicates this server declares errorReporting=true but toolAnnotations=false, meaning agents cannot programmatically distinguish safe (read-only) operations from risky (write/delete) ones.
Process management tools (updateProcessManagementAssignee, executeProcessManagementAction) lack context about required fields, valid action names, and state transitions. An LLM cannot infer what actions are valid without discovering them first, no enum or constraint provided.
Pagination parameters (offset, limit) are present but no tool description explains the result set size, max limit, or how to detect end-of-results. The baseline pattern requires 'return a total count or next_cursor', unclear if these are provided.
No per-tool permission declarations. Tools like deleteRecord should document required scopes (e.g., 'write:records', 'delete:records'). Without this, agents cannot be configured with least-privilege access, and audit trails cannot track which permission was exercised.