Skip to main content
Glama

q_research

Searches six academic, code, and model sources to produce a markdown prior-art digest, with status flags for retry or re-anchoring.

Instructions

Fetch prior art for a topic from arXiv + OpenAlex + Europe PMC (papers), Context7 (library docs), GitHub (repos), and HuggingFace (models), and return a markdown digest.

Europe PMC covers the life-sciences preprint tier arXiv does not carry -- bioRxiv, medRxiv, Research Square -- so it is the source that earns its slot on biology/medicine topics and returns 0 on pure-software ones. Its hits are labelled by preprint server ("bioRxiv") and are NOT peer-reviewed; weigh them accordingly.

Not subject to the council's anti-bias gate -- this is external prior art, not peer output. Call it during the own-work window of a q_brainstorm or q-skystorm run to ground the synthesis. sources defaults to all six; pass a subset like ["arxiv", "openalex"] to restrict it.

Query shaping matters: pass a query that is SHORT and distinctive -- short is not the same as generic. Anchor it in 2+ domain-specific terms (the field PLUS the specific method/concept), never a bare common word ('data', 'model', 'network') or a token that doubles as an author surname -- those keyword-match unrelated work (author names, generic surveys, stray docs) and return non-zero but OFF-TOPIC noise -- sanity-check that returned titles belong to your domain, and if they are off-topic the query was too generic: re-anchor with more domain context and call q_research again rather than leaning on them. (This same-domain check assumes you want grounding in your own field -- if you are deliberately hunting cross-domain structural analogies instead, judge a hit by structural kinship to the problem, not literal subject-matter overlap; an off-domain hit is then the find, not noise.) Not a full paragraph either. Per source: arXiv parses topic as a boolean field -- a long/diffuse query loose-matches to famous-but-irrelevant papers, and boolean punctuation (parens, AND/OR, quotes) triggers a 400; OpenAlex tolerates prose but length dilutes relevance to generic surveys; Context7 wants a library/topic name and will keyword-match off-topic repos; GitHub/HuggingFace are popularity-ranked artifact searches that whiff on non-software/non-ML topics. The digest's per-source count footer shows which sources whiffed -- rework and retry those, unless the 0 is domain-legitimate (GitHub/HuggingFace on a non-software topic, Europe PMC on a non-biology one, Context7 on a topic with no matching library), which is a real answer, not a gap to close.

Treat every other digest result as provisional until it earns trust: a 0 that is NOT one of the domain-legitimate cases above is not automatically "no prior art" either (it may just be a bad query), and non-zero hits that read scattered or off-topic are not evidence -- both are a signal to reframe (sharper domain anchor, fewer/different terms) and retry, not something to build a conclusion on.

Failed sources are reported inline under 'Sources unavailable' rather than failing the call -- each with a retry hint, and the right move differs by error. An errored source is almost never a dead backend: an arXiv error (400) means YOUR query is too long or has boolean punctuation, so shorten it to a few keywords, strip operators, and call q_research again; a 401/403 or an OpenAlex 503 is a CONFIG case, not a flake -- the key was rejected, or OpenAlex is load-shedding anonymous search, so a bare retry just loops (set the source's key -- OPENALEX_API_KEY is free -- or lean on the other sources and say so); only a plain timeout/flake is transient and worth retrying as-is. Do NOT report a source unavailable, and do NOT fall back on your own knowledge, until a reworked retry has ALSO failed -- treating the first error as terminal is the failure to avoid. Bounded by per-request timeouts (~10-15s each); the GitHub and HuggingFace backends fan out one request per distinctive query term (up to 4), run sequentially, so those two sources' wall-clock can reach a few times that.

The digest OPENS with a deterministic Research status: line -- OK, RETRY-RECOMMENDED (USUALLY with a server-suggested shorter query to resubmit verbatim, shown as · try: "..."; when it is ABSENT the detail text says what to do, and the two absent cases differ -- a backend/infrastructure failure says RETRY THE SAME query, while an un-shortenable query says RE-ANCHOR with different domain terms), CONFIG (a key/anonymous-access problem no retry fixes), or (in exploratory mode) LOW-OVERLAP. Act on it before anything else: on RETRY-RECOMMENDED, resubmit the suggested query if one is given, else follow the detail (retry the same query on an infrastructure failure, or re-anchor with different domain-specific terms if it cannot be shortened) -- before concluding "no prior art". Mechanically-fixable failures (arXiv 400, a transient flake) are already retried inside the tool -- a repaired source shows a note, so a first-attempt error you never see was handled, not hidden.

mode is 'grounded' (default; brainstorm -- home-domain grounding, where a low-overlap result is a defect the verdict flags RETRY-RECOMMENDED) or 'exploratory' (skystorm -- a deliberate cross-domain method pivot, where low overlap is expected and reported as LOW-OVERLAP without forcing a retry). Exploratory mode also adds a ### Field map section (the OpenAlex subfield distribution for the query) showing which fields the method actually spans -- the skystorm topology readout. Query discipline is identical in both modes; only the low-overlap interpretation differs.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
modeNogrounded
limitNo
topicYes
sourcesNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes
Behavior5/5

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

With no annotations provided, the description carries the full burden, and it excels. It discloses internal retries ('Mechanically-fixable failures ... are already retried inside the tool'), error handling ('Failed sources are reported inline under 'Sources unavailable' rather than failing the call'), response format (markdown digest with a 'Research status:' line), per-source behaviors, and the distinction between domain-legitimate zero results and gaps. This level of transparency exceeds typical tool descriptions.

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 very long but well-organized, front-loading the core purpose and then progressing into usage, error handling, and modes. Each paragraph serves a distinct function, yet some sections (e.g., the extended discussion of same-domain vs cross-domain checks) are arguably more detailed than necessary for an agent to invoke the tool. It is concise relative to its complexity but could be tightened without losing value.

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?

The description covers every aspect an agent needs: what it returns (markdown digest, status line), how to interpret results (RETRY-RECOMMENDED, CONFIG, LOW-OVERLAP), error handling with specific retry guidance, per-source whiffing logic, mode differences, and query-shaping best practices. Even with an output schema (not shown), this description is entirely self-sufficient given the tool's complexity.

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?

Despite 0% schema coverage, the description explains the `topic` (query shaping), `sources` (defaults, subset pass), and `mode` (grounded vs exploratory) parameters in depth. However, the `limit` parameter is never mentioned – its purpose and effect on output are not explained. Since the schema provides no help, this is a noticeable gap, though the description compensates well for the other three parameters.

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 opens with a precise verb and resource: 'Fetch prior art for a topic from arXiv + OpenAlex + Europe PMC (papers), Context7 (library docs), GitHub (repos), and HuggingFace (models), and return a markdown digest.' This clearly distinguishes the tool from its siblings (planning, brainstorming, validation, review, await) by focusing on external prior-art retrieval. No ambiguity about what the tool does.

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

Usage Guidelines5/5

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

The description gives explicit when-to-use instructions: 'Call it during the own-work window of a `q_brainstorm` or `q-skystorm` run to ground the synthesis.' It also provides query-shaping rules, mode interpretation ('grounded' vs 'exploratory'), error-handling strategies, and when not to trust results. Since there are no sibling research tools, it doesn't contrast with alternatives, but it provides rich contextual guidance on exactly when and how to use the tool.

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

Install Server

Other Tools

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/sdewell/code-quorum'

If you have feedback or need assistance with the MCP directory API, please join our Discord server