Skip to main content
Glama
deenesjakoruzh
aabGit

research-tools

by aabGit
OverviewSchemaRelated ServersScoreDiscussions
Python
Local

Autonomous Web Research Agent

A teaching project: one Python agent that plans, searches the web, stores notes in RAG, writes a report, then critiques itself and loops until the answer is good enough.

Stack: Python 3.11+ · LangChain · LangGraph · MCP · Chroma RAG · LangSmith

What you are building (classroom map)

Piece

File

Job

Config

src/research_agent/config.py

Reads .env

LLM layer

src/research_agent/llm.py

One function, many providers

Tools

src/research_agent/tools.py

Search + fetch pages

MCP

src/research_agent/mcp_server.py

Same tools over the MCP protocol

RAG

src/research_agent/rag.py

Remember pages in Chroma

State

src/research_agent/state.py

The graph's notebook

Nodes

src/research_agent/nodes.py

One function per step

Graph

src/research_agent/graph.py

Wires the loop

CLI

src/research_agent/cli.py

Run from terminal

API

src/research_agent/api.py

FastAPI backend

Read TEACHING.md for the full lesson.

Related MCP server: Local-MCP-server

Setup

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

Put at least one LLM key in .env (OPENAI_API_KEY is the default path). Search works with free DuckDuckGo. Add TAVILY_API_KEY later if you want higher-quality search. Add LANGCHAIN_API_KEY to watch traces in LangSmith.

Run a research job

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

Run the backend

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

Run the MCP server (for Cursor / other hosts)

python -m research_agent.mcp_server

Example Cursor MCP config:

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

Tests (no API key needed)

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