How do I use cpl-mcp?

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., "@cpl-mcp look up CPL 245.20" 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.

cpl-mcp

by njrenaissance

Overview Schema Related Servers Score Discussions

Python

Remote

cpl-mcp

Python Coverage

MCP server for the New York State Criminal Procedure Law (CPL). Wraps the NY Senate OpenLegislation API so any MCP client can look up CPL sections by citation and search the CPL by keyword.

Installation

With uv (recommended):

uvx cpl-mcp

With pip:

pip install cpl-mcp
python -m cpl_mcp.server

Related MCP server: tr-eli-mcp

Auth setup

The server requires a free OpenLegislation API key.

Go to https://legislation.nysenate.gov and click Sign up for an API Key.
Fill in the form — the key is emailed to you within a few minutes.
Set the environment variable before starting the server:

export NYS_LEG_API_KEY="your-key-here"

Or put it in a .env file in the project root — the server loads it automatically:

NYS_LEG_API_KEY=your-key-here

Claude Desktop config

Add the following to claude_desktop_config.json (~/Library/Application Support/Claude/ on macOS, %APPDATA%\Claude\ on Windows):

{
  "mcpServers": {
    "cpl": {
      "command": "uvx",
      "args": ["cpl-mcp"],
      "env": {
        "NYS_LEG_API_KEY": "your-key-here"
      }
    }
  }
}

If you prefer a local checkout instead of uvx:

{
  "mcpServers": {
    "cpl": {
      "command": "uv",
      "args": [
        "--directory", "/absolute/path/to/cpl-mcp",
        "run", "python", "-m", "cpl_mcp.server"
      ],
      "env": {
        "NYS_LEG_API_KEY": "your-key-here"
      }
    }
  }
}

Environment variables

Variable	Required	Description
`NYS_LEG_API_KEY`	Yes	OpenLegislation API key. Get one at https://legislation.nysenate.gov.

Tools

Tool	Description
`cpl_lookup_section`	Retrieve the full text of a CPL section or article by citation (e.g. `245.20`, `A245`).
`cpl_search`	Full-text keyword search across the CPL. Returns a ranked list of matching sections with snippets.

`cpl_lookup_section`

Use when you know the section number. Accepts flexible citation formats — CPL § 245.20, section 245.20, and 245.20 all resolve to the same location. Returns the statute text, active date, structural breadcrumb (article/title parents), and a link to the official nysenate.gov page.

`cpl_search`

Use when searching by topic rather than citation. Supports pagination via limit (1–50, default 10) and offset (1-based, default 1).

Both tools accept a response_format parameter: "markdown" (default, human-readable) or "json" (machine-readable, useful for chaining tools).

Running locally

# one-shot lookup — no MCP client needed
python -m cpl_mcp.server --selftest 245.20

# one-shot lookup + keyword search
python -m cpl_mcp.server --selftest 245.20 --search "speedy trial"

# HTTP transport for debugging (listens on 127.0.0.1:8000)
python -m cpl_mcp.server --http

Available Tools

2 tools

cpl_lookup_sectionA

Read-onlyIdempotent

Retrieve the full text of a single New York Criminal Procedure Law (CPL) location by citation.

Use this when the user names a specific CPL section or article (e.g. "What does CPL 245.20 say?", "pull up CPL section 510.10"). It returns the official statute text plus its title and structural context (article/title parents and adjacent sections). It does NOT search by topic — use cpl_search for that.

Args: params (LookupInput): Validated input containing: - citation (str): A CPL location id such as "245.20", "1.20", "A245", or "T1". Leading "CPL", "section", and "§" are stripped automatically. - response_format (ResponseFormat): "markdown" (default) or "json".

