How do I use gengomcp?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@gengomcp Show me papers on few-shot learning from EMNLP 2023" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

gengomcp

by sobamchan

Overview Schema Related Servers Score Discussions

Python

Remote

gengomcp

An MCP server (Python, stdio transport) that lets an agent retrieve ACL conference papers about NLP from a Qdrant vector database. It combines semantic search (Sentence‑Transformers embeddings) with structured filtering by bibliographic fields like publication year and venue.

Qdrant access is currently limited. This server queries a shared Qdrant collection of ACL NLP papers. If you'd like credentials to use it, please reach out to the project maintainer — access may be granted at a limited scale. You'll receive a QDRANT_URL, QDRANT_KEY, and QDRANT_COLLECTION_NAME to set in your MCP client's env field.

Quick start

Install gengomcp from PyPI:
```
pip install gengomcp
```
Configure credentials in your MCP client's env field. You'll need QDRANT_URL, QDRANT_KEY, and QDRANT_COLLECTION_NAME — see Wiring it into an MCP client for full config examples.
Use it. Your agent can now call search_papers, get_paper, list_papers, and get_collection_info to find ACL NLP conference papers.

Wiring it into an MCP client

Any MCP client over stdio works. When installed from PyPI (pip install gengomcp or uv tool install gengomcp), the gengomcp command is on your PATH and runs independently of your working directory, so it's safe to launch from anywhere.

Example for Claude Desktop (claude_desktop_config.json):

{
  "mcpServers": {
    "gengomcp": {
      "command": "gengomcp",
      "args": []
    }
  }
}

Configuring credentials via the MCP client

Credentials (QDRANT_URL, QDRANT_KEY, QDRANT_COLLECTION_NAME) are read from the process environment. Inject them directly through your MCP client's env field — this is the recommended way to configure per-agent credentials:

{
  "mcpServers": {
    "gengomcp": {
      "command": "gengomcp",
      "args": [],
      "env": {
        "QDRANT_URL": "https://<cluster>.cloud.qdrant.io",
        "QDRANT_KEY": "<your-api-key>",
        "QDRANT_COLLECTION_NAME": "papers_test"
      }
    }
  }
}

Credentials come from the MCP client's env field and are never logged or hard-coded. They live only on your machine — they are not sent to any third-party service.

Required variables (no defaults):

Variable	Description
`QDRANT_URL`	Qdrant cluster URL
`QDRANT_KEY`	Qdrant API key
`QDRANT_COLLECTION_NAME`	Collection to search (e.g. `papers_test`)

Optional variables (have defaults; not needed for basic use): EMBEDDING_MODEL, AUTO_CREATE_INDEXES, LOG_LEVEL.

If a required variable is missing at startup, the server exits with a clear error explaining how to set it.

Poolside (`pool`)

The server is registered to use the PyPI-installed gengomcp command with credentials injected via the env field. Verify with:

pool mcp list          # shows: gengomcp
pool mcp get gengomcp  # shows the stored command + args + env vars

The config is stored under mcp_servers in ~/.config/poolside/settings.yaml (personal config). Credentials are passed via the env field and live only on your machine — they are never sent to Poolside's servers. To remove the server later:

pool mcp remove gengomcp

Related MCP server: mcp-server-qdrant

Tools

Tool	Purpose
`search_papers`	Semantic search for ACL NLP papers. USE when the user has a topic/question. Embeds `query` and returns the most similar papers, optionally narrowed by structured filters.
`get_paper`	USE to inspect a single ACL NLP paper in full detail (abstract, summaries, entities) when you already have its `paper_uuid` from a search result.
`list_papers`	USE to browse/filter ACL NLP papers with no query text — pure structured filtering + pagination (e.g. "all ACL 2024 papers").
`get_collection_info`	USE first to discover available venues, years, fields of study, and vector names before building filters.

`search_papers` parameters

query                 str   (required) search text
limit                 int   = 10   (clamped 1..100)
vector_name           str   = "overview"   one of overview/approach/challenge/outcome
year                  int            exact publication year (e.g. 2026)
year_min / year_max   int            year range (inclusive)
year_gt  / year_lt    int            year range (exclusive)
venue                 str            substring match on the booktitle (e.g. "Annual Meeting")
collection_acronym    str            exact venue acronym, e.g. "ACL" / "EMNLP" / "NAACL"
collection_id         str            e.g. "2026.acl"
field_of_study        list[str]      membership on `field_of_studies` (e.g. ["Reasoning"])
author                str            name contained in `author_names`
min_score             float          only return results with similarity >= this value

