How do I use Search MCP Server?

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., "@Search MCP Server search for the latest Python tutorials" 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.

Search MCP Server

Q: Which integrations are available for this server?

Provides tools for searching arXiv academic papers, retrieving titles, abstracts, authors, and links with category filtering. Provides web and news search capabilities via DuckDuckGo, with time filtering and region-specific results. Provides tools for searching GitHub repositories by keywords, with sorting by stars, forks, or update date. Provides tools for searching biomedical and life science research papers on PubMed, returning titles, abstracts, authors, DOIs, and publication info. Provides tools for searching Wikipedia articles, retrieving summaries, and full article content with multi-language support.

by KazKozDev

Overview Schema Related Servers Score Discussions

Python

Hybrid

Search MCP Server

MCP server providing 27 tools for web search, content extraction, and data processing. No API keys required.

Built with a modular registry architecture for dynamic tool loading, categorization, and discovery.

Installation

From PyPI (recommended)

pip install mcp-search-server

From source

git clone https://github.com/KazKozDev/mcp-search-server.git
cd mcp-search-server
pip install -e .

Claude Desktop Configuration

Add to ~/Library/Application Support/Claude/claude_desktop_config.json (macOS) or %APPDATA%\Claude\claude_desktop_config.json (Windows):

{
  "mcpServers": {
    "search": {
      "command": "mcp-search-server"
    }
  }
}

Related MCP server: Fetch Crawl MCP

Available Tools (27)

Meta Tools - Tool Discovery

Why LLMs need this: With 27 tools available, finding the right one for a task is challenging. This meta-tool enables LLMs to search through available tools by keywords, categories, or use cases.

What it does: Searches the tool registry by name, description, category, or tags. Returns ranked results with relevance scores.

Parameters:

query (required): Search query (e.g., "find web pages", "date time", "github")
limit: Max results (default: 5)

Example:

{"query": "search academic papers", "limit": 3}

Why LLMs need this: Tools are organized into categories (web, knowledge, social, etc.). This tool helps discover what categories exist and how many tools are in each.

What it does: Returns all available tool categories with counts.

Example:

{}

Why LLMs need this: Before using a tool, LLMs need to understand its parameters, return format, and usage examples. This tool provides complete documentation for any registered tool.

What it does: Returns detailed metadata for a specific tool including description, parameters, category, priority, and usage info.

Parameters:

tool_name (required): Name of the tool

Example:

{"tool_name": "search_arxiv"}

Web Search & Content

Why LLMs need this: LLMs have a knowledge cutoff date and cannot access current information. This tool gives them real-time access to the web, enabling answers about recent events, current prices, latest news, and up-to-date documentation.

What it does: Searches the web using DuckDuckGo with support for web and news modes, time filtering, and region-specific results.

Parameters:

query (required): Search query
limit: Max results (default: 10)
mode: "web" or "news"
timelimit: "d" (day), "w" (week), "m" (month), "y" (year)

Example:

{"query": "Python async programming", "limit": 5, "mode": "news", "timelimit": "w"}

Why LLMs need this: LLMs cannot look up real addresses, business locations, or geographic data. This tool enables location-based queries like finding nearby businesses, getting addresses, and working with geographic coordinates.

What it does: Searches for places, addresses, and locations with geographic coordinates. Returns structured location data including names, addresses, and coordinates.

Parameters:

query (required): Place or address to search
limit: Max results (default: 5)

Example:

{"query": "coffee shops near Times Square NYC", "limit": 3}

Why LLMs need this: Raw HTML is cluttered with navigation, ads, and scripts. LLMs need clean, readable text to understand and summarize web content effectively. This tool extracts just the main content.

What it does: Extracts readable content from any webpage, removing ads, navigation, and boilerplate. Uses multiple parsing methods (Readability, Newspaper3k, BeautifulSoup) with automatic fallback.

Parameters:

url (required): URL to extract content from

Example:

{"url": "https://example.com/article"}

Why LLMs need this: PDFs are a common format for research papers, reports, and documentation, but LLMs cannot read binary files directly. This tool converts PDF content to text for analysis.

