Which integrations are available for this server?

Indexes public GitHub repositories and retrieves exact source excerpts from them, using repository links, commit-pinned snapshots, and optional GitHub API access to support search and citation of LegalQuants community builds.

How do I use LegalQuants MCP?

1. Click on "Deploy 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., "@LegalQuants MCP Search LegalQuants for clause bank builds and cite the Manus clause schema source" 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.

LegalQuants MCP

by onurkafk

Overview Schema Source Related Servers Discussions Admin

TypeScript

Local

LegalQuants MCP

A working local MCP pilot for finding LegalQuants community builds and retrieving specific source excerpts to help adapt them. Unofficial prototype; not affiliated with or endorsed by LegalQuants. No community application code is executed.

Quick start

Requires Node.js 22+ and npm. No AI provider key is required.

npm ci
npm run build
npm test

The checked-in catalog has 310 of 310 public builds, synced on September 12, 2026; 140 have GitHub repository links. Search works immediately. Source retrieval requires indexing; source snapshots are local and excluded from Git.

Index a real example (Manus Clause Bank):

npm run index -- 43eff50f-cbd8-4e38-80cf-f1f67feab8da

Then start with npm start, or connect through an MCP client below. A stdio server waits for protocol messages; it is not an interactive terminal prompt.

Related MCP server: mentu-navigator-mcp

Connect your AI client

Merge this into a client that supports mcpServers and stdio. Replace the path with your absolute checkout path. Use an absolute Node executable if your desktop client does not inherit your shell's PATH.

{
  "mcpServers": {
    "legalquants": {
      "command": "node",
      "args": ["/absolute/path/to/lq/dist/src/server.js"]
    }
  }
}

This server locates its data relative to its installation, independent of the client's working directory. Set LQ_DATA_DIR to an absolute directory to override.

Try:

I want to build a clause bank. Search LegalQuants for relevant projects, inspect Manus Clause Bank, and retrieve its clause schema and extraction code. Cite the exact source files and tell me what is unavailable or only claimed in the listing.

Tools

Tool	Inputs	Returns
`search_builds`	`query`, optional `area`, `source_only`, `limit`	Ranked builds, matching keywords, catalog coverage
`get_build`	`build_id`	Listing, builder, source links, indexing status, indexed file inventory
`search_build_content`	`build_ids` (1–5), `query`, optional `limit`	Ranked source windows with revision, line numbers and GitHub citations
`fetch_content`	`build_id`, `path`, `revision`, `start_line`, `end_line`	Exact excerpt at the requested indexed revision

All tools are local and read-only. Network access occurs only in the explicit index command. Unknown IDs/files are errors; missing indexes are disclosed rather than invented. Source text is untrusted reference data, not agent instructions.

The server guides the AI to start with three keyword matches, inspect promising builds, and search their source only when needed. It requests additional lines only when existing excerpts are insufficient, then stops with concise cited evidence. This guidance does not require calling all four tools for every question.

Refresh data

# Import the bundled snapshot, or pass a compatible Markdown export path.
# This replaces the full catalog with the partial 30-entry export.
npm run import
npm run import -- /absolute/path/to/new-export.md

# Sync the complete public directory, validating every ID against its search index.
npm run sync

# Index selected catalog build IDs, or all entries with GitHub links.
npm run index -- 43eff50f-cbd8-4e38-80cf-f1f67feab8da
npm run index -- --all

An optional GITHUB_TOKEN environment variable increases API availability. It is sent only to api.github.com. The current raw-file downloader supports public source; private repository support is not implemented. Never put tokens in committed files. Run one import/index writer at a time, with the server stopped during catalog import. Content indexing atomically replaces the snapshot after each project; restart is unnecessary. API failures retain any previous snapshot and record failure status.

Catalog sync reads the public page and discovers its current loadMoreWorks action from the published browser bundle. It retrieves the same pages as “Older entries,” decodes data without executing JavaScript, and checks exact unique-ID coverage before atomic replacement. This is an undocumented website integration: site changes can break it. An owner-provided feed remains preferable for long-term maintenance.