All filters are AND‑combined, so you can layer them, e.g. search_papers(query="...", year_min=2020, collection_acronym="ACL").

Example tool calls

search_papers(query="stress testing large language models",
              vector_name="overview", year_min=2024, year_max=2026,
              collection_acronym="ACL", limit=5)

get_paper(paper_id="000036a6-e2be-523e-8b8d-0f2cbe2b39e7")

list_papers(collection_acronym="EMNLP", year=2024, limit=20)

list_papers(field_of_study=["Reasoning"], author="Pan", limit=20, offset=<prev_uuid>)

How it works

Secrets & config — credentials are set via your MCP client's env field (QDRANT_URL, QDRANT_KEY, QDRANT_COLLECTION_NAME). QDRANT_KEY is passed directly to the Qdrant client and is never printed or hard-coded.
Payload indexes — Qdrant requires a payload index to filter on a field. This collection ships with no indexes, so the server creates the needed ones idempotently at startup (non-destructive — it only adds indexes). Disable with AUTO_CREATE_INDEXES=0 if you manage indexes yourself.
Embeddings — queries are embedded with Sentence‑Transformers using Snowflake/snowflake-arctic-embed-s, the only model that matches this collection's 384-dimensional index. The server can truncate+renormalise other model outputs to the index dimensionality (matryoshka‑style) as a safety net, but models in a different embedding space (e.g. the 768-dim m-v1.5) will still fail to retrieve — see The embedding model.
Named vectors — the overview/approach/challenge/outcome named vectors in the collection are all 384-dimensional.

The embedding model

The collection's vectors are 384-dimensional and were built with the Snowflake arctic-embed "s" model (Snowflake/snowflake-arctic-embed-s). This is the only model that produces embeddings in the correct space for this index — it is the default and should not be changed.

Other models in the Snowflake family (e.g. m-v1.5 at 768-dim or l-v1.5 at 1024-dim) live in different embedding spaces. Even though the server can truncate embeddings to the index dimensionality (matryoshka-style) as a safety net, those models will not retrieve against this collection — keep EMBEDDING_MODEL at its default unless you re-index with a different model.

Project layout

gengomcp/
├── server.py        # the MCP server (tools + Qdrant/Embeddings glue)
├── main.py          # thin launcher
├── pyproject.toml   # deps + `gengomcp` console script
├── uv.lock          # pinned dependency versions
├── LICENSE          # MIT
├── .env.example     # template for all config vars (committed)
└── README.md

Development / testing

uv run python -c "import server; print('ok')"

Available Tools

4 tools

get_collection_infoA

Discover the ACL NLP papers collection schema: vector dimensions, distance metrics, total paper count, and sampled distinct values for filterable fields (years, venue acronyms, booktitles, fields of study). USE THIS first when you need to know what venues, years, or fields exist before building search_papers or list_papers filters.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.7/5.0

Behavior4/5

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

With no annotations, the description carries the burden of behavioral disclosure. It does an above-average job by noting that distinct values are 'sampled' (not exhaustive) and lists exactly what metadata is returned. It does not explicitly state that the operation is read-only, but 'Discover' and the absence of parameters strongly imply this; the sampling caveat is especially valuable.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences long, front-loads the core purpose, and packs relevant details (schema contents, sampled values, usage guidance) without filler. Every sentence earns its place.

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?

Given the tool's simplicity (no parameters), the presence of an output schema, and the clear usage context, the description is complete. It explains what the tool returns, why it exists, and when to invoke it relative to sibling tools.

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?

The tool has zero parameters, so the parameter-semantics dimension has little to evaluate. Per the rubric, a zero-parameter tool receives a baseline of 4. The description adds no parameter-specific details because none exist, which is appropriate.

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 specific verb ('Discover') and clearly identifies the resource ('ACL NLP papers collection schema'), then enumerates what the tool reveals: vector dimensions, distance metrics, total paper count, and sampled distinct values for filterable fields. This differentiates it from sibling tools like search_papers and list_papers by positioning it as a schema-discovery tool.

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 explicitly says 'USE THIS first' and ties the tool to concrete scenarios: when you need to know venues, years, or fields before building search_papers or list_papers filters. This provides clear guidance on when to use it and implies that the sibling tools are the follow-up alternatives.

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

get_paperA

Fetch a single ACL conference NLP paper by its paper_uuid (the Qdrant point id). USE THIS to inspect a paper in full detail — abstract, summaries, method/task entities — when you already have its ID from a search_papers or list_papers result. Returns the complete paper payload.