What it does: Downloads and extracts text content from PDF documents using PyPDF2 or pdfplumber with automatic library selection.

Parameters:

url (required): PDF URL
max_chars: Maximum characters to extract (default: 50000)

Example:

{"url": "https://arxiv.org/pdf/2303.08774.pdf", "max_chars": 100000}

Wikipedia

Why LLMs need this: Wikipedia is a reliable, structured knowledge base. While LLMs have some Wikipedia knowledge from training, this tool provides access to the latest content and helps find specific articles on any topic.

What it does: Searches Wikipedia for articles matching a query. Returns article titles, snippets, and URLs.

Parameters:

query (required): Search query
limit: Max results (default: 5)

Example:

{"query": "machine learning", "limit": 3}

Why LLMs need this: Quick factual lookups need concise, authoritative information. Wikipedia summaries provide verified facts without the overhead of full articles, perfect for answering specific questions.

What it does: Gets a concise summary of a Wikipedia article - the introductory paragraphs that define the topic.

Parameters:

title (required): Article title

Example:

{"title": "Artificial Intelligence"}

Why LLMs need this: For in-depth research, LLMs need complete information with all sections, references, and details. This tool provides the full Wikipedia article for comprehensive analysis.

What it does: Gets the complete content of a Wikipedia article with all sections, supporting multiple languages.

Parameters:

title (required): Article title
lang: Language code (default: "en")

Example:

{"title": "Quantum computing", "lang": "en"}

Academic & Research

Why LLMs need this: Scientific research moves fast. arXiv hosts the latest preprints in physics, math, CS, and more. This tool gives LLMs access to cutting-edge research before it's even published in journals.

What it does: Searches arXiv for academic papers with filtering by category. Returns titles, abstracts, authors, and links.

Parameters:

query (required): Search query
max_results: Max results (default: 10)
category: arXiv category (e.g., "cs.AI", "physics")

Example:

{"query": "transformer neural networks", "max_results": 5, "category": "cs.AI"}

Why LLMs need this: Medical and health questions require peer-reviewed sources. PubMed is the authoritative database for biomedical research, enabling LLMs to cite real studies rather than general knowledge.

What it does: Searches PubMed for biomedical and life science research papers. Returns titles, abstracts, authors, DOIs, and publication info.

Parameters:

query (required): Search query
max_results: Max results (default: 10)

Example:

{"query": "CRISPR gene therapy", "max_results": 5}

Why LLMs need this: For current events and global news analysis, LLMs need access to worldwide media coverage. GDELT monitors news from every country, enabling analysis of how stories develop globally.

What it does: Searches the GDELT database for global news articles and events with time filtering.

Parameters:

query (required): Search query
timespan: "1d", "7d", or "1m" (default: "1d")
max_results: Max results (default: 10)

Example:

{"query": "climate summit", "timespan": "7d", "max_results": 5}

GitHub

Why LLMs need this: Developers ask about libraries, frameworks, and code examples. This tool helps LLMs find relevant repositories, compare alternatives, and recommend tools based on real popularity metrics (stars, forks).

What it does: Searches GitHub for repositories by keywords with sorting by stars, forks, or update date.

Parameters:

query (required): Search query
max_results: Max results (default: 5)
sort: "stars", "forks", "updated" (default: "stars")

Example:

{"query": "python web framework", "max_results": 10, "sort": "stars"}

Why LLMs need this: README files contain installation instructions, API docs, and usage examples. This tool lets LLMs read actual documentation to provide accurate, up-to-date guidance on using any library.

What it does: Fetches the README file content from a GitHub repository in markdown format.

Parameters:

repo (required): Repository in "owner/repo" format

Example:

{"repo": "langchain-ai/langchain"}

Why LLMs need this: Reddit contains real user experiences, reviews, and discussions. For questions like "what's the best X" or "how do people feel about Y", Reddit provides authentic community perspectives that formal sources lack.

What it does: Searches Reddit for posts across all subreddits or within a specific one, with time filtering.

Parameters:

query (required): Search query
subreddit: Specific subreddit (optional)
limit: Max results (default: 10)
time_filter: "hour", "day", "week", "month", "year", "all"

