Skip to main content
Glama
blueqwertz

linda-mcp

by blueqwertz
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Linde MCP Server

Ein MCP (Model Context Protocol) Server, der KI-Modellen Zugriff auf linda.lindeverlag.at (Linde Datenbank) gibt. Suche, Dokument-Volltext, Ausgaben-Inhaltsverzeichnisse, Kommentare und See-Also-Verweise über stdio.

Wichtig: Linda nutzt IP-basierten Zugriff (z.B. WU-Wien-Netz, VPN). Es ist kein Login erforderlich — der MCP-Server muss einfach vom WU-Netz aus erreichbar sein.

Features

  • Suche: Volltextsuche über linda.lindeverlag.at/SearchResults/ mit Paginierung, Sortierung (Relevanz/Datum) und Filter (My/All, Archiv).

  • Autocomplete: Vorschläge über search/autocompletesuggestions.

  • Dokument-Volltext: Titel, Autor, Literaturquelle, Rechtsnorm-Verweise, Literaturverzeichnis und Volltext.

  • Ausgabe (Magazin): Inhaltsverzeichnis gruppiert nach Sektionen.

  • Kommentare: Liste der verfügbaren Kommentare (My/All).

  • See-Also: Verwandte Rechtsnormen, Literatur und Judikatur.

  • Auth-Status & Cookie-Set: Optional — für hinter Paywall liegende Inhalte können manuell Cookies gesetzt werden.

Related MCP server: German Legal MCP Server

Konfiguration & Zugang

Linda ist über IP autorisiert (z.B. WU-Wien-Campus-Netz, eduroam, oder VPN zum WU-Netz). Keine Credentials nötig.

Optionale Cookie-Authentifizierung (für Premium-Inhalte):

  • Environment Variable: LINDA_COOKIE="DbSessionVWINASP02=...; bis_logonguid=..."

  • Command Line Flag: --cookie "DbSessionVWINASP02=...; bis_logonguid=..."

Cookie-Werte aus dem Browser: DevTools → Application → Cookies → linda.lindeverlag.at und .lindeverlag.at.

Installation & Running

Direkt via npx (empfohlen)

npx -y github:blueqwertz/linda-mcp

Mit Cookie:

LINDA_COOKIE="DbSessionVWINASP02=...; bis_logonguid=..." npx -y github:blueqwertz/linda-mcp

Lokale Entwicklung

git clone https://github.com/blueqwertz/linda-mcp.git
cd linda-mcp
npm install
npm run build     # TypeScript -> dist/
npm start         # Startet den MCP-Server

Im Dev-Modus mit Hot-Reload:

npm run dev       # tsx src/index.ts

Smoke-Test (6 Tests gegen die Live-Site, benötigt IP-Zugriff auf linda.lindeverlag.at):

npx tsx test.ts

Integration mit AI-Agents

Claude Desktop

~/Library/Application Support/Claude/claude_desktop_config.json:

{
  "mcpServers": {
    "linda-mcp": {
      "command": "npx",
      "args": ["-y", "github:blueqwertz/linda-mcp"]
    }
  }
}

Mit Cookie:

{
  "mcpServers": {
    "linda-mcp": {
      "command": "npx",
      "args": ["-y", "github:blueqwertz/linda-mcp"],
      "env": {
        "LINDA_COOKIE": "DbSessionVWINASP02=...; bis_logonguid=..."
      }
    }
  }
}

Claude Code

claude mcp add linda-mcp -- npx -y github:blueqwertz/linda-mcp

OpenCode

opencode.json/opencode.jsonc:

{
  "mcp": {
    "linda-mcp": {
      "type": "local",
      "command": ["npx", "-y", "github:blueqwertz/linda-mcp"],
      "enabled": true
    }
  }
}

Codex

~/.codex/config.toml:

[mcp_servers.linda-mcp]
command = "npx"
args = ["-y", "github:blueqwertz/linda-mcp"]

Exposed Tools

linda_search

Durchsucht die Linde Datenbank.

  • Arguments:

    • query (string, required): Suchbegriff.

    • skip (number, default 0): Offset für Paginierung (0, 20, 40, ...).

    • limit (number, default 20, max 20): Max Treffer.

    • sort ("Rank" | "Date", default "Rank").

    • place ("My" | "All", default "My").

    • includingArchive (bool, default false).

  • Returns: {query, skip, nextSkip, results: [{id, titel, beschreibung, vorschau, link, listPos}], totalCount?, hasMore}

