Patch the same fields across multiple existing tasks (max 25). Use ONLY when the user explicitly requests a bulk operation across N items (e.g. "そのプロジェクトの未完了タスクを全部 archived_at にして"). For a single item use items_patch instead. detail_append is not supported here — pass detail to overwrite, or omit. This always requires explicit user confirmation.
Parameters 13 · input schema
| Arg | Type | Required |
|---|
| item_refs | array | yes |
| title | string | no |
| detail | string | no |
| due_date | string | no |
| due_time | string | no |
| start_date | string | no |
| priority | string | no |
| labels | array | no |
| archived_at | string | no |
| area_id | string | no |
| kind | string | no |
| estimate | string | no |
| sprint_id | string | no |
{
"type": "object",
"properties": {
"item_refs": {
"type": "array",
"items": {
"type": "string"
},
"description": "Array of 2-25 item refs like [\"#42\",\"WORK#43\"] (project prefix optional; bare \"#42\" resolves owner-wide)."
},
"title": {
"type": "string"
},
"detail": {
"type": "string",
"description": "Replaces detail of every target item."
},
"due_date": {
"type": "string",
"format": "date"
},
"due_time": {
"type": "string",
"description": "Time-of-day for the due date in HH:MM (JST, 24h). null to clear (all-day). Applies to every target item."
},
"start_date": {
"type": "string",
"format": "date"
},
"priority": {
"type": "string",
"enum": [
"urgent",
"high",
"normal",
"low"
]
},
"labels": {
"type": "array",
"items": {
"type": "string"
}
},
"archived_at": {
"type": "string",
"description": "ISO 8601 datetime to archive every item. Pass null to unarchive. Omit to leave unchanged."
},
"area_id": {
"type": "string",
"description": "Area id to assign to every target item (must belong to each item's own project). Pass null to clear the area on every item. Omit to leave unchanged. For path-based single-item assignment prefer project_areas_assign_item."
},
"kind": {
"type": "string",
"description": "Work-item kind key to set on every target item (lowercase / digits / - _, e.g. \"story\", \"bug\"). Pass null to clear the kind on every item. Omit to leave unchanged. Not validated against each project's custom kinds — built-in kinds always work."
},
"estimate": {
"type": "string",
"description": "Estimate value to set on every target item (must match each project's estimate unit, e.g. numeric for sp/hours). Pass null to clear the estimate on every item. Omit to leave unchanged."
},
"sprint_id": {
"type": "string",
"description": "Sprint id to assign every target item to (must belong to each item's own project). Pass null to remove every item from its (non-closed) sprint. Omit to leave unchanged."
}
},
"required": [
"item_refs"
]
}
Dry-run preview for items_bulk_patch. Accepts the SAME args as items_bulk_patch and returns, for each item_ref, the current value vs. the value after applying the patch, plus the list of fields that would change. Read-only — no write happens. Use this BEFORE items_bulk_patch to show the user exactly what will change across N items, and to catch ownership / not-found errors per ref before requesting confirmation. Up to 25 items per call.
Parameters 12 · input schema
| Arg | Type | Required |
|---|
| item_refs | array | yes |
| title | string | no |
| detail | string | no |
| due_date | string | no |
| due_time | string | no |
| start_date | string | no |
| priority | string | no |
| labels | array | no |
| archived_at | string | no |
| kind | string | no |
| estimate | string | no |
| sprint_id | string | no |
{
"type": "object",
"properties": {
"item_refs": {
"type": "array",
"items": {
"type": "string"
},
"description": "Array of 2-25 item refs like [\"#42\",\"WORK#43\"] (project prefix optional; bare \"#42\" resolves owner-wide)."
},
"title": {
"type": "string"
},
"detail": {
"type": "string",
"description": "Replaces detail of every target item."
},
"due_date": {
"type": "string",
"format": "date"
},
"due_time": {
"type": "string",
"description": "HH:MM in JST (24h). null clears time (back to all-day)."
},
"start_date": {
"type": "string",
"format": "date"
},
"priority": {
"type": "string"
},
"labels": {
"type": "array",
"items": {
"type": "string"
}
},
"archived_at": {
"type": "string",
"description": "ISO 8601 datetime to archive. null to unarchive. Omit to leave unchanged."
},
"kind": {
"type": "string",
"description": "Work-item kind key (lowercase). null clears. Omit to leave unchanged."
},
"estimate": {
"type": "string",
"description": "Estimate value (must match project unit). null clears. Omit to leave unchanged."
},
"sprint_id": {
"type": "string",
"description": "Sprint id to assign. null removes from sprint. Omit to leave unchanged."
}
},
"required": [
"item_refs"
]
}
Mark an existing task as completed. This ALWAYS transitions to the single workflow state marked "default for close" (typically "Done") — it does NOT let you pick which closed state. Use this ONLY for a plain completion: the user clearly says "完了", "done", "終わった", "finished" (or a bare "クローズ" / "閉じて" that means "done"). For a close with a SPECIFIC terminal state — "重複" / "duplicate" → the "Duplicated" state, "却下" / "rejected" / "やめる" / "WONT-FIX" → the "Rejected" state, or any other named closed state — do NOT use this; call workflow_states_list to get that state id and move with items_move_state (those terminal states are closed but have is_default_for_close=false, so items_complete would wrongly land them in "Done"). Prefer this over manually setting status via items_patch — items_patch does NOT change workflow state.
Parameters 2 · input schema
| Arg | Type | Required |
|---|
| item_ref | string | yes |
| reason | string | no |
{
"type": "object",
"properties": {
"item_ref": {
"type": "string",
"description": "Item reference like \"#42\" (owner-wide number, prefix optional) or \"WORK#42\". Bare \"#42\" resolves the item in any project — no project prefix needed."
},
"reason": {
"type": "string",
"description": "Optional reason for completion."
}
},
"required": [
"item_ref"
]
}
Fetch a task and its full surrounding context (attachments metadata, discussions, pending reminders, relations) in a single call. Use this as the FIRST read when the user references a specific task and you need to understand it before responding or proposing changes (e.g. "INBOX#121 って何？" / "このバグ進捗どう？"). Returns metadata for attachments — use attachments_download to fetch image / PDF binary. Read-only. Best-effort: if a sub-section fails (e.g. relations), the main item is still returned and the failure is reported under `errors`.
Parameters 2 · input schema
| Arg | Type | Required |
|---|
| item_ref | string | yes |
| include | array | no |
{
"type": "object",
"properties": {
"item_ref": {
"type": "string",
"description": "Item reference like \"#42\" (owner-wide number, prefix optional) or \"WORK#42\". Bare \"#42\" resolves the item in any project — no project prefix needed."
},
"include": {
"type": "array",
"items": {
"type": "string",
"enum": [
"attachments",
"discussions",
"reminders",
"relations"
]
},
"description": "Sections to include. Default: all of [\"attachments\",\"discussions\",\"reminders\",\"relations\"]. Pass a subset to reduce payload."
}
},
"required": [
"item_ref"
]
}
Create a new task in the user's task management system. project_key is REQUIRED — pass the project to create the task in. There is NO implicit default: to create in the user's Inbox, pass project_key:"INBOX" explicitly. Use this when the user clearly intends to track a new actionable item; do NOT use it for things they only mention casually or hypothetically. For due time-of-day (e.g. "明日 9:00 まで"), pass due_time as "HH:MM" in JST; omit due_time for all-day tasks. Pass `kind` to classify the item as a work-item kind — built-in kinds are epic / story / task / bug / chore (use these directly, no lookup needed). Projects with board profiles enabled may define additional custom kinds; discover those via item_kinds_list. FIELD POLICY: a kind may declare a `field_policy` (see item_kinds_list) saying which agile fields it uses. Honor it — e.g. a Nano Epic does NOT use estimate / sprint (assign it a version instead); a Chore uses none. Do not set fields the kind does not use. Pass `parent` (an item_ref like "WORK#10") to link this new item under a parent (e.g. a Story under an Epic). Pass `version` (version name) to assign to a roadmap version at creation time. Pass `sprint` (sprint name or path like "Q3/Sprint 1") to assign to a sprint at creation time. Pass `area_path` (e.g. "API/Auth") to assign to a project area at creation time. When `parent` is given and version/sprint/area_path are omitted, the new item inherits the parent's version/sprint/area automatically. Returns `{ itemId, ref }`. Use `ref` (e.g. `INBOX#178`) for any user-facing reference; `itemId` is an internal UUID for relation / FK lookups only.
Parameters 13 · input schema
| Arg | Type | Required |
|---|
| project_key | string | yes |
| title | string | yes |
| detail | string | no |
| due_date | string | no |
| due_time | string | no |
| start_date | string | no |
| priority | string | no |
| labels | array | no |
| kind | string | no |
| parent | string | no |
| version | string | no |
| sprint | string | no |
| area_path | string | no |
{
"type": "object",
"properties": {
"project_key": {
"type": "string",
"description": "Required. Existing project key to create the task in. Pass \"INBOX\" for the Inbox project (no implicit default)."
},
"title": {
"type": "string",
"description": "Task title (1-200 chars)."
},
"detail": {
"type": "string",
"description": "Optional task detail/description (Markdown, up to 32000 chars/call). For longer content, create first then append in chunks via items_patch detail_append."
},
"due_date": {
"type": "string",
"description": "Due date in YYYY-MM-DD (JST).",
"format": "date"
},
"due_time": {
"type": "string",
"description": "Optional time-of-day for the due date in HH:MM (JST, 24h). Requires due_date. Omit to keep the task all-day."
},
"start_date": {
"type": "string",
"description": "Start date in YYYY-MM-DD.",
"format": "date"
},
"priority": {
"type": "string",
"enum": [
"urgent",
"high",
"normal",
"low"
],
"description": "Optional priority."
},
"labels": {
"type": "array",
"items": {
"type": "string"
},
"description": "Optional labels."
},
"kind": {
"type": "string",
"enum": [
"epic",
"story",
"task",
"bug",
"chore"
],
"description": "Optional work-item kind. Built-in kinds: epic / story / task / bug / chore — pick one of these directly (no lookup needed). Projects with board profiles may define custom kinds (lowercase / digits / - _); discover them via item_kinds_list and they are also accepted here."
},
"parent": {
"type": "string",
"description": "Optional parent item reference (e.g. \"WORK#10\") to link this item under as a child."
},
"version": {
"type": "string",
"description": "Optional version name to assign this item to at creation time (e.g. \"v2.0\"). Must exist in the project. If parent is given and version is omitted, the parent's version is inherited."
},
"sprint": {
"type": "string",
"description": "Optional sprint name or path to assign this item to at creation time (e.g. \"Sprint 3\" or \"Q3/Sprint 1\"). Must exist and not be closed. If parent is given and sprint is omitted, the parent's active/planned sprint is inherited."
},
"area_path": {
"type": "string",
"description": "Optional area path within the project to assign this item to (e.g. \"API/Auth\"). Must exist and not be archived. Pass null to skip inheritance when a parent is set. If parent is given and area_path is omitted, the parent's area is inherited."
}
},
"required": [
"project_key",
"title"
]
}
Get full details of a specific item (task / note / event / task_template) by its ref (e.g. "#42", "INBOX#3", or "WORK#42"; the project prefix is optional — bare "#42" works). Use this in two main situations: (1) READ-FOR-ANSWER — after `tasks_list` / `notes_list` / `events_list` returned a matching ref but the user's question concerns the body (本文 / detail / 詳細 / 例年 / 経緯 / 人数 / ノート内容); list tools do not return `detail`, so you MUST call `items_get` here before answering. (2) PRE-UPDATE — to read the current title, detail, due_date, status, etc. before proposing changes. For richer context (attachments + discussions + reminders + relations in one call), prefer `items_context_get` instead. The returned `type` field tells you which kind of item this is — use it to decide which follow-up tool to call (tasks_* / notes_* / events_* / templates_*). When present, `series_links` lists the custom numbering series this item belongs to: each has series_key, series_label, and display_ref (e.g. "INV-0012") — or display_ref=null for a number-less link (membership only). Use series_key with custom_number_assign / custom_number_unassign. When present, `detail_summary` is an auto-generated summary of the item's confirmed discussions up to `detail_summary_updated_at`; it is separate from the user-authored `detail` body (which is never rewritten). To get the latest context, combine `detail_summary` with any discussions posted AFTER `detail_summary_updated_at` (read those via discussions_list). When `detail_summary` is absent, read the discussions directly. The response always includes `detail_length` (total character count of the detail body). For a very large body, fetch it in chunks: pass `detail_offset` (start character, default 0) and `detail_max_chars` (chunk size); when the returned slice is partial, `detail_truncated` is true and `detail_next_offset` is the character offset to pass back as `detail_offset` for the next chunk. Omitting both returns the full body (default, unchanged). To locate a specific string inside a large body, prefer items_grep.
Parameters 3 · input schema
| Arg | Type | Required |
|---|
| item_ref | string | yes |
| detail_offset | number | no |
| detail_max_chars | number | no |
{
"type": "object",
"properties": {
"item_ref": {
"type": "string",
"description": "Item reference like \"#42\" (owner-wide number, prefix optional) or \"WORK#42\". Bare \"#42\" resolves the item in any project — no project prefix needed."
},
"detail_offset": {
"type": "number",
"description": "Optional. Start character offset into the detail body for windowed reads of a large detail. Default 0 (start of body). Combine with detail_max_chars to page through a long body using the detail_next_offset returned in the response."
},
"detail_max_chars": {
"type": "number",
"description": "Optional. Max number of characters of detail to return starting at detail_offset. Omit to return the full remaining body (default = full detail, backward compatible). When the slice is partial, the response sets detail_truncated=true and detail_next_offset for the next chunk."
}
},
"required": [
"item_ref"
]
}
EXACT lexical / regex search across the user's items — the precision counterpart to `query`. Use `items_grep` for: exact string / identifier / error-message search, finding ALL occurrences, duplicate-issue checks, and ABSENCE PROOF ("is this string anywhere?"). It searches item title / detail / labels / comments / custom field values. There is NO semantic fallback and results are NOT ranked — they are exhaustive and deterministic. TRUST 0 hits as proof of absence ONLY when the response has `exhaustive=true` AND `truncated=false`. If `exhaustive=false` (candidate cap / timeout / regex reject), the result is incomplete — narrow with `filters`. Contrast with `query`: use `query` for discovery / cross-type / semantic / ranked recall (its 0 hits are NOT proof of absence). pattern is a literal substring by default; set regex=true for a JS RegExp. `filters` is a filter-ONLY DSL (its free text is ignored — put search text in `pattern`) and shares the Items View vocabulary: project / type / system_status / priority / label / due / area / sprint / version / agile_kind / cf:<field_key>. Note type = item type (task|note), agile_kind = work-item kind (story|bug|...). Example (fictional): pattern="ACME_LEGACY_FLAG", filters="agile_kind:bug area:Platform/API". Returns grouped-by-item results with field-level locators (comment_id / field_key) so you rarely need a follow-up items_get.
Parameters 11 · input schema
| Arg | Type | Required |
|---|
| pattern | string | yes |
| regex | boolean | no |
| ignore_case | boolean | no |
| fields | array | no |
| custom_field_keys | array | no |
| filters | string | no |
| context_chars | number | no |
| count_only | boolean | no |
| limit_items | number | no |
| max_snippets_per_item | number | no |
| cursor | string | no |
{
"type": "object",
"properties": {
"pattern": {
"type": "string",
"description": "Search text. Literal substring by default; a JS RegExp when regex=true."
},
"regex": {
"type": "boolean",
"description": "Interpret pattern as a regular expression (JS RegExp)."
},
"ignore_case": {
"type": "boolean",
"description": "Case-insensitive match."
},
"fields": {
"type": "array",
"items": {
"type": "string",
"enum": [
"title",
"detail",
"labels",
"comments.body",
"comments.author",
"custom.value",
"custom.key"
]
},
"description": "Fields to search. Omit for content default (title/detail/labels/comments.body/custom.value). comments.author and custom.key are opt-in (not indexed, force a scan)."
},
"custom_field_keys": {
"type": "array",
"items": {
"type": "string"
},
"description": "Restrict custom field search to these field_keys."
},
"filters": {
"type": "string",
"description": "Filter-only DSL (e.g. \"type:note priority:high area:Platform/API agile_kind:bug cf:severity\"). Free text here is ignored — use `pattern` for the search text."
},
"context_chars": {
"type": "number",
"description": "Snippet context characters around a match (default 80)."
},
"count_only": {
"type": "boolean",
"description": "Return per-item match counts without snippets/locators."
},
"limit_items": {
"type": "number",
"description": "Max items per page (default 50)."
},
"max_snippets_per_item": {
"type": "number",
"description": "Max snippets emitted per item (default 3)."
},
"cursor": {
"type": "string",
"description": "Pagination cursor from a prior response."
}
},
"required": [
"pattern"
]
}
Move an existing task to a specific workflow state (status). The `status_definition_id` is a workflow state id — get it from workflow_states_list (the `id` field). Always derive the project from the item and call workflow_states_list(project_key) so you pick a state from THIS item's workflow; do not reuse a state id from another workflow. Use this ONLY when the user actually asks to CHANGE / MOVE an item to a state — imperatives like "レビュー中にして" / "ブロック中にして" / "検収待ちにする" / "未着手に戻す" / "再オープン". A bare MENTION, QUESTION, or CORRECTION about a status name is NOT a move request — do NOT call this. Examples that are READS, not moves: clarifying which status exists ("Reviewing って言うステータスのはず"), or asking which items are in a state ("レビュー待ちのは?" / "レビュー中のタスク"). For those, answer with a read — use the `query` tool with `status:<state name>` — and do not propose a state change. For plain completion intent ("完了" / "done" / "終わった" / "クローズ"), prefer items_complete instead (it targets the default-for-close state without needing an id). items_patch does NOT change workflow state; items_patch(archived_at) is only for archive/unarchive, NOT for reopening a workflow state. For a vague "次にして" / "進めて" (advance) without a named state, first call workflow_transitions_list(from_state_id) to find the allowed next state, then move there.
Parameters 3 · input schema
| Arg | Type | Required |
|---|
| item_ref | string | yes |
| status_definition_id | string | yes |
| reason | string | no |
{
"type": "object",
"properties": {
"item_ref": {
"type": "string",
"description": "Item reference like \"#42\" (owner-wide number, prefix optional) or \"WORK#42\". Bare \"#42\" resolves the item in any project — no project prefix needed."
},
"status_definition_id": {
"type": "string",
"description": "Target workflow state id (= workflow_states_list `id`). Must belong to this item's project workflow."
},
"reason": {
"type": "string",
"description": "Optional reason for the state change."
}
},
"required": [
"item_ref",
"status_definition_id"
]
}
Patch attributes of an existing task (title / detail / due_date / due_time / start_date / priority / labels). Use only for items in the current thread context (pinned items or items the user explicitly mentioned by ref). Do NOT use this to change workflow state — use items_complete for completion, items_move_state for any other workflow state (e.g. "レビュー中"), or set the `archived_at` field via items_patch for archiving. To APPEND text to an existing detail (e.g. "追記して"), use detail_append instead of detail. To EDIT specific parts of an existing detail (e.g. "ここを直して"), use detail_edits with find/replace pairs. detail replaces the entire detail field; detail_append adds text to the end; detail_edits patches specific substrings. Only one of detail/detail_append/detail_edits can be used per call. For time-of-day on the due date (e.g. "9 時にして"), pass due_time as "HH:MM" in JST. Pass due_time=null to clear the time component (back to all-day). When changing due_date alone, the existing due_time is reset to null unless you pass due_time explicitly. Common state-transition vocabulary: "完了" / "done" / "終わった" / "クローズ" → use items_complete (NOT this tool). "レビュー中" / "ブロック中" / any named workflow state, and "再オープン" / "未完了に戻す" → use items_move_state (NOT this tool — it changes workflow state). "アーカイブ解除" / unarchive → items_patch(archived_at=null). "重複" / "duplicate" → if the workflow has a matching state use items_move_state; otherwise items_patch(labels=[...existing, "duplicate"]) — read labels first via items_get. "後回し" / "Someday" → items_patch(due_date=null). "延期" / "リスケ" → items_patch(due_date=<new YYYY-MM-DD>). "archive" / "アーカイブ" → items_patch(archived_at=<ISO 8601 now>). To set or change the PARENT of this item (e.g. "親を WORK#10 にして" / "Story を別の Epic 配下に移して"), pass `parent` as the new parent item_ref; pass parent=null to detach (make it top-level). Re-parenting replaces the existing parent (single-parent). For re-pointing MANY items at once, prefer relations_reassign. Note: unlike items_create, re-parenting via items_patch does NOT inherit the new parent's version/sprint/area.
Parameters 12 · input schema
| Arg | Type | Required |
|---|
| item_ref | string | yes |
| title | string | no |
| detail | string | no |
| detail_append | string | no |
| detail_edits | array | no |
| due_date | string | no |
| due_time | string | no |
| start_date | string | no |
| priority | string | no |
| labels | array | no |
| archived_at | string | no |
| parent | string | no |
{
"type": "object",
"properties": {
"item_ref": {
"type": "string",
"description": "Item reference like \"#42\" (owner-wide number, prefix optional) or \"WORK#42\". Bare \"#42\" resolves the item in any project — no project prefix needed."
},
"title": {
"type": "string"
},
"detail": {
"type": "string",
"description": "Replaces the entire detail/description (up to 32000 chars/call). Use detail_append to add text instead."
},
"detail_append": {
"type": "string",
"description": "Text to append to the existing detail (詳細欄), up to 32000 chars/call. Use this when the user says \"追記\" or \"詳細追加\", and to add long content in chunks (total detail is capped at 100000 chars)."
},
"detail_edits": {
"type": "array",
"items": {
"type": "object",
"properties": {
"find": {
"type": "string",
"description": "Exact substring to find in the current detail."
},
"replace": {
"type": "string",
"description": "Replacement text."
},
"occurrence": {
"type": "string",
"enum": [
"first",
"all"
],
"description": "Which occurrences to replace. Default: first."
}
},
"required": [
"find",
"replace"
]
},
"description": "Partial edit of detail by find-and-replace. Use when the user wants to change specific parts of the detail without rewriting the whole text. Each edit is applied in order; if any find string is not found, the entire operation is aborted (all-or-nothing). Mutually exclusive with detail and detail_append."
},
"due_date": {
"type": "string",
"format": "date",
"description": "Due date in YYYY-MM-DD (JST). null to clear."
},
"due_time": {
"type": "string",
"description": "Time-of-day for the due date in HH:MM (JST, 24h). null to clear time (back to all-day). Note: changing due_date alone resets due_time to null unless you also pass due_time."
},
"start_date": {
"type": "string",
"format": "date"
},
"priority": {
"type": "string",
"enum": [
"urgent",
"high",
"normal",
"low"
]
},
"labels": {
"type": "array",
"items": {
"type": "string"
}
},
"archived_at": {
"type": "string",
"description": "ISO 8601 datetime to archive the task. Pass null to unarchive. Omit to leave unchanged."
},
"parent": {
"type": "string",
"description": "New parent item reference (e.g. \"WORK#10\") to set/re-parent this item under. Replaces any existing parent (single-parent). Pass null to detach (top-level). Omit to leave unchanged. A descendant cannot be set as parent (cycle is rejected). Does NOT inherit the parent's version/sprint/area."
}
},
"required": [
"item_ref"
]
}
Set or clear custom field values on a task. Identify the task by ref (e.g. "WORK#42" or "#42") and pass `custom_fields` as a map of field_key → value (discover field_keys via project_custom_fields_list). v1.0 stores text values; pass an empty string or null to CLEAR a field. Unknown or deactivated field_keys are rejected. The field must belong to the task's own project. This only touches custom field values — use items_patch for built-in attributes.
Parameters 2 · input schema
| Arg | Type | Required |
|---|
| item_ref | string | yes |
| custom_fields | object | yes |
{
"type": "object",
"properties": {
"item_ref": {
"type": "string",
"description": "Item ref, e.g. \"WORK#42\" or \"#42\"."
},
"custom_fields": {
"type": "object",
"description": "Map of field_key → value (text in v1.0). Empty string or null clears the field. field_keys come from project_custom_fields_list."
}
},
"required": [
"item_ref",
"custom_fields"
]
}
Trigger background regeneration of an item's auto-summary (detail_summary) from its confirmed discussions. This is asynchronous: it returns immediately after enqueuing, and the refreshed summary appears later on the item (re-read the item with items_get to see detail_summary). The item's main detail body is NOT modified. Owner-only and opt-in: it works only when the owner has enabled auto-summarization. Use when the user explicitly asks to summarize / re-summarize / refresh the summary of a task from its discussion history.
Parameters 1 · input schema
| Arg | Type | Required |
|---|
| item_ref | string | yes |
{
"type": "object",
"properties": {
"item_ref": {
"type": "string",
"description": "Item reference like \"#42\" (owner-wide number, prefix optional) or \"WORK#42\". Bare \"#42\" resolves the item in any project — no project prefix needed."
}
},
"required": [
"item_ref"
]
}
Search and list the user's tasks with optional filters. Use this to find tasks by description before patching/completing them, or to answer questions about a task. Returns up to `limit` tasks with their ref, title, due_date, due_time (HH:MM JST or null for all-day), priority, status, `detail`, and `detail_truncated`. BODY: the response now includes `detail` (本文 / body / notes). Short bodies are returned in full. Long bodies are condensed into a snippet — centered around the `title_contains` keyword if it appears in the body, otherwise the head. When `detail_truncated: false`, you have the entire body — answer directly from it. When `detail_truncated: true`, the body was condensed; if the snippet does NOT contain the answer the user asked about (本文全体 / 詳細 / 例年 / 経緯 / 議事録 / participant lists / embedded numbers may live outside the snippet), you MUST follow up with `items_get` using the returned `ref` to read the full body BEFORE answering. Replying "情報はありませんでした" while the snippet is truncated and might be missing the answer is a contract violation. Recurring task templates (the generators themselves) are not returned here — use `task_templates_list` for those. For memos use `notes_list`, for calendar events use `events_list`. FINDING A TASK BY NAME: `title_contains` is a CONTIGUOUS substring (LIKE) match, so passing the user's whole sentence (e.g. "アクメ社から5万円返金してもらった") will NOT match a task titled "アクメ社に5万円返金依頼する" — the full phrase is not a contiguous substring. When the user references a task in natural language, decompose it and pass only the MOST DISTINCTIVE SHORT keyword (a proper noun / entity, e.g. "アクメ社"). If 0 results, shorten further, or use the `query` tool with mode "semantic" for meaning-based matching. Do not give up after one full-sentence miss. FILTERING BY WORKFLOW STATE (status / column): the `status` arg and `is:open|closed` here only express open vs closed — they CANNOT filter by a named workflow state (the kanban column, e.g. "Reviewing" / "検収待ち"). When the user asks which items are in a named state (e.g. 「レビュー待ちのは?」「レビュー中のタスク」), do NOT search the status word as a title with `title_contains`. Instead map the user's phrase to the actual workflow state name (from me_overview `vocabulary.statuses` / workflow_states_list, or the per-card state in the current-screen board/list context) and use the `query` tool with `status:<that name>` (e.g. `query status:reviewing is:open`). You may also pass a DSL query via `q`. These are the supported axes on this path — the canonical values below are authoritative, so build the query from them rather than guessing syntax from memory or from prior items:
- `is:` 状態 — open / done / closed / overdue / wip / pending / unscheduled / archived / mine / unestimated / estimated
- `priority:` 優先度 — urgent / high / normal / low
- `due:` 期日 — today / tomorrow / yesterday / overdue_today / this_week / anytime / someday / YYYY-MM-DD / 範囲(..) / 比較(>=,<=)
- `completed:` 完了日 — today / tomorrow / yesterday / overdue_today / this_week / anytime / someday / YYYY-MM-DD / 範囲(..) / 比較(>=,<=)
- `status:` ステータス — カスタムステータス名 (例: status:"In Review")
- `project:` プロジェクト — プロジェクトキー / ID
- `sprint:` スプリント — @current / @next / @none
- `agile_kind:` 作業種別 — epic / story / task / bug / chore / @none
- `estimate:` 見積もり — 見積もり値 (estimate:>3 / estimate:1..5 / estimate:@none で未見積もり)。Items ビュー専用。
- `area:` 領域 — 領域パス (例: area:API/Auth。カンマで OR / area:@none で未分類)
- `version:` バージョン — バージョン (version:バージョン名 / version:@none で未計画)。Items ビュー専用。
- `parent:` 親 — 親アイテム (parent:#158 で #158 の直下の子)。Items ビュー専用。
- `epic:` 配下（推移） — 配下すべて (epic:#158 で #158 の子孫を再帰的に)。Items ビュー専用。
- `cf:` カスタムフィールド — カスタムフィールド (cf:<field_key>:<value>)。Board Queries / Items ビュー専用。
NEGATION: prefix any axis with `-` to exclude (e.g. `-area:Product/Search`, `-agile_kind:epic`, `-epic:#158`). PRESENCE: `has:X` = items that HAVE attribute X; `-has:X` = items MISSING it, where X ∈ {due, sprint, area, version, estimate, agile_kind, parent, assignee}. Common "unassigned/empty" queries: スプリント未割当(バックログ)=`-has:sprint`, 期日なし/未設定=`-has:due` (or `due:none`), 領域未分類=`-has:area`, 未計画=`-has:version`, 未見積もり=`is:unestimated` (= `-has:estimate`), 担当者なし=`-has:assignee`. DUE NUANCE: `due:none` / `due:anytime` mean the task has NO due date set; `due:someday` means it is explicitly filed as 「いつかやる」(someday). These are DIFFERENT — do not conflate them. When the user says 「期日なし」/「期日未設定」 use `-has:due`/`due:none`, NOT `due:someday`. Do NOT express "no due date" with `due_before`/`due_after` — those cannot match a NULL due date and will silently miss every undated task. HIERARCHY: `parent:<ref>` matches DIRECT children (one level); `epic:<ref>` matches the WHOLE subtree (transitive, grandchildren included). `<ref>` is an item ref like `#158` / `INBOX#158` / `158` (e.g. `epic:#158 is:open`, `parent:#158`). DSL filters are merged with the explicit args (explicit args take precedence). COMPLETION DATE: to find or count tasks the user actually **completed/finished** on a date, use the `completed:` axis in `q` (e.g. `completed:today`, `completed:>=2026-06-01`, `completed:2026-05-01..2026-05-31`). It filters by when the task was finished (completion history), which is DIFFERENT from `due:` (the deadline). NEVER answer "how many did I finish today / 今日完了したタスク" with `due:today` — a task due today may be unfinished, and a task finished today may have had a different (or no) due date. Use `completed:today` for completion questions. PAGINATION: the response includes `has_more: boolean`. If `has_more` is true, the returned slice is incomplete — narrow the filter (`q`, `status`, `project_key`, `due_before` / `due_after`, `title_contains`) and re-query, or warn the user that the listing is partial. Do not claim the returned set is exhaustive while `has_more` is true. SORTING: pass `sort` + `order` to control ordering. To get the OLDEST task(s) by registration date (「一番古いタスク」), use `sort:"created"`, `order:"asc"`, `limit:1`. For the most recently created use `sort:"created"` with `order:"desc"`. `sort:"updated"` orders by last-modified time. Omit `sort` for the default due-date ordering. Do NOT try to infer creation order from ref numbers.
Parameters 15 · input schema
| Arg | Type | Required |
|---|
| project_key | string | no |
| status | string | no |
| due_before | string | no |
| due_after | string | no |
| title_contains | string | no |
| q | string | no |
| sort | string | no |
| order | string | no |
| limit | number | no |
| include_custom_fields | boolean | no |
| include_relations | boolean | no |
| include_agile | boolean | no |
| include_area | boolean | no |
| include_attachments | boolean | no |
| include_custom_numbers | boolean | no |
{
"type": "object",
"properties": {
"project_key": {
"type": "string",
"description": "Filter by project key (e.g. \"WORK\"). Omit for all projects."
},
"status": {
"type": "string",
"enum": [
"open",
"closed"
],
"description": "Filter by open/closed status. Omit for all."
},
"due_before": {
"type": "string",
"format": "date",
"description": "Return tasks due on or before this date (YYYY-MM-DD)."
},
"due_after": {
"type": "string",
"format": "date",
"description": "Return tasks due on or after this date (YYYY-MM-DD)."
},
"title_contains": {
"type": "string",
"description": "Filter tasks whose title contains this string (case-insensitive)."
},
"q": {
"type": "string",
"description": "DSL query string (e.g. \"is:open priority:p1 due:>=today\"). Merged with explicit args."
},
"sort": {
"type": "string",
"enum": [
"due",
"created",
"updated",
"priority"
],
"description": "Order field. \"due\" (default) = by due date; \"created\" = by registration date; \"updated\" = by last-modified; \"priority\" = by priority. For 「一番古いタスク」 use \"created\" with order \"asc\"."
},
"order": {
"type": "string",
"enum": [
"asc",
"desc"
],
"description": "Direction for `sort` (applies to created/updated). \"asc\" = oldest first, \"desc\" = newest first. Default \"desc\". Ignored for due/priority."
},
"limit": {
"type": "number",
"description": "Max results (1-20, default 10)."
},
"include_custom_fields": {
"type": "boolean",
"description": "Opt-in: when true, each returned task includes its project-defined custom field values (`custom_fields`: array of { field_key, label, field_type, value }). Default false (omitted) to keep the response lightweight. Use this when the user asks about a custom field (e.g. a per-project \"priority_rank\" / \"ADR\" field) so you can answer without a follow-up items_get per task."
},
"include_relations": {
"type": "boolean",
"description": "Opt-in: include the parent link (parent_ref / parent_title / parent_kind) so you can see an item's hierarchy without a follow-up call. Default false (omitted)."
},
"include_agile": {
"type": "boolean",
"description": "Opt-in: include agile placement (sprint_id / sprint_name / version_id / version_name / resolved_field_policy). Note estimate / agile_kind are already always included. Default false (omitted)."
},
"include_area": {
"type": "boolean",
"description": "Opt-in: include the assigned area (area_id / area_path, e.g. \"Product/Search\"). Default false (omitted)."
},
"include_attachments": {
"type": "boolean",
"description": "Opt-in: include attachment_count (number of non-deleted attachments). Default false (omitted)."
},
"include_custom_numbers": {
"type": "boolean",
"description": "Opt-in: include custom series refs (custom_numbers: array of { series_key, display_ref, number }, e.g. \"INV-0012\"). Default false (omitted)."
}
}
}