Example:

{"query": "best programming languages 2024", "subreddit": "programming", "limit": 5}

Why LLMs need this: The real value of Reddit is in the comments - detailed explanations, counterarguments, and community voting. This tool extracts comment threads for deeper analysis of discussions.

What it does: Fetches comments from a specific Reddit post with scores and hierarchy.

Parameters:

url (required): Reddit post URL
limit: Max comments (default: 10)

Example:

{"url": "https://www.reddit.com/r/Python/comments/abc123/post_title/", "limit": 20}

Date, Time & Location

Why LLMs need this: LLMs have no concept of "now" - they don't know the current date or time. This tool enables time-aware responses: scheduling, deadlines, "is it open now?", age calculations, and timezone conversions.

What it does: Gets the current date and time for any timezone with detailed components (day of week, week number, Unix timestamp).

Parameters:

timezone: Timezone name (default: "UTC")
include_details: Include additional info (default: true)

Example:

{"timezone": "America/New_York", "include_details": true}

Returns: ISO datetime, date/time components, day of week, week number, Unix timestamp.

Why LLMs need this: LLMs have no concept of "here" - they don't know where the user is. This tool enables location-aware responses: local weather, nearby services, correct timezone, and region-specific information.

What it does: Gets geographic location from an IP address including country, city, timezone, coordinates, and ISP info.

Parameters:

ip_address: IP to lookup (optional, uses server IP if omitted)

Example:

{"ip_address": "8.8.8.8"}

Returns: Country, region, city, ZIP, timezone, lat/lon, ISP, AS number.

Analysis & Processing

Why LLMs need this: Not all sources are equal. When citing information, LLMs need to distinguish between peer-reviewed research, reputable news, and random blogs. This tool provides objective credibility metrics to support source evaluation.

What it does: Assesses web source credibility using 30+ signals including domain age (WHOIS), citation network (PageRank), and content analysis with Bayesian confidence intervals.

Parameters:

url (required): URL to assess
title: Document title (optional)
content: Full text content (optional, improves accuracy)
metadata: Additional metadata (year, authors, citations, doi, is_peer_reviewed)

Example:

{"url": "https://arxiv.org/abs/2301.00234", "metadata": {"is_peer_reviewed": true}}

Returns: Credibility score (0-1), confidence interval, category, PageRank, 30+ signal scores.

Why LLMs need this: Long documents exceed context limits. Before analyzing a large PDF or article, this tool can create a concise summary, letting LLMs work with more sources without running out of context.

What it does: Summarizes long text using TF-IDF extraction, keyword-based selection, or fast heuristic methods. Runs locally with no external APIs.

Parameters:

text (required): Text to summarize
strategy: "auto", "extractive_tfidf", "extractive_keyword", "heuristic"
compression_ratio: Target ratio 0.1-0.9 (default: 0.3)

Example:

{"text": "Long article text here...", "strategy": "extractive_tfidf", "compression_ratio": 0.3}

Returns: Summary, method used, statistics (original/summary length, compression ratio).

Why LLMs need this: LLMs are notoriously bad at math. Even simple arithmetic can produce wrong answers. This tool provides accurate calculations for everything from basic math to trigonometry and logarithms.

What it does: Performs mathematical calculations using safe AST parsing (no eval). Supports arithmetic, trigonometry, logarithms, factorials, and mathematical constants.

Parameters:

expression (required): Math expression

Supported: +, -, *, /, **, ^, %, //, sqrt, sin, cos, tan, log, log10, exp, factorial, pi, e, and more.

Example:

{"expression": "sqrt(144) + sin(pi/2) * 10"}

File Management

Why LLMs need this: Users often want to discuss files on their system. This tool lets LLMs read text, PDFs, Word docs, and more to answer questions about file contents, analyze data, or help with editing.

What it does: Reads content from text, PDF, Word, Excel, or image files with automatic format detection.

Parameters:

path (required): File path (relative paths use data/files/ as base)

Example:

{"path": "notes.txt"}

Why LLMs need this: LLMs can generate code, documents, and data, but without file writing they can only display output. This tool lets them save generated content to actual files users can use.