linda_autocomplete

  • Arguments: query (string, required).

  • Returns: {query, count, suggestions: [{text, isLastSearch}]}

linda_get_document

  • Arguments:

    • id (string, required): Dokument-ID ("18729") oder URL.

    • includeVolltext (bool, default true).

    • maxVolltextLength (number, default 50000).

  • Returns: {id, titel, autor?, literaturQuelle?, rechtsnormVerweise: [{id,label,link}], literatur: string[], volltext?, meta, link}

linda_get_issue

  • Arguments: id (string, required): Ausgabe-ID ("WWK77SH6EQ") oder URL.

  • Returns: {id, titel, jahr?, ausgabeNr?, sectionCount, articleCount, sektionen: [{name, dokumente: [{id,titel,beschreibung?,link}]}]}

linda_get_see_also

  • Arguments: id (string, required).

  • Returns: {id, summary, rechtsnormen: [...], literatur: [...], judikatur: [...], sonstiges: [...]}

linda_list_kommentare

  • Arguments: place ("My" | "All", default "My").

  • Returns: {place, count, kommentare: [{bookId, titel, link}]}

linda_auth_status

  • Arguments: keine.

  • Returns: {authenticated, statusCode, url, cookiesSet, note}

linda_set_cookie

  • Arguments: cookie (string, required): "name1=val1; name2=val2; ...".

  • Returns: {cookieSet, cookiesStored, note}

Architektur

src/
├── index.ts          # CLI-Parsing, McpServer, stdio transport
├── client.ts         # LindaClient: HTTP + CookieJar wrapper
├── auth.ts           # CookieJar (in-memory name->value)
├── parser.ts         # cheerio-basierte HTML-Extraktoren
└── tools/
    ├── index.ts      # toolDefinitions + handleToolCall dispatch
    ├── search.ts     # linda_search
    ├── autocomplete.ts
    ├── document.ts
    ├── issue.ts
    ├── see_also.ts
    ├── kommentare.ts
    └── auth.ts       # linda_auth_status + linda_set_cookie

Inspiriert von blueqwertz/rdb-mcp (Manz RDB), aber angepasst an Lindes HTML-basierte API.

License

MIT

Available Tools

8 tools
linda_auth_statusA

Prüft ob linda.lindeverlag.at erreichbar ist und ob Cookies gesetzt sind. Linda nutzt IP-basierten Zugriff (z.B. WU-Netz) — kein Login nötig. Optional: manuell Cookies via linda_set_cookie setzen.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A4.7/5.0
Behavior4/5

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

No annotations provided, but the description adequately discloses that the tool is a read-only status check, mentions network access requirements, and does not hint at any destructive behavior. Could be slightly improved by noting idempotency.

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?

Two concise sentences, front-loaded with the primary action, no filler. Every sentence adds 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?

Given zero parameters and no output schema, the description is complete. It also provides context about IP-based access and the sibling tool for cookie setting, covering all necessary information for an agent to invoke it 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?

No parameters exist, which matches the baseline of 4. The description adds meaning beyond the empty schema by explaining what the tool checks without needing input.

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 'prüft' (checks) and the resource: reachability of linda.lindeverlag.at and cookie status. It distinguishes from siblings by mentioning the optional use of linda_set_cookie for manual cookie setting.

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?

Explicitly states when to use (to check status) and suggests an alternative action (manually set cookies via linda_set_cookie). Also clarifies IP-based access and no login required.

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

linda_autocompleteA

Liefert Autocomplete-Vorschläge für die Linda-Suche. Hilfreich um die exakte Schreibweise eines Begriffs vor der Volltextsuche zu prüfen.

ParametersJSON Schema
NameRequiredDescriptionDefault
queryYesSuchtext für Vorschläge (z.B. 'Ges', 'ABGB', 'Kalss').

TDQS

A4/5.0
Behavior3/5

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

With no annotations provided, the description carries the burden of disclosing behavior. It implies a read-only operation by providing suggestions, but it does not explicitly state that no data is modified or that it is safe. The description is adequate but could be more explicit about behavioral traits.

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 concise sentences with no wasted words. It is front-loaded with the core purpose and provides a practical use case.

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?

