Descrepencies in i/o schema of tool actions
# support-forums
shant_1
11/18/2025, 7:35 AMComposio API returns inconsistent response structures across different tools:
Previous Tool call response data:
Tool: GOOGLESHEETS_CREATE_GOOGLE_SHEET1
{
"data": {
"response_data": {
"sheets": [
{
"properties": {
"gridProperties": {
"columnCount": 26,
"rowCount": 1000
},
"index": 0,
"sheetId": 0,
"sheetType": "GRID",
"title": "Sheet1"
}
}
],
"spreadsheet_id": "1aHH-AFM9J8XFmJ3GmXMG6mO-xHF-jP9Ftu30Ns9txkg"
}
},
"successful": true,
"error": null,
"log_id": "log_KvxEku02rx8Z"
}
Expected Input mapping fetched from composio api for the next tool call.
This output is generated by an LLM but the data mapping is done correctly according to what it was provided :
Tool :
GOOGLESHEETS_BATCH_UPDATE
{
"values": {
"source_reference": "step1.formatted_results"
},
"sheet_name": {
"source_reference": "step2.data.response_data.sheets[0].properties.title"
},
"spreadsheet_id": {
"source_reference": "step2.data.response_data.spreadsheetId"
}
}
The input schema expects spreadsheetId in the structure but we get spreadsheet_id.
I found various descrepencies accorss other tools as well. How can we normalise the data for I/O for sequential tool calling ?
u
Uday
11/20/2025, 2:16 PMHey @shant_1,Thanks for flagging this! we'll push a fix for the tool to make the fields more consistent.
Uday
11/21/2025, 1:14 PMHey @shant_1, we maintain snake case for our request payloads across all Composio tools. Let us know if your LLM faces any issue with mapping.
s
shant_1
11/22/2025, 8:22 AMSo i