What it does: Writes content to a file, creating it if it doesn't exist. UTF-8 text files only.

Parameters:

path (required): File path
content (required): Content to write

Example:

{"path": "output.txt", "content": "Hello, World!"}

Why LLMs need this: For logging, note-taking, and incremental data collection, appending is safer than overwriting. This tool adds content to existing files without losing previous data.

What it does: Appends content to an existing file or creates a new one.

Parameters:

path (required): File path
content (required): Content to append

Example:

{"path": "log.txt", "content": "\nNew log entry"}

Why LLMs need this: Before reading or writing files, LLMs need to know what exists. This tool provides directory listings with file sizes and types, enabling file management workflows.

What it does: Lists files and directories with sizes and types.

Parameters:

path: Directory path (default: data/files/)

Example:

{"path": ""}

Why LLMs need this: Complete file management requires deletion. This tool enables cleanup of temporary files, old outputs, and user-requested deletions with security restrictions.

What it does: Deletes a file (restricted to data/files/ directory for security).

Parameters:

path (required): File path to delete

Example:

{"path": "temp.txt"}

Architecture

The server uses a modular registry architecture:

Dynamic Tool Loading: Tools are registered in a central registry with metadata (category, priority, tags)
Category-Based Organization: Tools organized into 7 categories: meta, web, knowledge, social, analysis, context, files
Meta-Tool Discovery: Built-in tools (search_tools, list_tool_categories, get_tool_info) help LLMs discover and understand available capabilities
Extensible: Easy to add new tools by implementing BaseTool and registering in the configuration

Key files:

server.py - Main MCP server with registry integration
registry/ - Tool registry and loader
tools/ - Tool implementations organized by category

Development

# Install dev dependencies
pip install -e ".[dev]"

# Run tests
pytest

# Format code
black src/

# Lint
ruff check src/

If you like this project, please give it a star ⭐

For questions, feedback, or support, reach out to:

Artem KK | MIT LICENSE

Available Tools

27 tools

append_fileD

ParametersJSON Schema

Name	Required	Description	Default
`file_path`	Yes
`content`	Yes

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

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

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

assess_source_credibilityD

ParametersJSON Schema

Name	Required	Description	Default
`url`	Yes
`title`	No
`content`	No
`metadata`	No

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

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

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

calculatorD

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

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

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

delete_fileD

ParametersJSON Schema

Name	Required	Description	Default
`file_path`	Yes

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

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

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

extract_webpage_contentD

ParametersJSON Schema

Name	Required	Description	Default
`url`	Yes

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

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

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

get_current_datetimeD

ParametersJSON Schema

Name	Required	Description	Default
`timezone_name`	No
`include_details`	No

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

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

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

get_github_readmeD

ParametersJSON Schema

Name	Required	Description	Default
`full_name`	Yes

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

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

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

get_location_by_ipD

ParametersJSON Schema

Name	Required	Description	Default
`ip_address`	No

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

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

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

get_reddit_commentsD

ParametersJSON Schema

Name	Required	Description	Default
`url`	Yes
`limit`	No

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

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

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

get_tool_infoC

Get detailed tool info

ParametersJSON Schema

Name	Required	Description	Default
`tool_name`	Yes

TDQS

C2.6/5.0

Behavior2/5

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

With no annotations, the description bears the full burden of behavioral disclosure. It omits details such as what constitutes 'detailed info', error handling for invalid tool names, or whether any side effects occur. This leaves the agent with insufficient information.

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 a single, concise sentence, which is efficient. However, it sacrifices informativeness for brevity; additional context would improve usability without significantly increasing length.

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 lack of output schema, annotations, and limited parameter documentation, the description is incomplete. It does not explain what the returned 'detailed tool info' contains, leaving the agent uncertain about the tool's output.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The single parameter 'tool_name' is required and described only by its schema type (string). The description adds no extra context, such as valid formats or examples, and schema description coverage is 0%, so the description fails to compensate.

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 'Get detailed tool info' clearly identifies the action (get) and the resource (tool info), making the purpose straightforward. However, it does not explicitly distinguish itself from the sibling 'search_tools' tool, which might have overlapping functionality.

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 like 'search_tools'. The description lacks contextual cues about prerequisites or use cases.

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

