Loading ToolBench
MCP server wrapping Asta's AI-powered Paper Finder for academic paper search
LitLens has three clearly named tools with reasonable descriptions and basic parameter schemas. However, it suffers from incomplete output documentation, missing parameter descriptions, and weak error handling guidance. The async job model is well-motivated but not fully self-documenting, LLMs need clearer guidance on polling behavior and timeout expectations. Descriptions exceed the baseline length (194 chars avg) and provide some context about when to use tools, but lack structured output schemas and parameter constraint details.
Start an asynchronous follow-up on an existing search thread. COMPLEMENTARY TOOL: - Use this to refine the search or ask questions about the papers found. ASYNC/PARALLEL USAGE: - Like search_papers, this is async. Launch it, then do other work (checking other sources, writing code) while waiting. Returns a Job ID immediately. Use fetch_results(job_id) to get the output. Please wait at least 30 seconds before calling fetch_results.
Check the status or get the results of a search job. This tool will block for up to 10 seconds waiting for the job to complete.
Start an asynchronous search for academic papers using the Asta Agent. STRATEGY: - Asta is an intelligent agent, not just a keyword search engine. - COMPLEMENTARY TOOL: This tool is best used alongside web search. Use this for deep academic retrieval and web search for broader context or recent developments. - ASYNC/PARALLEL USAGE: This tool returns a Job ID immediately. While waiting for the results (which may take a minute), you should continue with other tasks, such as performing web searches or analyzing other data. You do not need to wait idly. - Provide RICH context. Instead of "tell me about transformers", try "evolution of transformer architectures for efficient long-context processing". - Use this tool to EXPLORE. Ask for "related approaches", "seminal papers", or "contrasting viewpoints". - If initial results are too broad, follow up with `continue_search` to refine, rather than starting over. Returns a Job ID immediately. Use fetch_results(job_id) to get the output.
No documented output schema for any tool. fetch_results returns formatted paper data but structure is undefined, LLMs cannot extract fields for downstream use.
Parameter descriptions are sparse and lack constraints. 'query' has no length bounds, format rules, or complexity guidance. 'thread_id' has no format hint or TTL warning. 'job_id' lacks format details.
Error handling is minimal. Tools raise ToolError but provide limited recovery guidance. 'Rate limit exceeded' does not suggest retry timing. 'Thread ID not found or expired' could suggest starting a new search, but this is coded, not surfaced to LLM via error message.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 48 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Async job model is implicit, not explicit. Tools return Job IDs but polling behavior, timeout, retry logic, and worst-case wait time are only documented in descriptions, not in structured return types. LLMs may not understand when to retry or abandon a job.
Session management (thread_id) is server-side with 1-hour TTL, but LLMs have no way to know TTL or validate thread_id before calling continue_search. Missing: clear error message guiding LLM to restart if thread expired.
Mode parameter in fetch_results uses enum but descriptions are vague. 'compact' returns 'top 20 papers by relevance', but what does each paper object look like? Are there pagination controls? Missing: sample output structure.