Skip to main content
Glama
ascentkorea

Hubble MCP Server

by ascentkorea

crawl_google_trends

Collect Google Trends data to analyze search interest trends for up to three keywords in South Korea or Japan over specific timeframes, returning normalized 0-100 values for comparison.

Instructions

구글 트렌드 수집 요청
최근 며칠 이내의 키워드 트렌드 추이를 0~100 사이의 값으로 표현 됩니다.
(검색량은 아니고, 검색 관심도를 나타냅니다. 해당 수치는 0~100 사이의 값으로 표현 됩니다.)
trends: 기간을 기준으로 차트에서 가장 높은 지점 대비 검색 관심도를 나타냅니다. 
값은 검색 빈도가 가장 높은 검색어의 경우 100, 검색 빈도가 그 절반 정도인 검색어의 경우 50, 
해당 검색어에 대한 데이터가 충분하지 않은 경우 0으로 나타납니다.
키워드 하나에 대한 검색 관심도 추이를 알수 있으며, 최대 3개 키워드를 비교 할수 있습니다.
특정 키워드하나를 입력했을때, 특정 기간의 최대값이 100 이라고 했을때,
키워드 여러개 입력시에는 검색관심도가 가장 큰 키워드는 0~100 사이값으로 표현되고, 나머지는 적절히 스케일링 되므로 
비교시에 특정 키워드의 최대값은 100이 아닐수 있습니다.
따라서, 키워드간 관심도 비교시에 4개 이상의 키워드를 비교 하기 위해서는 
우선 3개를 비교 하고, 이후 가장 높은 관심도가 있는 키워드를 계속 같이 추가해야 각 수치간에 비교가 가능해집니다.
args:
    keywords: List[str], 키워드 리스트
    location: Literal['South Korea', 'Japan'],
    timeframe: Literal['now 1-H', 'now 7-d', 'today 1-m'],
    gl: Literal['kr', 'jp']
returns:
    dict[Any] | None: 구글 트렌드 수집 결과

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
req_paramYes

Implementation Reference

  • The handler function for the 'crawl_google_trends' tool. It is registered via @mcp.tool() decorator and includes retry logic. Makes an HTTP POST request to the external Hubble API's /google_trend endpoint with the input parameters.
    @async_retry(exceptions=(Exception), tries=2, delay=0.3)
    async def crawl_google_trends(
            req_param: GoogleTrendsParameters) -> dict[Any] | None:
        '''
        구글 트렌드 수집 요청
        최근 며칠 이내의 키워드 트렌드 추이를 0~100 사이의 값으로 표현 됩니다.
        (검색량은 아니고, 검색 관심도를 나타냅니다. 해당 수치는 0~100 사이의 값으로 표현 됩니다.)
        trends: 기간을 기준으로 차트에서 가장 높은 지점 대비 검색 관심도를 나타냅니다. 
        값은 검색 빈도가 가장 높은 검색어의 경우 100, 검색 빈도가 그 절반 정도인 검색어의 경우 50, 
        해당 검색어에 대한 데이터가 충분하지 않은 경우 0으로 나타납니다.
        키워드 하나에 대한 검색 관심도 추이를 알수 있으며, 최대 3개 키워드를 비교 할수 있습니다.
        특정 키워드하나를 입력했을때, 특정 기간의 최대값이 100 이라고 했을때,
        키워드 여러개 입력시에는 검색관심도가 가장 큰 키워드는 0~100 사이값으로 표현되고, 나머지는 적절히 스케일링 되므로 
        비교시에 특정 키워드의 최대값은 100이 아닐수 있습니다.
        따라서, 키워드간 관심도 비교시에 4개 이상의 키워드를 비교 하기 위해서는 
        우선 3개를 비교 하고, 이후 가장 높은 관심도가 있는 키워드를 계속 같이 추가해야 각 수치간에 비교가 가능해집니다.
        args:
            keywords: List[str], 키워드 리스트
            location: Literal['South Korea', 'Japan'],
            timeframe: Literal['now 1-H', 'now 7-d', 'today 1-m'],
            gl: Literal['kr', 'jp']
        returns:
            dict[Any] | None: 구글 트렌드 수집 결과
        '''
        async with httpx.AsyncClient() as client:
            headers = {"X-API-Key": HUBBLE_API_KEY}
            response = await client.post(
                f"{HUBBLE_API_URL}/google_trend",
                headers=headers,
                json=req_param.model_dump(),
                timeout=30.0)
            response.raise_for_status()
            return response.text
  • Pydantic BaseModel defining the input schema (parameters) for the crawl_google_trends tool, including keywords list, location, timeframe, and gl.
    class GoogleTrendsParameters(BaseModel):
        keywords: List[str] = Field(
            min_items=1,
            max_items=3,
        )
        location: Literal['South Korea', 'Japan']
        timeframe: Literal['now 1-H', 'now 7-d', 'today 1-m']
        gl: Literal['kr', 'jp']
    @mcp.tool()
  • data_api.py:464-464 (registration)
    The @mcp.tool() decorator registers the crawl_google_trends function as an MCP tool.
    @async_retry(exceptions=(Exception), tries=2, delay=0.3)
Behavior4/5

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

With no annotations provided, the description carries full burden and does well by disclosing key behavioral traits: it explains the output format (0-100 values for search interest, not search volume), scaling behavior for multiple keywords, and the need for iterative comparisons with 4+ keywords. It also notes data availability issues (value 0 if insufficient data). However, it misses details like rate limits or 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.

Conciseness3/5

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

The description is front-loaded with purpose and key details, but it becomes verbose with repetitive explanations of the 0-100 scale and comparison logic. Sentences like '값은 검색 빈도가 가장 높은 검색어의 경우 100...' could be condensed. The structure includes clear sections (args, returns), but some redundancy reduces efficiency.

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 no annotations, no output schema, and 0% schema coverage, the description does a good job covering essentials: it explains the tool's purpose, parameters, and behavioral traits like output scaling. It provides enough context for an agent to use the tool effectively, though it could benefit from more on error cases or example usage to reach a perfect score.

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?

Schema description coverage is 0%, so the description must compensate. It adds significant meaning beyond the schema: it explains keywords as a list for trend comparison (up to 3 items), clarifies location and gl as country-specific settings, and describes timeframe options for recent periods. The args section explicitly lists parameters with types and purposes, though it could better explain enum values like 'now 1-H'.

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 collects Google Trends data for keywords, showing search interest trends over recent days with 0-100 values. It specifies the verb 'crawl_google_trends' and resource 'keywords', distinguishing it from siblings like crawl_google_serp or crawl_google_suggest. However, it doesn't explicitly contrast with all siblings, missing a perfect score.

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 by detailing what the tool does (collect trends for keywords) and mentions limitations like max 3 keywords and scaling behavior for comparisons. It provides some context on when to use it (for trend analysis) but lacks explicit guidance on when to choose this over alternatives like get_keyword_info or clear exclusions, leaving usage somewhat inferred.

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/ascentkorea/hubble_mcp'

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