list_tasks gave you every task in a list as a read — you could count them, loop them, filter them. A read never changes anything. Today the action writes. What does that shift feel like?
list_tasks was safe to run ten times in a row. A write is different — if I call it twice I get two tasks. I need to be more deliberate.
Exactly the right instinct. GOOGLETASKS_INSERT_TASK creates a task in your real Google Tasks list — it shows up immediately in the app. Here's the call:
result = toolset.execute_action(Action.GOOGLETASKS_INSERT_TASK, {
"tasklist": list_id,
"title": title,
"notes": notes,
})
Three keys — tasklist, title, notes. But the function signature says list_id, not tasklist. Why does the action want a different name?
Composio maps to the Google Tasks API field names, not yours. Your function accepts list_id on the outside — clean, human-readable — and translates it to tasklist inside the params dict. Same pattern as recipient_email in GMAIL_SEND_EMAIL. Your callers never see the API's vocabulary.
So every action has its own internal key names and I just look them up once. After that it's just a translation layer in the params dict. Calendar had calendar_id, Tasks has tasklist.
You just wrote the mental model most people take a week to form, and you did it unprompted. That's week 2 clicking into place. Here's the full function — note the print before the return, so you can see the title confirm in your terminal:
def add_task(list_id: str, title: str, notes: str) -> dict:
result = toolset.execute_action(Action.GOOGLETASKS_INSERT_TASK, {
"tasklist": list_id,
"title": title,
"notes": notes,
})
print(f"Inserted task '{title}'")
return result
And in a real workflow I'd confirm the task details before inserting — not just fire it silently.
Correct. In production you'd show the title and notes, ask for approval, then call add_task. Tests target @default — your own list, not a colleague's project. The next step is updating tasks that already exist: GOOGLETASKS_UPDATE_TASK takes a task ID, and you now have the tools to read those IDs from list_tasks.
GOOGLETASKS_INSERT_TASK creates a task immediately in your Google Tasks account. The tasklist param takes a list ID — use @default for your primary list.
| Your arg | Composio key |
|---|---|
list_id | tasklist |
title | title |
notes | notes |
Returns the created task dict directly — includes the new task's id, title, notes, and status. Use that id with GOOGLETASKS_UPDATE_TASK to modify it later.
Always confirm task details before inserting in real workflows. Tests use @default — your own list only.
list_tasks gave you every task in a list as a read — you could count them, loop them, filter them. A read never changes anything. Today the action writes. What does that shift feel like?
list_tasks was safe to run ten times in a row. A write is different — if I call it twice I get two tasks. I need to be more deliberate.
Exactly the right instinct. GOOGLETASKS_INSERT_TASK creates a task in your real Google Tasks list — it shows up immediately in the app. Here's the call:
result = toolset.execute_action(Action.GOOGLETASKS_INSERT_TASK, {
"tasklist": list_id,
"title": title,
"notes": notes,
})Three keys — tasklist, title, notes. But the function signature says list_id, not tasklist. Why does the action want a different name?
Composio maps to the Google Tasks API field names, not yours. Your function accepts list_id on the outside — clean, human-readable — and translates it to tasklist inside the params dict. Same pattern as recipient_email in GMAIL_SEND_EMAIL. Your callers never see the API's vocabulary.
So every action has its own internal key names and I just look them up once. After that it's just a translation layer in the params dict. Calendar had calendar_id, Tasks has tasklist.
You just wrote the mental model most people take a week to form, and you did it unprompted. That's week 2 clicking into place. Here's the full function — note the print before the return, so you can see the title confirm in your terminal:
def add_task(list_id: str, title: str, notes: str) -> dict:
result = toolset.execute_action(Action.GOOGLETASKS_INSERT_TASK, {
"tasklist": list_id,
"title": title,
"notes": notes,
})
print(f"Inserted task '{title}'")
return resultAnd in a real workflow I'd confirm the task details before inserting — not just fire it silently.
Correct. In production you'd show the title and notes, ask for approval, then call add_task. Tests target @default — your own list, not a colleague's project. The next step is updating tasks that already exist: GOOGLETASKS_UPDATE_TASK takes a task ID, and you now have the tools to read those IDs from list_tasks.
GOOGLETASKS_INSERT_TASK creates a task immediately in your Google Tasks account. The tasklist param takes a list ID — use @default for your primary list.
| Your arg | Composio key |
|---|---|
list_id | tasklist |
title | title |
notes | notes |
Returns the created task dict directly — includes the new task's id, title, notes, and status. Use that id with GOOGLETASKS_UPDATE_TASK to modify it later.
Always confirm task details before inserting in real workflows. Tests use @default — your own list only.
Create a free account to get started. Paid plans unlock all tracks.