Given the tool's simplicity (one parameter, no output schema, no annotations), the description is fairly complete. It explains the tool's function and intended use, though it does not describe the return format or any limitations.

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 coverage is 100% with a descriptive parameter description. The tool description does not add additional meaning beyond the schema, so the baseline score of 3 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 clearly states the tool provides autocomplete suggestions for Linda search and helps verify spelling before full-text search. It uses a specific verb ('liefert') and resource ('Autocomplete-Vorschläge'), and the purpose distinguishes it from sibling tools like linda_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 gives context for when to use the tool (before full-text search to check spelling) but does not explicitly mention when not to use it or provide direct alternatives. The guidance is clear but lacks explicit exclusions.

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

linda_get_documentA

Ruft ein Dokument anhand seiner ID ab: Titel, Autor, Literatur-Quelle, Verweise auf Rechtsnormen, Literaturverzeichnis und Volltext. ID = numerische Dokument-ID (z.B. '18729') oder URL.

ParametersJSON Schema
NameRequiredDescriptionDefault
idYesDokument-ID (z.B. '18729') oder vollständige URL (z.B. 'https://linda.lindeverlag.at/Dokument/18729/').
includeVolltextNoVolltext des Dokuments zurückgeben (default true).
maxVolltextLengthNoMax. Zeichen für den Volltext (default 50000).

TDQS

A3.7/5.0
Behavior3/5

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

No annotations are provided, so the description carries the burden. It mentions that IDs can be numeric or URLs and includes parameters for full text length, but does not disclose safety, idempotency, or permission requirements. Basic read operation behavior is implied.

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 one sentence, front-loaded with the core action, and lists deliverables efficiently. Minor redundancy but overall concise.

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?

Given no output schema, the description lists the returned fields (title, author, source, etc.) and mentions defaults for full text. It covers the essentials for invoking the tool correctly.

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 100%, so baseline is 3. The description adds context about what the document contains and that ID can be numeric or URL, but does not add significantly more meaning beyond the schema.

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 'Ruft ein Dokument anhand seiner ID ab' (retrieves a document by ID) and lists exact contents (title, author, source, references, full text). It distinguishes from siblings like linda_search (search) and linda_get_issue (issue).

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

Usage Guidelines3/5

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

Usage is implied for when you have a document ID or URL, but no explicit guidance on when not to use it or alternatives. No exclusion criteria are mentioned.

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

linda_get_issueA

Liefert das Inhaltsverzeichnis einer Zeitschrift-Ausgabe (Magazin) gruppiert nach Sektionen (z.B. 'Editorial', 'Fachbeiträge'). ID = Ausgabe-ID (z.B. 'WWK77SH6EQ').

ParametersJSON Schema
NameRequiredDescriptionDefault
idYesAusgabe-ID (z.B. 'WWK77SH6EQ') oder vollständige URL (z.B. 'https://linda.lindeverlag.at/Ausgaben/WWK77SH6EQ/').

TDQS

A3.5/5.0
Behavior2/5

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

No annotations are provided, and the description does not disclose any behavioral traits such as authentication requirements, rate limits, or side effects. The description only states what the tool returns, leaving the agent uninformed about safety or permissions.

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 concise with only two sentences, front-loading the core purpose and grouping detail. Every word adds value without redundancy.

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

Completeness3/5

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

Given the tool's simplicity (one parameter, no output schema), the description is adequate but could be more complete by hinting at the output structure or error behavior. It lacks details on return format or potential issues like invalid IDs.

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 100% for the single parameter 'id', and the description adds a brief explanation and example in German, but does not add significant meaning beyond the schema. The schema already specifies the parameter format and example, so the description offers minimal extra value.

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 'Liefert' (delivers) and the resource 'Inhaltsverzeichnis' (table of contents) of a magazine issue. It distinguishes from siblings like linda_get_document and linda_get_see_also by specifying the specific use case of retrieving the issue table of contents grouped by sections.

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

Usage Guidelines3/5

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

The description implies usage for retrieving a magazine issue's table of contents but provides no explicit guidance on when to use this tool versus alternatives like linda_search or linda_get_document. No exclusions or alternative tool names are mentioned.

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

linda_get_see_alsoA

Liefert verwandte Inhalte zu einem Dokument: passende Rechtsnormen, Literaturhinweise und Judikatur-Verweise.

