Skip to main content
Glama
deenesjakoruzh
aabGit

research-tools

by aabGit
OverviewSchemaRelated ServersScoreDiscussions
Python
Local

Автономный веб-исследовательский агент

Учебный проект: один Python-агент, который планирует, ищет в интернете, сохраняет заметки в RAG, пишет отчет, а затем критикует себя и повторяет цикл, пока ответ не станет достаточно хорошим.

Стек: Python 3.11+ · LangChain · LangGraph · MCP · Chroma RAG · LangSmith

Что вы создаете (карта урока)

Компонент

Файл

Задача

Config

src/research_agent/config.py

Читает .env

LLM layer

src/research_agent/llm.py

Одна функция, много провайдеров

Tools

src/research_agent/tools.py

Поиск + загрузка страниц

MCP

src/research_agent/mcp_server.py

Те же инструменты через протокол MCP

RAG

src/research_agent/rag.py

Запоминает страницы в Chroma

State

src/research_agent/state.py

Записная книжка графа

Nodes

src/research_agent/nodes.py

Одна функция на шаг

Graph

src/research_agent/graph.py

Собирает цикл

CLI

src/research_agent/cli.py

Запуск из терминала

API

src/research_agent/api.py

Бэкенд на FastAPI

Читайте TEACHING.md для полного урока.

Related MCP server: Local-MCP-server

Настройка

cd ~/Projects/autonomous-web-research-agent
python3.11 -m venv .venv
source .venv/bin/activate
pip install -e ".[dev]"
cp .env.example .env

Поместите хотя бы один LLM-ключ в .env (OPENAI_API_KEY — путь по умолчанию). Поиск работает с бесплатным DuckDuckGo. Добавьте TAVILY_API_KEY позже, если хотите более качественный поиск. Добавьте LANGCHAIN_API_KEY для просмотра трассировок в LangSmith.

Запуск исследовательской задачи

python -m research_agent.cli "How does MCP differ from a normal LangChain tool?"

Запуск бэкенда

python -m research_agent.api
# POST http://127.0.0.1:8001/research  {"question": "..."}

Запуск MCP-сервера (для Cursor / других хостов)

python -m research_agent.mcp_server

Пример конфигурации Cursor MCP:

{
  "mcpServers": {
    "research-tools": {
      "command": "/Users/YOU/Projects/autonomous-web-research-agent/.venv/bin/python",
      "args": ["-m", "research_agent.mcp_server"]
    }
  }
}

Тесты (ключ API не требуется)

pytest

Available Tools

2 tools
fetch_pageB

Download a URL and return cleaned visible text.

ParametersJSON Schema
NameRequiredDescriptionDefault
urlYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

B3.4/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 full responsibility for behavioral disclosure. It states the action is a download (read-only) but does not mention idempotency, error handling, rate limits, or any side effects. The term 'cleaned' is ambiguous regarding filtering and transformations.

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 extraneous words. It efficiently conveys the core function without redundancy.

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

Completeness3/5

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

The tool is simple with one parameter and an output schema, but the description lacks usage guidance and behavioral details. It covers the basic purpose but misses context that would help an agent decide when to invoke it relative to the sibling tool.

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?

Schema description coverage is 0%, so the description must compensate. It adds only that the tool downloads a URL, but does not clarify expected format, protocol (HTTP/HTTPS), or validation rules. The parameter 'url' is left mostly undocumented beyond its name.

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 action ('Download a URL') and the result ('return cleaned visible text'). It distinguishes from sibling 'search_web' by specifying a direct URL fetch rather than a search operation.

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

Usage Guidelines3/5

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

The description implies usage when you have a specific URL to retrieve, but does not provide explicit guidance on when to use this tool versus 'search_web', nor does it mention any exclusions or prerequisites.

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

search_webC

Search the public web and return titles, URLs, and snippets.

ParametersJSON Schema
NameRequiredDescriptionDefault
queryYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

C2.9/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 full behavioral burden. It does not disclose important details such as whether results are limited, if there are any access restrictions or rate limits, or how the search is performed. The description is minimal, missing context about result behavior.

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 a single, concise sentence that is front-loaded with the essential action. It avoids unnecessary words, earning its place by being brief yet informative.

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 annotations and incomplete schema description, the description fails to fully compensate. An output schema exists, but the description does not explain return values or behavioral details, leaving gaps for a comprehensive understanding.

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 schema describes one required parameter 'query' but has 0% description coverage, meaning the description adds no meaningful context beyond the schema. However, the description implies the query is used for web searching, providing moderate value.

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 searches the public web and returns specific fields (titles, URLs, snippets). It effectively conveys the action and resource, though it lacks explicit differentiation from the sibling tool 'fetch_page'.

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 'fetch_page'. The context suggests it's for web searches, but there's no explicit instruction on usage context or limitations.

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.

  1. 2 tool updatesv0.1.0
    • First observedfetch_page
    • First observedsearch_web
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.5/5.0
Disambiguation5/5

search_web is for querying the web and returning snippets, while fetch_page retrieves full content from a specific URL. Their purposes are completely distinct and easily distinguishable.

Naming Consistency5/5

Both tools follow a consistent verb_noun pattern (search_web, fetch_page), making the naming predictable and clear.

Tool Count3/5

With only two tools, the server feels thin for a general research purpose. While each tool is essential, the minimal count borders on insufficient for complex workflows.

Completeness4/5

The two tools cover the basic research loop of searching and fetching content. Minor gaps exist (e.g., no ability to refine searches or manage results), but agents can work around them.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • open-search-mcp

    rockindahizzy
    A
    license
    Not graded
    quality
    D
    maintenance
    Web search, page fetching, and research from the terminal or any MCP client — no API key required.
    1
    MIT

  • crawl4ai-mcp

    pazyork
    A
    license
    Not graded
    quality
    D
    maintenance
    A minimal MCP server for agent-friendly web extraction and search. Offers two tools: fetching real pages with Playwright and Crawl4AI, and searching across 7 engines with automatic fallback.
    33
    AGPL 3.0

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/aabGit/Autonomous-Web-Research-Agent'

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