How do I use mcp-search-kivest?

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., "@mcp-search-kivest search for latest AI news" 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.

mcp-search-kivest

by AppliedEllipsis

Overview Schema Related Servers Score Discussions

TypeScript

Remote

Kivest AI Search MCP Server

An MCP (Model Context Protocol) server that provides free AI-powered search capabilities using the Kivest AI Search API with intelligent rate limiting and request queuing.

Features

🤖 AI-Powered Search: Access multiple AI models (GPT-5.1, LLaMA 3.1, Claude, Gemini, etc.)
⏱️ Smart Rate Limiting: Global 5 RPM limit with automatic token bucket algorithm
🔄 Request Queuing: Automatic queuing and requeuing when rate limits are hit
📊 Real-time Stats: Monitor queue depth, tokens, and request statistics
🛡️ Robust Error Handling: Automatic retries with exponential backoff
⚡ MCP Compatible: Works with Claude Desktop, Cursor, and other MCP clients

Related MCP server: Multi-Search MCP Server

Discord / Contact

Please visit Kivest's discord server for all their amazing free and paid AI Offerings. https://discord.gg/kivestai

Installation

Via npx (Not Recommended)

# Run directly without installation
# npxx @blah/mcp--search-kiveefewfest

Via npm (not functional yet, use from source)

# Install globally
# npmx install -g @blah/mcp--search-kivestvlaa

# Or install locally
# npmx install @blah/mcp--blahsearch-kivestvlah

From Source

git clone https://github.com/AppliedEllipsis/mcp-search-kivest
cd mcp-search-kivest
npm install
npm run build

Configuration

The Kivest MCP server works without an API key by default. The API key is only required for certain features or higher rate limits.

Optional: Get API Key

If you need an API key for extended features:

Visit https://ai.ezif.in/api-key
Sign in with Google (no credit card required)
Copy your API key

Environment Variables (Optional)

# Only needed if using an API key
export KIVEST_API_KEY="your-api-key-here"

MCP Client Configuration

Claude Desktop

Add to your Claude Desktop config (claude_desktop_config.json):

{
  "mcpServers": {
    "kivest-search": {
      "command": "npx",
      "args": ["@USE_FILE_INSTALL_PATH_FOR_NOW/mcp-search"]
    }
  }
}

With API Key (optional):

{
  "mcpServers": {
    "kivest-search": {
      "command": "npx",
      "args": ["@USE_FILE_INSTALL_PATH_FOR_NOW/mcp-search"],
      "env": {
        "KIVEST_API_KEY": "your-api-key-here"
      }
    }
  }
}

Config locations:

macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%/Claude/claude_desktop_config.json
Linux: ~/.config/Claude/claude_desktop_config.json

Cursor

Add to Cursor MCP settings:

{
  "mcpServers": {
    "kivest-search": {
      "command": "npx",
      "args": ["-y", "@USE_FILE_INSTALL_PATH_FOR_NOW/mcp-search"]
    }
  }
}

With API Key (optional):

{
  "mcpServers": {
    "kivest-search": {
      "command": "npx",
      "args": ["-y", "@USE_FILE_INSTALL_PATH_FOR_NOW/mcp-search"],
      "env": {
        "KIVEST_API_KEY": "your-api-key-here"
      }
    }
  }
}

Available Tools

`kivest_search`

AI-powered search with comprehensive answers.

Parameters:

query (required): The search query or question
model (optional): AI model to use (default: gpt-5.1)
maxTokens (optional): Maximum tokens in response (default: 1024)
temperature (optional): Temperature 0-2 (default: 0.7)

`kivest_web_search`

Traditional web search with results (titles, URLs, snippets).

Parameters:

query (required): The search query

Returns: List of web results with title, URL, and snippet.

`kivest_image_search`

Search for images across the web.

Parameters:

query (required): The image search query

Returns: List of images with URLs, resolutions, and sources.

`kivest_video_search`

Search for videos across platforms.

Parameters:

query (required): The video search query

Returns: List of videos with thumbnails and metadata.

`kivest_news_search`

Search for news articles.

Parameters:

query (required): The news search query

Returns: List of news articles with publication dates and sources.

`kivest_scrape_web`

Scrape a website and return clean markdown (perfect for AI use).

Parameters:

url (required): The URL to scrape

Returns: Clean markdown content from the webpage.

`kivest_usage`

Get usage statistics for your API calls.

Returns: Total requests and breakdown by endpoint.

