Skip to main content
Glama

cpl_search

Read-onlyIdempotent

Find New York Criminal Procedure Law sections by searching full-text terms like 'discovery' or 'speedy trial'. Returns ranked results with citations and titles for further lookup.

Instructions

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).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
paramsYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes
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.

Install Server

Other Tools

Latest Blog Posts

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