Which integrations are available for this server?

Provides tools to search arXiv, read paper metadata, and export BibTeX using the arXiv API. Fetches YouTube captions as timestamped text from YouTube.

mcp-minis

by JONASXZB

Overview Schema Source Related Servers Discussions Admin

Python

Local

mcp-minis

Five tiny, single-purpose MCP servers that give your AI agent superpowers — no API keys, no sign-ups, no bloat.

Python MCP License: MIT PRs Welcome

Why mcp-minis?

Most MCP servers try to do everything. These do one thing each — and do it well:

Small — every server is a single readable Python file you can audit in minutes.
Single-purpose — search papers or fetch a transcript or check a quote. Nothing else.
No API keys — every data source is free and keyless (arXiv, YouTube captions, Stooq, Frankfurter, your own disk).
Works anywhere — standard MCP over stdio: Claude Code, Claude Desktop, Cursor, or any other MCP client.
Honest failure — tools return clear error strings instead of crashing your session.

Related MCP server: Recall

The servers

Server	What it does	Data source
arxiv-scholar	Search arXiv, read paper metadata, export BibTeX	arXiv API
youtube-transcript	Fetch YouTube captions as timestamped text	YouTube captions
web-to-markdown	Turn any web page into clean, readable Markdown	trafilatura extraction
market-pulse	Stock / index / crypto quotes and currency conversion	Stooq + Frankfurter
memory-vault	A persistent, full-text-searchable notebook for your agent	Local SQLite (FTS5)

Each server's README lists its tools, parameters, and copy-paste configs.

Quick Start

Option A — run any server straight from GitHub (no clone)

With uv installed, point your MCP client at a server package:

{
  "mcpServers": {
    "arxiv-scholar": {
      "command": "uvx",
      "args": [
        "--from",
        "git+https://github.com/JONASXZB/mcp-minis#subdirectory=servers/arxiv-scholar",
        "arxiv-scholar"
      ]
    }
  }
}

Swap arxiv-scholar for any other server name (in both places) to use a different mini.

For Claude Code, the equivalent is one command:

claude mcp add arxiv-scholar -- uvx --from "git+https://github.com/JONASXZB/mcp-minis#subdirectory=servers/arxiv-scholar" arxiv-scholar

Option B — clone and install

git clone https://github.com/JONASXZB/mcp-minis.git
cd mcp-minis/servers/arxiv-scholar
pip install .

Then register the command with your client:

{
  "mcpServers": {
    "arxiv-scholar": { "command": "arxiv-scholar", "args": [] }
  }
}

Want all five at once?

Grab a ready-made combined config from examples/:

examples/claude_desktop_config.json — Claude Desktop / Cursor
examples/mcp.json — generic MCP client config

Roadmap

weather-now — current conditions + forecast from Open-Meteo (also keyless)
rss-reader — fetch and summarize RSS/Atom feeds
pdf-reader — extract text and structure from PDF files
PyPI releases for each mini, so uvx arxiv-scholar just works
Streamable HTTP transport option for hosted use

Ideas for a mini you'd actually use? Open an issue — or better, add one yourself.

Contributing

PRs are welcome — especially new minis that follow the house rules: one job, free data, no API keys, minimal dependencies, graceful errors. See CONTRIBUTING.md for the template conventions every server follows.

License

MIT — see LICENSE. Use these however you like.

Available Tools

6 tools

delete_noteA

Permanently delete a note from the vault.

Args: note_id: The numeric ID of the note to delete.

Returns: A confirmation, or an error message if no such note exists.

ParametersJSON Schema

Name	Required	Description	Default
`note_id`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.6/5.0

Behavior3/5

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

With no annotations, the description carries the full behavioral burden. It usefully discloses that deletion is permanent and that a missing note yields an error, but says nothing about permissions required, whether related data is affected, or any confirmation step — meaningful gaps for a destructive operation.

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?

Front-loaded with the action and permanence caveat, then the argument and return value. The Args/Returns scaffolding is slightly redundant given the schema and output schema exist, but it is short and wastes no space.

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?

