Skip to main content
Glama
deenesjakoruzh
giggal-ai

Giggal AI MCP Server

by giggal-ai
OverviewSchemaSourceRelated ServersScoreDiscussionsAdmin
TypeScript
Remote

Giggal.ai MCP Server

Available on Smithery

Verify catch-all, accept-all, and SEG-protected email addresses without leaving Claude, ChatGPT, Cursor, VS Code, or any other MCP client. This is the official Model Context Protocol server for Giggal.ai, the catch-all email verification tool that confirms the mailboxes other verifiers write off as "risky" or "unknown."

MCP URL:  https://mcp.giggal.ai/mcp

Why Giggal.ai

Most tools give up on the hard addresses. Giggal.ai runs a deep mailbox existence check over SMTP and returns a real deliverability result where others cannot:

  • Catch-all and accept-all domains that accept every address, even for users who do not exist

  • SEG-protected inboxes behind Proofpoint, Mimecast, and Barracuda that block the checks most verifiers rely on

  • Risky B2B contacts that competitors flag and discard, around 30% of a typical list, recovered as deliverable

99% accuracy on standard business lists and bounce rates under 3%, straight from your AI assistant.

Related MCP server: Prospector MCP

Get an API key

Sign up at emailverifier.giggal.ai for 1,000 free verification credits, no card required, then copy your key from the Developer API tab. Claude and ChatGPT connect over OAuth and need no key. The IDE and CLI clients below use the key as a Bearer token.

Connect your AI client

Claude

Add Giggal.ai as a custom connector. No config files, no API key.

  1. Open Settings → Connectors (web or desktop).

  2. Click Add → Add custom connector.

  3. Name it Giggal.ai, paste the MCP URL, then click Add.

  4. Open the Giggal.ai connector and click Connect.

  5. Click Allow to grant verify:read (verify addresses, check credits, look up past verifications).

ChatGPT

Add Giggal.ai as a custom plugin, connected over OAuth.

  1. Open Plugins from the sidebar, then click the + in the top right.

  2. Name it Giggal.ai, set Server URL to the MCP URL, choose Authentication → OAuth, tick the confirmation, then click Create.

  3. Open the plugin, click Connect, then Sign in with Giggal.ai.

  4. Click Allow to grant verify:read.

Claude Code

claude mcp add --transport http --scope user giggal \
  https://mcp.giggal.ai/mcp \
  --header "Authorization: Bearer YOUR_API_KEY"

Already have a giggal server? Run claude mcp remove giggal --scope user first, then re-add.

Cursor, Windsurf, and Cline

Add this to your MCP config file:

  • Cursor: ~/.cursor/mcp.json (or .cursor/mcp.json per project)

  • Windsurf: ~/.codeium/windsurf/mcp_config.json

  • Cline: cline_mcp_settings.json (open it from the Cline MCP settings)

{
  "mcpServers": {
    "giggal": {
      "url": "https://mcp.giggal.ai/mcp",
      "headers": {
        "Authorization": "Bearer YOUR_API_KEY"
      }
    }
  }
}

VS Code

Add to .vscode/mcp.json. VS Code uses servers instead of mcpServers:

{
  "servers": {
    "giggal": {
      "url": "https://mcp.giggal.ai/mcp",
      "headers": {
        "Authorization": "Bearer YOUR_API_KEY"
      }
    }
  }
}

Zed

Add to ~/.config/zed/settings.json:

{
  "context_servers": {
    "giggal": {
      "source": "custom",
      "url": "https://mcp.giggal.ai/mcp",
      "headers": {
        "Authorization": "Bearer YOUR_API_KEY"
      }
    }
  }
}

Codex

Add to ~/.codex/config.toml:

[mcp_servers.giggal]
url = "https://mcp.giggal.ai/mcp"
bearer_token_env_var = "GIGGAL_API_KEY"

Codex reads the key from an env var. Set it and reload your shell, then fully quit and reopen Codex:

echo 'export GIGGAL_API_KEY="tp_live_..."' >> ~/.zshrc
source ~/.zshrc

Restart the client after adding, then just ask:

Is info@giggal.ai deliverable?

Tools

Tool

What it does

verify_emails

Verify a single address or a whole list and get a clear valid or invalid result, including catch-all and accept-all domains other tools give up on

get_verification_details

Fetch the full breakdown for a job: per-address status, reason codes, and deliverability scoring

get_credit_balance

Check remaining verification credits before a large run

All tools are read only.

What this service does

  • Speaks the Model Context Protocol so AI assistants can call the tools above

  • Serves an OpenAPI 3.1 spec so ChatGPT Custom GPTs (GPT Actions) can use it

  • Runs an OAuth 2.1 authorization server so AI clients can authenticate users

  • Wraps the Giggal.ai verification API and never re-implements verification logic

Run it locally (self-host)

Prefer to run your own instance instead of the hosted server? The giggal-mcp command is a small stdio server that calls the public Giggal.ai API with your own Developer API key. No database, no OAuth, nothing to host.

