Lacuna Research MCP

Search Lacuna

search_lacuna

Read-onlyIdempotent

Search Lacuna's ML/AI corpus for papers, authors, venues, hypotheses, and linked resources like code, datasets, and models to aid literature review and research idea generation.

Instructions

Search Lacuna's ML/AI corpus for papers, research directions, authors, venues, institutions, novel research hypotheses, and research resources (code repositories, datasets, models, and demos linked to papers).

For novel ML/AI research ideas, use search_type="hypothesis", then get_hypothesis on promising results.

search_type accepts all, cluster, paper, author, institution, venue, hypothesis, or resource. Use paper for literature and get_paper to read a result. Use other sources for biographies, news, and non-research web content.

Resources: search_type="resource" searches GitHub repositories, Hugging Face datasets/models, and Zenodo records that Lacuna has linked to at least one paper. To find benchmark or evaluation datasets, use search_type="resource" with resource_kind="dataset" (for example query "image classification benchmark" or a dataset name like "ImageNet"). resource_kind accepts codebase, dataset, model, or demo (one value or a list); provider accepts github, huggingface, or zenodo. Both filters require search_type "resource" or "all" (with either filter set, only resources are returned). Each result has an external url, a Lacuna context_url, and linked_paper_count; call get_resource on its id to list the linked papers (with their relationship to the resource), then get_paper on those papers for reported results and numbers. Resource search does not support date_from/date_to, venue, year sorting, or semantic ranking.

ranking_profile accepts:

default / lexical (default): production ranking; relevance-sorted paper searches combine lexical and semantic retrieval when fields is unset.
semantic: conceptual paper retrieval; supported for paper and all.
bm25_title_abstract / bm25: lexical paper matching over those fields.

sort accepts relevance (default), year_desc, or year_asc. Semantic ranking cannot use year sorting; constrain recency with date_from/date_to instead. date_from and date_to are inclusive YYYY, YYYY-MM, or YYYY-MM-DD bounds. author_id_or_url constrains a paper search to one author. Pass an author ID or Lacuna author page URL; it requires search_type="paper".

fields optionally restricts and weights lexical fields, for example "title^4,abstract". Supported names are title, abstract, summary, concepts, name, top_names, and venue, plus description, topics, provider_key, and paper_titles for resources (a resource's title already includes its description, topics, README text, and linked paper titles). Fields must exist on the selected search_type, weights must be within 0 < weight <= 100, and fields cannot be combined with semantic ranking.

Input Schema

Name	Required	Default
`sort`	No	relevance
`limit`	No
`query`	Yes
`venue`	No
`fields`	No
`offset`	No
`date_to`	No
`provider`	No
`date_from`	No
`search_type`	No	all
`resource_kind`	No
`ranking_profile`	No
`author_id_or_url`	No

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv0.5.1Sep 28, 2026

addedInput schema / properties / provider

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Provider"
+}

addedInput schema / properties / resource_kind

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Resource Kind"
+}

Changed1 schema field changedv0.3.0Sep 21, 2026

addedInput schema / properties / author_id_or_url

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Author Id Or Url"
+}

First observedv0.2.0Jul 31, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Annotations already declare readOnly/openWorld/idempotent/non-destructive, so the bar is lower, yet the description adds substantial operational context: resource search constraints (no date_from/date_to, venue, year sorting, or semantic ranking), that resource_kind/provider filters require search_type 'resource' or 'all', that author_id_or_url requires 'paper', and that semantic ranking cannot use year sorting. These combination rules are the main reason this scores well; it stops short of describing pagination or result-count behavior for the general case.

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 long, but the tool has 13 parameters with zero schema documentation, so most sentences are load-bearing and each paragraph maps to a coherent theme (purpose, routing, resources, ranking, filters). It is front-loaded with purpose and alternatives; density is high but waste is low.

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?

An output schema exists, so return values need not be explained, and the description instead covers what the schema cannot: filter compatibility rules, ranking-mode restrictions, and the get_paper/get_resource follow-up path including linked_paper_count and context_url. Combined with the annotations covering safety semantics, an agent has enough to call this correctly.

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% across 13 params, so the description carries the full burden and largely meets it: search_type values, resource_kind values, provider values, ranking_profile options, sort options, date bound formats (YYYY / YYYY-MM / YYYY-MM-DD, inclusive), author_id_or_url input format, and fields names/weight syntax (0 < weight <= 100) are all spelled out. limit, offset, and the purpose of venue outside the resource caveat are left undocumented, so it is not fully compensating.

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?

Opens with a specific verb and resource: 'Search Lacuna's ML/AI corpus for papers, research directions, authors, venues, institutions, novel research hypotheses, and research resources.' It enumerates exactly what entity types are covered, letting an agent separate this broad search tool from the narrow get_paper/get_resource/get_hypothesis siblings without opening any schema.

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?

Explicit routing is provided: 'For novel ML/AI research ideas, use search_type="hypothesis", then get_hypothesis on promising results', and 'Use paper for literature and get_paper to read a result' with a stated exclusion ('Use other sources for biographies, news, and non-research web content'). It also names follow-on tools (get_resource, get_paper) and the conditions that select them.

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

Deploy Server