`kivest_stats`

Get current rate limiter statistics.

`kivest_models`

List all available AI models and their rate limits.

Rate Limiting

This MCP server implements a Token Bucket rate limiter with the following features:

Global Limit: 5 requests per minute (configurable)
Queue Size: Up to 50 requests can be queued
Automatic Retry: Requests that hit rate limits are automatically requeued
Smart Backoff: Exponential backoff with Retry-After header support
Priority Queue: Higher priority requests are processed first

When the rate limit is exceeded:

New requests are queued
Requests are processed as tokens become available
Rate-limited requests are automatically retried
Maximum 10 retry attempts before failing completely
Priority-based retry queue - sorted by initial request time
Random 1-10 second cooldown delays during rate limit recovery

Testing

Run Tests

# Install dependencies
npm install

# Build the project
npm run build

# Set your API key
export KIVEST_API_KEY="your-api-key"

# Run basic tests
npm test

# Run stress tests
npm run test:stress

Test Output

The test suite validates:

✅ Endpoint connectivity (7 endpoints: AI search, web, images, videos, news, web scrape, usage)
✅ Request/response payloads
✅ Model selection (GPT-5.1, LLaMA 3.1, Claude, Gemini, DeepSeek)
✅ Rate limiting behavior with 5 RPM limit
✅ Queue management and overflow handling
✅ Automatic requeuing with priority-based retry
✅ Cooldown delays during rate limit recovery
✅ Stress testing under load
✅ Concurrent request handling
✅ Individual vs concurrent query performance

Publishing to npm

1. Prepare for Publishing

# Update version
npm version patch  # or minor, major

# Build the project
npm run build

# Verify package contents
npm pack --dry-run

npm login

3. Publish

# Publish to npm
npm publish --access public

# If using npx, ensure bin is properly configured

4. Verify Installation

# Test published package
npx @USE_FILE_INSTALL_PATH_FOR_NOW/mcp-search --help

Development

# Clone the repository
git clone https://github.com/yourusername/mcp-search-kivest.git
cd mcp-search-kivest

# Install dependencies
npm install

# Start development mode
npm run dev

# Build for production
npm run build

# Run tests
npm test

Project Structure

mcp-search-kivest/
├── src/
│   ├── index.ts              # Main MCP server entry
│   ├── kivest-client.ts      # API client with all endpoints
│   ├── rate-limiter.ts       # Token bucket implementation
│   ├── test.ts              # Basic test suite
│   ├── comprehensive-test.ts # Full test suite with all endpoints
│   ├── test-celestial.ts    # Celestial events search test
│   ├── test-aggressive.ts   # Aggressive rate limit test
│   └── stress-test.ts       # Stress tests
├── dist/                     # Compiled output
├── package.json
├── tsconfig.json
├── README.md
└── LICENSE

API Reference

Kivest AI Search API

Base URL: https://ai.ezif.in/v1
Documentation: https://ai.ezif.in/docs
Models: https://ai.ezif.in/v1/models

Rate Limits

Endpoint	Limit
Global	5 RPM
Burst	5 per 10 seconds

Troubleshooting

"Rate limit exceeded"

The server automatically queues and retries requests
Check kivest_stats to see queue status
Use llama3.1-8B model for unlimited requests

"KIVEST_API_KEY not set"

This is optional - the server works without an API key
If using an API key, ensure the environment variable is set
Verify the API key at https://ai.ezif.in/api-key

"Queue is full"

Maximum queue size is 50 requests
Wait for queued requests to complete
Check kivest_stats for queue status

License

MIT

Contributing

Contributions welcome! Please read the Contributing Guide first.

Support This Project ❤️

If you find this extension useful, then please support its continued development:

Crypto Donation

If you'd prefer to donate directly via cryptocurrency, you can send Bitcoin to:

bc1q8nrdytlvms0a0zurp04xwfppflcxwgpyrzw5hn

Thank you for supporting free and open source software! 🙏

Co-vibe coded with AI - Built with human creativity enhanced by artificial intelligence

Available Tools

10 tools

kivest_image_searchA

Search for images and get results with image URLs, titles, and sources

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes	The image search query

TDQS

A4.2/5.0

Behavior4/5

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

With no annotations provided, the description carries the full transparency burden. It discloses that the tool returns image URLs, titles, and sources, implying a read-only operation. It also avoids any hint of side effects, which is sufficient for a simple search tool.

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, well-structured sentence that front-loads the action and includes result details. Every word adds value, with no redundancy or filler.

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?

