Skip to content

Add keyless Parallel Search MCP example - #287

Closed
georgeatparallel wants to merge 1 commit into
Eigenwise:mainfrom
georgeatparallel:feat/parallel-search-mcp-example
Closed

georgeatparallel wants to merge 1 commit into
Eigenwise:mainfrom
georgeatparallel:feat/parallel-search-mcp-example

Conversation

@georgeatparallel

Copy link
Copy Markdown

Adds a runnable remote MCP example for web search and page extraction through Parallel, with no account, API key, local server, or LLM key needed. It uses Atomic Agents' existing SDK-session interface and discovered tool schemas.

Parallel's anonymous search uses Fast. Artificial Analysis currently shows Fast at 80% DeepSearchQA F1 and 18.4 seconds per benchmark task. Those API benchmark results give useful context for this starter example; they aren't timing measurements of Atomic Agents.

The example sends atomic-agents/<installed-version> in its User-Agent for aggregate free MCP usage measurement and explains what data goes to Parallel. It also fixes MCP tool errors being converted into successful output, with regressions for typed and generic results.

Validation: 343 tests passed, 3 skipped; Black and Flake8 passed. The exact example discovered and called Search and Fetch anonymously, returned useful URLs and excerpts, and sent project identification on both calls. Sphinx built successfully. Existing search examples and provider choices stay unchanged.

I work at Parallel, which operates this service.

@Eigenwise

Copy link
Copy Markdown
Owner

Thanks for this. There are two separate things in here though.

The isError guard is a real fix. On main, a tool with an outputSchema that returns isError: true with a structuredContent that happens to fit the schema comes back as a successful typed result. I want that fixed. It also changes behavior for untyped tools (error text in result becomes a raised RuntimeError), so it should be its own PR where that tradeoff is the whole discussion. Could you split it out with the test?

The Parallel docs section I'm going to pass on. Remote servers already work through client_session, and I don't take vendor-specific examples for the same reason I don't take provider additions (see #273). The hardcoded User-Agent for usage measurement isn't something I want to ship in the docs either.

@Eigenwise

Copy link
Copy Markdown
Owner

Closing this as discussed earlier: the vendor-specific docs and usage-measurement headers add promotion and service coupling we do not want in the framework guide. The MCP error-handling fix now has its own PR, #295, and is being reviewed separately. The error guard here also includes the entire result in diagnostics, which can expose private structured content. Thanks for separating the useful fix.

@Eigenwise Eigenwise closed this Oct 4, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants