Skip to main content
Glama
KasperskyLab

Kaspersky OpenTIP MCP Server

Official
by KasperskyLab

search_domain

Read-only

Check web domains for security threats using Kaspersky's threat intelligence database to identify malicious activity.

Instructions

Get threat intelligence data about a web domain

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
domainYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Implementation Reference

  • The handler function for the 'search_domain' MCP tool, including registration via @mcp.tool decorator. It calls the OpenTIP API to search for threat intelligence on a given domain.
    @mcp.tool(
        description="Get threat intelligence data about a web domain",
        annotations=ToolAnnotations(
            title="Investigate a domain",
            readOnlyHint=True,
            openWorldHint=True,
        ),
    )
    async def search_domain(domain: str) -> dict[str, Any] | None:
        """Get threat intelligence data about a web domain
    
        Args:
            domain: domain that you want to investigate
        """
        params = {"request": domain}
        return await opentip_request(Endpoints.search_domain, "get", params)
  • Enum defining API endpoints used by the search_domain tool.
    class Endpoints(StrEnum):
        search_hash = "search/hash"
        search_ip = "search/ip"
        search_domain = "search/domain"
        search_url = "search/url"
        analyze_file = "scan/file"
        get_analysis_results = "getresult/file"
  • Helper function that performs the actual API request for search_domain and other tools.
    async def opentip_request(
        endpoint: str,
        request_type: RequestType = "get",
        params: Optional[dict[str, Any]] = None,
        content: Optional[bytes] = None,
        headers: Optional[dict[str, str]] = None,
    ) -> dict[str, Any]:
        """Make a request to the OpenTIP API with proper error handling."""
        headers = headers or {}
        headers = {
            "user-agent": "opentip-mcp-client",
            "x-api-key": OPENTIP_API_KEY,
            **headers
        }
    
        async with httpx.AsyncClient() as client:
            try:
                url = f"{OPENTIP_API_BASE}{endpoint}"
                if request_type == "get":
                    response = await client.get(
                        url, headers=headers, params=params, timeout=OPENTIP_API_TIMEOUT
                    )
                elif request_type == "post":
                    response = await client.post(
                        url, headers=headers, params=params, content=content, timeout=OPENTIP_API_TIMEOUT
                    )
                response.raise_for_status()
                return response.json()
            except httpx.HTTPStatusError as e:
                if e.response.status_code == 400:
                    return {"result": "error", "error_message": "Invalid parameters. Please check your input and try again."}
                elif e.response.status_code == 401:
                    return {"result": "error", "error_message": "Authentication failed. Please ensure that you have provided the correct credentials and try again."}
                elif e.response.status_code == 403:
                    return {"result": "error", "error_message": "Quota or request limit exceeded. Check your quota and limits and try again."}
                else:
                    return {"result": "error", "error_message": str(e)}
            except Exception as e:  # noqa
                return {"result": "error", "error_message": str(e)}
Behavior3/5

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

Annotations already declare readOnlyHint=true and openWorldHint=true, indicating a safe, open-ended query. The description adds value by specifying the type of data ('threat intelligence'), but doesn't disclose additional behavioral traits like rate limits, authentication needs, or response format details beyond what annotations provide.

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 a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's front-loaded and wastes no space, making it highly concise and well-structured for quick understanding.

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 low complexity (one parameter), annotations covering safety and openness, and the presence of an output schema (which handles return values), the description is reasonably complete. It could improve by adding usage guidelines, but it adequately conveys the core purpose in context.

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 0%, so the schema only provides a basic parameter name and type. The description adds some context by implying the parameter is for a 'web domain', but doesn't elaborate on format (e.g., TLD requirements) or examples. With one parameter, this is minimally adequate but lacks depth.

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 verb ('Get') and resource ('threat intelligence data about a web domain'), making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like search_ip or search_url beyond the domain focus, which is implied but not stated.

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. The description mentions 'web domain' but doesn't specify scenarios or exclusions, such as when to use search_ip for IP addresses instead. This leaves the agent without explicit usage context.

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/KasperskyLab/threat-intelligence'

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