ParametersJSON Schema
NameRequiredDescriptionDefault
idYesDokument-ID (z.B. '18932') oder vollständige URL. Liefert verwandte Rechtsnormen, Literatur und Judikatur.

TDQS

A3.8/5.0
Behavior3/5

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

No annotations are provided, so the description carries the full burden. It states the tool 'delivers related content' but does not disclose any behavioral traits (e.g., read-only, side effects, required permissions). The name 'get' suggests idempotency, but this is not explicit.

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 a single sentence that front-loads the main purpose. No redundant or unnecessary words; every word adds value.

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?

Given the tool's simplicity (one parameter, no output schema), the description and schema together provide a clear picture of what the tool does. However, additional context about the output format or related content types would improve completeness.

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 coverage is 100%, and the schema description for 'id' largely repeats the tool description. The description adds no additional meaning beyond what the schema already provides, so a baseline score of 3 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 clearly states that the tool delivers related content (legal norms, literature references, case law) for a given document. It uses a specific verb 'Liefert' and resource 'verwandte Inhalte', distinguishing it from siblings like linda_get_document (returns the document itself) and linda_search (general search).

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

Usage Guidelines3/5

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

The description implies usage for retrieving related content, but it does not explicitly state when to use this tool over alternatives like linda_search or linda_get_document. No usage context or exclusions are provided.

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

linda_list_kommentareA

Listet die verfügbaren Kommentare in der Linde Datenbank auf. Mit place='All' werden alle 141 Kommentare geladen, mit 'My' nur die eigenen (~113).

ParametersJSON Schema
NameRequiredDescriptionDefault
placeNoSichtbereich: 'My' (meine Kommentare) oder 'All' (alle).My

TDQS

A4.2/5.0
Behavior3/5

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

No annotations provided, so description must carry behavioral burden. Adds counts and filtering behavior but does not mention read-only nature, permissions, or side effects. Adequate but minimal.

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?

Two succinct sentences: first for purpose, second for parameter details. No redundancy, highly efficient.

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?

For a simple list tool with one parameter, description covers core functionality. Lacks pagination info but counts imply all results are returned. Reasonably complete.

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 coverage is 100%, baseline 3. Description adds value by providing specific comment counts (141 vs ~113), going beyond the schema's enum description.

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?

Clearly states it lists comments in the Linde database, differentiating between all and own comments. Verb 'listet' and noun 'Kommentare' make purpose specific. Siblings are distinct tools for search, document retrieval, etc.

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?

Explicitly explains when to use 'All' vs 'My' with count details. Doesn't discuss when not to use or alternatives, but the name and context make usage obvious.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 8 tool updatesv0.1.0
    • First observedlinda_auth_status
    • First observedlinda_autocomplete
    • First observedlinda_get_document
    • First observedlinda_get_issue
    • First observedlinda_get_see_also
    • First observedlinda_list_kommentare
    • First observedlinda_search
    • First observedlinda_set_cookie
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4.1/5.0

Scored across 8 tools

Disambiguation5/5

Each tool has a clear, distinct purpose: authentication check, autocomplete, document retrieval, issue table of contents, related content, commentary listing, search, and cookie setting. No two tools overlap in functionality.

Naming Consistency5/5

All tools follow a consistent pattern: 'linda_' prefix + verb_noun (e.g., get_document, list_kommentare, set_cookie). Naming is uniform, descriptive, and uses snake_case throughout.

Tool Count5/5

With 8 tools, the server is well-scoped for a legal database retrieval system. It covers essential operations without being too sparse or bloated.

Completeness4/5

The tool set covers key workflows: authentication, search, document retrieval, issue browsing, related content, and commentary lists. A minor gap is the absence of a dedicated tool to fetch a single commentary item, but the surface is largely complete for typical usage.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • Online Kommentar MCP Server

    self-tech-labs
    F
    license
    B
    quality
    D
    maintenance
    Provides access to Swiss legal commentaries through Model Context Protocol, allowing users to search and retrieve detailed legal commentary content from onlinekommentar.ch in multiple languages.
    2
    4
    -

  • German Legal MCP Server

    metaneutrons
    A
    license
    A
    quality
    C
    maintenance
    Provides unified access to German federal and state legislation, court decisions, and European Union legal databases for comprehensive legal research. It enables users to search and retrieve full-text laws, parliamentary documents, and judicial rulings directly through the Model Context Protocol.
    20
    244 npm
    GPL 3.0