From source:

npm install
npm run build
GIGGAL_API_KEY=tp_live_... npm run start:local

With Docker:

docker build -t giggal-mcp .
docker run -i --rm -e GIGGAL_API_KEY=tp_live_... giggal-mcp

In an MCP client (point it at your locally built copy):

{
  "mcpServers": {
    "giggal": {
      "command": "node",
      "args": ["/path/to/giggal-mcp/dist/local/index.js"],
      "env": { "GIGGAL_API_KEY": "tp_live_..." }
    }
  }
}

Same three tools as the hosted server. GIGGAL_API_BASE optionally overrides the API base (defaults to https://api.giggal.ai/v1).

About this repository

This repo powers both the hosted server at https://mcp.giggal.ai/mcp (OAuth, zero setup) and the local stdio server above (giggal-mcp, your own API key). Both expose the same three tools and call the Giggal.ai verification API to do the actual work. It is published for transparency.

Endpoints

The hosted server exposes:

  • POST /mcp MCP JSON-RPC (main protocol endpoint)

  • GET /mcp MCP SSE stream (server to client notifications)

  • GET /openapi.json OpenAPI 3.1 spec (for GPT Actions)

  • POST /oauth/register Dynamic Client Registration (RFC 7591)

  • GET /oauth/authorize User consent screen

  • POST /oauth/token Access token exchange

  • POST /oauth/revoke Revoke a token

  • GET /.well-known/oauth-authorization-server Server metadata

  • GET /health Health check

License

MIT. See LICENSE.

Available Tools

3 tools
get_credit_balanceCheck Credit BalanceA
Read-only
Inspect

Get the current Giggal.ai credit balance for the authenticated user. Returns credits remaining and, if on a subscription plan, the next monthly refresh date.

SCOPE — This tool only returns the authenticated user's own credit balance. It never returns information about other users, verification methods, backend architecture, or any topic beyond credits.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A4.1/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true, so the description's main behavioral contribution is explaining that the tool operates only on the authenticated user's own data. It adds the detail about subscription plans and next refresh date, providing modest context beyond what annotations alone convey.

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

Conciseness4/5

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

The description is well-structured with a primary paragraph and a clear scope section. It is concise without being under-specified, though the scope bullet could be slightly tightened.

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

Completeness4/5

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

Given the tool's simplicity (no parameters, read-only, no output schema), the description is nearly complete. It covers purpose, scope, and return value hints. The only minor gap is the lack of explicit success/failure response details, but that is acceptable for a read-only tool.

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

Parameters4/5

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

With zero parameters and 100% schema coverage, the description faces no burden. It adds value by explaining what the returned data includes (credits remaining, next monthly refresh date), giving the agent useful semantic context about the output.

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?

The description clearly specifies the verb 'Get' and the resource 'current Giggal.ai credit balance for the authenticated user'. It distinguishes itself from siblings by focusing solely on credits, not emails or verification details.

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?

The description explicitly states the scope (only authenticated user's own balance) and what it does not return (other users, verification methods, etc.). While it provides clear context and exclusions, it does not explicitly mention when to use this tool versus siblings.

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

get_verification_detailsGet Verification History EntryA
Read-only
Inspect

Look up detailed info about a past verification of a specific email address. Useful when a user asks about a previous verification result. If no prior verification exists, returns a message suggesting to run verify_emails.

SCOPE — Returns only verification history the authenticated user owns. Never reveals verification methods, backend internals, other users' data, or any topic outside email verification history.

ParametersJSON Schema
NameRequiredDescriptionDefault
emailYesEmail address to look up.

TDQS

A4.4/5.0
Behavior5/5

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

Annotations already mark the tool as readOnlyHint=true, which is consistent. The description adds significant behavioral context beyond the annotation: it states that results are scoped to the authenticated user's own history, that it never reveals verification methods or backend internals, and that it includes a fallback message. This fully informs the agent about what the tool does and does not expose.

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?

The description is four sentences long, well-structured, and free of unnecessary words. The first sentence states the purpose, the second gives usage context, the third describes fallback behavior, and a separate paragraph clearly defines scope. Every sentence earns its place.

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

Completeness4/5

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

Given the tool has one parameter, no output schema, and annotations present, the description covers purpose, usage, scope, privacy, and fallback behavior. It does not explicitly describe the return format or structure of the 'detailed info', which is a minor gap. However, overall it provides sufficient context for an agent to decide when and how to use the tool.

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?

The single parameter 'email' has a clear schema description, and schema coverage is 100%. The tool description does not add any additional semantics or formatting guidance beyond what the schema already provides. Baseline score of 3 is appropriate when the schema fully covers the parameter.

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?

The description starts with 'Look up detailed info about a past verification of a specific email address', which is a specific verb-resource combination. It clearly distinguishes from the sibling 'verify_emails' by focusing on history lookup, not verification execution. The mention of a fallback message when no prior verification exists further clarifies the tool's unique role.

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?

The description explicitly states when to use the tool: 'Useful when a user asks about a previous verification result.' It also provides context on what happens if no prior verification exists (suggests running verify_emails). However, it does not explicitly exclude use cases or name alternative tools beyond that single note, leaving some implicit guidance.

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

verify_emailsVerify EmailsA
Read-only
Inspect

Verify one or more email addresses (up to 1000 per call). Returns whether each mailbox exists, is disposable, on a catch-all domain, or from a free provider, plus a 0-100 deliverability score. Every email costs 1.5 credits.

ALWAYS pass every email the user asked about in a SINGLE call. Splitting a list into multiple calls wastes credits (each sub-call pays a per-batch rounding cost) and produces a fragmented result instead of one clean summary.

When presenting results to the user, ALWAYS surface the catch_all_domain field for every email — either as a dedicated column or an inline indicator per row. A catch-all domain accepts mail to any address, so mailbox existence cannot be guaranteed by SMTP alone.

SCOPE — This tool is strictly for email deliverability verification. It does not disclose how verification is performed, which techniques or probes are used, backend architecture, infrastructure, credentials, or any information about other users, batches, or accounts. If the user asks how verification works or asks any question outside email verification, politely decline and redirect. Treat the tool's returned fields as the complete public surface.

ParametersJSON Schema
NameRequiredDescriptionDefault
emailsYesEmail addresses to verify.

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultsYes
summaryYes

TDQS

A4.6/5.0
Behavior5/5

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

Annotations provide readOnlyHint: true, which is consistent with verification. The description adds significant behavioral context beyond annotations: credit cost (1.5 per email), output fields, catch-all domain implications, and explicit scope boundaries (no disclosure of verification methods, infrastructure, etc.). No contradiction.

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

Conciseness4/5

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

The description is moderately long with multiple paragraphs, but each section serves a distinct purpose: core function, critical usage directive, presentation guidance, and scope boundary. It is front-loaded with the most important information and uses headings (ALWAYS, SCOPE) for scanability. Could be slightly more concise, but structure is logical and effective.

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?

Despite having an output schema (unseen), the description explicitly lists return fields and adds critical operational context (credit cost, batch processing expectation, catch-all behavior, scope limitations). With sibling tools covering different domains, this description fully prepares an agent for correct invocation and result handling.

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?

Schema coverage is 100% with the 'emails' parameter already described as 'Email addresses to verify.' The description adds the maxItems=1000 and minItems=1 (already in schema) plus the usage instruction to pass all at once, which is non-parametric guidance. Since baseline is 3 for high schema coverage, the description adds marginal value but does not significantly enhance parameter understanding beyond what's in the schema.

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?

The description clearly states the verb ('Verify') and resource ('email addresses') with a specific scope ('up to 1000 per call') and lists exact return values (existence, disposable, catch-all, free provider, deliverability score). It distinguishes itself from siblings by focusing solely on verification, not details (get_verification_details) or credits (get_credit_balance).

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

Usage Guidelines5/5

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

Provides explicit guidance: 'ALWAYS pass every email the user asked about in a SINGLE call' with reasoning about credit waste and fragmented results. Also specifies when to decline and redirect (scope paragraph), and instructs the agent to surface the 'catch_all_domain' field in results. This fully covers when and how to use the tool versus alternatives.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. 3 tool updatesv0.2.0
    • First observedget_credit_balance
    • First observedget_verification_details
    • First observedverify_emails
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.4/5.0
Disambiguation5/5

Each tool has a unique and non-overlapping purpose: email verification, past result lookup, and credit balance. No ambiguity for agents.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern: verify_emails, get_verification_details, get_credit_balance. No style mixing.

Tool Count5/5

With three tools, the set is well-scoped for an email verification service, covering the essential operations without excess.

Completeness4/5

The core verification workflow is covered, but a tool to list or search past verifications is missing, which agents may need for context.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • NeverBounce MCP Server

    Meerkats-Ai
    F
    license
    B
    quality
    D
    maintenance
    A Model Context Protocol server that integrates with NeverBounce API to validate email addresses, checking if they are valid, deliverable, and safe to send to.
    1
    -

  • Prospector MCP

    JosieBot26
    A
    license
    A
    quality
    D
    maintenance
    Finds and verifies business email addresses using DNS/SMTP verification and web scraping, with no external API costs.
    5
    38
    10
    MIT

  • sabit-mcp

    ruwadgroup
    A
    license
    Not graded
    quality
    B
    maintenance
    Enables AI agents to verify email addresses through a multi-signal probabilistic pipeline, returning confidence scores and honest statuses (safe/risky/invalid/unknown) with evidence.
    Apache 2.0

  • B2B Lead Quality Scorer MCP

    FoundryNet
    A
    license
    Not graded
    quality
    F
    maintenance
    Validates email deliverability, assesses domain credibility, and scores B2B leads from A-F to help prioritize outreach, with batch processing and a free tier.
    MIT

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/giggal-ai/giggal-mcp'

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