Skip to main content
Glama
aizukanne

ihyee-mcp

by aizukanne
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

ihyee-mcp

MCP (Model Context Protocol) server for the ihyee web intelligence API. Gives AI assistants like Claude, Cursor, and other MCP clients the ability to search the web, fetch pages, and render JavaScript-heavy sites.

Tools

Tool

Description

ihyee_search

Search the web and return extracted, summarized content from top results

ihyee_fetch

Fetch and extract content from specific web page URLs

ihyee_render

Force full browser rendering of a JavaScript-heavy web page

Related MCP server: o3-search MCP

Install

pip install ihyee-mcp

Configure

Set your ihyee API key as an environment variable:

export IHYEE_API_KEY="your_api_key_here"

Get an API key at ihyee.delta-telematics.ca.

Usage

With Claude Desktop

Add to your claude_desktop_config.json:

{
  "mcpServers": {
    "ihyee": {
      "command": "ihyee-mcp",
      "env": {
        "IHYEE_API_KEY": "your_api_key_here"
      }
    }
  }
}

Config file locations:

  • macOS: ~/Library/Application Support/Claude/claude_desktop_config.json

  • Windows: %APPDATA%\Claude\claude_desktop_config.json

  • Linux: ~/.config/Claude/claude_desktop_config.json

With Claude Code

claude mcp add ihyee -- ihyee-mcp

Then set the API key in your environment or pass it via the MCP config.

With Cursor

Add to your Cursor MCP settings (.cursor/mcp.json):

{
  "mcpServers": {
    "ihyee": {
      "command": "ihyee-mcp",
      "env": {
        "IHYEE_API_KEY": "your_api_key_here"
      }
    }
  }
}

Direct (stdio)

IHYEE_API_KEY=your_key ihyee-mcp

The server communicates over stdin/stdout using the MCP protocol.

Tool Details

ihyee_search

Search the web and return extracted content from top results.

Parameters:

Parameter

Type

Required

Default

Description

query

string

Yes

Search query

max_results

integer

No

5

Number of results (1-10)

content_mode

string

No

"both"

"both", "full_text", or "summary"

render

boolean

No

false

Use browser rendering

before

string

No

Results before date (YYYY-MM-DD)

after

string

No

Results after date (YYYY-MM-DD)

must_have

string

No

Required exact phrase

ihyee_fetch

Fetch and extract content from specific URLs.

Parameters:

Parameter

Type

Required

Default

Description

urls

string[]

Yes

URLs to fetch (max 10)

content_mode

string

No

"both"

"both", "full_text", or "summary"

render

boolean

No

false

Use browser rendering

ihyee_render

Force browser rendering for JavaScript-heavy pages.

Parameters:

Parameter

Type

Required

Default

Description

url

string

Yes

URL to render

wait_for

string

No

"networkidle"

"networkidle", "domcontentloaded", or "load"

wait_selector

string

No

CSS selector to wait for

timeout_ms

integer

No

30000

Max wait time in ms

Development

git clone https://github.com/aizukanne/ihyee-mcp.git
cd ihyee-mcp
pip install -e ".[dev]"
pytest

License

MIT

Available Tools

3 tools
ihyee_fetchB

Fetch and extract clean content from specific web page URLs. Returns extracted text, summaries, metadata, and links from each page.

ParametersJSON Schema
NameRequiredDescriptionDefault
urlsYesList of URLs to fetch (maximum 10)
content_modeNoWhat content to extract: 'both', 'full_text', or 'summary'both
renderNoWhether to use browser rendering for JavaScript-heavy pages

TDQS

B3.2/5.0
Behavior2/5

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

No annotations are provided, so the description carries the full burden. It mentions 'fetch and extract clean content' and returns specific data types, but does not disclose behavioral traits such as rate limits, authentication needs, error handling, or what 'clean content' entails. This leaves significant gaps for a tool that interacts with external web resources.

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 front-loaded and efficiently structured in two sentences with zero waste. It clearly states the tool's purpose and outputs without unnecessary details, making it easy to understand quickly.

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 complexity of web fetching and extraction, no annotations, and no output schema, the description is incomplete. It lacks details on behavioral aspects like permissions, rate limits, or error cases, and does not explain the structure or format of returned data, leaving the agent with insufficient context for reliable use.

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%, so the schema fully documents parameters. The description adds no additional meaning beyond what the schema provides, such as explaining the implications of 'content_mode' choices or when to use 'render'. Baseline 3 is appropriate as the schema does the heavy lifting.

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 action ('fetch and extract clean content') and resource ('from specific web page URLs'), and specifies the return values ('extracted text, summaries, metadata, and links'). It distinguishes from sibling tools by focusing on direct URL fetching rather than rendering or searching, though not explicitly named.

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 extracting content from web pages, but does not explicitly state when to use this tool versus alternatives like 'ihyee_render' or 'ihyee_search'. It provides some context with the 'render' parameter hinting at JavaScript-heavy pages, but lacks clear guidance on tool selection.

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

