Serves a read-only snapshot of a Langflow installation as a knowledge base: look up Langflow components with their exact fields, types, accepted values and defaults; find which components declare a given field name or type; list components by category; and semantically search the docs.langflow.org documentation by meaning. Every answer reports the Langflow/docs version and snapshot date it came from.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@langflow-kb what fields does ext:openai:OpenAIModelComponent@official have?"
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.
A read-only snapshot of a Langflow installation, served as an MCP server so an agent can look up components and fields exactly and search the documentation by meaning instead of answering from memory.
Half | What it contains | Source |
Component catalog | every component with its fields, types, accepted values and defaults — advanced fields included |
|
Documentation index |
| docs 1.11.0, crawled 2026-08-01T16:29:22+00:00 |
Nothing here talks to a Langflow instance or to docs.langflow.org: the data ships inside the package. The only outbound call is the OpenAI embeddings API, made once per semantic search to embed the query.
This repository is generated by a script from a private source repository (commit cc5172c) and is never edited by hand. Each release is a commit plus a tag vX.Y.Z; this one is 0.2.0.
uv on your PATH. It builds and runs the server; nothing else to install.
OPENAI_API_KEY in the environment of the MCP client, only if you want langflow_kb_search_docs. The four catalog tools work without it, and the search tool tells you what is missing instead of failing silently.
Related MCP server: Marcus Local MCP Server
Registers the MCP server and the skill that teaches Claude when to query it:
/plugin marketplace add mavha/langflow-kb-dist
/plugin install langflow-kb@langflow-kb-distOr from the shell: claude plugin marketplace add mavha/langflow-kb-dist && claude plugin install langflow-kb@langflow-kb-dist.
Check with /mcp (server langflow-kb connected) and call langflow_kb_status. The server runs from the plugin's installed copy. The first start builds the package and fetches its dependencies (about 10 s, measured); after that uv serves it from cache and it starts in about a second, with no network.
To update: /plugin update langflow-kb@langflow-kb-dist after a new tag is published.
Run the server straight from this repository, pinned to a release tag:
uvx --from git+https://github.com/mavha/langflow-kb-dist@v0.2.0 kb-mcpClaude Code without the plugin (no skill, tools only):
claude mcp add --scope user langflow-kb -- uvx --from git+https://github.com/mavha/langflow-kb-dist@v0.2.0 kb-mcpClaude Desktop (claude_desktop_config.json), Cursor (.cursor/mcp.json) and most other clients take the same shape:
{
"mcpServers": {
"langflow-kb": {
"command": "uvx",
"args": ["--from", "git+https://github.com/mavha/langflow-kb-dist@v0.2.0", "kb-mcp"],
"env": { "OPENAI_API_KEY": "sk-..." }
}
}
}The first start clones, builds and fetches dependencies (about 10 s); afterwards uv serves it from cache. To update, change the tag.
Tool | Use it when | Needs |
| you know the component name and want all its fields, defaults and accepted values | — |
| you know a field name or a field type and want to know which components declare it | — |
| you want to know what exists, optionally by category | — |
| the question is conceptual and no exact name is at stake (ask in English) |
|
| something does not answer as expected: reports what is loaded, from which version and when | — |
Every tool accepts response_format="json" for machine-readable output. Every answer ends with its provenance (version and date): read it, because the data is a snapshot.
Matching in the catalog tools is exact. Since Langflow 1.11.1 most bundle components are named ext:<bundle>:<Class>@official (for example ext:openai:OpenAIModelComponent@official, not OpenAIModel); if an exact name finds nothing, list by category before concluding it does not exist. The bundled skill covers these edge cases.
It is a snapshot. Catalog and docs are frozen at the versions above. A newer Langflow may add, rename or remove components; langflow_kb_status tells you what you have.
Not re-indexable from here. The kb CLI ships with the package, but kb index, kb crawl and kb embed are not supported in this distribution: they would write into the installed package. Re-indexing happens in the source repository, and the result is published as a new release.
The documentation corpus is in English; queries in English retrieve measurably better.
Langflow 1.11.1, catalog indexed 2026-08-01T18:22:39+00:00
docs 1.11.0, crawled 2026-08-01T16:29:22+00:00
generated from source commit cc5172c, release 0.2.0
Devuelve todos los campos de un componente de Langflow: tipo, opciones, valor por defecto y cuales estan ocultos tras el modo avanzado.
Busqueda por nombre exacto sobre la instancia indexada.
| Name | Required | Description | Default |
|---|---|---|---|
| nombre | Yes | Nombre exacto del componente, por ejemplo File | |
| response_format | No | markdown |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, closed-world behavior, so the safety profile is covered. The description adds value beyond them by disclosing the return content, including that advanced-mode hidden fields are surfaced, which is useful for callers deciding whether to follow up with search_fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with no filler; the return-content summary is front-loaded and the lookup constraint follows. It is terse but every line contributes.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only, two-parameter tool with no output schema, the description covers purpose, lookup mode, and the shape of the returned data. It stops short of explaining the response_format option or error behavior on a non-matching name, minor gaps given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50%: 'nombre' is documented in the schema and the description reinforces it with the exact-match constraint, but 'response_format' has no description in either schema or description. The enum values are self-explanatory, so the description neither compensates fully nor adds much beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource in Spanish ('Devuelve todos los campos de un componente de Langflow') and enumerates what is returned (tipo, opciones, valor por defecto, campos ocultos en modo avanzado). It distinguishes itself from search/list siblings only implicitly via the exact-name lookup line, so it falls short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Búsqueda por nombre exacto sobre la instancia indexada' implies the condition for use (exact-name lookup against indexed components), which contrasts with the fuzzy search siblings, but no alternative tool is named and no when-not guidance is given. Usage is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lista los componentes disponibles en la instancia indexada, con su categoria. Acepta filtro por categoria.
| Name | Required | Description | Default |
|---|---|---|---|
| limite | No | Maximo de componentes a devolver | |
| categoria | No | Acota a una categoria, por ejemplo files_and_knowledge | |
| response_format | No | markdown |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and a closed world, so the safety profile is covered. The description adds only that the source is an "instancia indexada" (indexed instance) — useful snapshot semantics, but nothing about pagination, result size behavior, or what happens beyond the limit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two compact sentences with the core purpose front-loaded and the filter capability second; no filler. It is arguably terse given the tool's three parameters, but nothing is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only list tool with good annotations this is close to adequate, but there is no output schema and the description does not explain the maximum/default of "limite" semantics or the undocumented "response_format" parameter. An agent can call it, but with avoidable ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 67%: "limite" and "categoria" are documented in the schema, while "response_format" is not documented anywhere. The description restates the category filter but adds no meaning beyond the schema's own example ("files_and_knowledge"), so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource ("Lista los componentes disponibles en la instancia indexada") plus a scope modifier (with their category). This clearly separates it from siblings like describe_component or search_docs, though it never names those alternatives explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
"Acepta filtro por categoria" implies the filtering use case, but there is no statement of when to prefer this tool over langflow_kb_describe_component or langflow_kb_search_fields, and no prerequisites or exclusions are given. Usage is inferable but not directed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Busca por significado en la documentacion de Langflow y devuelve los pasajes mas cercanos, cada uno con la URL que abre su seccion exacta.
Para preguntas conceptuales. La documentacion esta en ingles. Cada resultado trae su cercania: valores bajos significan que no hay nada realmente parecido en el corpus.
| Name | Required | Description | Default |
|---|---|---|---|
| limite | No | Maximo de pasajes | |
| consulta_texto | Yes | Pregunta en lenguaje natural. El corpus esta en ingles: preguntar en ingles recupera bastante mejor. | |
| response_format | No | markdown |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the safe, idempotent read profile, so the description earns credit for adding non-obvious context: the corpus is English-only and result proximity scores must be interpreted (low values mean no real match). This output-semantics detail is genuinely useful and not derivable from annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tight sentences, front-loaded with the action and the return shape, followed by the query-language caveat and the score-interpretation rule. No filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description carries the burden of explaining returns, and it does so reasonably: passages plus clickable section URLs plus proximity scores with a rough interpretation rule. Only the ordinal meaning of the distance values and pagination/limit behavior remain underspecified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 67% and the schema already documents 'consulta_texto' and 'limite', including the English-language advice the description partly repeats. The description adds no syntax or format guidance for 'limite' or the undocumented 'response_format' enum, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Busca por significado en la documentacion de Langflow') plus what it returns ('pasajes mas cercanos, cada uno con la URL que abre su seccion exacta'). The 'preguntas conceptuales' framing implicitly separates it from the structured-search sibling langflow_kb_search_fields.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives one usage cue ('Para preguntas conceptuales') but never names the alternative tool (search_fields for structured lookups) or states when-not-to-use, leaving the agent to infer the boundary between the two search tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Busca en todo el catalogo que componentes declaran un campo con cierto nombre, o que campos existen de cierto tipo.
Coincidencia exacta: buscar 'ocr' no encuentra 'ocr_engine'. Pasa nombre o tipo, no ambos.
| Name | Required | Description | Default |
|---|---|---|---|
| tipo | No | Tipo exacto del campo, por ejemplo file | |
| nombre | No | Nombre exacto del campo, por ejemplo ocr_engine | |
| response_format | No | markdown |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, closed-world behavior, so the safety profile is covered. The description adds a non-obvious behavioral trait: matching is exact, demonstrated by the 'ocr' vs 'ocr_engine' example, which is exactly the kind of search-semantics detail annotations cannot express.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short paragraphs, purpose front-loaded, followed by the one non-obvious matching rule. No filler; the example is the only slightly padded element but it earns its place by clarifying exact matching.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, and the description never indicates what a result contains (component names? field lists?) or in what shape, despite mentioning a response_format parameter in the schema. The input side is well covered, but the return-value side is left entirely to inference.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 67% and the schema already documents tipo and nombre with examples. The description adds meaning beyond that: the mutual exclusion rule ('pasa nombre o tipo, no ambos') and the exact-match semantics that govern how values must be supplied.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: searching the whole catalog for components that declare a field with a given name, or for fields of a given type. This is far more specific than the sibling langflow_kb_list_components, though it never names a sibling to differentiate explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description conveys the use condition (look up fields by exact name or by type) and a constraint that name and type are passed one at a time, not both. It stops short of saying when to prefer this over langflow_kb_describe_component or langflow_kb_search_docs, so the agent must infer the routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Informa que artefactos de la knowledge base estan construidos, de que version provienen y cuando se generaron.
El servidor es de solo lectura: no reconstruye nada, solo avisa si hace falta.
| Name | Required | Description | Default |
|---|---|---|---|
| response_format | No | markdown |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, non-destructive, closed-world. The description adds genuinely new behavioral context: the server does not rebuild anything, it only reports. That 'no side effects even when triggered' nuance goes beyond the annotation set.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the purpose, and the read-only caveat is placed efficiently. No wasted text, though the second sentence is more reassurance than specification.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, and the description compensates by naming what is reported (build state, version, generation time). That is adequate for a simple status tool; only the response_format parameter is left unexplained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There is one parameter (response_format, enum markdown/json) with 0% schema description coverage, and the description says nothing about it. The enum values are self-explanatory, but the description does not compensate for the missing documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource: it reports that knowledge-base artifacts are built, which version they come from, and when they were generated. That is distinguishable from the search/list/describe siblings, though it never names them explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It implies the usage context ('avisa si hace falta' / warns if something is needed) and clarifies this is the tool to consult for state rather than to rebuild. But it gives no explicit when-to-use rule or comparison against the sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.2.0langflow_kb_describe_componentlangflow_kb_list_componentslangflow_kb_search_docslangflow_kb_search_fieldslangflow_kb_statusScored across 5 tools
Each tool targets a distinct operation: listing components by category, semantic doc search, exact component description, exact field-catalog search, and KB status. search_docs (meaning-based, docs) vs search_fields (exact match, catalog) are clearly differentiated by description, and list_components vs describe_component differ by scope.
All tools share the langflow_kb_ prefix and mostly follow snake_case verb_noun (list_components, search_docs, describe_component, search_fields). The lone noun-only 'status' is a minor deviation but still readable and predictable.
Five focused tools are well-scoped for a read-only knowledge-base server, each earning its place with no redundancy. This is squarely in the ideal 3-15 range.
The surface covers listing, semantic doc search, exact component/field lookup, and artifact status, providing coherent lifecycle coverage for a read-only KB. Minor gap: no direct tool to fetch a complete doc page beyond ranked passages, but URLs are returned to work around it.
Versioned documentation registry and semantic search for AI tools and coding assistants.
Ingest, manage, and retrieve documents for RAG-powered AI applications
Ingest and search LogsLoom logs from coding agents.
Cloud or self-hosted knowledge for AI agents: hybrid search, reranking, GraphRAG, scoped MCP tools.