Returns: str: In markdown mode, a formatted document with the section title, citation, full statute text, structural breadcrumb, and a source link. In json mode, an object with this schema: { "lawId": str, # "CPL" "locationId": str, # e.g. "245.20" "docType": str, # e.g. "SECTION", "ARTICLE", "TITLE" "title": str, # human title, e.g. "Automatic discovery" "activeDate": str, # ISO date this version became active "text": str, # full statute text "parents": [ {"docType": str, "docLevelId": str, "title": str} ], "sourceUrl": str # canonical nysenate.gov page }

On failure, a string beginning with "Error:".

Examples: - Use when: "Show me CPL 245.20" -> citation="245.20" - Use when: "What's in article 245 of the CPL?" -> citation="A245" - Don't use when: "Which CPL section covers discovery?" (use cpl_search instead)

ParametersJSON Schema

Name	Required	Description	Default
`params`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.9/5.0

Behavior5/5

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

Annotations already declare read-only, idempotent, and non-destructive behavior. The description adds valuable context beyond this: input normalization ('Leading "CPL", "section", and "§" are stripped automatically'), return format details (markdown vs. json with full object schema), and error behavior ('On failure, a string beginning with "Error:"'). No contradiction with annotations.

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 well-structured with a clear lead sentence, separate Args, Returns, and Examples sections. It is fairly long but every section provides necessary information for correct tool usage; it only slightly duplicates schema details.

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?

The description is fully self-contained: it covers input normalization, output format, return schema, error handling, and differentiation from the sibling tool. Given the tool's moderate complexity and the presence of an output schema, the description leaves no gaps for an AI agent.

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?

Although the schema includes detailed descriptions for both parameters, the description reinforces and clarifies them with concrete examples of valid citations ('245.20', 'A245', 'T1') and the expected response_format values. It also explains the output schema in plain language, which goes beyond the schema's field descriptors.

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 ('Retrieve') and resource ('full text of a single New York Criminal Procedure Law location by citation'), making the tool's exact function clear. It also explicitly distinguishes itself from the sibling tool cpl_search by stating 'It does NOT search by topic — use cpl_search for that.'

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 provides explicit when-to-use guidance ('Use this when the user names a specific CPL section or article'), when-not-to-use ('Don't use when: 'Which CPL section covers discovery?''), and names the alternative tool (cpl_search). It also includes concrete examples of user utterances and corresponding citation values.

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

cpl_searchA

Read-onlyIdempotent

Full-text search the New York Criminal Procedure Law (CPL) for sections matching a term.

Use this when the user describes a topic rather than naming a section (e.g. "Which CPL sections deal with automatic discovery?", "find CPL provisions about speedy trial"). Returns a ranked list of matching locations with their citation and title. Follow up with cpl_lookup_section to get the full text of a hit.

Args: params (SearchInput): Validated input containing: - term (str): Full-text query, e.g. "automatic discovery", "speedy trial". - limit (Optional[int]): Max results, 1-50 (default 10). - offset (Optional[int]): 1-based start index for pagination (default 1). - response_format (ResponseFormat): "markdown" (default) or "json".

Returns: str: In markdown mode, a numbered list of matches (citation + title + snippet). In json mode, an object with this schema: { "term": str, "total": int, # total matches available "count": int, # results in this page "offset": int, # 1-based offset used "has_more": bool, "next_offset": int|null, "results": [ { "locationId": str, # e.g. "245.20" "title": str, # section title "docType": str, # e.g. "SECTION" "snippet": str, # highlighted match context (may be empty) "sourceUrl": str } ] }

On failure, a string beginning with "Error:".

Examples: - Use when: "What CPL sections cover discovery?" -> term="discovery" - Use when: "Find speedy trial rules in the CPL" -> term="speedy trial" - Don't use when: You already know the section number (use cpl_lookup_section).

ParametersJSON Schema

Name	Required	Description	Default
`params`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.7/5.0

Behavior4/5

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

Annotations declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is already clear. The description adds valuable behavioral context: full-text search semantics, pagination (offset 1-based), output format differences (markdown vs json), the 'Error:' prefix on failure, and the suggestion to follow up with cpl_lookup_section. This is more than minimal, though it doesn't discuss rate limits or underlying API details.

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 well-structured with a clear opening sentence, a usage paragraph, a compact Args section that parrots the schema but adds examples and defaults, a Returns section that documents the JSON shape, and a short Examples list. No wasted words; 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?

The tool has only one required parameter (wrapped in SearchInput) and a comprehensive output schema. The description covers the tool's purpose, usage boundaries, parameter nuances, return format details, error behavior, and follow-up action. This is complete for an agent to select and invoke the tool correctly without additional context.

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 input schema is detailed with descriptions for each parameter, but the description adds extra semantic value: it explains the purpose of 'term' with examples ('automatic discovery', 'speedy trial'), clarifies the offset as 1-based, notes default values, and describes the response_format as 'markdown' (default) or 'json'. Since schema coverage is 0% by the context signal (though schema itself has param descriptions), the tool description compensates well by restating and enriching parameter meaning.

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 states a specific verb ('Full-text search') and resource ('New York Criminal Procedure Law (CPL)'), and clearly distinguishes from the sibling tool by noting 'use cpl_lookup_section' when the section number is already known. It also conveys the ranked-list return behavior.

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 says when to use: when the user describes a topic rather than naming a section, with concrete example queries. It also states when not to use: when the section number is known, directing to cpl_lookup_section. This exceeds the 'clear context, no exclusions' threshold.

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. Dates show when Glama detected each change.

2 tool updatesv0.1.0Aug 1, 2026
- First observedcpl_lookup_section
- First observedcpl_search

Install Server

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

TDQS

A4.7/5.0

Disambiguation5/5

The two tools have clearly distinct purposes: cpl_lookup_section retrieves specific sections by citation, while cpl_search performs full-text topic searches. Each explicitly states when to use the other, leaving no ambiguity.

Naming Consistency5/5

Both tools follow a consistent 'cpl_' prefix followed by a verb or verb_noun (lookup_section, search). The naming clearly signals the action and domain, and the pattern is uniform.

Tool Count4/5

The server has only two tools, which feels thin for a general API but is appropriate for a focused legal statute lookup service. The two tools cover the essential search-and-retrieve workflow and earn their place.

Completeness4/5

The pair covers the key user journeys: finding a section by topic and reading a section by citation. A minor gap is the lack of a browse or list-all-articles tool, but search and citation lookup handle most practical needs.

Maintenance

ActivityStale

ResponsivenessNo issues

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

mcpOAuth
com.bullpenstrategygroup.rotunda
An MCP server that provides congressional transcripts
Government Data Search Open Data
2
CourtListener B
io.github.Vaquill-AI
MCP for CourtListener: US federal and state opinions, dockets, judges, plus eCFR regulations.
Legal & Compliance Government Data
3422
forkast-mcp-docs A
io.github.ForkastPredict
MCP server for querying Forkast documentation
Documentation Access Search Developer Tools
42
Airweave SearchOAuth
io.github.airweave-ai
MCP server for searching Airweave collections with natural language queries.
Search Art & Culture Open Data
25,729

Related MCP Servers

Vaquill-AI/vaquill-mcpofficial
Legal & Compliance Search Government Data
Vaquill-AI
A
license
A
quality
A
maintenance
MCP server for Vaquill legal research API. Covers US federal + 50-state law (USC, CFR, state legislation, CourtListener case law)
Updated 4 days ago (2026-09-02 15:58 UTC)
25
5
MIT
tr-eli-mcp
Legal & Compliance Government Data
matematicsolutions
A
license
A
quality
A
maintenance
An MCP server for accessing Turkish legislation (laws, regulations, decrees) via the Adalet Bakanligi API, providing search, full-text retrieval, and structured citations.
Updated 13 days ago (2026-08-24 13:58 UTC)
5
Apache 2.0
au-eli-mcp
Government Data Search
matematicsolutions
A
license
A
quality
A
maintenance
MCP server for Australia's Federal Register of Legislation. Enables searching and fetching Commonwealth Acts with verifiable citations.
Updated 13 days ago (2026-08-24 13:54 UTC)
3
Apache 2.0
rcw-mcp
Government Data Legal & Compliance Open Data
RetiredOnMyTerms
A
license
A
quality
B
maintenance
An MCP server for the Revised Code of Washington (RCW) that enables retrieving full statutory text by citation, searching for citations by partial reference, and finding bills that affect a given citation.
Updated 2 months ago (2026-07-13 03:16 UTC)
3
MIT

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/njrenaissance/cpl-mcp'

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

cpl-mcp

Installation

Auth setup

Claude Desktop config

Environment variables

Tools

cpl_lookup_section

cpl_search

Running locally

Available Tools

Output Schema

TDQS

Output Schema

TDQS

Tool Schema Changelog

TDQS

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Vaquill-AI/vaquill-mcpofficial

tr-eli-mcp

au-eli-mcp

rcw-mcp

Latest Blog Posts

MCP directory API

`cpl_lookup_section`

`cpl_search`