Search US federal and 50-state statutes, regulations, constitutions, and court rules.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 4.3/5 across 15 of 15 tools scored.
Multiple tools overlap in searching Indian case law: search_legal_cases, quick_search, and search_cases_by_citation all cover similar ground, with quick_search being a lighter version of search_legal_cases. While descriptions help differentiate them, the boundaries are not always clear, especially for agents choosing between them.
Most tools follow a verb_noun pattern (get_act_text, search_legislation, resolve_citation), but 'quick_search' deviates, and 'ask_legal_question' is a phrase rather than a simple verb_noun. Overall, the pattern is predictable and readable.
With 15 tools, the server is at the upper edge of the ideal range. The count is justified by the dual jurisdiction (US and India) and separate concerns (statutes, cases, legislation, citations). However, a few tools like get_pricing feel auxiliary to the legal research purpose, making the count slightly heavier than necessary.
The Indian law surface is well-covered (search, browse, get text, amendments, citations). However, US case law is only accessible indirectly via ask_legal_question; there is no direct US case search or case text retrieval. Also, the US statute section lacks an amendment history tool and a browsing capability, leaving notable gaps for a legal research server.
ask_legal_questionAInspectAI-generated legal answer grounded in primary sources. countryCode='US' (default) covers USC, CFR, 50-state law, and CourtListener case law. countryCode='IN' covers 31M+ Indian judgments + 23K+ acts. US-only sourcesFilter: 'all' | 'statutes_only' | 'cases_only'. Modes: 'standard' or 'deep' (multi-hop, more thorough). Pass chatHistory for follow-ups. Returns answer with numbered citations.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | standard | |
| sources | No | ||
| question | Yes | ||
| max_sources | No | ||
| chat_history | No | ||
| country_code | No | ||
| sources_filter | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses key behaviors: jurisdiction coverage (US/IN), source filter applicability ('US-only'), mode differences, chat history support, and output with numbered citations. However, it omits the behavior of the 'sources' and 'max_sources' parameters, and has minor naming inconsistencies (countryCode vs country_code).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense and well-structured: purpose first, then jurisdiction, filter, modes, follow-ups, and output. Every sentence provides useful information, and it is not overly verbose for a tool with 7 parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 7-parameter tool with no annotations, the description covers the main behavioral aspects but leaves gaps: the purpose of 'sources' and 'max_sources' is unclear, and the phrase 'US-only sourcesFilter' is ambiguous because the schema allows the filter for both country codes. Overall, it is adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has no descriptions (0% coverage), so the description adds meaningful semantics for country_code, sources_filter, mode, and chat_history. However, 'sources' and 'max_sources' are never explained, and the mismatched naming (countryCode, sourcesFilter) could confuse an AI agent mapping to schema properties.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it provides 'AI-generated legal answer grounded in primary sources', with a specific verb (ask) and resource (legal question). It distinguishes itself from sibling tools by focusing on Q&A rather than retrieval or document access, and provides details on jurisdiction coverage and output format.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers clear context on when to use the tool (for legal questions) and covers jurisdiction differences, source filters, and modes, but it does not explicitly mention alternatives or exclusions (e.g., 'for finding a statute use search_us_statutes').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_act_textAInspectGet URLs for the full text, PDF, and HTML versions of a specific Indian act. Pass the act_id (e.g., 'IND_central_2187' for Indian Contract Act). Returns R2 CDN URLs — fetch the text/PDF content directly from those URLs.
| Name | Required | Description | Default |
|---|---|---|---|
| act_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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 discloses a key behavioral trait: the tool returns R2 CDN URLs, not the actual content, and the user must fetch the text/PDF from those URLs. This goes beyond the schema and prevents the misconception that the tool returns the act text directly. It doesn't cover error cases or access restrictions, but given the simple scope, this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, directly states the purpose, and gives a usage example in the first sentence. Every word contributes; there is no fluff or repetition of schema information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one parameter and no annotations, the description provides enough context to use it correctly: what it returns (URLs for text, PDF, HTML), what to pass (act_id with an example), and how to use the result. It doesn't mention how to discover act_id or handle invalid IDs, but given the simplicity and presence of related lookup tools (e.g., list_legislation), it is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only defines the parameter name 'act_id' with no description. The tool description adds meaning by explaining it as the ID of a specific Indian act and gives a concrete example ('IND_central_2187'), which helps the agent construct valid inputs. Since schema coverage is 0%, this compensation is valuable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the function ('Get URLs for the full text, PDF, and HTML versions of a specific Indian act') with a specific verb and resource. It also distinguishes itself from siblings by focusing on Indian acts and on returning URLs rather than content directly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear usage context by instructing to pass act_id with a concrete example ('IND_central_2187' for Indian Contract Act). It also tells the user what to do with the output (fetch from the returned URLs). It doesn't explicitly mention when not to use it or suggest alternatives, but the guidance is sufficient for a simple lookup tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_amendmentsAInspectGet the complete amendment history for an Indian act. Returns all footnotes showing substitutions, insertions, omissions, and notes made by amending acts. Filter by section number or amendment type. Each footnote shows the amending act name and original text (if available). Use to trace how a statute evolved.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | ||
| act_id | Yes | ||
| section | No | ||
| page_size | No | ||
| footnote_type | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses valuable behavioral details: returns footnotes showing substitutions/insertions/omissions, includes amending act name, and notes that original text is 'if available.' It also mentions filtering options, giving a clear picture of the returned data. It does not discuss pagination or auth, but the core behavior is well covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the main purpose, followed by return details, filtering options, and a use case. Every sentence adds value and there is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (5 params, output schema present), the description covers the core return structure, filtering, and use case. The existence of an output schema means return details don't need to be exhaustive. Slight gaps include pagination behavior and parameter details, but overall the description is sufficient for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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. It explains the semantic meaning of two parameters: 'Filter by section number or amendment type' maps to section and footnote_type. However, it does not explain act_id, page, or page_size. While page/page_size are somewhat self-explanatory with defaults, the explanation is partial given 5 parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Get the complete amendment history for an Indian act.' It specifies the resource (Indian act), the operation (get amendment history), and differentiates from siblings by focusing on amendments rather than full text, citations, or searches.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides an explicit use case: 'Use to trace how a statute evolved.' This implies the appropriate context and separates it from alternatives like get_act_text (current text) or search tools. It does not explicitly name alternatives, but the guidance is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_citation_networkAInspectTraverse the citation network around a case. Returns nodes (cases) and edges (citing relationships) with treatment types (followed, distinguished, overruled). Specify direction: 'outbound' (cases this cites), 'inbound' (cases citing this), or 'both'. Set depth (1-3 hops) and limit (1-100 nodes). Useful for understanding a case's legal influence.
| Name | Required | Description | Default |
|---|---|---|---|
| depth | No | ||
| limit | No | ||
| citation | Yes | ||
| direction | No | both | |
| country_code | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the return structure (nodes and edges with treatment types), and adds operational constraints beyond the schema (depth 1-3 hops, limit 1-100 nodes). It does not mention permissions, errors, or side effects, but for a read-only traversal tool this is reasonably transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with purpose, and every sentence adds value. It condenses return type, parameters, and usage context without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters (1 required) and no schema descriptions, the description is incomplete: it omits citation format and country_code semantics. It does describe the output shape, but the input gaps mean an agent may struggle to invoke the tool correctly without additional examples or schema hints.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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. It explains direction (outbound/inbound/both), depth (1-3 hops), and limit (1-100 nodes). However, it does not explain the required 'citation' parameter format or the optional 'country_code' parameter, leaving key inputs underspecified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies a clear verb ('traverse') and resource ('citation network around a case'), and mentions distinct output elements (nodes, edges, treatment types). It differentiates from sibling tools like search_legal_cases or lookup_case by focusing on network relationships rather than simple search or retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear context for when to use the tool: 'useful for understanding a case's legal influence.' It does not explicitly name alternatives or state when not to use it, but the context is strong enough to guide an AI agent's selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_pricingAInspectGet current API credit pricing. Returns per-endpoint credit costs and credit-to-currency conversion rates (1 credit = $0.01 USD). No authentication required. Use to check costs before making API calls.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well: it discloses that no authentication is required, and it specifies the return content (per-endpoint costs and credit-to-currency conversion). This is sufficient behavioral context for a read-only pricing tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (two sentences), front-loaded with the main purpose, and every word earns its place. It includes purpose, return details, auth requirement, and usage guidance without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, output schema exists), the description is complete. It explains what the tool does, what it returns, authentication, and when to use it, leaving no critical gaps 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.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and an empty schema, so no parameter-specific explanation is needed. The baseline is 4, and the description inherently conveys that the tool requires no input.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Get current API credit pricing.' It specifies the exact resource (pricing) and what it returns (per-endpoint credit costs and conversion rates). This distinguishes it from the sibling legal research tools, as none of them deal with pricing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool: 'Use to check costs before making API calls.' This provides clear guidance without ambiguity, and since it's a unique utility tool among siblings, no alternative exclusion is needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_us_statute_sectionAInspectGet metadata for a specific US statute or regulation section by act_id (e.g. 'USC_T42_C21_S1983'). The act_id comes from search_us_statutes results or ask_legal_question sources. Returns citation, title hierarchy, breadcrumb, and links to HTML, PDF, and XML formats. Use before get_us_statute_section_text to preview a section.
| Name | Required | Description | Default |
|---|---|---|---|
| act_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It clearly conveys a read-only operation ('Get metadata', 'preview', 'Returns citation...') and enumerates return contents, which implies no destructive side effects. However, it does not explicitly mention permissions, failure modes, or rate limits, though these are less critical for a read-only metadata endpoint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four sentences, each providing distinct value: what it does, where the ID comes from, what it returns, and how to use it before a related tool. There is no padding or redundancy, making it efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with a single parameter and an output schema, the description covers all essential aspects: purpose, parameter semantics, return values, and workflow positioning relative to siblings. The output schema handles structured details, so the description is complete for an agent to select and invoke this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description fully compensates. It explains act_id with a concrete example ('USC_T42_C21_S1983') and states its provenance ('comes from search_us_statutes results or ask_legal_question sources'). This gives the agent complete understanding of the parameter without needing external schema docs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with a specific verb and resource: 'Get metadata for a specific US statute or regulation section by act_id'. It includes an example ID format and the phrase 'metadata' clearly distinguishes it from the sibling tool get_us_statute_section_text. This makes the tool's purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage context: 'The act_id comes from search_us_statutes results or ask_legal_question sources' and 'Use before get_us_statute_section_text to preview a section.' This names a specific sibling alternative and gives a sequential workflow, satisfying the when-to-use requirement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_us_statute_section_textAInspectGet the full text of a US statute or regulation section (USC or CFR) by act_id. Returns both styled HTML (with cross-references and paragraph numbering as published in the official code) and plain text. Use when you need the actual statutory language for quotation, drafting, or analysis.
| Name | Required | Description | Default |
|---|---|---|---|
| act_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses that the tool returns both styled HTML (with cross-references and paragraph numbering as published in the official code) and plain text, giving useful behavioral detail. It does not mention error handling or rate limits, but the core behavior is well-described.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: two sentences, front-loaded with the main action and output format, and containing no fluff. Every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tool's purpose, output, and usage context, which is adequate for a simple one-parameter tool. However, it lacks guidance on how to obtain an act_id or how this tool relates to siblings like get_us_statute_section or resolve_citation, leaving integration gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, act_id, has no schema description, and the description merely references it without explaining its format, origin, or how to obtain it. Since schema coverage is 0%, the description should compensate but does not, leaving the agent uncertain about what values are valid.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action: retrieving the full text of a US statute or regulation section (USC or CFR) by act_id. It also distinguishes itself from sibling tools like get_us_statute_section by emphasizing full text and the return of styled HTML and plain text.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states when to use the tool: 'when you need the actual statutory language for quotation, drafting, or analysis.' This provides clear context, though it does not mention exclusions or alternatives, so it does not earn the top score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_legislationAInspectBrowse 23,000+ Indian acts, regulations, and legislation. Use to discover act_id values for get_act_text and get_amendments. Filter by category (central, state, regulatory, repealed, spent), state slug, department (sebi, rbi, etc.), year range, and status (in_force, repealed, spent). Sort by year_desc, year_asc, title_asc, title_desc, or popular.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | ||
| sort | No | year_desc | |
| state | No | ||
| search | No | ||
| status | No | ||
| year_to | No | ||
| category | No | ||
| page_size | No | ||
| year_from | No | ||
| department | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses the browse/filter nature and lists filter options, but does not mention pagination behavior, response format, or explicitly state that it is a read-only operation. It adds some context (e.g., scale of 23,000+) but not rich behavioral detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with three sentences that are front-loaded with the primary action. Bolding adds emphasis, and every sentence contributes value without unnecessary fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 10-parameter browse tool with an output schema, the description covers the main filters but ignores search and pagination. It also does not clarify how the filters interact. Given the existence of an output schema, return values are covered, but the input parameter coverage is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must add meaning. It explains several parameters (category, state slug, department, year range, status, sort) and provides examples for department and valid category/status values. However, it omits the 'search' parameter and the pagination parameters (page, page_size), which are important for a browsing tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Browse 23,000+ Indian acts, regulations, and legislation.' It uses a specific verb and resource, and explicitly mentions the purpose of discovering act_id values for get_act_text and get_amendments, distinguishing it from sibling tools like search_legislation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: 'Use to discover act_id values for get_act_text and get_amendments.' This indicates a primary use case but does not explicitly state when not to use or name alternatives, so it lacks full exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
lookup_caseAInspectGet full details for a specific case by its citation. Returns comprehensive case metadata, all known citation aliases, and citation treatment statistics showing how many times the case was followed, distinguished, overruled, approved, or referred. Use after resolve_citation or search_cases_by_citation for deep case analysis.
| Name | Required | Description | Default |
|---|---|---|---|
| citation | Yes | ||
| country_code | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and discloses return behavior comprehensively: 'comprehensive case metadata, all known citation aliases, and citation treatment statistics.' It also implies that a valid citation is required. It doesn't mention errors or auth, but for a read-only lookup this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with purpose, then return details, then usage guidance. Every sentence adds value and there is no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is complete enough for a lookup tool with an output schema and clear usage context. It covers what is returned, the input type, and the workflow position. It could mention the optional country_code param but that is a parameter semantics gap, not overall completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description only hints at the 'citation' parameter. It does not explain the optional 'country_code' parameter at all, leaving the agent to infer its meaning. The description must compensate for the schema's lack of documentation but only does so partially.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Get full details for a specific case by its citation.' It uses a specific verb and resource, and distinguishes itself from siblings by explicitly positioning it as a follow-up to resolve_citation or search_cases_by_citation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells the agent when to use this tool: 'Use after resolve_citation or search_cases_by_citation for deep case analysis.' This provides clear context and differentiates it from alternative lookup/search tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
quick_searchAInspectFast compact Indian legal case search returning top 3-5 results with just the essentials: title, citation, court, year, summary excerpt, and PDF link. Same boolean query syntax as search_legal_cases but returns fewer, flatter results. Best when you need a quick overview rather than detailed results.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| top_k | No | ||
| year_to | No | ||
| year_from | No | ||
| court_name | No | ||
| court_type | No | ||
| country_code | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so description carries full burden. It discloses return format (title, citation, court, year, summary excerpt, PDF link), result limit (3-5), and search scope (Indian). However, it omits error behavior, rate limits, or authentication, which are common for tools. Core behavior is reasonably transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each with a purpose: function, output features, and usage guidance. No redundancy or filler; front-loaded and to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, return values are covered. Description covers purpose, scope, and usage. But it omits details on filter parameters and query syntax specifics, which is notable since schema has no descriptions. Overall, adequate for a quick search tool but with clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must explain parameters, but it only references the query syntax via comparison to search_legal_cases. There is no explanation of top_k, year_from/year_to, court_name, court_type, or country_code. This is a significant gap for a 7-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it's a compact search for Indian legal cases returning top 3-5 results with essential fields. It explicitly distinguishes itself from search_legal_cases by noting the same query syntax but fewer, flatter results.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit usage guidance: 'Best when you need a quick overview rather than detailed results' and references search_legal_cases as the comparison point. Doesn't explicitly say when NOT to use, but the implication is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
resolve_citationAInspectResolve any Indian legal citation format to its canonical case record. Accepts SCC, AIR, SCR, MANU, SCALE, INSC formats (e.g., '(2019) 11 SCC 706' or 'AIR 1976 SC 1207'). Returns case details and all known citation aliases/formats. Returns found=false (not an error) when citation cannot be resolved.
| Name | Required | Description | Default |
|---|---|---|---|
| citation | Yes | ||
| country_code | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does disclose key behaviors: it accepts multiple citation formats, returns case details and aliases, and returns found=false instead of throwing an error when a citation cannot be resolved. It does not cover authentication or rate limits, but for a read-only lookup tool, the key behaviors are addressed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences with no fluff: the first states purpose, the second provides accepted formats and examples, and the third clarifies failure behavior. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers core functionality, input formats, and the found=false behavior, and an output schema exists. However, it omits context for the optional country_code parameter and does not differentiate from similar citation tools like lookup_case or search_cases_by_citation, leaving a small completeness gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explains the 'citation' parameter with format examples and a sample value, which is valuable since schema coverage is 0%. However, the optional 'country_code' parameter is not mentioned at all, leaving a gap in parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: resolving any Indian legal citation to its canonical case record. It lists specific formats (SCC, AIR, SCR, MANU, SCALE, INSC) with examples, giving a specific verb+resource+scope and distinguishing it from sibling tools like lookup_case or search_cases_by_citation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool by listing accepted citation formats, and it clarifies behavior on unresolved citations (returns found=false, not an error). However, it does not explicitly name alternative tools or state when not to use this tool, so it lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_cases_by_citationAInspectSearch for legal cases by citation text or case name. Use when you know part of a case name (e.g., 'Maneka Gandhi') or a partial citation. Filter by court code (SC, DEL, BOM, MAD, etc.), year range, and validity status (GOOD_LAW, OVERRULED, DISTINGUISHED, etc.). Returns up to 50 matching cases with metadata.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes | ||
| year_end | No | ||
| court_code | No | ||
| year_start | No | ||
| country_code | No | ||
| validity_status | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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 discloses key behavioral traits: 'Returns up to 50 matching cases with metadata' and the filtering capabilities. This goes beyond a simple 'search' statement, though it does not detail edge cases, error handling, or whether the operation is read-only (though that 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence with no filler. It front-loads the core action ('Search for legal cases') and then lists supporting details. Every clause earns its place, making it both concise and information-dense.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present (though not shown), return values are likely covered. The description addresses the main use case, filters, and result limit. However, it lacks explicit jurisdiction context (e.g., Indian courts) and does not distinguish itself from the sibling 'search_legal_cases' in the description itself. These are minor gaps given the overall clarity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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. It maps well to parameters: 'query' (case name/partial citation), 'court_code' (SC, DEL, BOM, MAD), 'year_start'/'year_end' (year range), and 'validity_status' (GOOD_LAW, OVERRULED, etc.). It also implies 'limit' via 'up to 50'. It misses explicit mention of 'country_code' and does not explain the exact format of 'query' beyond partial citation, but overall adds significant value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Search for legal cases by citation text or case name.' This is a specific verb-resource pair that distinguishes it from siblings like search_legal_cases (broader search) and resolve_citation (exact resolution). The mention of filters (court code, year, validity) further sharpens the purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage context: 'Use when you know part of a case name (e.g., 'Maneka Gandhi') or a partial citation.' This clearly tells the agent when to choose this tool. However, it does not explicitly name alternatives or state when not to use it, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_legal_casesAInspectBoolean keyword search of the Indian corpus. Supports AND, OR, NOT and quoted phrases. Filter by courtType (supreme_court, high_court), courtName, year range. Returns paginated results with text, citation, court, relevance score, snippet, PDF. Present only the top results, do NOT emphasize total count. Use pageSize 10 for conversational answers, 20 for exhaustive lists. For US case law, use ask_legal_question with countryCode='US'.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | ||
| query | Yes | ||
| year_to | No | ||
| page_size | No | ||
| year_from | No | ||
| court_name | No | ||
| court_type | No | ||
| country_code | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well: it discloses return fields (text, citation, court, relevance score, snippet, PDF), pagination behavior, boolean syntax support, and presentation instruction ('Present only the top results, do NOT emphasize total count'). It lacks explicit mention of read-only nature or error/rate-limit details, but for a search tool this is quite transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loaded with the core purpose, and every sentence adds value—covering scope, syntax, filters, return format, usage guidance, and an explicit alternative. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 8 parameters, no annotations, and an output schema, the description covers the essential aspects: corpus scope, query syntax, filters, return fields, pagination defaults, and cross-tool guidance. It is thorough enough for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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. It explains the query syntax (AND, OR, NOT, quoted phrases), valid court_type values ('supreme_court, high_court'), courtName, year range, and pageSize recommendations. It does not explicitly explain 'page' or 'country_code' semantics, but the overall parameter meaning is greatly clarified beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs a Boolean keyword search of the Indian legal corpus. It distinguishes itself from US case law search by explicitly directing users to ask_legal_question for US, and the mention of 'Indian corpus' sets it apart from sibling search tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit guidance on when to use this tool vs alternatives: 'For US case law, use ask_legal_question with countryCode='US''. It also offers usage tactics for pageSize based on context (conversational vs exhaustive), which goes beyond basic when-to-use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_legislationAInspectSearch 23,000+ Indian acts, regulations, and legislation using semantic search. Find specific statutory provisions, definitions, penalties, and procedures. Filter by category (central, state, regulatory), state, department (SEBI, RBI, TRAI, etc.), and year range. Returns relevant act sections with text excerpts, section numbers, provision type, and PDF links. Use for questions like 'What is the penalty for insider trading under SEBI Act?' or 'Definition of goods under GST Act'.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| state | No | ||
| year_to | No | ||
| category | No | ||
| page_size | No | ||
| year_from | No | ||
| department | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It explains the semantic search behavior, the filters applied, and what the tool returns ('act sections with text excerpts, section numbers, provision type, and PDF links'). While it doesn't mention rate limits or non-mutating status explicitly, the behavior is largely transparent for a 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficient, using four sentences that each add value: purpose, target content, filters, and usage examples. It is front-loaded with the main action and avoids unnecessary fluff, though it is slightly longer than the bare minimum.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers what the tool does, when to use it, what it returns, and what filters are available. The output schema handles return value details. Minor gaps include lack of mention of pagination and optional parameter behavior, but overall it is sufficiently complete for a search tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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. It explains filter parameters such as category (with examples 'central, state, regulatory'), state, department (with examples 'SEBI, RBI, TRAI'), and year range. However, it omits page_size entirely and does not detail the exact value formats or that all filters are optional, leaving some gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Search 23,000+ Indian acts, regulations, and legislation using semantic search.' It specifies the verb (search), resource (Indian legislation), and scope (specific provisions, definitions, penalties). It also distinguishes itself from siblings like search_legal_cases by focusing on acts/legislation rather than case law.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context with explicit examples ('Use for questions like...'), and outlines filterable dimensions. However, it does not explicitly mention when not to use it or name alternatives, so it falls short of fully explicit when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_us_statutesAInspectSemantic search across the United States Code (USC) and Code of Federal Regulations (CFR). Use for federal statutory and regulatory questions: SEC (Title 17), FDA (Title 21), civil rights (Title 42), tax (Title 26), etc. Filter by corpusType ('USC' | 'CFR') and titleNumber. Returns sections with citation, title hierarchy, HTML/PDF/XML links. The returned act_id (e.g. 'USC_T42_C21_S1983') feeds get_us_statute_section_text for full text.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes | ||
| corpus_type | No | ||
| title_number | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must disclose behavior. It states that the tool performs semantic search and returns sections with citation, hierarchy, and links. It also discloses the act_id convention. However, it doesn't mention parameter constraints (e.g., limit behavior) or potential errors, but for a search tool this is reasonable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with dense information. Each sentence serves a purpose: scope, usage, return format and downstream usage. No fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with an output schema, the description covers scope, filters, return content, and integration with a sibling tool. It doesn't detail pagination or error handling, but the presence of a limit parameter and output schema mitigates that.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions filtering by corpusType and titleNumber, which maps to corpus_type and title_number in the schema. It doesn't address the limit parameter, but query and limit are self-explanatory. The description uses camelCase that could be confusing, but it's understandable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description opens with 'Semantic search across the United States Code (USC) and Code of Federal Regulations (CFR)', clearly stating the verb and resource. It distinguishes from siblings like search_legal_cases and search_legislation by specifying statutory/regulatory scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states 'Use for federal statutory and regulatory questions' and provides example titles. It also explains how the returned act_id feeds get_us_statute_section_text, implying a workflow. However, it doesn't explicitly state when not to use this tool versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
Sign in to create a connector for this server.