ihyee_renderA

Force full browser rendering of a JavaScript-heavy web page using Playwright, then extract its content. Use this for single-page apps, pages behind JS frameworks, or when a regular fetch returns incomplete content.

ParametersJSON Schema
NameRequiredDescriptionDefault
urlYesThe URL to render
wait_forNoWhen to consider the page loadednetworkidle
wait_selectorNoCSS selector to wait for before extracting content
timeout_msNoMaximum time to wait for page load in milliseconds

TDQS

A4.1/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 the full burden of behavioral disclosure. It describes the core behavior ('Force full browser rendering', 'extract its content') and context ('JavaScript-heavy web page'), but lacks details on error handling, performance characteristics (e.g., slower than fetch), or output format. For a tool with no annotations, this provides basic transparency but misses key operational details.

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 two sentences that are front-loaded with the core purpose and usage guidelines. Every sentence earns its place: the first defines the tool's action, and the second provides critical context for when to use it. There is zero waste or redundancy.

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 no annotations and no output schema, the description is incomplete for a tool that performs complex rendering and extraction. It covers purpose and usage well but lacks information on what 'extract its content' returns (e.g., HTML, text, screenshots), error scenarios, or performance implications. For a 4-parameter tool with no structured output documentation, this leaves significant 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%, so the schema fully documents all 4 parameters. The description adds no parameter-specific information beyond what's in the schema (e.g., it doesn't explain 'wait_for' options or 'wait_selector' usage). With high schema coverage, the baseline score of 3 is appropriate as the description doesn't enhance parameter understanding.

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 tool's purpose with specific verbs ('Force full browser rendering', 'extract its content') and resource ('JavaScript-heavy web page using Playwright'). It distinguishes from sibling tools by specifying use cases like 'single-page apps, pages behind JS frameworks, or when a regular fetch returns incomplete content', which differentiates it from ihyee_fetch (likely a regular fetch) and ihyee_search (likely a search operation).

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?

The description explicitly states when to use this tool ('Use this for single-page apps, pages behind JS frameworks, or when a regular fetch returns incomplete content'), providing clear context and alternatives (implied regular fetch). It effectively guides the agent to choose this tool over ihyee_fetch for JavaScript-heavy content extraction scenarios.

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.

  1. 3 tool updatesv0.1.0
    • First observedihyee_fetch
    • First observedihyee_render
    • First observedihyee_search
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.7/5.0

Scored across 3 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: ihyee_fetch for direct URL content extraction, ihyee_render for JavaScript-heavy pages requiring full browser rendering, and ihyee_search for web search with result extraction. There is no overlap or ambiguity between these functions.

Naming Consistency5/5

All tool names follow a consistent 'ihyee_' prefix with descriptive suffixes (fetch, render, search) in snake_case. The naming pattern is uniform and predictable across all tools.

Tool Count4/5

Three tools is a reasonable count for a web content extraction server, covering core scenarios (direct fetch, JS rendering, search). It might feel slightly thin if advanced features like batch processing or filtering are expected, but it's well-scoped for the apparent purpose.

Completeness4/5

The toolset covers key web content extraction workflows: fetching from URLs, handling JavaScript-heavy pages, and searching the web. Minor gaps might include operations like caching, content filtering, or handling specific formats (e.g., PDFs), but the core domain is adequately addressed.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • MCP2Tavily

    mcp2everything
    F
    license
    C
    quality
    D
    maintenance
    An MCP protocol server that enables web search functionality using the Tavily API, allowing AI assistants to perform internet searches in real-time.
    4
    4
    -

  • o3-search MCP

    yoshiko-pg
    A
    license
    A
    quality
    C
    maintenance
    An MCP server that enables web search capabilities using OpenAI's o3 model, allowing AI assistants to perform text-based web searches and return AI-powered results.
    1
    112 npm
    288
    MIT

  • web-fetch-mcp

    xiaozhuABCD1234
    A
    license
    Not graded
    quality
    D
    maintenance
    An MCP server that provides web scraping and Bing search capabilities, supporting both static and dynamic content through Puppeteer. It allows AI assistants to extract page summaries, SEO metadata, and full text with automatic detection for headless browser rendering.
    GPL 3.0

  • mult-fetch-mcp-server

    lmcc-dev
    A
    license
    A
    quality
    C
    maintenance
    An MCP server that enables AI assistants to fetch web content in multiple formats (HTML, JSON, text, Markdown) with intelligent content extraction, chunk management, and browser automation support.
    5
    52 npm
    15
    MIT