The index follows each repository's default branch and pins its commit SHA. Links to subdirectories are currently normalized to the repository; branch/subdirectory restrictions are not preserved. Text/source allowlisting excludes common generated, upload and secret paths. Per repository: at most 100 files, 100 KB per file and 2 MB total. Truncated trees, budgets and file failures produce partial status. These filters are not a secret scanner; only index sources suitable for your users.

Retrieval behavior and limits

Weighted keyword matching; no embeddings, semantic reranker or LLM calls.
Source search returns overlapping 40-line windows, not AST-resolved functions.
Search returns at most five excerpts; exact fetch returns at most 120 lines and 16,000 characters. Returned line boundaries describe the actual excerpt.
Catalog descriptions remain publisher claims. Repository licenses and README maturity statements can be retrieved, but are not automatically adjudicated.
Relative dates from the export are not converted into invented publication dates.
No remote HTTP hosting, accounts, billing, automatic sync or app execution yet.

Development

npm run check
npm run build
npm test

Tests cover import completeness, six representative top-three retrieval cases, source scoping, line bounds, URL normalization, and all four tools through a real stdio SDK client using an isolated source fixture. These are smoke evaluations, not evidence of broad semantic search quality. GitHub Actions runs build and tests.

src/catalog.ts handles normalization and discovery, src/content.ts handles source excerpts, scripts/index.ts builds GitHub snapshots, and src/server.ts exposes the MCP interface. The approved scope is recorded in docs/design.md.

Before a hosted owner pilot, replace the public-page sync with an owner-provided feed, obtain contributor source/reuse metadata, add authenticated remote transport, and evaluate retrieval with real lawyer tasks.

Catalog attribution: LegalQuants Community Builds. Original project authors and source links are preserved in every catalog record.

Available Tools

4 tools

fetch_contentA

Read-onlyIdempotent

Read a specific indexed file range. Use path and revision from get_build or search_build_content. Lines are 1-based and inclusive; request only what is needed, up to 120 lines / 16,000 characters. A changed revision requires a fresh lookup.

ParametersJSON Schema

Name	Required	Description	Default
`path`	Yes
`build_id`	Yes
`end_line`	Yes
`revision`	Yes
`start_line`	Yes

TDQS

A4.6/5.0

Behavior4/5

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

Annotations cover the safety profile (read-only, idempotent, non-destructive). The description adds valuable operational context not in the annotations: the 1-based inclusive indexing, the hard limits (120 lines / 16,000 characters), and the dependency on revision freshness. It doesn't describe return format, but with no output schema and the function being a straightforward read, this is acceptable.

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?

Three sentences, zero waste, and front-loaded with the core action. The usage and limits are presented in a logical sequence.

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 complexity (a retrieval tool with specific indexing rules and limits) and the lack of an output schema, the description provides all necessary context to call it correctly. It covers dependencies, parameter meaning, limits, and indexing semantics.

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 must compensate, and it does. It explains the meaning of 'path' and 'revision' (from other tools), clarifies the 1-based inclusive line indexing, and specifies limits for the requested range. This adds critical semantic meaning not present in the bare schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Read a specific indexed file range'), which is clear. However, it does not explicitly distinguish itself from the sibling 'search_build_content' beyond directing the agent to use path/revision from it.

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 when and how: 'Use path and revision from get_build or search_build_content' and 'request only what is needed.' It also states a conditional dependency: 'A changed revision requires a fresh lookup.' This is strong, actionable guidance.

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

get_buildA

Read-onlyIdempotent

Inspect one build: listing, builder, source links, indexing status and available file paths, revisions and line counts. Use a build ID returned by search.

ParametersJSON Schema

Name	Required	Description	Default
`build_id`	Yes

TDQS

A4.5/5.0

Behavior4/5

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 needs no restating. The description adds value by enumerating the categories of data the inspection returns, which is useful given there is no 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?

Two sentences: the payload is front-loaded, the sourcing instruction trails. No filler or repetition.

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?