get_wikipedia_contentD

ParametersJSON Schema

Name	Required	Description	Default
`title`	Yes
`lang`	No

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

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

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

get_wikipedia_summaryD

ParametersJSON Schema

Name	Required	Description	Default
`title`	Yes

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

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

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

list_filesD

ParametersJSON Schema

Name	Required	Description	Default
`dir_path`	No

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

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

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

list_tool_categoriesB

List tool categories

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

B3.1/5.0

Behavior2/5

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

The description only says 'list', implying a read operation, but does not disclose permissions, side effects, or what specific categories are meant. With no annotations, the agent lacks critical behavioral context.

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 extremely concise with one sentence, no wasted words, and front-loaded. It is appropriate for a simple parameterless tool.

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 zero parameters and no output schema, the description adequately conveys the tool's purpose. However, it could be slightly more informative by clarifying what 'tool categories' are, but overall it is sufficient for a trivial listing tool.

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 and schema coverage is 100%, so baseline is 4. The description adds no parameter information, which is acceptable as there are none.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'List tool categories' restates the tool name without additional context. It clearly indicates the tool lists categories, but does not differentiate from siblings like 'search_tools' or 'get_tool_info', which may relate to tool discovery.

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 like 'search_tools' or 'get_tool_info'. It does not specify exclusions or typical usage scenarios.

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

parse_pdfD

ParametersJSON Schema

Name	Required	Description	Default
`url`	Yes
`max_chars`	No

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

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

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

read_fileD

ParametersJSON Schema

Name	Required	Description	Default
`file_path`	Yes

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

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

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

search_arxivD

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes
`max_results`	No
`sort_by`	No

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

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

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

search_duckduckgoD

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes
`limit`	No
`timelimit`	No
`mode`	No
`no_cache`	No

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

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

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

search_gdeltD

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes
`timespan`	No
`max_results`	No
`country`	No
`domain`	No

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

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

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

search_githubD

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes
`sort`	No
`max_results`	No

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

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

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

search_mapsD

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes
`limit`	No
`country_codes`	No
`no_cache`	No

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

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

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

search_pubmedD

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes
`max_results`	No
`sort`	No

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

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

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

search_redditD

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes
`subreddit`	No
`limit`	No
`sort`	No
`time_filter`	No

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

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

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

search_toolsD

Search available tools

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes
`category`	No
`limit`	No

TDQS

D1.8/5.0

Behavior2/5

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

No annotations are provided, so the description must fully convey behavior. It only states 'Search available tools', omitting whether it reads or writes, performance implications, or result behavior. This is insufficient for a generic 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.

Conciseness2/5

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

The description is extremely short, but this is under-specification rather than conciseness. It fails to convey necessary details for a 3-parameter tool with no schema documentation.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 3 parameters, no output schema, and no annotations, the description is completely inadequate. It does not explain return values, filtering behavior, or how to effectively query available tools.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0% and the description does not mention any of the three parameters (query, category, limit). The schema alone provides no semantic hints, so the description adds no value in explaining parameter meaning or usage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose2/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description 'Search available tools' is a tautology of the tool name. It fails to specify what is being searched (e.g., tool names, descriptions, categories) or how it differs from sibling tools like 'get_tool_info' or 'list_tool_categories'.

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 on when to use this tool vs alternatives. Sibling tools include many specialized searches and info retrieval tools, but the description offers no context on selecting 'search_tools' over them.

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

search_wikipediaD

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes
`limit`	No

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

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

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

summarize_textD

ParametersJSON Schema

Name	Required	Description	Default
`text`	Yes
`strategy`	No
`compression_ratio`	No

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

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

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

write_fileD

ParametersJSON Schema

Name	Required	Description	Default
`file_path`	Yes
`content`	Yes

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

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

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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.