An output schema exists, so explaining the return value is optional. For a simple one-parameter delete tool the description covers the action, the argument, and the failure mode; only auth/scope details are absent.

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

Parameters4/5

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

Schema description coverage is 0%, so the description must compensate. It states note_id is 'the numeric ID of the note to delete', giving the type (numeric) and semantics (it identifies the target note), which is enough for a single-parameter tool.

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 states a specific verb and resource ('Permanently delete a note from the vault'), which clearly distinguishes it from the read/list/save siblings. It stops short of naming a sibling as the alternative, but the destructive action is unambiguous.

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 word 'Permanently' implies this is the irreversible removal path versus update_note, so usage is implied. However, there is no explicit when-to-use statement, no mention of prerequisites (e.g. the note must exist, ownership/permissions), and no steer away from alternatives.

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

get_noteA

Get one note by its ID, with its full content.

Args: note_id: The numeric ID returned by save_note (shown as #id in search/list results).

Returns: The full note, or an error message if no such note exists.

ParametersJSON Schema

Name	Required	Description	Default
`note_id`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.9/5.0

Behavior3/5

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

No annotations are provided, so the description carries the burden. It discloses the error behavior when no such note exists and that the full content is returned, which is useful, but says nothing about permissions, truncation, or data sensitivity. Adequate but with clear gaps for a read tool.

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?

Purpose is front-loaded in the first sentence, with Args/Returns sections that are compact. The Returns line is somewhat redundant given an output schema exists, but nothing is bloated.

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

Completeness4/5

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

For a single-parameter read tool with an output schema, the important pieces (identity semantics of the ID, error case) are covered. The absence of annotation coverage and any safety/permission context is a minor gap rather than a blocking one.

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

Parameters4/5

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

Schema description coverage is 0%, so the description must compensate and largely does: it explains note_id is the numeric ID returned by save_note and shown as '#id' in search/list results, which is information the bare integer schema lacks. It stops short of format/range constraints.

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?

States a specific verb and resource with scope: fetch exactly one note by ID and return its full content. This clearly separates it from list_notes and search_notes, which return sets of notes, without the agent needing to open another schema.

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?

Usage is only implied: the caller must already have a note_id, and the description notes that IDs come from save_note or search/list results. There is no explicit statement of when to prefer this over search_notes or list_notes, so guidance is adequate but not stated.

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

list_notesA

List notes in the vault, most recently updated first.

Args: tag: Optional — only list notes carrying this tag. limit: Maximum number of notes to return (1-100, default 20). The result always reports the total number of matching notes, so a truncated list is never mistaken for the whole vault.

Returns: A list of notes with previews, or a message if the vault is empty.

ParametersJSON Schema

Name	Required	Description	Default
`tag`	No
`limit`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.1/5.0

Behavior4/5

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

With no annotations, the description carries the full burden and does well: it discloses sort order (most recently updated first), that the result reports the total matching count so truncation is visible, and that an empty vault returns a message. It stops short of stating permissions/auth needs, but the read-only nature is evident from 'List'.

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?

Front-loaded main sentence followed by tight Args/Returns structure; every line is functional. The total-count explanation is slightly more than the minimum but earns its place by preventing truncation misreads.

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

Completeness5/5

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

For a two-param, zero-required list tool with an output schema, the description covers ordering, filtering, result bounding, truncation disclosure and the empty case. An agent has everything needed to call it correctly without opening the schema.

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

Parameters5/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, and it does: tag is documented as an optional filter by carried tag, and limit is given a semantic bound (1-100) plus the default of 20, none of which appears in the schema.

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?

States a specific verb and resource plus ordering behavior ('List notes in the vault, most recently updated first'), which is clear. It does not, however, distinguish itself from the sibling search_notes, which could plausibly cover the tag-filtering case, so the agent must infer the boundary.

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 tag and limit args imply when to filter or bound results, and the note about totals guards against misreading a truncated list. But there is no explicit when-to-use or when-to-use-instead guidance naming alternatives like search_notes or get_note.

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

save_noteB

Save a note to the vault so it can be found in future sessions.

Args: title: A short, descriptive title for the note. content: The note body. Markdown is fine. tags: Optional comma-separated tags, e.g. "travel, japan, ideas".

Returns: A confirmation including the new note's ID, or an error message.

ParametersJSON Schema

Name	Required	Description	Default
`tags`	No
`title`	Yes
`content`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.4/5.0

Behavior3/5

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

With no annotations, the description carries the full burden. It discloses the return behavior (confirmation with new note ID, or error), which is genuine behavioral context, but it omits whether saving overwrites an existing note with the same title, where the vault lives, and any permission requirements.

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?

Front-loaded with the core action in the first sentence, then cleanly separated Args and Returns sections. The Args block restates parameter names that already exist in the schema, which is mildly redundant, but overall it is tight and scannable.

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

Completeness4/5

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

For a 3-parameter, 2-required creation tool with an output schema, the description covers the action, every parameter, and the return shape. The remaining gap is collision/overwrite behavior, which is not covered by the schema or annotations either.

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

Parameters4/5

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

Schema description coverage is 0%, so the description must compensate, and it does: all three parameters are documented, with tags given a concrete comma-separated example format and content noting that Markdown is acceptable. Only the title/content length or constraint semantics are left unstated.

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?

States a specific verb and resource ('Save a note to the vault') plus the reason for persistence ('found in future sessions'). It is clear this creates a new note rather than mutating one, but it never explicitly distinguishes itself from the sibling update_note, leaving the create-vs-update boundary implicit.

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?

There is a weak contextual cue ('so it can be found in future sessions'), but no statement of when to use this versus update_note, search_notes, or any other sibling, and no prerequisites or exclusions. The agent must infer that 'save' means 'create'.

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

search_notesA

Full-text search the vault (title, content, and tags).

Args: query: Words to search for. Notes containing all words rank first (FTS5 relevance order). limit: Maximum number of notes to return (1-100, default 20). The result always reports the total number of matches, so a truncated list is never mistaken for the whole vault.

Returns: Matching notes with previews, best matches first — or a message saying nothing matched.

ParametersJSON Schema

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

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4/5.0

Behavior4/5

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

With no annotations, the description carries the full burden and does well: it discloses FTS5 relevance ranking, that notes containing all words rank first, the 1-100 limit cap, and that a truncated result still reports total match count. The remaining gap is only that read-only/safety semantics are implied by "search" rather than stated.

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?

Front-loaded with the core verb+resource, then cleanly sectioned into Args and Returns with no wasted prose. The Returns section partially duplicates the existing output schema, which costs a little, but the total-match nuance justifies it.

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

Completeness4/5

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

For a two-parameter read tool with an output schema and no annotations, the description covers parameters, ranking, and truncation behavior adequately. Slightly more explicit sibling differentiation would make it fully complete.

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

Parameters5/5

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

Schema coverage is 0%, so the description must compensate, and it does: query is defined as words to search with all-words ranking behavior, and limit is given a range (1-100) and default (20) plus the truncation-reporting guarantee. This adds real meaning beyond the bare typed properties.

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?

"Full-text search the vault (title, content, and tags)" gives a specific verb and resource, and the scope of searched fields adds precision. It does not, however, explicitly distinguish itself from the sibling list_notes, so the agent must infer that this tool is the query-driven one.

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?

Usage is implied: an agent can infer this is the tool for finding notes by keyword. But no alternatives are named (e.g. list_notes vs search_notes) and there are no when-not-to-use conditions, leaving the routing decision to inference.

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

update_noteA

Update an existing note in the vault.

Only the fields you pass are changed; omit a field (or pass None) to keep its current value. Passing a field replaces it wholesale: content="" empties the note's body and tags="" clears all its tags. A title cannot be cleared — a passed title must be non-empty (the same rule save_note applies).

Args: note_id: The numeric ID of the note to update. title: New title, or omit to keep the current one. content: New body text, or omit to keep the current one; "" clears the body. tags: New comma-separated tag list replacing the whole list, or omit to keep current tags; "" clears all tags.

Returns: A confirmation, or an error message if the note does not exist or nothing was provided to change.

ParametersJSON Schema

Name	Required	Description	Default
`tags`	No
`title`	No
`content`	No
`note_id`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.3/5.0

Behavior4/5

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

With no annotations, the description carries the full burden and does well: it discloses wholesale replacement semantics, that content="" empties the body and tags="" clears tags, that a title cannot be cleared, and the two error conditions. It omits permissions/auth requirements and whether the change is reversible.

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?

Front-loaded with the key replacement rule in the first sentences, then structured Args/Returns. Slightly redundant with the schema on parameter names, but every sentence adds behavioral meaning rather than restating types.

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

Completeness5/5

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

For a mutation tool with no annotations and 0% schema coverage, the description supplies the missing mutation semantics, clearing rules, and error cases. An output schema exists, so the brief Returns note is sufficient and no return-value detail is needed.

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

Parameters5/5

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

Schema coverage is 0%, yet the description documents all four parameters with meaning beyond the schema: note_id is the numeric ID, and title/content/tags each have explicit omit-vs-empty semantics that the bare schema types/nullable defaults cannot convey.

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?

States a specific verb and resource ("Update an existing note in the vault"), which clearly separates it from get_note/list_notes/delete_note. It partially differentiates from save_note by referencing the shared title rule, but never explicitly says save_note is for creation, so sibling routing is only implied.

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

Usage Guidelines4/5

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

Gives concrete usage semantics: only passed fields change, omit or pass None to keep current value, and "nothing was provided" is an error. It stops short of naming save_note as the create alternative or stating any preconditions/permissions.

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.

3 tool updatesv0.6.0Oct 1, 2026
- Changedlist_notes1 field changed
  - addedInput schema / properties / limit
```
Added value: +{
+  "default": 20,
+  "title": "Limit",
+  "type": "integer"
+}
```
- Changedsearch_notes1 field changed
  - addedInput schema / properties / limit
```
Added value: +{
+  "default": 20,
+  "title": "Limit",
+  "type": "integer"
+}
```
- Changedupdate_note9 fields changed
  - addedInput schema / properties / content / anyOf
```
Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]
```
  - changedInput schema / properties / content / default
```
Previous value: -""New value: +null
```
  - removedInput schema / properties / content / type
```
Removed value: -"string"
```
  - addedInput schema / properties / tags / anyOf
```
Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]
```
  - changedInput schema / properties / tags / default
```
Previous value: -""New value: +null
```
  - removedInput schema / properties / tags / type
```
Removed value: -"string"
```
  - addedInput schema / properties / title / anyOf
```
Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]
```
  - changedInput schema / properties / title / default
```
Previous value: -""New value: +null
```
  - removedInput schema / properties / title / type
```
Removed value: -"string"
```
6 tool updatesv0.1.0Sep 30, 2026
- First observeddelete_note
- First observedget_note
- First observedlist_notes
- First observedsave_note
- First observedsearch_notes
- First observedupdate_note

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4.1/5.0

Scored 2026-10-01 21:50 across 6 tools

Disambiguation5/5

Each tool targets a clearly distinct operation: save_note creates, get_note retrieves by ID, list_notes and search_notes offer different retrieval modes (browse vs full-text query), update_note modifies, and delete_note removes. There is no meaningful overlap; an agent can easily choose the right tool based on intent.

Naming Consistency5/5

All tool names follow a consistent snake_case verb_noun pattern: get_note, save_note, list_notes, delete_note, update_note, search_notes. The one variation save_note vs a hypothetical create_note is semantically clear and conventional for note vaults.

Tool Count5/5

Six tools provide exactly the operations needed for a note vault without bloat: create/read/update/delete plus listing and search. Each tool earns its place and the set is well-scoped for the domain.

Completeness5/5

The surface covers full CRUD lifecycle (save, get, update, delete) along with two complementary retrieval methods (list and full-text search). No obvious gaps for a note-taking server; even edge cases like empty updates and clearing tags are addressed in descriptions.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

OpenClaw MCP Ecosystem
io.github.yedanyagamiai-cmd
9 remote MCP servers on Cloudflare Workers for AI agents. Free tier + Pro API keys.
Agent Orchestration Cloud Platforms RAG Systems
3
agent.social A
io.github.singularitystudiosdev
Free social platform for AI agents — boards with tool-call receipts; MCP server + REST API.
Social Media
101
AIsa Web Search & Research AOAuth
one.aisa
Your agent needs the open web — searched by more than one engine, and read as clean markdown rather than raw HTML. **What you can ask for** • "Search this question with two providers and tell me where they disagree." • "Scrape these 40 URLs into markdown, in one batch." • "Crawl this documentation site and give me every page." • "Do deep research on this topic and cite the sources." • "Find the academic papers behind this claim." **How to use it** Point any MCP client at https://mcp.aisa.one/search/mcp and sign in with OAuth — there is no key to create or paste. 30 tools across several independent providers: Tavily and Exa search, answers, contents and agent runs; Firecrawl scrape, batch scrape, crawl, map and search; Perplexity Sonar, Sonar Pro, reasoning and deep research; Oxylabs AI search and LLM jobs; OpenAI and Anthropic web search; and scholarly search. **Why this rather than the source** Several independent indexes behind one account, because one engine's blind spot is not visible from inside it. **It is also a door to the rest** The same login reaches 26 sources and 580+ operations. Find the page here, then ask the same agent who links to it or how much traffic it gets — without adding a second server. **What it costs** Finding and inspecting an operation is free. Running one is billed per call at API prices, with no seat and no monthly minimum, and every call takes max_price_usd so an agent cannot overspend by accident. **Where else it reaches** https://mcp.aisa.one/seo-serp/mcp for the Google results page itself, https://mcp.aisa.one/seo-serp-other-engines/mcp for Bing, Baidu and Naver.
Browser Automation Search Web Scraping
351
UnifAPIOAuth
com.unifapi
Hosted MCP server for live public-data APIs and Skills for AI agents.
Open Data Search AI & Machine Learning
2

Related MCP Servers

Agent Toolbox
Search Web Scraping Weather Services
Vincentwei1021
A
license
Not graded
quality
C
maintenance
Production-ready MCP server for AI agents — web search, content extraction, screenshots, weather, finance, email validation, translation, and IP geolocation.
Updated 7 months ago (2026-03-10 13:06 UTC)
11 npm
6
MIT
Recallofficial
Knowledge & Memory RAG Systems
RecallWorks
A
license
Not graded
quality
C
maintenance
Open-source MCP memory server for AI agents — persistent, searchable, tiered memory across sessions. Works over stdio (Cursor, Claude Desktop) or HTTP+SSE. MIT licensed.
Updated 4 months ago (2026-06-16 08:03 UTC)
8
MIT
webpage-mcp
Browser Automation Web Scraping Search
Vl4dimirz
A
license
Not graded
quality
D
maintenance
A zero-config MCP server that lets AI agents fetch, read, and search live web pages without API keys or databases, using in-process BM25 retrieval.
Updated 3 months ago (2026-06-30 01:16 UTC)
71 npm
MIT
Combined MCP Server
SMH01-MOD-NEXT
A
license
Not graded
quality
C
maintenance
A self-hosted MCP server that gives AI agents controlled access to a machine: filesystem, shell, background processes, git, web fetching and persistent key-value memory.
Updated 2 months ago (2026-07-17 12:47 UTC)
GPL 3.0

mcp-minis

Why mcp-minis?

The servers

Quick Start

Option A — run any server straight from GitHub (no clone)

Option B — clone and install

Want all five at once?

Roadmap

Contributing

License

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

Recallofficial