ParametersJSON Schema

Name	Required	Description	Default
`paper_id`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.4/5.0

Behavior4/5

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

With no annotations, the description carries the full burden. It discloses that the tool returns the complete paper payload and mentions the content (abstract, summaries, method/task entities). It implies read-only behavior via 'Fetch' and 'inspect', though it doesn't explicitly state lack of side effects. Sufficient for a simple read operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, front-loaded with the core action, and every clause adds value: what it fetches, the identifier, when to use, and what it returns. No fluff.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is simple with one parameter and an output schema (though not shown), so the description doesn't need to detail return structure. It covers purpose, usage, parameter meaning, and return payload. The only gap is the parameter name mismatch, preventing a perfect score.

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

Parameters3/5

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

The schema has one parameter `paper_id` with 0% description coverage, so the description must compensate. It does explain the identifier as `paper_uuid` and notes it comes from search/list results, adding meaning. However, the inconsistency between the description's `paper_uuid` and the schema's `paper_id` could confuse an agent, reducing clarity.

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 clearly states the verb 'Fetch' and the resource 'a single ACL conference NLP paper', specifying the identifier as `paper_uuid` (Qdrant point id). It also distinguishes from siblings by mentioning it is used after obtaining an ID from search_papers or list_papers, making its purpose unambiguous.

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?

Provides explicit usage guidance: 'USE THIS to inspect a paper in full detail when you already have its ID from a search_papers or list_papers result.' This clearly indicates when to use and implicitly contrasts with searching or listing, offering context for tool selection.

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

list_papersA

Browse ACL conference NLP papers using structured filters only (no semantic query). USE THIS to list papers when you know the filters but have no search text — e.g. 'all ACL 2024 papers' or 'all papers by this author'. Supports year/venue/acronym/field_of_study/author filters and pagination via offset (the last paper_uuid from the previous batch).

ParametersJSON Schema

Name	Required	Description	Default
`year`	No
`limit`	No
`venue`	No
`author`	No
`offset`	No
`year_gt`	No
`year_lt`	No
`year_max`	No
`year_min`	No
`collection_id`	No
`field_of_study`	No
`collection_acronym`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.4/5.0

Behavior4/5

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

With no annotations, the description carries the burden. It discloses a key behavioral detail – pagination via `offset` defined as 'the last paper_uuid from the previous batch' – which goes beyond the schema. It does not mention ordering, result shape, or read-only nature, but those are either obvious or covered by the output schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is three sentences, front-loaded with purpose, then usage, then parameter/pagination details. Every sentence adds distinct value with no fluff.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description explains the core listing functionality and pagination sufficiently, and an output schema exists for return values. However, it leaves out some filter parameters (e.g., year_min/year_max) which are non-obvious from names alone, making it slightly incomplete for a 12-parameter tool.

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

Parameters3/5

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

Schema description coverage is 0%, so the description must compensate. It lists 'year/venue/acronym/field_of_study/author' and 'offset', covering 5 of 12 properties. It omits range filters (year_gt/lt/min/max), limit, collection_id, and doesn't clarify whether 'acronym' maps to collection_acronym. The offset semantics are well explained, but the partial coverage leaves gaps.

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 clearly states the tool 'Browse ACL conference NLP papers using structured filters only (no semantic query)' – a specific verb+resource+constraint. It distinguishes from siblings by explicitly excluding semantic queries and by giving concrete examples like 'all ACL 2024 papers'.

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?

It gives an explicit when-to-use: 'USE THIS to list papers when you know the filters but have no search text' and provides examples. The 'no semantic query' phrase implies that for search text, one should use a different tool (search_papers). This is nearly as clear as naming the alternative.

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

search_papersA

Semantic search for ACL conference papers about NLP. Embeds the query with a Sentence-Transformers model (Snowflake arctic-embed-s, 384-dim, matching the collection index) and returns the most similar papers ranked by cosine similarity. USE THIS when the user has a research topic or question and wants to find relevant papers. Narrow results with structured filters: publication year (exact or range), venue/booktitle, collection acronym (e.g. ACL/EMNLP/NAACL), collection id, field of study, or author. Set vector_name to search within a specific summary dimension (overview/approach/challenge/outcome).

ParametersJSON Schema

Name	Required	Default
`year`	No
`limit`	No
`query`	Yes
`venue`	No
`author`	No
`year_gt`	No
`year_lt`	No
`year_max`	No
`year_min`	No
`min_score`	No
`vector_name`	No	overview
`collection_id`	No
`field_of_study`	No
`collection_acronym`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.4/5.0

