LegalQuants MCP
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| LQ_DATA_DIR | No | Set to an absolute directory to override where this server locates its data. | |
| GITHUB_TOKEN | No | Optional environment variable that increases GitHub API availability. It is sent only to api.github.com. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| search_buildsA | Find projects by keyword. Returns build IDs, listing details, match terms and catalog coverage. Use for discovery; source contents require separate tools. |
| get_buildA | Inspect one build: listing, builder, source links, indexing status and available file paths, revisions and line counts. Use a build ID returned by search. |
| search_build_contentB | 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. |
| fetch_contentA | 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. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 4 tools
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.
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.
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.
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.