Search US and Indian statutes, regulations, constitutions, and court rules.
Fetch one Indian enactment by the id from a search result, returning {id, title, text, url, metadata}. Also accepts a source URL or a bare path. NOTE: the India corpus serves an enactment as publisher links rather than inline text, so text carries the title and metadata carries the PDF, HTML and plain-text URLs to read. Prefer get_act_text if you can call it.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, so the safety profile is already covered. The description adds valuable behavioral context beyond that: the India corpus does not serve inline text, `text` carries the title, and `metadata` carries the PDF/HTML/plain-text URLs. It does not go into failure behavior, but the annotations and output schema reduce the need for that.
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 no filler. The core behavior is front-loaded, the corpus-specific caveat is clearly 'NOTE'-labeled, and the routing advice is placed last without diluting the main message.
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, the return shape is already documented, and the description correctly focuses on the non-obvious corpus behavior and tool routing. The only notable gap is the unresolved URL/path parameter mapping, which prevents a perfect completeness score.
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 carries the burden of explaining the lone `id` parameter. It usefully clarifies that `id` comes from a search result and that source URLs or bare paths are also accepted. However, it is ambiguous whether the URL/path is passed through the `id` parameter or is a separate, undocumented mode of invocation, and no format details are given.
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?
States a specific verb and resource: 'Fetch one Indian enactment by the `id` from a `search` result,' and lists the return shape. It also distinguishes itself from `get_act_text` by naming the preferred sibling, so an agent can differentiate the 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?
Explicitly says the id comes from a search result and instructs the agent to 'Prefer `get_act_text` if you can call it,' giving a clear routing rule. The alternate source URL or bare path input is also mentioned, providing concrete when-to-use context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The amendment history recorded against one enactment: substitutions, insertions and omissions, each with the amending Act and its effective date (e.g. 'Subs. by Act 22 of 2023, s. 44 (w.e.f. 13-11-2025)'). Use to check whether a provision still reads as enacted before relying on its text. An empty list means no amendment was recorded, NOT that the Act was never amended. Cost: 5 credits.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number | |
| type | No | Filter: substitution, insertion, omission, note, renumbering | |
| act_id | Yes | Section identifier, e.g. `USC_T42_C21_S1983` (Title 42, Chapter 21, Section 1983, written 42 U.S.C. 1983). Take it from a search result rather than assembling it: the title and section are derivable from a citation but the CHAPTER is not, so hand-built ids usually 404. | |
| section | No | Filter by section number | |
| pageSize | No | Results per page |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, it discloses the empty-list semantics ('NOT that the Act was never amended'), the exact entry format with a real example, and the credit cost. This is rich behavioral context that cannot be inferred from the schema or annotations.
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?
Each sentence earns its place: definition, use case, empty-list caveat, and cost. It is front-loaded with the core behavior and keeps the critical caveat at the end without any 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?
With a present output schema and fully documented parameters, the description supplies the essential semantic context: output structure, effective-date format, when to use it, how to interpret empty results, and cost. Nothing needed for correct selection and invocation is missing.
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 100%, so the baseline is 3. The description does not add parameter-specific details beyond the schema; however, the act_id parameter schema is already detailed with an example and a warning about hand-building IDs. A 3 is appropriate.
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 names a specific verb and resource ('amendment history recorded against one enactment') and gives a concrete example of the output format. It clearly distinguishes itself from siblings like get_act_text and get_corresponding_provisions by focusing on amendments rather than current 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?
Provides an explicit use case: 'Use to check whether a provision still reads as enacted before relying on its text.' This gives clear guidance on when to call the tool, though it does not name alternative tools or exclusion conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Source links for one enactment: the plain-text, PDF and HTML renderings, plus how many sections it holds. Use when the user wants to read or cite the Act itself rather than a matched section. Cost: 3 credits.
| Name | Required | Description | Default |
|---|---|---|---|
| act_id | Yes | Section identifier, e.g. `USC_T42_C21_S1983` (Title 42, Chapter 21, Section 1983, written 42 U.S.C. 1983). Take it from a search result rather than assembling it: the title and section are derivable from a citation but the CHAPTER is not, so hand-built ids usually 404. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
readOnlyHint already establishes the safety profile, and the description adds useful behavioral context: exact credit cost and the form of the return data. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences with no filler. The core output is front-loaded, followed by the usage condition and cost 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 single-parameter, read-only tool with a detailed input schema and an output schema, the definition fully covers what the agent needs: what the tool returns, when to call it, and its cost. The matched-section contrast provides enough routing guidance.
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 description itself adds no act_id detail, but the input schema already covers 100% of the parameter and includes a rich description with an example and guidance to take IDs from search results. Baseline 3 is appropriate.
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?
States a specific outcome: source links (plain-text, PDF, HTML renderings) and section count for one enactment. It explicitly distinguishes the Act itself from a matched section, which differentiates it from section-oriented siblings.
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?
Provides a clear usage condition: use when the user wants to read or cite the Act itself rather than a matched section. It implies when not to use section-level tools, though it does not name alternative sibling tools explicitly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Map a repealed Indian criminal code to the 2023 code that replaced it, section by section: IPC to BNS and CrPC to BNSS, in force from 1 July 2024. Pass either side ('ipc' or 'bns' both work). Use whenever a source, a pleading or the user cites an old section number, so you answer under the provision actually in force rather than the repealed one. 'iea'/'bsa' return 404 until that mapping lands. Cost: 1 credit.
| Name | Required | Description | Default |
|---|---|---|---|
| act_code | Yes | Act code: ipc, crpc, iea, bns, bnss or bsa |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, and the description complements this by noting the mapping is effective from 1 July 2024 and that 'iea'/'bsa' return 404. It does not contradict annotations. It could disclose more about response format or error behavior beyond 404, but given the annotation covers safety, the added temporal and error context earns a 4.
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 compact and front-loaded: the core mapping purpose is stated in the first sentence, followed by usage timing, accepted input, unsupported codes, and cost. Every sentence earns its place, with 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?
For a single-parameter read-only mapping tool with an output schema and a simple enum-like pattern, the description covers purpose, input variants, current support gaps, effective date, and cost. Nothing essential is missing 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?
Schema description coverage is 100%, and the schema already documents the act_code parameter and its allowed values. The description adds a useful clarification that 'ipc' or 'bns' both work, and that 'iea'/'bsa' currently return 404, but it doesn't need to add more because the schema does the heavy lifting. Baseline 3 is appropriate.
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 maps repealed Indian criminal code sections to the 2023 replacement code (IPC to BNS, CrPC to BNSS), with a specific verb 'Map' and resource. It also distinguishes itself from siblings by focusing on section-by-section mapping between old and new codes, which is unique among the listed 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?
The description explicitly says when to use it: whenever a source, pleading, or user cites an old section number, so the agent answers under the provision actually in force. It also provides exclusion guidance, noting 'iea'/'bsa' return 404 until mapping lands, preventing wasted calls. This is strong contextual routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Self-describing filter vocabulary: every category, state, department and status the acts corpus actually holds, with counts. Call this before filtering, so a query uses a value that exists instead of returning empty because the spelling was wrong.
| 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?
Annotations already signal readOnlyHint=true, and the description adds useful behavioral context: the tool returns corpus-derived vocabulary with counts, and the values reflect what actually exists in the data. It does not discuss pagination or rate limits, but the output schema covers return structure.
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?
Two sentences with no filler: the first defines what the tool returns, the second gives the usage directive. Every word earns its place, and the key purpose is front-loaded.
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 no-parameter, read-only vocabulary tool with an output schema, the description provides everything an agent needs: what data is returned, why to call it, and when to call it. Nothing critical is missing.
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 the schema is empty, so there are no parameter semantics to describe. The baseline for zero-parameter tools is 4, and the description's focus on output contents rather than inputs is fully appropriate.
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 names a specific verb ('list') and resource ('act filters'), and clearly states that it returns the filter vocabulary (categories, states, departments, statuses) with counts. This distinguishes it from sibling tools like list_acts and search_acts, which operate on acts rather than the filter vocabulary.
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 instructs the agent to call this tool 'before filtering' and explains the benefit: using a value that exists avoids empty results from spelling errors. It does not name alternatives or give exclusion conditions, but the guidance is clear and actionable for a simple no-parameter tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Browse and filter enactments rather than searching their text: by jurisdiction (central or a state), issuing regulator, year and status. Use when the user wants to know WHAT exists in an area before asking what it says, or to confirm an Act's exact title before citing it. Cost: 1 credit.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number | |
| sort | No | Sort: year_desc, year_asc, title_asc, title_desc, popular | year_desc |
| state | No | Filter by state slug (e.g. 'maharashtra', 'delhi') | |
| search | No | Filter by title substring | |
| status | No | Filter: in_force, repealed, spent | |
| yearTo | No | Maximum year (inclusive) | |
| category | No | Filter: central, state, regulatory, repealed, spent | |
| pageSize | No | Results per page (1-100) | |
| yearFrom | No | Minimum year (inclusive) | |
| department | No | Filter by regulatory body (e.g. 'sebi', 'rbi') |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already covers the safety profile, lowering the bar. The description adds useful context such as the one-credit cost and the metadata-browsing behavior, but it does not disclose pagination behavior, result shape beyond the output schema, or any rate-limit implications. This is adequate but not rich.
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?
Two sentences carry the full value: the action and contrast, the filter dimensions, the use cases, and the cost. Every clause earns its place, and the most decision-relevant information is front-loaded.
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 10 optional parameters, a complete input schema, an output schema, and a readOnly annotation, the description covers the essential selection and invocation context well. It could have named sibling alternatives or pointed to list_act_filters for valid filter values, but nothing an agent critically needs to call it correctly is missing.
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 100%, so the input schema already documents all 10 parameters. The description re-expresses several filters at a high level (jurisdiction, regulator, year, status) but adds no semantic detail beyond the schema. Baseline 3 is appropriate.
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 opens with a specific verb-resource pair ('Browse and filter enactments') and immediately contrasts it with text search, distinguishing it from siblings like search_acts and get_act_text. It also names the key dimensions (jurisdiction, regulator, year, status) and the concrete use cases of discovering what exists or confirming an exact title.
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 the user wants to know WHAT exists before asking what it says, or to confirm an Act's exact title before citing it. The phrase 'rather than searching their text' implies the alternative, but it does not name sibling tools explicitly or give a clear when-not-to-use list, so it stops 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.
Generic corpus search over Indian Central and State legislation, returning {id, title, url} records for citation. Present so this server works in clients that require the standard search/fetch pair. Prefer search_acts if you can call it: it filters by category, state, year and status. Pair with fetch to read a result.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds useful behavior beyond that: the corpus scope, the citation-oriented return records, and the role as the standard search/fetch pair for client compatibility. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The first sentence is well front-loaded and informative, and the sibling routing is useful. However, the sentence 'Present so this server works in clients that require the standard search/fetch pair' is awkward and reads like an implementation note rather than agent-facing guidance, slightly weakening structure.
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 single-parameter read-only search tool with an output schema, the description covers scope, return purpose, alternative routing, and the follow-up fetch step. It does not document query formulation or result limits, but the tool is simple enough that this is a minor 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 input schema has one required `query` string with 0% schema description coverage, so the description carries the full burden for parameter meaning. It only implies that `query` is used for searching the corpus, but it does not explain query syntax, matching behavior, or examples.
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 states a specific verb/resource: 'Generic corpus search over Indian Central and State legislation' and explicitly names the return shape `{id, title, url}` for citation. It also distinguishes itself from `search_acts` by framing that tool as the filtered alternative.
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 says to prefer `search_acts` when available and explains why: it filters by category, state, year, and status. It also tells the caller to pair with `fetch` to read a result, giving clear routing and follow-up guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Indian legislation down to the individual section: Central and State Acts plus the instruments of the principal regulators (SEBI, RBI, MCA, IRDAI, TRAI, DGFT). Use for any 'what does Indian law say' question. Supports boolean and phrase queries; filters by category, state, year and status. Returns sections with title, chapter and a sourceUrl pointing at the publisher's own document. The returned actId (e.g. 'IND_central_2065') feeds every acts tool. Cost: 2 credits.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | 1-based page number. `page * pageSize` may not exceed 100; narrow the query with filters to reach deeper matches. | |
| query | Yes | Search query | |
| state | No | Filter by state slug (e.g. 'maharashtra', 'delhi') | |
| yearTo | No | Maximum year (inclusive) | |
| actTitle | No | Filter by act title substring (e.g. 'Indian Penal Code', 'BNSS') | |
| category | No | Filter: central, state, regulatory, repealed, spent | |
| pageSize | No | Results per page (1-50) | |
| yearFrom | No | Minimum year (inclusive) | |
| department | No | Filter by regulatory body (e.g. 'sebi', 'rbi') | |
| sectionNumber | No | Filter by exact section number (e.g. '23', '302', '498A') |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description discloses meaningful behavioral details: search query capabilities (boolean/phrase), filters (category, state, year, status), return fields (title, chapter, sourceUrl), and the downstream value of actId. It also mentions the credit cost. Nothing contradicts the annotations.
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?
Four sentences, with the core purpose front-loaded, followed by usage, supported search features, return format, downstream integration, and cost. There is no redundancy or filler; every sentence adds useful 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?
The description covers what the tool searches, how to use it, what it returns, and how the result connects to other tools. A small gap is that it says 'filters by status' but no 'status' parameter exists in the schema (status is represented via category values like 'repealed' and 'spent'), which could slightly confuse an agent. Overall, output schema supplies return details, so this is nearly 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 already provides 100% parameter description coverage, so the baseline is 3. The description adds value by explaining that boolean and phrase queries are supported and by summarizing the filter dimensions (category, state, year, status). It does not deeply elaborate on each parameter but enriches overall search semantics.
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 opens with a specific verb and resource: 'Search Indian legislation down to the individual section.' It clearly identifies the scope (Central and State Acts plus regulator instruments) and distinguishes this from a general search tool by noting the actId feeds every acts tool. The 'what does Indian law say' usage line further anchors the tool's role.
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 says to use this for any 'what does Indian law say' question, giving a clear primary use case. It also mentions the returned actId feeds other acts tools, which implies a workflow. However, it does not explicitly state when to prefer sibling tools like list_acts or get_act_text, nor does it list exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
fetchget_act_amendmentsget_act_textget_corresponding_provisionslist_act_filterslist_actssearchsearch_actsClaiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such as io.github.acme/server also needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
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
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
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!
Public Indian legal search MCP for Roop judgments, statutes, and corpus grounding.
Search UK Acts, Statutory Instruments, and legislation with full text retrieval
Resolve, search and verify legal citations against the official sources, with provenance.
Search and cite US law from official sources, then form an LLC or nonprofit with free agent tools.
Add one secure layer between your agents and this server.
Most tools have clearly distinct purposes: search_acts does section-level text search, list_acts browses filters, get_act_text retrieves source links, and get_act_amendments covers legislative history. A few overlapping pairs exist (search vs search_acts, fetch vs get_act_text), but the descriptions explicitly steer callers toward the preferred tool, reducing real ambiguity.
Tool names mostly follow a predictable get_/list_/search_ pattern, with get_act_text, get_act_amendments, list_acts, list_act_filters, and search_acts being clear and consistent. The bare names fetch and search are minor deviations, though they serve as standard compatibility hooks rather than random exceptions.
Eight tools is a well-scoped count for an Indian legislation research server. Each tool covers a distinct aspect of the workflow: searching, browsing, filtering, retrieving text, checking amendments, and mapping repealed codes, with no unnecessary bloat.
The tool set covers the core research lifecycle end to end: discover what exists (list_acts), understand filter vocabulary (list_act_filters), search sections (search_acts), retrieve source text (get_act_text), check amendments (get_act_amendments), and translate repealed provisions to current law (get_corresponding_provisions). The only noted gap, the IEA/BSA mapping, is explicitly flagged as not yet available rather than silently missing.