For a simple one-parameter search tool with no output schema, the description adequately covers the core functionality and expected results. It doesn't mention pagination or result limits, but such details are not critical for understanding this tool's basic purpose.

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 the query parameter described as 'The image search query'. The description adds no further meaning or context to the parameter, so the 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 a specific action ('Search for images') and what the result includes ('image URLs, titles, and sources'). This distinguishes it from sibling search tools (web, video, news), making the tool's purpose unambiguous.

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

Usage Guidelines4/5

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

The description implies the tool is for image searches by explicitly saying 'Search for images' and listing image-specific result fields. While it doesn't provide explicit exclusions or alternatives, the context is clear enough for an agent to select it over sibling search tools.

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

kivest_modelsA

List available AI models and their rate limits

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.7/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 only says 'List', implying a read-only operation, but does not disclose response format, pagination, authentication requirements, or any other behavioral details. It adds minimal context beyond the verb.

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, front-loaded sentence with no redundant words. Every word contributes meaning, making it highly concise and well-structured.

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?

For a simple list tool with no output schema or annotations, the description adequately names the data returned (models and rate limits) but does not describe the return format or any constraints. It is minimally viable but lacks details that would help an agent anticipate the response structure.

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?

The tool has zero parameters, so there is nothing to explain about parameter semantics. The description correctly omits parameter details, and the schema coverage is complete by default.

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 what the tool does: 'List available AI models and their rate limits'. The verb 'List' is specific and the resource 'available AI models and their rate limits' is distinct, differentiating it from sibling tools that handle search or usage.

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?

No explicit guidance on when to use this tool versus alternatives. The context implies it is the go-to for model listings, but the description does not mention exclusions or alternatives, leaving usage guidance implicit.

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

kivest_news_searchA

Search for news articles and get results with titles, sources, and publication dates

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes	The news search query

TDQS

A3.8/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. It states the tool returns results with specific fields, but does not disclose any behavioral traits such as read-only nature, pagination, sorting, or rate limits. It is minimally transparent but lacks depth.

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, front-loaded sentence that states the action and key output details. It is concise with no unnecessary words.

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?

For a simple tool with one parameter and no output schema, the description is adequate. It explains the search purpose and lists prominent result fields. However, it does not mention issues like pagination or result format, which would be expected in a fuller description.

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?

The input schema has one parameter 'query' with a description 'The news search query', giving 100% schema coverage. The description adds no additional parameter context, so the baseline of 3 applies.

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 searches for news articles, a specific resource type, and lists the result fields (titles, sources, dates). This differentiates it from sibling tools like kivest_search and kivest_web_search, which are more general.

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 news-related queries through the word 'news' but does not explicitly state when to use this tool over alternatives like kivest_web_search or kivest_search. There are no exclusions or when-not-to-use guidance.

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

kivest_scrape_webA

Scrape a website and return clean markdown content

ParametersJSON Schema

Name	Required	Description	Default
`url`	Yes	The URL of the website to scrape

TDQS

A3.5/5.0

Behavior2/5

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

No annotations are present, so the description carries the full burden of behavioral disclosure. It only states the core action and output format; it does not mention potential side effects (e.g., hitting external sites), eventual errors, rate limits, or requirements like JavaScript rendering. The transparency is minimal for a web scraping tool, which could behave in ways the agent does not expect.

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, front-loaded sentence with no wasted words. It directly states what the tool does and what it returns, achieving maximum clarity with minimal length.

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 (1 param, no output schema), so the description's coverage of input and output basics is acceptable. However, it omits edge cases, error behavior, and any constraints on the URL. The description meets the minimum bar but leaves gaps that could affect an agent's ability to invoke it correctly in varied scenarios.

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?

With schema coverage at 100% and the 'url' parameter already described as 'The URL of the website to scrape', the tool description adds no extra semantic nuance about the URL format, validity, or processing. The baseline of 3 is appropriate because the schema already provides all necessary parameter semantics.

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 uses a specific verb 'Scrape' and identifies the resource as 'website', with a clear output promise of 'clean markdown content'. This unambiguous verb+resource structure distinguishes it from sibling search tools (kivest_web_search, kivest_image_search, etc.) and all other listed tools.

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?