27 tool updatesv0.2.1May 28, 2026
- First observedappend_file
- First observedassess_source_credibility
- First observedcalculator
- First observeddelete_file
- First observedextract_webpage_content
- First observedget_current_datetime
- First observedget_github_readme
- First observedget_location_by_ip
- First observedget_reddit_comments
- First observedget_tool_info
- First observedget_wikipedia_content
- First observedget_wikipedia_summary
- First observedlist_files
- First observedlist_tool_categories
- First observedparse_pdf
- First observedread_file
- First observedsearch_arxiv
- First observedsearch_duckduckgo
- First observedsearch_gdelt
- First observedsearch_github
- First observedsearch_maps
- First observedsearch_pubmed
- First observedsearch_reddit
- First observedsearch_tools
- First observedsearch_wikipedia
- First observedsummarize_text
- First observedwrite_file

Install Server

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

TDQS

D1.9/5.0

Disambiguation4/5

Tools have distinct names and generally target different resources or actions. However, some pairs like get_wikipedia_content and get_wikipedia_summary may cause confusion, especially without descriptions.

Naming Consistency5/5

All tool names follow a consistent snake_case verb_noun pattern (e.g., append_file, search_arxiv). No mixing of conventions.

Tool Count3/5

27 tools is on the high side for a general-purpose server, but each tool serves a distinct function. The count is borderline but not extreme.

Completeness3/5

The server covers a wide range of common tasks (file ops, search, web scraping), but each domain is shallow. There are no obvious critical gaps, but the broad scope makes completeness hard to assess.

Maintenance

ActivityInactive

ResponsivenessSyncing

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

HasData AOAuth
com.hasdata.mcp
Direct access to 40+ scraping and search tools. Extract structured data from Google (Search, Maps, Trends), Amazon, Airbnb, Social Media, and any web page directly into your AI agent.
Browser Automation RAG Systems Web Scraping
2
Universal Web Data Scraper & Extractor ToolOAuth
com.ranovam
Extract data from any website with this web scraper tool.
Web Scraping Browser Automation
1
extract B
com.mart402
Web extraction, OCR (Japanese-strong), invoice and company data for AI agents. x402, no API key.
Browser Automation Web Scraping
352
ToolSnap MCP A
app.toolsnap
Deterministic AI agent microtools, no accounts/API keys. fetch_extract: 98% token cut. 38 tools.
Blockchain RAG Systems Web Scraping
1731

Related MCP Servers

JieBang Tools MCP Serverofficial
Developer Tools AI & Machine Learning
jiebang-tools
F
license
Not graded
quality
C
maintenance
Offers 29 free tools for text processing, AI-powered generation, SEO optimization, utilities, cron tasks, file processing, and ideas management, all without requiring an API key.
Updated 3 months ago (2026-06-17 05:36 UTC)
-
Fetch Crawl MCP
Browser Automation Web Scraping
GeorgesAdSim
F
license
A
quality
D
maintenance
Enables fetching, crawling, and analyzing web pages with 29 tools for SEO audits, content extraction, and more.
Updated 4 months ago (2026-05-11 15:24 UTC)
29
-
MCP Web Search
Search Web Scraping Browser Automation
jsitla
F
license
Not graded
quality
D
maintenance
Provides 19 tools for web search, content fetching, and extraction, including DuckDuckGo search, YouTube transcripts, and webpage screenshots.
Updated 7 months ago (2026-01-31 16:41 UTC)
1
-
firecrawl-lite-mcp-server
Web Scraping Browser Automation
ariangibson
A
license
A
quality
A
maintenance
Enables privacy-first web scraping and structured data extraction using a local headless browser and your own LLM key. Supports tools for scraping, batch scraping, data extraction with prompts or schemas, and screenshots.
Updated 13 days ago (2026-08-24 15:53 UTC)
5
370
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/KazKozDev/mcp-search-server'

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

Search MCP Server

Installation

From PyPI (recommended)

From source

Claude Desktop Configuration

Available Tools (27)

Meta Tools - Tool Discovery

Web Search & Content

Wikipedia

Academic & Research

GitHub

Reddit

Date, Time & Location

Analysis & Processing

File Management

Architecture

Development

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

JieBang Tools MCP Serverofficial

Latest Blog Posts

MCP directory API