Phishunt
Server Details
Public phishing feed: suspicious/confirmed phishing URLs detected hourly. No auth, CC0.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- 0xDanielLopez/phishunt-mcp
- GitHub Stars
- 1
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Score is being calculated. Check back soon.
Available Tools
10 toolsanalyze_urlAInspect
Analyze any URL for phishing signals WITHOUT contacting it (passive): live URL-shape heuristics (brand keyword match, typosquat distance, homograph, entropy, abused TLD), phishunt's stored score/verdict if the domain is already known, and historical detections on the same apex domain. Suspicious unknown domains are automatically queued for full pipeline analysis.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Full URL or bare domain to analyze |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses passive nature, use of heuristics, stored scores, and queuing for unknown domains. Lacks details on error handling or edge cases, but overall transparent about key behaviors.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with dense, relevant information. Front-loaded with core purpose and key constraint (passive). No superfluous details. Every part of the description contributes meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (single parameter, no nested objects, no output schema), the description covers the analysis scope, method, and post-processing behavior comprehensively. No gaps evident for its intended use case.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 1 param with a minimal description; the tool description adds significant context about what the URL is used for (phishing analysis, passive), enhancing understanding beyond the schema alone. Since schema coverage is 100%, baseline is 3, and the added value justifies a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the action ('Analyze'), resource ('any URL'), and scope ('for phishing signals'). Emphasizes passive analysis, which distinguishes it from potential active tools. Verb+resource combination is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus siblings like check_domain or get_brand_metadata. The purpose is clear, but selection criteria are not stated. Implicitly, it's for passive URL analysis, but alternatives are not mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
check_domainInspect
Check whether a domain (or URL substring) appears in the phishunt active phishing feed. Returns matching entries with detection metadata if found, or a 'not found' note otherwise.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | Domain or URL substring to search (e.g. 'fake-bank.com'). Case-insensitive substring match against the feed. |
get_brand_metadataInspect
Fetch curated metadata for a tracked brand: display name, category, primary domain, an AI-authored characterisation of why the brand tends to be targeted by phishing, and the current count of active phishings. Useful for adding context to brand-specific responses.
| Name | Required | Description | Default |
|---|---|---|---|
| brand | Yes | Brand slug (lowercase). Examples: 'amazon', 'binance', 'paypal', 'microsoft'. See https://phishunt.io/api/ for the full list. |
get_campaignInspect
Get full detail on one possible campaign / suspected cluster: evidence breakdown and every member indicator (domain, targeted brand, status, relationship score, detail page). Shared-infrastructure grouping of public detections, not an attribution claim.
| Name | Required | Description | Default |
|---|---|---|---|
| campaign_id | Yes | Campaign (cluster) id, from the 'id' field of get_campaigns results. |
get_campaignsInspect
List possible campaigns / suspected clusters: groups of phishing indicators that share infrastructure or content signals (same TLS certificate, IP, hosting, page content, etc.), computed by a daily correlation job. This is shared-infrastructure grouping of public detections, not an attribution claim - clusters are labeled 'possible campaign' or 'suspected cluster' only, never an actor or group.
| Name | Required | Description | Default |
|---|---|---|---|
| brand | No | Filter to campaigns with at least one member targeting this brand slug (e.g. 'coinbase'). | |
| limit | No | Max campaigns to return (1-50). Default 10. | |
| active_only | No | If true, only return campaigns with at least one currently-active member. Default false (all). |
get_cert_metadataAInspect
Fetch factual metadata for a TLS intermediate CA seen on phishing sites: operator, root CA, key type (RSA/ECDSA), typical use case, related sibling intermediates, and the count of active phishings using this intermediate. Helps answer 'I saw cert X in my browser, what is it?' for the most-abused intermediates.
| Name | Required | Description | Default |
|---|---|---|---|
| cert | Yes | Intermediate CA common name as stored by phishunt (e.g. 'WE1', 'R10', 'GTS CA 1C3'). Case-sensitive exact match. See https://phishunt.io/cert/ for the list. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must convey behavior. It states the tool 'fetches factual metadata', indicating a read-only operation. It lists the output fields, providing sufficient transparency for an agent to understand its effects. However, it does not discuss rate limits, authentication, or data freshness.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, directly stating the action and listing outputs. It is front-loaded with the core purpose and contains no fluff. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool without output schema or annotations, the description provides a solid overview of inputs and outputs, and a use case. It does not cover error handling or whether the certificate list is exhaustive, but it is largely complete for typical usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a clear parameter description including example values and a reference URL. The tool description adds context about the purpose but does not add essential extra 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches factual metadata for TLS intermediate CAs seen on phishing sites, listing specific fields like operator, root CA, key type, and use case. It also provides a representative query ('I saw cert X in my browser, what is it?') and distinguishes from siblings which deal with URLs, domains, or brands.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage through a real-world scenario ('I saw cert X') but does not explicitly state when not to use or provide alternatives. It mentions 'most-abused intermediates', hinting at scope, but lacks explicit exclusions or comparisons to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_recent_detectionsAInspect
Retrieve phishing detections since a given date. Useful for delta-syncing a blocklist or threat intel pipeline.
| Name | Required | Description | Default |
|---|---|---|---|
| brand | No | Optional brand slug filter (e.g. 'amazon'). | |
| limit | No | Max results (1-1000). Default 100. | |
| since | Yes | ISO date (YYYY-MM-DD) for the lower bound. Example: '2026-04-15'. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description discloses it returns detections but omits details like pagination, result format, or rate limits. Adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, direct, no wordiness. Front-loads core action and use case.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Lacks output description or sample, but use case is clear. Given no output schema, more detail on return values would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions cover 100% of parameters (since, brand, limit). Description adds minimal value beyond 'since a given date', so baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states action ('retrieve phishing detections'), key parameter ('since a given date'), and use case ('delta-syncing a blocklist or threat intel pipeline'). Distinguishes from sibling tools like 'analyze_url' or 'check_domain'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states its primary use case (delta-syncing). Does not provide when-not-to-use or alternatives, but context is sufficient given the name and purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_brand_phishingsAInspect
List active phishing sites targeting a specific brand. Returns the most recent detections with URL, IP, country, cert issuer, hosting org, and detection source flags.
| Name | Required | Description | Default |
|---|---|---|---|
| brand | Yes | Brand slug (lowercase). Examples: 'microsoft', 'binance', 'spotify', 'paypal'. See https://phishunt.io/api/ for the full list. | |
| limit | No | Max results (1-1000). Default 50. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description accurately describes the tool's behavior: it returns a list of recent detections with specified fields. It does not mention side effects (none expected) but lacks details on pagination or rate limits. Still, it's fairly transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no wasted words, front-loaded with the core action and return details. Highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description explains what the tool returns (URL, IP, etc.), and the two parameters are well-documented in the schema. For a simple list tool, the description is complete and sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The tool description doesn't add new semantic meaning beyond what the schema already provides for brand and limit. It mentions return fields but not parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists active phishing sites for a specific brand, using the verb 'List' and specifying the resource. It distinguishes from siblings like search_phishings by focusing on a specific brand and returning detections with specific fields.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use (for brand-specific phishing listings) but does not explicitly tell when not to use or compare with alternatives like search_phishings. It gives clear context but lacks exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_phishingsAInspect
Free-text search across active phishing URLs, domains, and IP addresses. Returns matching detections sorted by most recent first_seen. Use for queries like 'show me sites containing steamcommunity', 'phishing on 1.2.3.4', or 'sites with ingdirect in the URL'.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results (1-200). Default 50. | |
| query | Yes | Search string (min 3 chars). Case-insensitive substring match against URL, domain, or IP. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It mentions the tool searches 'active' phishing data and sorts by first_seen, but lacks details on data freshness, rate limits, or pagination. Adequate but could be more transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Exactly two sentences: first defines purpose and sorting, second gives three varied examples. No unnecessary words, front-loaded effectively.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description should hint at return structure. It says 'returns matching detections' but does not specify fields, leaving the user to guess. Missing explicit differentiation from siblings in a complex tool set.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with clear parameter descriptions. The description adds examples but no new semantic information beyond what the schema provides, warranting a baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it performs free-text search across active phishing URLs, domains, and IP addresses, returning detections sorted by first_seen. It distinguishes from siblings in purpose but does not explicitly differentiate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides concrete query examples that illustrate when to use this tool. However, no explicit guidance on when not to use it or how it compares to alternative sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!