With no output schema, the description carries the return-value burden and does so by listing the inspected fields. Annotations cover the safety profile, and the lone parameter's provenance is stated, so an agent has everything needed to call it.

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?

Only one parameter, and the schema already supplies type/format/pattern for it. The description adds provenance semantics ('a build ID returned by search'), telling the agent where a valid value originates — meaningful beyond the raw UUID 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?

States a specific verb ('Inspect one build') and enumerates the resource payload (listing, builder, source links, indexing status, file paths, revisions, line counts). A single-build fetch is clearly distinguished from the sibling search_builds.

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?

'Use a build ID returned by search' tells the agent where the required identifier comes from and implies this tool follows search_builds rather than replacing it. No explicit exclusion of alternatives (e.g., search_build_content), so it falls short of a full when/when-not statement.

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

search_build_contentB

Read-onlyIdempotent

Find source excerpts within selected build IDs. Returns keyword-ranked line windows and commit-pinned citations. Check coverage before interpreting empty results. Reuse sufficient excerpts without fetching them again.

ParametersJSON Schema

Name	Required	Description
`limit`	No
`query`	Yes	Short functional keywords, e.g. clause extraction. Search is lexical, not semantic.
`build_ids`	Yes

TDQS

B3.4/5.0

Behavior3/5

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

Annotations already cover the safety profile (readOnlyHint, idempotentHint, destructiveHint). The description adds useful behavioral notes: keyword-ranked (not semantic) results and the caveat to check coverage before interpreting empty results. It doesn't disclose pagination limits or result-count behaviour, which is a gap for a ranked search tool.

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?

Four short, front-loaded sentences with no filler; purpose and return characteristics come first, operational hints follow. Efficient, though the final 'Reuse sufficient excerpts...' sentence is slightly vague.

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?

For a 3-param search tool with no output schema, the description conveys purpose, result shape, and a key caveat about empty results. However, with only 33% schema coverage and no output schema, more detail on limit behaviour, citation structure, or lexical matching rules would be needed to fully complete the picture.

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 only 33%, so the query parameter's lexical nature is partially documented in the schema ('Search is lexical, not semantic'). The description reinforces lexical ranking but adds no new parameter meaning for build_ids, limit, or the citation format. Baseline 3 given the partial schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a clear verb+resource: 'Find source excerpts within selected build IDs.' The scope ('within selected build IDs') and return ('keyword-ranked line windows and commit-pinned citations') are specific, distinguishing it somewhat from search_builds and fetch_content. No explicit sibling naming, so it stops short of 5.

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?

Provides implied context ('Reuse sufficient excerpts without fetching them again') which hints at when to reuse vs. call fetch_content, but never states when to use this over search_builds or fetch_content explicitly. Guidance is suggestive rather than explicit.

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

search_buildsA

Read-onlyIdempotent

Find projects by keyword. Returns build IDs, listing details, match terms and catalog coverage. Use for discovery; source contents require separate tools.

ParametersJSON Schema

Name	Required	Description
`area`	No	Exact practice-area label from a listing; omit if unknown.
`limit`	No
`query`	Yes	Short functional keywords, e.g. clause extraction. Search is lexical, not semantic.
`source_only`	No	Only builds with GitHub links. Does not guarantee indexed or accessible source.

TDQS

A3.6/5.0

Behavior3/5

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

Annotations already declare this a safe, idempotent, closed-world read, so the safety bar is covered. The description adds useful behavioral context about the return payload, but says nothing about result caps, ranking, or the lexical (non-semantic) matching that the schema mentions only for the query field.

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?

Two tight sentences with the core action front-loaded and no filler. Dense but every clause carries information; the return-shape list could arguably be trimmed since it overlaps with the schema's fields.

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?

