How do I use PhishTank MCP Server?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@PhishTank MCP Server Check if https://suspicious-site.com is phishing" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

PhishTank MCP Server

by Cyreslab-AI

Overview Schema Related Servers Score Discussions

JavaScript

Remote

PhishTank MCP Server

An MCP (Model Context Protocol) server that provides access to PhishTank, a collaborative clearing house for data and information about phishing on the Internet. PhishTank is operated by Cisco Talos Intelligence Group and provides real-time phishing URL verification and comprehensive phishing databases.

Features

URL Verification: Check if URLs are in PhishTank's phishing database
Batch Processing: Check multiple URLs with intelligent rate limiting
Database Access: Access to comprehensive phishing URL database
Search & Filter: Search phishing URLs by target, date, or verification status
Statistics: Get phishing trends and target analysis
Caching: Smart caching to reduce API calls and improve performance
Rate Limiting: Respects PhishTank's rate limits with automatic throttling

Related MCP server: MCP AbuseIPDB Server

Available Tools

1. `check_url`

Check if a single URL is in PhishTank's phishing database.

Parameters:

url (required): The URL to check (must include protocol)
format (optional): Response format ('json', 'xml', 'php', default: 'json')

Example:

{
  "url": "https://suspicious-site.com/login",
  "format": "json"
}

2. `check_multiple_urls`

Check multiple URLs with intelligent rate limiting.

Parameters:

urls (required): Array of URLs to check (max 50)
delay (optional): Delay between requests in milliseconds (500-10000, default: 1000)

Example:

{
  "urls": [
    "https://example1.com",
    "https://example2.com"
  ],
  "delay": 1500
}

3. `get_recent_phish`

Get recent verified phishing URLs from the database.

Parameters:

limit (optional): Number of entries to return (1-1000, default: 100)
include_offline (optional): Include offline phishing URLs (default: false)

4. `search_phish_by_target`

Search phishing URLs by target company/brand.

Parameters:

target (required): Target company or brand name (e.g., "PayPal", "Apple")
limit (optional): Number of results (1-500, default: 50)
verified_only (optional): Only return verified phishing URLs (default: true)

5. `get_phish_details`

Get detailed information about a specific phish by ID.

Parameters:

phish_id (required): PhishTank phish ID number

6. `get_phish_stats`

Get statistics about phishing trends and top targets.

Parameters:

days (optional): Number of days to analyze (1-30, default: 7)
top_targets_limit (optional): Number of top targets to include (default: 10)

7. `search_phish_by_date`

Search phishing URLs by submission date range.

Parameters:

start_date (required): Start date in YYYY-MM-DD format
end_date (required): End date in YYYY-MM-DD format
limit (optional): Number of results (1-500, default: 100)

Installation

Prerequisites

Node.js 18 or higher
npm or yarn

Install Dependencies

npm install

Build the Server

npm run build

Install Globally (Optional)

npm install -g .

Configuration

The server can be configured using environment variables. Copy .env.example to .env and customize:

cp .env.example .env

Environment Variables

PHISHTANK_API_KEY: Optional API key for higher rate limits and database downloads
PHISHTANK_USER_AGENT: Custom User-Agent string (recommended format: phishtank/username)

Getting an API Key

Visit PhishTank API Registration
Create an account or log in
Register your application to get an API key
Add the key to your .env file

Benefits of API Key:

Higher rate limits (100 vs 10 requests per minute)
Access to database downloads
More reliable service

Usage

Running the Server

# Run directly
npm start

# Or if installed globally
phishtank-mcp-server

# Run with MCP Inspector for testing
npm run inspector

Integration with MCP Clients

Add to your MCP client configuration:

{
  "name": "phishtank",
  "command": "node",
  "args": ["path/to/phishtank-mcp-server/build/index.js"]
}

Example Usage

Check a Suspicious URL

// Using MCP client
const result = await client.use_tool('check_url', {
  url: 'https://suspicious-site.com/login'
});

Search for PayPal Phishing

const phishingUrls = await client.use_tool('search_phish_by_target', {
  target: 'PayPal',
  limit: 20,
  verified_only: true
});

Get Recent Phishing Statistics

const stats = await client.use_tool('get_phish_stats', {
  days: 7,
  top_targets_limit: 15
});

Rate Limiting

The server automatically handles rate limiting:

Without API Key: 10 requests per minute
With API Key: 100 requests per minute
Automatic Throttling: Requests are queued and spaced appropriately
Caching: Results are cached to reduce API calls

Caching

URL Checks: Cached for 5 minutes
Database Downloads: Cached for 1 hour
Automatic Cleanup: Cache is cleaned up automatically

Error Handling

The server provides comprehensive error handling:

