Lacuna Research MCP

search_lacuna

Read-onlyIdempotent

Search Lacuna's ML/AI corpus for papers, authors, venues, institutions, hypotheses, and linked resources like code, datasets, models, and demos.

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

TableJSON 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

TableJSON 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.9/5.0

Behavior5/5

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

Annotations already declare read-only, idempotent, open-world, non-destructive, but the description adds substantial behavioral constraints beyond them: resource search does not support date_from/date_to, venue, year sorting, or semantic ranking; semantic ranking cannot use year sorting; fields cannot be combined with semantic ranking and weights must fall in 0 < w <= 100. These are exactly the limitations an agent needs to avoid erroring.

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?

Front-loaded with purpose, then workflow routing, then parameter behavior; each block earns its place given 13 parameters with zero schema documentation. It is dense and occasionally repetitive (resource filters are restated across several sentences), so it stops just short of maximally tight.

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 no explanation, and annotations cover the safety profile; the description fills the remaining gaps (filter interdependencies, ranking restrictions, date formats, follow-up tools). An agent has everything needed to call this correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description carries the full burden and largely does: it documents search_type values, resource_kind and provider enums and their dependency on search_type, ranking_profile options and their applicability, sort values, inclusive date bound formats, author_id_or_url semantics and its search_type=paper requirement, and fields syntax with weight bounds. Only limit, offset, query, and venue receive no explanation, which is a minor residual gap.

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?

States a specific verb (search) and resource (Lacuna's ML/AI corpus), and enumerates the entity types retrievable: papers, directions, authors, venues, institutions, hypotheses, and resources. It clearly separates itself from read-style siblings like get_paper and get_resource, which it names as follow-up steps.

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 guidance: use search_type=hypothesis for novel ideas then get_hypothesis; use paper for literature then get_paper; use resource with resource_kind=dataset for benchmarks. It also names the conditions under which filters apply (resource_kind/provider require search_type resource or all) and the alternatives for biographies/news.

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

Deploy Server