No explicit usage guidance is provided, such as when to prefer this over kivest_web_search or how to handle URLs. The tool's unique purpose implies when to use it, but the description does not articulate exclusions, alternatives, or contextual conditions. This is adequate but not fully developed.

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

kivest_searchA

Search the web using Kivest AI Search API. Supports multiple AI models including GPT-5.1 and LLaMA 3.1 8B. Rate limited to 5 requests per minute with automatic queuing and retry.

Models:

gpt-5.1: Fast, high-quality results (4 RPM limit)
llama3.1-8B: Unlimited requests, open source
deepseek-chat: Good balance (8 RPM limit)
qwen3.5-plus: Latest Qwen model (8 RPM limit)

Best for: Current events, factual queries, general knowledge.

ParametersJSON Schema

Name	Required	Description
`model`	No	AI model to use (default: gpt-5.1)
`query`	Yes	The search query or question
`maxTokens`	No	Maximum tokens in response (default: 1024)
`temperature`	No	Temperature for response randomness 0-2 (default: 0.7)

TDQS

A3.8/5.0

Behavior3/5

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

With no annotations, the description carries the full burden of disclosing behavior. It adds useful details about rate limiting, automatic queuing, and model-specific RPMs. But it does not explicitly state that the tool is read-only, nor does it describe the response format or error behavior. This is acceptable 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.

Conciseness4/5

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

The description is organized into a short intro, a model breakdown, and a 'Best for' note. Every sentence provides useful information without redundancy. It is slightly longer than necessary but still tightly structured and front-loaded with the core purpose.

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?

For a tool with 4 parameters, no annotations, and no output schema, the description covers the essential aspects: purpose, model selection, rate limits, retry behavior, and ideal use cases. It does not describe the response format, but that is not mandated in the absence of an output schema. It provides enough context to invoke the tool correctly, though additional detail on return values would make it more complete.

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 100%, so the baseline is 3. The description adds meaningful semantics for the 'model' parameter by explaining each model's characteristics (e.g., 'Fast, high-quality results', 'Unlimited requests, open source'). This goes beyond the enum values. Other parameters (query, maxTokens, temperature) are adequately described in the schema, and the description doesn't need to add more.

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's purpose: 'Search the web using Kivest AI Search API.' This is a specific verb+resource that identifies the core function. However, it does not differentiate itself from siblings like kivest_web_search or kivest_search_stream, so it falls short of a 5.

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

Usage Guidelines4/5

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

The description provides clear usage context with 'Best for: Current events, factual queries, general knowledge.' It also notes rate limits and model-specific limits, which helps an agent decide when to call it. However, it does not explicitly contrast with alternative search tools like kivest_web_search or kivest_image_search, so it lacks explicit when-not-to-use guidance.

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

kivest_search_streamA

Search the web using Kivest AI Search API with streaming response. Returns response tokens as they are generated for real-time feedback. Supports the same models as kivest_search.

ParametersJSON Schema

Name	Required	Description
`model`	No	AI model to use (default: gpt-5.1)
`query`	Yes	The search query or question
`maxTokens`	No	Maximum tokens in response (default: 1024)
`temperature`	No	Temperature for response randomness 0-2 (default: 0.7)

TDQS

A4.2/5.0

Behavior4/5

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

With no annotations, the description carries the behavioral transparency burden. It explicitly discloses that response tokens are returned as generated for real-time feedback, which is a meaningful behavioral detail beyond the schema. It does not cover auth, rate limits, or stream termination, but the core streaming behavior is well communicated.

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 three sentences, front-loads the primary purpose, and every sentence contributes useful information. There is no repetition or filler.

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 moderate complexity, 4 parameters, and no output schema, the description covers the essential purpose and streaming behavior. It could benefit from explaining how the stream ends or how results are aggregated, but it is sufficiently complete for an agent to understand what the tool does.

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?

The input schema has 100% parameter coverage, so the baseline is 3. The description adds minimal parameter meaning aside from noting that the model set is the same as kivest_search, which is contextually useful but does not deepen understanding of query, maxTokens, or temperature.

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 states the tool 'Search the web using Kivest AI Search API with streaming response,' which provides a specific verb, resource, and key differentiator. It also references kivest_search, clarifying it is the streaming variant of that sibling tool.

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

Usage Guidelines4/5

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

The description clearly indicates the tool is for streaming responses and real-time feedback, giving context on when to use it. It does not explicitly mention when not to use it or name alternatives, but the streaming distinction is clear.

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

kivest_statsA