Rate Limit Exceeded: Automatic retry with backoff
Invalid URLs: Validation before API calls
Network Errors: Proper error messages and recovery
API Errors: Detailed error information from PhishTank

API Response Format

All tools return structured JSON responses with:

{
  "result": { /* Tool-specific data */ },
  "rate_limit_info": {
    "interval": "300 Seconds",
    "limit": 100,
    "count": 5,
    "remaining": 95
  },
  "summary": "Human-readable summary of the result"
}

Security Considerations

No API Key Required: Basic functionality works without API key
Rate Limiting: Respects PhishTank's service limits
URL Validation: All URLs are validated before processing
Error Handling: Prevents information leakage in error messages

Development

Scripts

npm run build: Compile TypeScript to JavaScript
npm run watch: Watch for changes and rebuild
npm run inspector: Run with MCP Inspector for testing

Project Structure

phishtank-mcp-server/
├── src/
│   ├── index.ts              # Main server implementation
│   └── types/
│       └── phishtank-types.ts # TypeScript type definitions
├── build/                    # Compiled JavaScript (auto-generated)
├── package.json
├── tsconfig.json
├── .env.example
└── README.md

Contributing

Fork the repository
Create a feature branch
Make your changes
Add tests if applicable
Submit a pull request

License

MIT License - see LICENSE file for details

URLhaus MCP Server - URLhaus malware URL database
OpenFDA MCP Server - FDA drug and device information
CIRCL CVE Search MCP Server - CVE vulnerability information

Support

Issues: GitHub Issues
Documentation: PhishTank API Documentation
Community: MCP Community

Acknowledgments

PhishTank by Cisco Talos Intelligence Group
Model Context Protocol by Anthropic
All contributors and the cybersecurity community

Available Tools

7 tools

check_multiple_urlsB

Check multiple URLs for phishing with intelligent rate limiting

ParametersJSON Schema

Name	Required	Description	Default
`urls`	Yes	Array of URLs to check
`delay`	No	Delay between requests in milliseconds (default: 1000)

TDQS

B3.4/5.0

Behavior2/5

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

With no annotations provided, the description carries the full burden. It mentions 'intelligent rate limiting' but fails to disclose what happens on failure, concurrency behavior, or other important traits like error handling.

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?

Single sentence with no unnecessary words, clearly front-loaded. Highly efficient while conveying key purpose and feature.

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

Completeness2/5

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

Given no output schema and no annotations, the description is too minimal. It lacks information on return values, error handling, and usage context, leaving significant gaps for an agent.

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% so the schema already describes both parameters. The description adds no new parameter meaning beyond the schema, aligning with baseline 3.

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 action (check), resource (multiple URLs), and a distinctive feature (intelligent rate limiting). It effectively distinguishes from the sibling tool 'check_url' which likely handles single URLs.

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

Usage Guidelines3/5

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

The description implies usage for batch checking with rate limiting but lacks explicit guidelines on when to use this tool versus alternatives like 'check_url', and does not mention any prerequisites or limitations.

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

check_urlB

Check if a URL is in PhishTank's phishing database

ParametersJSON Schema

Name	Required	Description	Default
`url`	Yes	The URL to check for phishing (must be a complete URL with protocol)
`format`	No	Response format: json, xml, or php (default: json)

TDQS

B3.1/5.0

Behavior2/5

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

With no annotations, the description carries full burden but only states basic functionality. No disclosure of return format, side effects, rate limits, or authentication requirements.

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?

Single sentence, no fluff. However, it could be expanded with essential details without being verbose.

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

Completeness2/5

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

Given no output schema and no annotations, the 12-word description is insufficient. It does not explain response format or limitations, leaving agents underinformed.

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 covers 100% of parameters with descriptions, so the tool description adds no extra meaning. Baseline score of 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?

