Skip to main content
Glama
Ali1041

Leadloadz

verify_email

Verify email deliverability in real-time with MX record, SMTP, and risk analysis to validate leads before campaigns.

Instructions

Check email deliverability in real-time: MX records, SMTP, disposable/role detection. Read-only. Requires API key. Rate limit: 30/min per user. Use after search_leads or before sending campaigns. Returns deliverability score and risk assessment.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
emailYesSingle email address to verify. Must be a valid RFC-like address format.

Implementation Reference

  • src/index.ts:131-141 (registration)
    Tool registration for 'verify_email' — defines the tool name, description, and input schema (expected 'email' string). This is part of a fallback tool list used when the API is unreachable. When the API is available, tool definitions (including verify_email) are fetched dynamically from the Leadloadz API.
    {
      name: "verify_email",
      description: "Check email deliverability in real-time: MX records, SMTP, disposable/role detection. Read-only. Requires API key. Rate limit: 30/min per user. Use after search_leads or before sending campaigns. Returns deliverability score and risk assessment.",
      inputSchema: {
        type: "object" as const,
        properties: {
          email: { type: "string", description: "Single email address to verify. Must be a valid RFC-like address format." }
        },
        required: ["email"]
      }
    },
  • Generic tool call handler — the 'verify_email' tool is handled generically via apiClient.callTool(name, args). The tool name 'verify_email' is passed to the Leadloadz API (via JSON-RPC 'tools/call'), which executes the actual email verification logic server-side. No client-side specific logic exists for verify_email.
    server.setRequestHandler(CallToolRequestSchema, async (request) => {
      const { name, arguments: args } = request.params
    
      // Validate tool exists
      const tool = cachedTools.find((t) => t.name === name)
      if (!tool) {
        telemetry.track("tool_called", { tool: name, success: false, reason: "unknown_tool" })
        return {
          content: [
            {
              type: "text",
              text: JSON.stringify(
                {
                  error: `Unknown tool: '${name}'. Available tools: ${cachedTools.map((t) => t.name).join(", ")}`,
                },
                null,
                2
              ),
            },
          ],
          isError: true,
        }
      }
    
      // Call the API
      const result = await apiClient.safeCall(() => apiClient.callTool(name, args || {}))
      if (!result.success) {
        telemetry.track("tool_called", { tool: name, success: false, reason: "api_error" })
        return {
          content: [
            {
              type: "text",
              text: JSON.stringify({ error: result.error }, null, 2),
            },
          ],
          isError: true,
        }
      }
    
      const response = result.data
    
      // Check for JSON-RPC error in the response
      if (response.error) {
        telemetry.track("tool_called", { tool: name, success: false, reason: "rpc_error", code: response.error.code })
        return {
          content: [
            {
              type: "text",
              text: JSON.stringify(
                {
                  error: response.error.message,
                  code: response.error.code,
                },
                null,
                2
              ),
            },
          ],
          isError: true,
        }
      }
    
      // Track successful tool call
      telemetry.track("tool_called", {
        tool: name,
        success: true,
        arg_count: Object.keys(args || {}).length,
      })
    
      // Return successful result
      return {
        content: [
          {
            type: "text",
            text: JSON.stringify(response.result, null, 2),
          },
        ],
      }
    })
  • API client's callTool method — sends a JSON-RPC request to the Leadloadz API with method 'tools/call' and params { name, arguments }. For 'verify_email', the arguments would contain { email: string }. The actual verification (MX records, SMTP, disposable/role detection) is performed by the remote API server.
    async callTool(
      name: string,
      args: Record<string, unknown>
    ): Promise<ToolCallResponse> {
      const url = `${this.config.baseUrl}`
    
      const response = await this.fetchWithTimeout(url, {
        method: "POST",
        headers: this.headers(),
        body: JSON.stringify({
          jsonrpc: "2.0",
          id: 1,
          method: "tools/call",
          params: {
            name,
            arguments: args,
          },
        }),
      })
    
      if (!response.ok) {
        // Map HTTP status codes to user-friendly messages
        const status = response.status
        let message: string
    
        switch (status) {
          case 401:
            message =
              "Authentication failed. Your API key may be invalid or revoked."
            break
          case 403:
            message =
              "Access denied. Your API key does not have permission to use this tool."
            break
          case 429:
            message =
              "Rate limit exceeded. Please wait a moment before trying again."
            break
          case 500:
          case 502:
          case 503:
          case 504:
            message =
              "The Leadloadz API is temporarily unavailable. Please try again later."
            break
          default:
            message = `The Leadloadz API returned an error (status ${status}). Please try again.`
        }
    
        return {
          jsonrpc: "2.0",
          id: 1,
          error: {
            code: MCPErrorCode.InternalError,
            message,
          },
        }
      }
    
      let data: unknown
      try {
        data = await response.json()
      } catch {
        return {
          jsonrpc: "2.0",
          id: 1,
          error: {
            code: MCPErrorCode.InternalError,
            message:
              "The Leadloadz API returned an invalid response. Please try again later.",
          },
        }
      }
      return data as ToolCallResponse
    }
  • Input schema for verify_email — defines an 'email' property (type: string) as required. No separate output schema is defined in the client; the response is returned as JSON from the API.
    inputSchema: {
      type: "object" as const,
      properties: {
        email: { type: "string", description: "Single email address to verify. Must be a valid RFC-like address format." }
      },
      required: ["email"]
    }
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Discloses read-only nature, API key requirement, and rate limit (30/min per user) without any annotations. Also describes return value (deliverability score and risk assessment).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Concise, packing core purpose, behavior, guidelines, and return info into a few sentences. No wasted words, well front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers all essential aspects for a simple tool: purpose, behavior, auth, rate limit, usage context, and return summary. No gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Input schema already provides 100% coverage with description for 'email' parameter. Description does not add additional semantic detail beyond the schema, so baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states 'Check email deliverability in real-time' with specific checks (MX records, SMTP, disposable/role detection). Differentiates from siblings like get_user_stats and search_leads by focusing on email verification.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says 'Use after search_leads or before sending campaigns', providing clear context. Lacks explicit exclusions or alternatives, but sufficiently guides usage.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Ali1041/leadloadz-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server