BrowserAI Dev vs Cite Caddy — MCP Server Comparison | AllMCPs
Side-by-Side Model Context Protocol Comparison
BrowserAI Dev vs Cite Caddy
In-depth architectural comparison of the BrowserAI Dev and Cite Caddy MCP servers. Compare execution transports, security boundaries, tool capabilities, quality scores, and ready-to-paste client installation snippets for Claude, Cursor, Windsurf, and VS Code.
At a Glance & Executive Verdict
BrowserAI Dev
Research · Local stdio
Quality: 64/100 (Good) | Auth: API Key required
Cite Caddy
Research · Local stdio
Quality: 44/100 (Fair) | Auth: No auth required
Verdict Summary: Choose BrowserAI Dev if you need specialized Research tools running via a local process. Choose Cite Caddy if your workspace requires Research integration with local subprocess execution. Both servers can be configured concurrently in your client's mcpServers manifest.
Which MCP Server Should You Choose?
Choose BrowserAI Dev when:
You need dedicated capabilities in the Research domain.
You prefer local stdio subprocess transport architecture.
Your security boundary fits: API Key required (Freemium).
You have access to required keys: LASTSEARCH_API_KEY.
Evidence-backed web research for AI agents. Real-time search with cited claims, confidence scores, and compare mode (raw LLM vs evidence-backed). MCP server, REST API, and Python SDK.
Remote MCP server for full read/write access to a Zotero library
BrowserAI Dev is categorized under Research and uses a local stdio subprocess. In contrast, Cite Caddy belongs to Research using local stdio subprocess. Select BrowserAI Dev when you need capabilities focused on research and Cite Caddy when you require tools for research.
Research within a session (recalls prior knowledge)
session_recall
Query session knowledge without new web search
session_share
Share a session publicly (returns share URL)
session_knowledge
Export all claims from a session
session_fork
Fork a shared session to continue the research
+1 more tools listed on main page
Cite Caddy Tools (39)
search_items
query` defaults to Zotero's quick search (title/creator/year); `full_text=True` also matches indexed content of attached files/notes (`qmode="everything"`), requires non-empty `query`. Each result's `creators` is a list of `{creatorType, firstName, lastName}` (or `{creatorType, name}` for single-fi…
get_item
creators` shape as above.
list_collections
list_tags
list_trash
creators` shape as above.
list_saved_searches
list_groups
id` doubles as `target_library_id` (with `target_library_type="group"`) for `move_item_to_different_library`.
list_item_types
list_item_fields
list_item_type_fields
Check before `create_item`/`update_item` instead of guessing — what fields a given `item_type` accepts.
list_item_creator_types
Same, for `creators` entries' `creatorType`.
list_creator_fields
Name-shape fields (`firstName`, `lastName`, `name`, ...) valid on a `creators` entry itself — not the same as `list_item_creator_types` (roles).