Redra
Server Details
Search current class-action settlements and identify possible matches using structured filters.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- sacrosaunt/Redra
- GitHub Stars
- 0
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.
Tool Definition Quality
Average 4.4/5 across 5 of 5 tools scored.
Each tool targets a distinct operation: dataset metadata, single settlement retrieval, multiple settlement retrieval, keyword search, and batch search. Descriptions clearly differentiate their use cases, leaving no ambiguity.
All tool names follow a consistent verb_noun pattern with underscores: get_* for retrieval and search_* for searching. No mixing of conventions, making the set predictable.
Five tools is well-scoped for a settlement search domain: one for dataset info, two for direct retrieval (single/multiple), and two for search (single/batch). Each tool earns its place without redundancy.
Covers key operations: dataset metadata, retrieval by ID, and search with filters and batching. Minor gap: no tool for listing settlement types or categories, but core search and retrieval are fully covered.
Available Tools
5 toolsget_dataset_infoGet dataset informationARead-onlyIdempotentInspect
Return source, license, freshness, counts, and hosted aggregate metrics.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the description's main job is to add value. It does so by specifying the returned content (source, license, etc.), which goes beyond the schema. No contradictions 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 description is a single sentence of 9 words, front-loaded with the verb 'Return'. Every word is meaningful and no redundant information is present.
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 no parameters and an output schema, the description covers the essential return fields. However, it does not clarify which dataset this info pertains to (e.g., current context), which is a minor gap for 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?
There are zero parameters, so the baseline is 4 according to instructions. The description correctly does not attempt to document non-existent 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 uses the specific verb 'Return' and lists concrete data types ('source, license, freshness, counts, and hosted aggregate metrics'), clearly stating what the tool does. The sibling tools are all about settlements, so this tool is clearly distinguished for dataset info.
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?
No explicit guidance is provided on when to use this tool versus alternatives. While sibling tool names imply a different domain (settlements), the description lacks any 'use this when' or 'prefer X for Y' statements, forcing the agent to rely solely on naming.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_settlementGet a settlementARead-onlyIdempotentInspect
Return one settlement and its official source links.
When web access is available, use the official links to verify the complete class definition and eligibility terms before presenting the record as more than a possible match. Present plausible matches as concise lead cards that separate confirmed terms, relevant user context, and facts still needed. If browsing is unavailable, say the terms could not be independently checked, avoid guessing, and direct the user to the official link.
| Name | Required | Description | Default |
|---|---|---|---|
| settlement_id | Yes | Exact settlement identifier returned by a search. |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds valuable context: it instructs verification of official links, presentation format, and handling when browsing is unavailable, enhancing transparency beyond 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 description is front-loaded with the core purpose, followed by detailed but earned usage advice. It is not overly verbose, though the presentation guidance could be slightly trimmed.
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 simple tool (1 param, output schema exists), the description adequately covers verification behavior and presentation. It does not need to explain return values due to output schema, and it addresses edge cases like missing web access.
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 single parameter 'settlement_id' is already well-described in the input schema with 'Exact settlement identifier returned by a search.' The description adds no extra parameter details, and schema coverage is 100%, so 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 'Return one settlement and its official source links,' specifying the verb and resource. It distinguishes from sibling tools like get_settlements (plural) and search_settlements by focusing on a single settlement with source links.
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 guidance on when to verify via web access and how to present results as lead cards. It implies usage when a specific settlement_id is available, though it doesn't explicitly contrast with siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_settlementsGet settlementsARead-onlyIdempotentInspect
Return complete stored records for multiple settlement finalists.
Retrieve every finalist before presenting it. Use the records and official links to separate evidence-backed leads from plausible or speculative leads. A detail record does not itself prove that the user is eligible. If browsing is available, verify the complete class definition on the official source.
| Name | Required | Description | Default |
|---|---|---|---|
| settlement_ids | Yes | Settlement identifiers to retrieve together. Use this for every finalist from a broad scan before composing the final answer. |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds no contradictory or extra behavioral traits; it merely restates the read-only retrieval. With annotations covering safety, the description adds modest context.
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 brief (4 sentences) and front-loaded with the main action. Every sentence serves a clear purpose: defining the operation, providing usage guidance, and emphasizing evidence validation. 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's low complexity (1 parameter, no enums, output schema present), the description fully covers when and why to use it. It explains the role in evidence-backed lead separation, which is sufficient for an agent to decide.
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 documentation for settlement_ids already has a description: 'Settlement identifiers to retrieve together. Use this for every finalist from a broad scan before composing the final answer.' The tool description reinforces this usage, adding value beyond schema fields with clear usage context.
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 retrieves complete stored records for multiple settlement finalists. It distinguishes from siblings like get_settlement (single) and search_settlements (search) by its plural and retrieval focus.
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 instructs to retrieve every finalist before presenting and to use records/official links to separate evidence-backed leads. It implies using this after a broad scan and before final answer, providing clear context, though it does not explicitly exclude alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_settlementsSearch settlementsARead-onlyIdempotentInspect
Search settlement records by keywords and structured filters.
Every keyword is required: the list uses logical AND, not OR. Use separate
searches for unrelated companies, products, or alternative terms. Keywords
should describe companies, products, services, employers, incidents, or
notices. For a broad eligibility scan, think expansively using relevant
context and memory available to the agent and make multiple queries across
plausible brands, aliases, parent companies, subsidiaries, purchases,
providers, fees, incidents, and eligibility-relevant demographic angles such
as age group, occupation, student or veteran status, parent or guardian status,
and housing or household situation. Use the state filter for location. Do not
invent user facts; speculative associations are search candidates only. Status is the
claim lifecycle and defaults to open. Use all only for an intentional search
across non-open lifecycle states too. Use settlement_type, not keywords, when
the term describes the type of settlement rather than a specific entity or event.
Source confidence is returned as objective metadata and quality flags; do not
exclude possible matches using the provider's verification tier. Do not send
names, addresses, account numbers, health details, or other identifying data.
State is a two-letter US postal abbreviation.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum records returned, from 1 to 50. | |
| state | No | Optional two-letter US postal abbreviation, such as CA. | |
| status | No | Claim lifecycle: open, closed, payment, unknown, or all. Defaults to open. Use all only when intentionally including non-open lifecycle states. | open |
| keywords | No | Required AND terms for specific companies, brands, products, employers, or incidents. Do not put a settlement-type label here when settlement_type applies. For broad eligibility scans, make multiple separate searches covering plausible aliases, related brands, parent companies, services, purchases, fees, incidents, and eligibility-relevant demographic angles. | |
| deadline_after | No | Include deadlines on or after this ISO 8601 date. | |
| proof_required | No | Exact proof requirement: yes, no, optional, or unknown. | |
| deadline_before | No | Include deadlines on or before this ISO 8601 date. | |
| settlement_type | No | Exact settlement taxonomy filter. Prefer this over keywords for type concepts such as data breaches, privacy, refunds, financial fees, or consumer products. |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds important behavioral details: keyword AND logic, deadline filtering, state format (two-letter US postal abbreviation), and data privacy warnings. No contradictions.
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 front-loaded with the core action and structured with clear paragraphs. While comprehensive, it is slightly verbose with some repetition (e.g., settlement_type guidance appears in both description and schema). Still, it earns its length.
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 8 parameters with 100% schema coverage, output schema exists, and annotations cover safety, the description is remarkably complete. It includes usage best practices, data privacy warnings, and eligibility scanning strategies, leaving no critical 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 100%, yet the description adds critical meaning beyond schema: keywords AND logic, status default and usage, settlement_type preference, state format, deadline format, and broad scan strategies. This significantly enhances 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 'Search settlement records by keywords and structured filters,' which specifies the verb (search) and resource (settlement records). It distinguishes from siblings like 'get_settlement' (single record) and 'search_settlements_batch' (batch operation) by focusing on standard search with filters.
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 extensive guidance: keywords use AND logic, use separate searches for unrelated terms, prefer settlement_type over keywords for type concepts, default status is 'open', and warns against sending personal data. It lacks explicit comparison to siblings but the context is overwhelmingly clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_settlements_batchSearch settlements in a batchARead-onlyIdempotentInspect
Run multiple independent settlement searches in one tool call.
Prefer this tool for broad eligibility scans and alternative terms. Each
query is evaluated independently. Returned records are deduplicated across
queries and include matched_query_indices that point to the query summaries.
Do not combine unrelated alternatives in one keywords list: keywords within
each query use logical AND, never OR. Speculative associations are search
candidates only, not evidence that the user matches a settlement. Choose
per-query limits based on expected noise and use max_total_results to bound
the unique records placed in model context without reducing search breadth.
For current eligibility scans, omit status or set it to open; do not use all
merely to broaden recall. The response's executed_query_count is the number
of independent searches performed in this call.
| Name | Required | Description | Default |
|---|---|---|---|
| queries | Yes | Independent settlement searches. Use one query object per unrelated company, product, alias, alternative term, or search angle. Keywords inside each object still use logical AND. | |
| max_total_results | No | Maximum unique settlement records returned across the whole batch after cross-query deduplication. This caps output, not the number of independent searches performed. |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint, destructiveHint), the description adds key behaviors: independent query evaluation, deduplication, matched_query_indices, and speculative associations are candidates only. No contradictions.
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 moderately long but well-structured with a clear opening sentence. Each sentence adds value without redundancy, though slightly verbose for the complexity.
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 deduplication, matched_query_indices, executed_query_count, and practical usage constraints. While no output schema is provided, the description compensates by explaining key response elements.
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?
With 100% schema coverage, baseline is 3. The description adds context: explains logical AND within queries, purpose of max_total_results to cap output, and guidance on using queries for unrelated items.
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 runs multiple independent settlement searches in one call. It distinguishes itself from siblings like search_settlements by explicitly mentioning batch capability.
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 when-to-use guidance (broad eligibility scans, alternative terms) and when-not-to (combining unrelated keywords in one query). It also covers best practices for limits, status, and output bounding.
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.
Discussions
No comments yet. Be the first to start the discussion!