The description clearly states the action ('Check') and the resource ('URL in PhishTank's phishing database'), distinguishing it from siblings like check_multiple_urls and search tools.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives (e.g., check_multiple_urls for bulk checks). No prerequisites or exclusions mentioned.

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

get_phish_detailsB

Get detailed information about a specific phish by ID

ParametersJSON Schema

Name	Required	Description	Default
`phish_id`	Yes	PhishTank phish ID number

TDQS

B3.3/5.0

Behavior2/5

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

No annotations provided. Description does not disclose behavioral traits such as rate limits, authentication requirements, or what constitutes 'detailed information'. The agent lacks insight into side effects or constraints.

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?

Single concise sentence with no wasted words. Information is front-loaded and easily parsed by an agent.

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

Completeness3/5

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

The tool is simple (one required param, no output schema). Description provides basic understanding but lacks context on what 'detailed information' includes (e.g., fields returned). Adequate for a minimal viable definition but leaves 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?

Schema description coverage is 100% with one parameter 'phish_id' described as 'PhishTank phish ID number'. Description adds minimal value beyond schema, merely stating 'by ID'. Baseline 3 applies as schema already does the work.

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 verb 'get', resource 'detailed information about a specific phish', and method 'by ID'. Distinguishes from sibling tools like 'get_recent_phish' or 'check_url' which have different scopes.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives. No mention of prerequisites, when to use, or when not to use. The description simply states what it does without contextual usage advice.

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

get_phish_statsB

Get statistics about phishing trends and top targets

ParametersJSON Schema

Name	Required	Description	Default
`days`	No	Number of days to analyze (1-30, default: 7)
`top_targets_limit`	No	Number of top targets to include (default: 10)

TDQS

B3.1/5.0

Behavior2/5

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

No annotations provided, so description must disclose behavioral traits. It only states 'get', implying read-only, but doesn't confirm no side effects, resource usage, or rate limits. Limited transparency.

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?

Single sentence, no wasted words. Front-loaded and efficient.

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

Completeness3/5

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

The description and parameters are sufficient for basic use, but no output schema is provided, leaving return format unclear. Could be more complete for an aggregation 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?

Schema coverage is 100% with well-described parameters. The description adds context (trends and top targets) that aligns with parameters, but doesn't add new meaning beyond the schema. Baseline 3 is appropriate.

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

Purpose4/5

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

The description clearly states the tool gets statistics about phishing trends and top targets, which is specific. However, it doesn't differentiate from siblings like get_phish_details, which also provides phishing-related information.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus siblings like get_phish_details, get_recent_phish, or search_phish_by_date. No exclusions or prerequisites mentioned.

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

get_recent_phishC

Get recent verified phishing URLs from PhishTank database

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No	Number of entries to return (1-1000, default: 100)
`include_offline`	No	Include offline phishing URLs (default: false)

TDQS

C2.8/5.0

Behavior2/5

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

With no annotations, the description carries full behavioral burden. It fails to explain what 'recent' means, any ordering, or potential limits. No mention of rate limits, data freshness, or response structure.

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

Conciseness3/5

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

Extremely concise (single sentence, 7 words) but lacks important details. Conciseness is positive, but under-specification hurts completeness.

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

Completeness2/5

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

Given the presence of several sibling tools and no output schema, the description is insufficient. It does not clarify how 'recent' is defined, what 'verified' means, or how results are ordered.

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?

Both parameters are fully described in the input schema (100% coverage). Description adds no additional meaning beyond schema, so baseline score of 3 is appropriate.

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

Purpose4/5

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

Description clearly states the verb 'Get', resource 'recent verified phishing URLs', and source 'PhishTank database'. However, it does not differentiate from sibling tools like search_phish_by_date or search_phish_by_target.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus its siblings. The description provides no context about typical use cases or conditions.

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

search_phish_by_dateB

Search phishing URLs by submission date range

ParametersJSON Schema

Name	Required	Description
`start_date`	Yes	Start date in ISO format (YYYY-MM-DD)
`end_date`	Yes	End date in ISO format (YYYY-MM-DD)
`limit`	No	Number of results to return (1-500, default: 100)

TDQS

B3.4/5.0

Behavior3/5

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

No annotations are provided, so the description carries full burden. It states the basic search behavior but omits details like ordering, pagination, or whether results are limited to certain fields. For a simple search, the behavioral disclosure is adequate but not thorough.

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 a single sentence, concise and to the point. It wastes no words, though it could be slightly more informative without losing conciseness.

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

Completeness3/5

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

Given the tool's simplicity (3 params, no output schema), the description provides the essential purpose. However, it lacks details about return format or pagination, which would improve completeness. The context signals show it's a straightforward search, so the description is minimally complete.

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 description coverage is 100%; all three parameters are documented in the schema. The description adds no additional meaning beyond stating the date range purpose, so baseline 3 is appropriate.

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

Purpose4/5

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

The description clearly states it searches phishing URLs by date range, with specific verb 'Search' and resource 'phishing URLs' by 'submission date range'. However, it doesn't distinguish from siblings like search_phish_by_target, which uses different criteria.

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

Usage Guidelines3/5

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

Usage is implied: use this tool when you need phishing URLs in a date range. But no explicit guidance on when not to use it or alternatives, such as get_recent_phish for the latest submissions.

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

search_phish_by_targetB

Search phishing URLs by target company/brand

ParametersJSON Schema

Name	Required	Description
`target`	Yes	Target company or brand name to search for (e.g., "PayPal", "Apple")
`limit`	No	Number of results to return (1-500, default: 50)
`verified_only`	No	Only return verified phishing URLs (default: true)

TDQS

B3.1/5.0

Behavior2/5

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

No annotations are present, so the description must carry the full burden. It only states the basic function without disclosing behavioral traits such as rate limits, authentication needs, or what happens if no results are found.

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 a single, concise sentence that is front-loaded with the key action. While very brief, it is not verbose and gets the point across efficiently.

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

Completeness2/5

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

The description lacks details about output format, pagination, and behavioral nuances. Given no output schema, it should at least mention the type of results or any default behavior.

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%, so each parameter is already well-documented in the schema. The description adds no additional semantic value beyond what the schema provides.

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 action ('search') and resource ('phishing URLs') with a specific filter ('by target company/brand'). This distinguishes it from sibling tools like search_phish_by_date, which searches by date.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives. With multiple search tools available (search_phish_by_date), explicit usage context would be helpful.

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.

7 tool updatesv1.0.0Jun 18, 2026
- First observedcheck_multiple_urls
- First observedcheck_url
- First observedget_phish_details
- First observedget_phish_stats
- First observedget_recent_phish
- First observedsearch_phish_by_date
- First observedsearch_phish_by_target

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.6/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose: single URL check, bulk check, details by ID, statistics, recent listings, and searches by date or target. No overlapping functionality.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern in snake_case (e.g., check_url, get_phish_details, search_phish_by_date), making them predictable and easy to understand.

Tool Count5/5

With 7 tools, the surface is well-scoped for a phishing database server, covering all common query needs without unnecessary bloat.

Completeness5/5

The tool set provides complete coverage for querying phishing data: single and batch checks, detailed info, stats, recent entries, and searching by date or target. No obvious gaps.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Phishtank B
io.github.pipeworx-io
PhishTank MCP — wraps PhishTank API (checkurl.phishtank.com)
Security Open Data
322
APICK Web A
app.apick
Domain/IP intelligence, web page capture and search APIs
Browser Automation Search Networking & Infrastructure
1311
Urlhaus A
io.github.pipeworx-io
URLhaus MCP — wraps abuse.ch URLhaus malware URL database (free, no auth)
Security Web Scraping Monitoring
352
Phishunt A
io.github.0xDanielLopez
Public phishing feed: suspicious/confirmed phishing URLs detected hourly. No auth, CC0.
Security Open Data
1121

Related MCP Servers

Malicious URLs MCP Server
Security Search
BACH-AI-Tools
A
license
C
quality
D
maintenance
Provides access to a malicious URL database API, enabling users to search, list, and retrieve information about potentially dangerous URLs for security analysis and threat detection.
Updated 9 months ago (2025-12-07 20:45 UTC)
3
MIT
MCP AbuseIPDB Server
Security Search Monitoring
alephnan
A
license
A
quality
D
maintenance
Provides threat intelligence lookups against the AbuseIPDB database, enabling IP reputation checks, CIDR block analysis, and log enrichment. It features intelligent caching and rate limiting to efficiently manage API usage for security analysis and automated workflows.
Updated 5 months ago (2026-04-09 04:29 UTC)
5
MIT
mcp-phishtank
Security
pipeworx-io
A
license
Not graded
quality
C
maintenance
Enables checking URLs against the PhishTank phishing database to identify malicious sites.
Updated 11 days ago (2026-08-26 17:32 UTC)
15
MIT
mcp-urlscan-io
Penetration Testing Search
pipeworx-io
A
license
Not graded
quality
C
maintenance
Enables searching past scans and submitting URLs for scanning via urlscan.io, with both keyless and key-based operations.
Updated 11 days ago (2026-08-26 17:32 UTC)
14
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/Cyreslab-AI/phishtank-mcp-server'

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

PhishTank MCP Server

Features

Available Tools

1. check_url

2. check_multiple_urls

3. get_recent_phish

4. search_phish_by_target

5. get_phish_details

6. get_phish_stats

7. search_phish_by_date

Installation

Prerequisites

Install Dependencies

Build the Server

Install Globally (Optional)

Configuration

Environment Variables

Getting an API Key

Usage

Running the Server

Integration with MCP Clients

Example Usage

Check a Suspicious URL

Search for PayPal Phishing

Get Recent Phishing Statistics

Rate Limiting

Caching

Error Handling

API Response Format

Security Considerations

Development

Scripts

Project Structure

Contributing

License

Related Projects

Support

Acknowledgments

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

1. `check_url`

2. `check_multiple_urls`

3. `get_recent_phish`

4. `search_phish_by_target`

5. `get_phish_details`

6. `get_phish_stats`

7. `search_phish_by_date`