feat(tools): add Presend email verify tool

[Zoymusk]

Adds presend_email_verify, a free, no-signup, no-key email verification tool, following the existing tool file conventions (see tools/hunter/email_verifier.ts).

Closes #8034

Scope: matches what @presendapp proposed in the issue — just the verification tool (syntax, MX record, disposable-domain, role-account checks), not Hunter's finder/discovery/company-lookup functionality.

Verified against the live endpoint (GET /api/email-verify?email=) — response is flat JSON with snake_case keys (syntax_valid, has_mx, mx_count, role_account, etc.), mapped to camelCase in transformResponse.

Testing: bun install + TypeScript checks pass with no errors in the new files.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

1 Skipped Deployment

Project	Deployment	Actions	Updated
docs	Skipped		Sep 27, 2026 1:55pm UTC

[greptile-apps]

Confidence Score: 4/5

[Medium risk] Adds a new email verification tool integration.

The PR is not ready to merge because the new tool cannot be discovered and the generated-metadata check will fail; the comment convention must also be satisfied.

Findings

1.  Tool missing from catalog ▶
2.  Reason description contradicts output ▶
3.  Declaration comments use inline syntax ▶

Summary

The PR adds a no-key Presend email-verification tool and registers it for execution.

• The generated discovery metadata was not updated, leaving the tool unavailable in the catalog and failing the synchronization check.
• The reason output documentation disagrees with the runtime value, and a new declaration comment does not follow the repository convention.

_{Reviews (1) · Last reviewed commit: "feat(tools): add Presend email verify to..."}

[greptile-apps]

Tool missing from catalog Registering presend_email_verify here does not add it to the generated tool IDs that the catalog uses. Users therefore cannot discover or select the new tool, and the metadata synchronization check will fail. Regenerate and commit the tool metadata alongside this registration.

[greptile-apps]

Reason description contradicts output The description says reason is null for a valid address, but the response mapping converts null to an empty string. Consumers relying on the documented value may handle valid results incorrectly; describe the value the tool actually returns.

Suggested change

	description: 'Explanation when the address is invalid, otherwise null',
	description: 'Explanation when the address is invalid, otherwise an empty string',

[greptile-apps]

Declaration comments use inline syntax // Email Verify tool types is a category comment before an exported declaration, and the same pattern appears at the top of this file. The repository requires TSDoc for documentation and reserves // for terse, non-obvious explanations or enforced annotations. This requirement must be satisfied before merging.

Context Used: CLAUDE.md (source)

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!

[presendapp]

Disclosure: I maintain Presend. Thanks for picking this up, @Zoymusk. The field mapping matches the live response.

One heads-up from our side, prompted by this PR: until today, /api/email-verify returned valid: false with reason: null when the MX lookup itself failed (DNS timeout), and cached that for an hour. That reports an outage as an invalid address, so we changed it: in that case the API now returns valid: null, has_mx: null and reason: "mx_lookup_failed", uncached. The other cases are unchanged.

With ?? false, that null would turn back into "invalid" / "no MX" on your side. I'd suggest mapping valid and mxFound with ?? null and documenting null as "could not be checked, retry later", which would also settle the null-vs-empty-string point greptile raised on reason. Possible reason values: invalid_syntax, no_mx_record, disposable_domain, mx_lookup_failed, or null when the address is valid.

Also worth knowing: the endpoint allows 30 requests per minute per client IP. Since Sim calls it server-side, all workspaces share your egress IPs, so heavy use will hit 429s. Your executor checks response.ok before transformResponse, so that surfaces as a tool error rather than a wrong result, but let me know if the limit becomes a bottleneck.

[vercel]

@Zoymusk is attempting to deploy a commit to the Sim Team on Vercel.

A member of the Team first needs to authorize it.

[Zoymusk]

Pushed a fix commit addressing the review feedback:

• Regenerated the tool metadata (tool-metadata:generate) so presend_email_verify shows up in the catalog
• Switched the declaration comments in types.ts to TSDoc
• @presendapp thanks for the heads-up. valid and mxFound now map with ?? null (documented as "could not be checked, retry later"), and reason is now null for valid addresses, with the possible values listed in the output description. That also settles the null vs empty string point.