Server has 9 well-structured tools with complete JSON schemas and Japanese descriptions. Strengths: all tools have explicit schemas with typed parameters and descriptions, parameter constraints (enums, limits), reasonable error handling. Weaknesses: descriptions are in Japanese (not English-optimized for LLM reasoning), several parameter descriptions lack detail on valid ranges and format constraints, no output schema documentation, missing tool annotations (readOnlyHint/destructiveHint/idempotentHint), no examples of error recovery guidance. Tool naming is generally clear (verb_noun pattern: create_, get_, update_, delete_, search_), but some lack dependency documentation. Security: API credentials injected via env vars (correct pattern). Composition: tools cleanly separated by concern (issues vs. search vs. analytics). Schema quality is above median but description quality and output documentation hold the score back.
Descriptions are in Japanese; MCP spec and LLM optimization baselines assume English descriptions. Non-English descriptions reduce LLM reasoning quality and prevent cross-language interop.
Add explicit output schemas for all 9 tools. For create/update/delete, document the returned issue object structure (id, title, status, owner, etc.). For searches, document per-item structure and totals. Use JSON Schema 'properties' with types and descriptions.
Translate all tool and parameter descriptions to English. Example: 'Create a new issue in a Pleasanter project. Returns the created issue object with id, title, and metadata. Use when planning new work items.'
Add tool annotations to schema: set readOnlyHint=true for all get_* and search_* tools, destructiveHint=true for delete_issue, idempotentHint=true for create_issue and update_issue (if idempotent by siteId+issueId).
Add error recovery guidance to descriptions. Example: 'If siteId is invalid, call pleasanter_list_sites() to discover available projects.' Add to create_issue, update_issue, delete_issue, and all search tools.
Document partial-failure handling for bulk_create_issues: specify whether response includes per-item status, which failed items are retryable, and how to retrieve IDs of successfully created issues.
Implement a confirmation mechanism for delete_issue: add an optional 'confirm' parameter (enum: ['yes']) or support a separate 'dry-run' mode. Require explicit 'confirm=yes' to prevent accidental deletions by agentic retry loops.
Add min/max constraints to schema for numeric parameters: limit offset ≥ 0, limit 1 - 1000, progressRate 0 - 100, workValue ≥ 0. Enforce these in the tool implementation and return validation errors with the constraint.
Tool annotations missing: no readOnlyHint for read tools, no destructiveHint for delete_issue, no idempotentHint for repeatable operations. This prevents agents from reasoning about safety and retry behavior.
No error recovery guidance in descriptions. Errors like 'siteId not found' lack next-step hints (e.g., 'Try list_sites() to discover valid siteIds'). LLMs get stuck on cryptic API errors.
Bulk create (pleasanter_bulk_create_issues) lacks partial-failure documentation. If 50/100 items fail, what is returned? How does the agent know which succeeded?
Delete operation (pleasanter_delete_issue) has no confirmation/dry-run pattern. Destructive operations should support explicit user approval before execution.
Result limits stated informally in descriptions ('最大100件', 'max 1000') but not enforced in schema. No documented enforcement that limit caps are actually applied in implementation.
Trend analysis tool (pleasanter_trend_analysis) lacks output schema specification. What structure does a 'completion' trend return? Counts? Percentages? Time series?
Parameter descriptions lack format/constraint details. E.g., 'startTime' says 'ISO 8601' but no length bounds or example. 'progressRate' says '0-100' in description but no minmax in schema.
pleasanter_create_issuepleasanter_update_issue
For trend_analysis, document output schema as JSON with fields like { period: string, analysisType: string, data: { label: string, value: number }[] }. Specify whether values are counts, percentages, or time-series data.
For multi_site_search, document grouping in output (e.g., { siteId: number, results: { id, title, ... }[] }[]). Clarify whether limit applies per-site or total.
Add status_summary output schema: { summary: { [groupByValue]: { count: number, completed: number, inProgress: number, ... } } }. Specify which counts are included for each groupBy option.
Add dependency hints to parameter descriptions. Example for update_issue: 'If you only have the issue title but not issueId, call pleasanter_get_issues(siteId, search=<title>) first.'
Document pagination behavior consistently: state that limit defaults to 50/100, offset starts at 0, and whether total count or has_more indicator is returned. Add these to all search/list responses.
For bulk_create_issues, clarify error behavior: do failed items cause the entire batch to fail, or are they skipped? Return a response like { successful: [...], failed: [{ item, error }] } to enable per-item retry logic.
Add examples to parameter descriptions for complex types like filters (advanced_search). Instead of free-form 'additionalProperties', document expected filter keys: 'filters: { Status: "100|200", ClassA: "バグ" }'.
Specify charset and length constraints in descriptions. E.g., 'title: max 200 characters, ASCII or UTF-8'. Add pattern constraints in schema where applicable.