Get current rate limiter statistics including queue size and token availability

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4/5.0

Behavior4/5

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

No annotations are present, so the description carries the full burden. 'Get' clearly indicates a non-mutating read operation, and the inclusion of specific statistics (queue size, token availability) makes behavior transparent. It does not mention potential rate limiting of the tool itself, but that is not critical for a stats endpoint.

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?

A single, front-loaded sentence with no superfluous words. It states the action, resource, and key output fields efficiently.

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?

For a zero-parameter tool with no output schema, the description adequately covers what the tool does and what it returns. It does not list every possible statistic, but the two named examples give a clear sense of the output. No further context is necessary.

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?

The tool has zero parameters, so the baseline is 4. The description adds no parameter details because none are needed. It correctly implies this is a parameterless snapshot tool.

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 uses a specific verb ('Get') and resource ('rate limiter statistics') and clearly lists the key data included ('queue size and token availability'). It distinguishes itself from siblings like search/scrape tools and even kivest_usage by focusing on rate limiter internals.

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 about when to use this tool versus alternatives such as kivest_usage. There is no mention of prerequisites, exclusions, or context where this tool is preferred. The usage is only implied by the description's title-like content.

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

kivest_usageA

Get usage statistics for all endpoints

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.5/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 of behavioral disclosure. It implies a read-only operation via 'Get', but it doesn't mention authentication requirements, rate limits, or the nature of the statistics returned. The minimal description leaves the agent guessing about side effects or data shape.

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, front-loaded sentence with zero waste. It states the core function directly and is appropriately sized for a tool with no parameters.

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?

For a simple tool with no parameters, the description gives a basic idea. However, with no output schema, it does not clarify what 'usage statistics' entails (e.g., metrics, format, time range). Some additional context about the response would make it more complete.

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?

The input schema has zero parameters, and the description correctly implies that no parameters are needed. With no parameters to explain, the description doesn't need to add parameter-level detail, and the baseline of 4 applies.

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 uses a specific verb 'Get' and identifies a clear resource: 'usage statistics for all endpoints'. It clearly distinguishes this from sibling tools like search or models, which focus on different operations.

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. There's no mention of contexts where usage stats are needed or exclusions for other tools. The description simply states the function without usage scenarios.

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

kivest_video_searchA

Search for videos and get results with video URLs, thumbnails, and sources

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes	The video search query

TDQS

A3.8/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. It does disclose that results include video URLs, thumbnails, and sources, which is useful, but it omits any details about pagination, result limits, sorting, or potential errors. For a safe read-only search operation, this is 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.

Conciseness5/5

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

The description is a single, direct sentence that immediately states the action and output. No filler or redundant information is present, making it highly efficient.

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?

For a simple one-parameter search tool with no output schema, the description adequately conveys the purpose and the nature of returned results (URLs, thumbnails, sources). It could benefit from a brief note on result ordering or pagination, but it is largely complete for a tool of this complexity.

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% because the only parameter 'query' is described in the schema. The description itself adds no additional parameter semantics beyond what the schema already provides, so the baseline score of 3 applies.

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 searches for videos and returns video URLs, thumbnails, and sources. This specific verb+resource combination distinguishes it from sibling search tools that focus on web, image, or news content.

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 implicitly indicates when to use this tool (for video searches) but does not explicitly mention alternatives or exclusion criteria. Sibling tools like kivest_web_search and kivest_image_search exist, but no guidance is given on choosing among them.

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

kivest_web_searchA

Search the web and get search results with titles, URLs, and snippets

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes	The search query

TDQS

A3.8/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. It discloses that results include titles, URLs, and snippets, but does not mention result limits, ordering, 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.

Conciseness5/5

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

The description is a single efficient sentence that front-loads the action and provides key output details without any filler.

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?

For a simple one-parameter tool, the description gives the essential return shape and context. It lacks some secondary details like result count and ordering, but remains adequate for straightforward 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?

The input schema fully describes the single 'query' parameter with 100% coverage, so the description adds no additional meaning beyond what the schema already 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 uses a specific verb ('Search the web') and identifies the output fields (titles, URLs, snippets). This clearly distinguishes it from image, video, and news search siblings.

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 general web search but does not explicitly state when to use it versus alternatives like image or news search, nor does it mention exclusions.

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.