Behavior4/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It explains the embedding model, dimensions, similarity ranking, and the vector_name feature for searching different summary dimensions. It does not describe the output structure, but the output schema exists, and the search operation is inherently read-only.

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 a single dense paragraph that leads with the core purpose and method, then adds filter options and vector_name details. It is longer than strictly necessary but every sentence contributes useful information without repetition or fluff.

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?

Given the tool's complexity (14 parameters) and the presence of an output schema, the description is remarkably complete. It covers the embedding mechanism, query semantics, structured filters, and vector_name customization, providing the agent with sufficient context to select and invoke the tool 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%, so the description must compensate. It successfully explains the meaning of major filter parameters (year, venue, collection acronym/id, field of study, author) and vector_name. However, limit and min_score are not explicitly described beyond their inferred names, leaving a minor semantic 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?

The description clearly identifies this as a semantic search tool for ACL conference papers, with a specific verb ('Semantic search'), a defined resource, and a distinctive method (embedding with Sentence-Transformers and cosine similarity). It distinguishes itself from siblings like list_papers and get_paper by emphasizing ranked relevance search.

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

Usage Guidelines4/5

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

The description explicitly states when to use the tool: 'USE THIS when the user has a research topic or question and wants to find relevant papers.' This gives clear usage context, but it does not mention when to use alternatives (e.g., list_papers or get_paper), so it stops short of a full when/when-not comparison.

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

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.7/5.0

Disambiguation5/5

Each tool has a distinct role: semantic search, ID-based retrieval, filter-based browsing, and schema discovery. There is no overlap in purpose; search_papers and list_papers differ meaningfully by query type.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern with lowercase and underscores: search_papers, get_paper, list_papers, get_collection_info. This is predictable and easy to understand.

Tool Count5/5

Four tools is well-scoped for a read-only ACL paper search and retrieval server. Each tool covers a core capability without unnecessary bloat.

Completeness5/5

The tool surface covers the full read-only lifecycle: discover schema, search semantically, browse with filters, and retrieve a specific paper by ID. There are no obvious missing operations for the stated purpose.

Maintenance

ActivityMaintained

ResponsivenessSyncing

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

mcp A
ai.llmse
Public MCP server for the LLM Search Engine
Search RAG Systems Developer Tools
102
Airweave Search
io.github.airweave-ai
MCP server for searching Airweave collections with natural language queries.
Search Art & Culture Open Data
25,729
Needle
com.needle-ai.mcp
The Needle MCP server enables semantic search on documents stored in files like PDFs, DOCX, and XLSX by connecting AI applications to external data sources. It provides capabilities to create and manage document collections, perform natural language searches on stored content, and retrieve relevant information without requiring exact keyword matches.
RAG Systems Search File Systems
2
Mirror Memory MCP Server
io.github.Tr1ckyMag1ca1
Personal knowledge base MCP server with semantic search, auto-categorization, metadata extraction
Knowledge & Memory Search Note Taking
2

Related MCP Servers

MCP Server for Qdrant
Vector Databases Search Databases
Jimmy974
A
license
Not graded
quality
D
maintenance
A Machine Control Protocol (MCP) server that enables storing and retrieving information from a Qdrant vector database with semantic search capabilities.
Updated a year ago (2025-03-18 14:44 UTC)
Apache 2.0
mcp-server-qdrant
Vector Databases RAG Systems
vaporif
A
license
Not graded
quality
C
maintenance
MCP server for Qdrant vector database with local BERT embeddings. Enables semantic search and vector storage operations through natural language.
Updated 3 months ago (2026-06-04 01:30 UTC)
MIT
research-assistant-mcp
RAG Systems Research & Data Vector Databases
laxmimerit
A
license
A
quality
D
maintenance
An MCP server that enables saving, retrieving, and managing research content using ChromaDB vector storage and semantic search.
Updated 9 months ago (2025-12-10 12:20 UTC)
5
MIT
Research Citations MCP Server
RAG Systems Search Research & Data
SebastianBoehler
F
license
Not graded
quality
D
maintenance
An MCP server for searching and citing research papers using RAG, enabling semantic search, citation finding, and question answering over a collection of PDF papers.
Updated 10 months ago (2025-11-17 17:20 UTC)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/sobamchan/gengomcp'

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

gengomcp

Quick start

Wiring it into an MCP client

Configuring credentials via the MCP client

Poolside (pool)

Tools

search_papers parameters

Example tool calls

How it works

The embedding model

Project layout

Development / testing

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

Poolside (`pool`)

`search_papers` parameters