With no output schema, the description compensates by naming what comes back, and the usage boundary against content tools is stated. Missing pagination/ranking guidance and clarification of limit behavior, but adequate for a simple search 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 75%, so the schema largely documents query, area, limit and source_only itself. The description adds only the notion of "keyword" searching and does not explain area's exact-label constraint or source_only's non-guarantee beyond what the schema already states.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clear verb+resource ("Find projects by keyword") and it explicitly enumerates the return payload (build IDs, listing details, match terms, catalog coverage). It differentiates itself from the content-oriented siblings by stating source contents require separate tools, though it never contrasts with get_build.

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?

"Use for discovery" gives an affirmative use case, and "source contents require separate tools" supplies an explicit exclusion routing the agent to search_build_content/fetch_content. It stops short of naming get_build or clarifying when a known ID should bypass search.

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.

4 tool updatesv0.1.0Sep 11, 2026
- First observedfetch_content
- First observedget_build
- First observedsearch_build_content
- First observedsearch_builds

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/5.0

Scored 2026-09-11 22:56 across 4 tools

Disambiguation5/5

Each tool targets a clearly distinct operation: search_builds for discovery, get_build for metadata, search_build_content for keyword search within builds, and fetch_content for exact file range retrieval. The boundaries are well-defined, and descriptions explicitly clarify the differences, eliminating confusion.

Naming Consistency4/5

All names use snake_case and follow a verb_noun pattern, which is mostly consistent. Minor deviations include plural 'builds' in search_builds versus singular 'build' in get_build, and the use of 'fetch' for content retrieval while 'get' is used for metadata.

Tool Count5/5

Four tools is well within the ideal 3-15 range and each tool serves a distinct, necessary purpose in the discovery-to-retrieval workflow. There is no redundant or missing tool among them.

Completeness4/5

The surface covers discovery, metadata inspection, content search, and content retrieval, forming a complete read-only pipeline. A minor gap is the lack of a bulk listing or filter-by-owner operation, but agents can work around this using search_builds with appropriate keywords.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

RepoFold
dev.repofold
A cited wiki of your GitHub repo: search, read pages, find symbols and ask, with line citations.
Version Control Documentation Access Search
2
kvasir — verifiable German, Austrian, Swiss & EU lawOAuth
legal.kvasir
Resolve, search and verify legal citations against the official sources, with provenance.
Legal & Compliance Search
2
searchcode A
com.searchcode
Code intelligence for LLMs. Analyze, search, and retrieve code from any public git repository.
Search Code Analysis Version Control
72
gentlyOAuth
is.gently
Ask a codebase what calls what: search, blast radius, paths between symbols, and diffs.
Code Analysis Developer Tools
1

Related MCP Servers

codesearch
Search RAG Systems Vector Databases
shahpnmlab
F
license
Not graded
quality
C
maintenance
Semantic search over local source repositories and forum archives, exposing tools to list sources, search code, read code, and search forum discussions.
Updated a month ago (2026-08-05 11:14 UTC)
-
mentu-navigator-mcpofficial
Search Code Analysis
mentu-ai
A
license
Not graded
quality
C
maintenance
Provides read-only, provenance-first repository navigation for agents and humans, with ranked lexical retrieval, exact query, document handles, symbol context, and change impact analysis.
Updated 23 days ago (2026-08-22 19:44 UTC)
42 npm
Apache 2.0
studyproof
RAG Systems Search Research & Data
Lapmlnex
A
license
Not graded
quality
B
maintenance
Provides read-only search and context-pack creation over a local source library, letting AI assistants retrieve relevant excerpts and audit cited quotations.
Updated 7 days ago (2026-09-07 16:26 UTC)
MIT
assurance-memory
Code Analysis Developer Tools Knowledge & Memory
yshaaban
F
license
Not graded
quality
B
maintenance
Enables coding agents to perform read-only source investigation via a local SQLite index, offering status, search, backlog, context, impact, and drift tools for TypeScript, JavaScript, and Java codebases.
Updated 6 days ago (2026-09-08 21:27 UTC)
-

LegalQuants MCP

Quick start

Connect your AI client

Tools

Refresh data

Retrieval behavior and limits

Development

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

mentu-navigator-mcpofficial