Add tools for creating themed and recurring invoices - #84
Conversation
| "args_schema": CreateRecurringSeriesParameters, | ||
| "actions": {"invoices": {"createRecurringSeries": True}}, | ||
| "execute": create_recurring_series, | ||
| }, |
There was a problem hiding this comment.
If the user's underlying intent is simply "create an invoice," I'd suggest we consolidate rather than create separate tools per variant. Instead of having distinct tools, we could keep a single CREATE_INVOICE tool and add an invoice_type enum to its input schema (e.g., CREATE_INVOICE_WITH_THEME | CREATE_RECURRING_INVOICE, etc.). The LLM can then ask the user for any missing details (theme, recurrence settings, etc.) conversationally, rather than us needing separate tool definitions for each variant.
There was a problem hiding this comment.
I have updated as per your suggestion. Kept recurring invoice as separate tool since recurring is a separate resource and a lot of features are not supported by recurring invoices.
| class ActivateRecurringSeriesParameters(BaseModel): | ||
| recurring_series_id: str = Field(..., description="The ID of the recurring invoice series to activate.", pattern=RECURRING_SERIES_ID_REGEX.pattern) | ||
|
|
||
|
|
There was a problem hiding this comment.
Mark parameters as optional vs. required in the schema. Anything not required by the tool should be marked optional.
Tip: The tool's input schema doesn't need to mirror the actual API payload structure. Keep the schema simple and user/LLM-friendly — we can handle the transformation into the actual API request payload later, inside the method implementation.
There was a problem hiding this comment.
@cnallam, I've made all the optional fields as optional. Also as per your suggestion, I have updated the payload structure. Please review now
2 participants
No description provided.