Skip to main content
Glama
deenesjakoruzh
aabGit

research-tools

by aabGit
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

自律型Webリサーチエージェント

教育用プロジェクト：1つのPythonエージェントが計画し、Webを検索し、RAGにメモを保存し、レポートを作成し、その後自己批評し、答えが十分になるまでループします。

スタック：Python 3.11+ · LangChain · LangGraph · MCP · Chroma RAG · LangSmith

構築するもの（教室マップ）

部品

ファイル

役割

設定

src/research_agent/config.py

.envを読み込む

LLM層

src/research_agent/llm.py

1つの関数、複数のプロバイダ

ツール

src/research_agent/tools.py

検索＋ページ取得

MCP

src/research_agent/mcp_server.py

MCPプロトコル経由で同じツール

RAG

src/research_agent/rag.py

Chromaにページを記憶

状態

src/research_agent/state.py

グラフのノートブック

ノード

src/research_agent/nodes.py

ステップごとに1つの関数

グラフ

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

少なくとも1つの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.

  1. 2 tool updatesv0.1.0
    • First observedfetch_page
    • First observedsearch_web
Deploy Server
Give agents eyes on the webHosted screenshot MCP. Send a URL, get a pixel-perfect image. $0.002 per grab. Works with Claude, Cursor, and Codex.grabbit.liveAd

TDQS

A3.5/5.0

Scored across 2 tools

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

ActivitySlowing
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • crawl4ai-mcp

    pazyork
    A
    license
    Not graded
    quality
    C
    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.
    3
    AGPL 3.0

  • myscrape

    Bonifatius94
    A
    license
    Not graded
    quality
    C
    maintenance
    A self-contained web-research MCP server that lets local LLM agents search, fetch, and synthesize web content using tools like web_search, web_fetch, and web_research.
    2
    MIT