Skip to content
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
12 changes: 12 additions & 0 deletions src/tools/listTools.ts
Original file line number Diff line number Diff line change
Expand Up @@ -249,6 +249,18 @@ export async function generateToolStructure(): Promise<ModuleStructure> {
description: 'Preview a rendered templated email without sending. Returns rendered subject, body, and recipients. Pure function — no API calls.',
example: 'const preview = gmail.dryRun({ to: ["amy@example.com"], subject: "{{firstName}}, quick follow-up", template: "Hey {{firstName}},\\n\\n{{note}}", variables: { firstName: "Amy", note: "checking in" } });\nconsole.log(preview.subject); // "Amy, quick follow-up"\nconsole.log(preview.wouldSend); // false',
},
{
name: 'sendFromTemplate',
signature: 'sendFromTemplate({ to: string[], subject: string, template: string, variables: Record<string, string>, cc?: string[], bcc?: string[], isHtml?: boolean, from?: string })',
description: 'Render a templated email ({{variable}} substitution in subject and body) and send it. Returns messageId and threadId.',
example: 'const result = await gmail.sendFromTemplate({ to: ["amy@example.com"], subject: "{{firstName}}, quick follow-up", template: "Hey {{firstName}},\\n\\n{{personalNote}}", variables: { firstName: "Amy", personalNote: "Great chat!" } });\nconsole.log(result.messageId);',
},
{
name: 'sendBatch',
signature: 'sendBatch({ subject: string, template: string, recipients: Array<{ to: string, variables: Record<string, string>, cc?: string[], bcc?: string[] }>, delayMs?: number, isHtml?: boolean, dryRun?: boolean, from?: string })',
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 Badge Remove unsupported per-recipient cc/bcc from sendBatch docs

The new sendBatch signature in tool discovery advertises recipients[].cc/recipients[].bcc, but the actual operation only supports { to, variables } per recipient (BatchRecipient) and sendBatch() only reads recipient.to and recipient.variables before calling sendMessage. In practice, callers that rely on gdrive://tools will provide per-recipient CC/BCC and silently get incorrect behavior (those recipients are never included), which makes this discovery metadata inaccurate and misleading.

Useful? React with 👍 / 👎.

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟠 Major

sendBatch signature advertises per-recipient cc/bcc, but runtime does not pass them through.

Line 260 includes cc?: string[], bcc?: string[] on each recipient, but src/modules/gmail/send.ts (lines 125-185 snippet) constructs sendOpts without cc/bcc. This makes the discovery contract misleading and can cause silent data loss of requested recipients.

🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In `@src/tools/listTools.ts` at line 260, The sendBatch signature advertises
per-recipient cc/bcc but the runtime path that builds sendOpts (in the code that
constructs sendOpts for each recipient within the Gmail send flow) does not
forward recipient.cc/recipient.bcc, causing loss of those fields; update the
code that constructs sendOpts (the routine preparing per-recipient send options
used by sendEmail/send or the Gmail transporter) to copy recipient.cc and
recipient.bcc (when present) into sendOpts.cc and sendOpts.bcc (preserving
existing global from/delivery options and merging arrays appropriately), and
ensure downstream send logic accepts those properties so the advertised contract
for sendBatch (recipients with cc?: string[], bcc?: string[]) is honored.

description: 'Send templated emails to multiple recipients with per-recipient variable substitution and configurable delay between sends (default 5000ms). Set dryRun: true to preview all rendered emails without sending. Returns { sent, failed, results?, previews? }.',
example: 'const result = await gmail.sendBatch({ subject: "Hi {{name}}", template: "Hello {{name}}, {{note}}", recipients: [{ to: "alice@example.com", variables: { name: "Alice", note: "checking in" } }, { to: "bob@example.com", variables: { name: "Bob", note: "quick update" } }], delayMs: 5000 });\nconsole.log(`Sent: ${result.sent}, Failed: ${result.failed}`);',
Comment on lines +261 to +262
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟠 Major

Default throttling value conflicts with linked requirement.

Line 261 (and the example on Line 262) documents a default of 5000ms, while Issue #51 / AC-2 specify a default of 500ms. Please align the documented and implemented default to one value and keep all surfaces consistent.

🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In `@src/tools/listTools.ts` around lines 261 - 262, The docs and example claim a
default delay of 5000ms but Issue `#51/AC-2` requires 500ms; update the default
throttling everywhere to 500ms: change the description string and the example in
listTools.ts (the description/examplar lines referencing gmail.sendBatch) to
state 500ms, and change the implementation default for the sendBatch
function/method (gmail.sendBatch / sendBatch) so its delayMs default parameter
or fallback value is 500 instead of 5000; also update any related tests or
comments that reference 5000ms to 500ms to keep all surfaces consistent.

},
Comment on lines +252 to +263
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🛠️ Refactor suggestion | 🟠 Major

Use the operation-based tool shape instead of adding action-specific entries.

Lines 252-263 add separate sendFromTemplate and sendBatch tools, which conflicts with the repository rule for src/**/*.ts. Please model this through a single operation-based entry (single operation parameter) to stay consistent with the rest of the contract surface.

As per coding guidelines, "src/**/*.ts: Use operation-based tool pattern with single operation parameter instead of separate tools per action".

🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In `@src/tools/listTools.ts` around lines 252 - 263, The current tool list exposes
two separate actions sendFromTemplate and sendBatch; change this to a single
operation-based tool entry (e.g., a unified tool with an operation parameter) so
callers pass operation: "sendFromTemplate" | "sendBatch" and a single payload
object; update the signature/description to accept operation plus a union-typed
payload (for sendFromTemplate: { to: string[], subject: string, template:
string, variables: Record<string,string>, cc?: string[], bcc?: string[],
isHtml?: boolean, from?: string } and for sendBatch: { subject: string,
template: string, recipients: Array<{ to: string, variables:
Record<string,string>, cc?: string[], bcc?: string[] }>, delayMs?: number,
isHtml?: boolean, dryRun?: boolean, from?: string }) and adjust example and
description to document both operations and return shapes (messageId/threadId
for sendFromTemplate, { sent, failed, results?, previews? } for sendBatch);
locate and modify the entries named sendFromTemplate and sendBatch in
src/tools/listTools.ts to a single operation-based entry and ensure consumers
are informed to switch to operation-based calls.

],
calendar: [
{
Expand Down
Loading