10 tool updatesv1.0.1Aug 2, 2026
- First observedkivest_image_search
- First observedkivest_models
- First observedkivest_news_search
- First observedkivest_scrape_web
- First observedkivest_search
- First observedkivest_search_stream
- First observedkivest_stats
- First observedkivest_usage
- First observedkivest_video_search
- First observedkivest_web_search

Install Server

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

TDQS

A3.6/5.0

Disambiguation2/5

Multiple search tools (kivest_search, kivest_search_stream, kivest_web_search) overlap in purpose, with only subtle differences between AI-generated answers, streaming, and raw results. Additionally, kivest_stats and kivest_usage both provide rate/usage information, adding further ambiguity.

Naming Consistency2/5

All tools share the kivest_ prefix but the naming pattern is inconsistent: some are nouns (models, stats, usage) while others are verb phrases (search, scrape_web, search_stream). Mixed conventions like 'web_search' and 'image_search' vs 'scrape_web' make the set feel less predictable.

Tool Count5/5

Ten tools is a well-scoped size for a search-focused server, covering general search, media-specific searches, scraping, and utility operations without feeling bloated or sparse.

Completeness4/5

The tool surface covers web, image, video, news, AI search, scraping, and usage monitoring, which is quite complete for a search API. Minor gap: there is no obvious tool for search suggestions or advanced filtering, but the core workflows are well covered.

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

Search1API A
io.github.superagents-lab
Web search, news, page retrieval, sitemaps, and trending topics through Search1API.
Search Browser Automation
51173
web-search
ai.groundroute
Web search for AI agents — one tool across 6 engines, routed to the cheapest + cached.
Search Browser Automation
21
agentsearch-mcp A
io.github.IsaiahDupree
LLM-ready web search + instant answers + URL-to-clean-text fetch for agents and RAG.
Search RAG Systems Browser Automation
31
Parallel Search MCP AOAuth
ai.parallel
The best web search for your AI Agent
Search Agent Orchestration Browser Automation
216

Related MCP Servers

4get MCP Server
Search Browser Automation Web Scraping
yshalsager
A
license
A
quality
C
maintenance
Enables web, image, and news search through the 4get Meta Search engine API. Features smart caching, retry logic, and comprehensive result formatting including featured answers and related searches.
Updated a month ago (2026-08-05 01:26 UTC)
3
14
GPL 3.0
Multi-Search MCP Server
Search Browser Automation RAG Systems
guptabhishek
A
license
A
quality
C
maintenance
Provides unified web search across multiple providers (Google, Tavily, DuckDuckGo, Brave) with automatic fallback, maximizing free API quota usage for AI workflows.
Updated a year ago (2025-08-03 10:30 UTC)
1
17
7
MIT
web-search-mcp
Search RAG Systems
Backerss
F
license
Not graded
quality
C
maintenance
Provides free web search, content fetching, image search, and deep research via SearXNG, no API keys required.
Updated 3 months ago (2026-06-16 01:47 UTC)
-
OpenSERP Cloudofficial
Search Browser Automation Web Scraping
openserpapi
A
license
B
quality
C
maintenance
Search API for AI, SEO & automation. Browser-rendered Google, Bing, Yandex, Baidu, DuckDuckGo and Ecosia results with URL extraction (+image search and engine metadata tools)
Updated a month ago (2026-08-03 23:59 UTC)
9
60
2
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/AppliedEllipsis/mcp-search-kivest'

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

Kivest AI Search MCP Server

Features

Discord / Contact

Installation

Via npx (Not Recommended)

Via npm (not functional yet, use from source)

From Source

Configuration

Optional: Get API Key

Environment Variables (Optional)

MCP Client Configuration

Claude Desktop

Cursor

Available Tools

kivest_search

kivest_web_search

kivest_image_search

kivest_video_search

kivest_news_search

kivest_scrape_web

kivest_usage

kivest_stats

kivest_models

Rate Limiting

Testing

Run Tests

Test Output

Publishing to npm

1. Prepare for Publishing

2. Login to npm

3. Publish

4. Verify Installation

Development

Project Structure

API Reference

Kivest AI Search API

Rate Limits

Troubleshooting

"Rate limit exceeded"

"KIVEST_API_KEY not set"

"Queue is full"

License

Contributing

Support This Project ❤️

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

OpenSERP Cloudofficial

Latest Blog Posts

MCP directory API

`kivest_search`

`kivest_web_search`

`kivest_image_search`

`kivest_video_search`

`kivest_news_search`

`kivest_scrape_web`

`kivest_usage`

`kivest_stats`

`kivest_models`