RegLayer Instant Decision Briefs

Server Details

Company-specific regulatory assessments for concrete business questions, as structured data or PDF.

If you are the author of this connector, you can claim ownership with GitHub, an HTTP challenge, or a DNS record. Claimed connector authors can inspect health checks, view analytics, and manage their listing.

Status: Healthy
Last Tested: 2026-09-06 15:22
Transport: Streamable HTTP
URL

Available Tools

10 tools

get_check_pdfGet Check PDF URLA

Read-onlyIdempotent

Inspect

Return the authenticated PDF endpoint after the Check is ready.

ParametersJSON Schema

Name	Required	Description	Default
`order_id`	Yes
`access_token`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`ok`	No	Whether the private status request succeeded.
`error`	No	A machine-readable error label when the request cannot be completed.
`notice`	No	The notice that must travel with RegLayer research outputs.
`status`	No	The current order state, such as researching, ready, or failed.
`message`	No	A human-readable status, authentication, or not-ready message.
`pdf_url`	Yes	The authenticated endpoint for downloading the finished PDF.
`product`	No	The purchased Instant Brief product code.
`brief_id`	No	The Decision Brief identifier used in the finished artifact.
`order_id`	No	The private RegLayer order identifier.
`reference`	No	The customer-facing brief reference.
`api_version`	No	The version of the RegLayer agent delivery contract.
`delivery_mode`	No	The asynchronous delivery pattern used for this order.
`authentication`	Yes	The authorization header required to download the PDF.
`poll_after_seconds`	No	Seconds to wait before the next status check, or null when no further polling is needed.
`connection_required`	No	Whether the original connection must remain open.
`delivery_instructions`	No	Instructions for retrieving the result without relying on email.

TDQS

A3.5/5.0

Behavior4/5

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

The annotations already establish the read-only, idempotent, open-world, non-destructive nature. The description adds meaningful context beyond those flags by specifying that the return value is an authenticated PDF endpoint and that readiness is a precondition. There is 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.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single front-loaded sentence with no filler. Every element—'authenticated', 'PDF endpoint', 'after ready'—adds necessary information without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With a rich input schema, strong annotations, and an output schema present, the minimal description covers the core need. The main gap is the absence of guidance for the not-ready case and no explicit statement that both order_id and access_token are required, though the schema supplies that.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

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 for the parameters. It only indirectly alludes to them: 'Check' maps to order_id and 'authenticated' maps to access_token. It does not explain how the parameters are used, the required patterns, or the meaning of the returned endpoint.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb ('Return'), the resource ('PDF endpoint'), and the domain ('Check'), which is enough to tell it apart from the instant-brief siblings. It does not explicitly contrast it with get_check_result or get_check_status, so it stops short of a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

'after the Check is ready' gives an explicit timing condition, implying this tool should only be called once readiness is confirmed. However, there is no guidance on when to prefer this over get_check_result or get_check_status, and no mention of what to do if the Check is not ready.

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

get_check_resultGet structured CheckA

Read-onlyIdempotent

Inspect

Retrieve the structured Check result after status reaches ready.

ParametersJSON Schema

Name	Required	Description	Default
`order_id`	Yes
`access_token`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`ok`	No	Whether the private status request succeeded.
`error`	No	A machine-readable error label when the request cannot be completed.
`notice`	No	The notice that must travel with RegLayer research outputs.
`result`	No	The complete structured Decision Brief when research is ready.
`status`	No	The current order state, such as researching, ready, or failed.
`message`	No	A human-readable status, authentication, or not-ready message.
`product`	No	The purchased Instant Brief product code.
`brief_id`	No	The Decision Brief identifier used in the finished artifact.
`order_id`	No	The private RegLayer order identifier.
`reference`	No	The customer-facing brief reference.
`api_version`	No	The version of the RegLayer agent delivery contract.
`result_kind`	No	The type of structured artifact returned.
`published_at`	No	The timestamp when the result became available.
`delivery_mode`	No	The asynchronous delivery pattern used for this order.
`result_version`	No	The version of the stored structured result.
`poll_after_seconds`	No	Seconds to wait before the next status check, or null when no further polling is needed.
`connection_required`	No	Whether the original connection must remain open.
`delivery_instructions`	No	Instructions for retrieving the result without relying on email.

TDQS

A3.8/5.0

Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, covering the safety profile. The description adds the readiness precondition and the structured nature of the result, but it does not disclose behavior when called before ready or error/response characteristics. 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.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, well-structured sentence with the action front-loaded and the condition appended. Every word contributes meaning, with no redundant or filler content.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The presence of an output schema reduces the need to explain return values, but the description fails to connect to sibling tools like get_check_status or prepare_check_request to clarify parameter provenance and workflow sequencing. It is minimally sufficient but leaves notable gaps for an agent unfamiliar with the tool family.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% and the description never mentions order_id or access_token. The agent must rely solely on parameter names and the pattern/minLength constraints, with no guidance on how to obtain these values or how they relate to prepare_check_request. The description does not compensate for the schema gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Retrieve') and a specific resource ('structured Check result'), and the qualifier 'structured' distinguishes it from siblings like get_check_pdf and get_check_status. The phrase 'after status reaches ready' adds a precise precondition, making the tool's purpose immediately clear.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear usage context by stating the result should only be retrieved after status reaches ready, implicitly guiding the agent to check status first. However, it does not explicitly name alternatives such as get_check_status or get_check_pdf, nor does it state when not to use this tool.

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

get_check_statusGet Check statusB

Read-onlyIdempotent

Inspect

Read private Check status.

ParametersJSON Schema

Name	Required	Description	Default
`order_id`	Yes
`access_token`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`ok`	No	Whether the private status request succeeded.
`error`	No	A machine-readable error label when the request cannot be completed.
`notice`	No	The notice that must travel with RegLayer research outputs.
`status`	No	The current order state, such as researching, ready, or failed.
`message`	No	A human-readable status, authentication, or not-ready message.
`product`	No	The purchased Instant Brief product code.
`brief_id`	No	The Decision Brief identifier used in the finished artifact.
`order_id`	No	The private RegLayer order identifier.
`reference`	No	The customer-facing brief reference.
`api_version`	No	The version of the RegLayer agent delivery contract.
`delivery_mode`	No	The asynchronous delivery pattern used for this order.
`poll_after_seconds`	No	Seconds to wait before the next status check, or null when no further polling is needed.
`connection_required`	No	Whether the original connection must remain open.
`delivery_instructions`	No	Instructions for retrieving the result without relying on email.

TDQS

B3/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true, and destructiveHint=false. The description's 'Read' is consistent with those annotations and adds a small hint of access control via 'private,' but it does not disclose anything further about response behavior or limitations. No contradiction exists.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is one short, front-loaded sentence with no wasted words. It is appropriately concise for a simple read tool, though it is terse enough that it omits usage context and sibling differentiation.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple two-parameter read operation with a rich output schema and strong safety annotations, the description is minimally viable. However, the sibling list includes get_check_result and get_instant_brief_status, and the description does not clarify where Check status fits or when to choose it, leaving a completeness gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, and the description adds no real meaning for order_id or access_token. The word 'private' weakly signals access_token's purpose, but order_id semantics are left entirely to the schema's name and pattern, so the description does not compensate for the coverage gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states the operation ('Read') and the resource ('Check status'), so an agent can tell it is a status-retrieval tool. It is clear but minimal: it does not explicitly differentiate itself from sibling tools like get_check_result or get_instant_brief_status, relying on the word 'status' to carry that distinction.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no guidance about when to use this tool versus alternatives such as get_check_result or get_check_pdf. The description does not mention exclusions, prerequisites, or a preferred selection context, so an agent must infer usage from the name and schema alone.

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

get_instant_brief_pdfGet Instant Brief PDF URLA

Read-onlyIdempotent

Inspect

Return the authenticated PDF endpoint after status reaches ready. Use the same bearer token when downloading it.

ParametersJSON Schema

Name	Required	Description	Default
`order_id`	Yes	The order_id returned by the paid Instant Brief purchase request.
`access_token`	Yes	The private RegLayer access token returned with the order. Send it only to RegLayer and never expose it to the end user.

Output Schema

ParametersJSON Schema

Name	Required	Description
`ok`	No	Whether the private status request succeeded.
`error`	No	A machine-readable error label when the request cannot be completed.
`notice`	No	The notice that must travel with RegLayer research outputs.
`status`	No	The current order state, such as researching, ready, or failed.
`message`	No	A human-readable status, authentication, or not-ready message.
`pdf_url`	Yes	The authenticated endpoint for downloading the finished PDF.
`product`	No	The purchased Instant Brief product code.
`brief_id`	No	The Decision Brief identifier used in the finished artifact.
`order_id`	No	The private RegLayer order identifier.
`reference`	No	The customer-facing brief reference.
`api_version`	No	The version of the RegLayer agent delivery contract.
`delivery_mode`	No	The asynchronous delivery pattern used for this order.
`authentication`	Yes	The authorization header required to download the PDF.
`poll_after_seconds`	No	Seconds to wait before the next status check, or null when no further polling is needed.
`connection_required`	No	Whether the original connection must remain open.
`delivery_instructions`	No	Instructions for retrieving the result without relying on email.

TDQS

A4.3/5.0

Behavior4/5

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

With annotations already declaring readOnlyHint and idempotentHint, the description adds valuable context: the returned endpoint is authenticated and requires the same bearer token when downloading. This clarifies auth behavior beyond the structured data.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, front-loaded with the primary purpose, and contains no redundant information. Every word contributes to the tool's understanding.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple tool with two well-documented parameters and an output schema, the description covers purpose, precondition, and auth requirements. It is fully sufficient for an agent to use the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the parameters are already well-documented. The description doesn't add extra semantics for order_id or access_token beyond what the schema provides, warranting the baseline score of 3.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Return') and resource ('authenticated PDF endpoint'), with a clear condition ('after status reaches ready'). This distinguishes it from sibling tools like get_instant_brief_status or get_instant_brief_result.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides a clear usage context by stating the tool should be used after status reaches ready, implying a sequencing with status checks. It doesn't explicitly name alternatives or exclusions, 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.

get_instant_brief_resultGet structured Instant BriefA

Read-onlyIdempotent

Inspect

Read the structured result after status reaches ready. If still researching, close the call and retry after 20 seconds.

ParametersJSON Schema

Name	Required	Description	Default
`order_id`	Yes	The order_id returned by the paid Instant Brief purchase request.
`access_token`	Yes	The private RegLayer access token returned with the order. Send it only to RegLayer and never expose it to the end user.

Output Schema

ParametersJSON Schema

Name	Required	Description
`ok`	No	Whether the private status request succeeded.
`error`	No	A machine-readable error label when the request cannot be completed.
`notice`	No	The notice that must travel with RegLayer research outputs.
`result`	No	The complete structured Decision Brief when research is ready.
`status`	No	The current order state, such as researching, ready, or failed.
`message`	No	A human-readable status, authentication, or not-ready message.
`product`	No	The purchased Instant Brief product code.
`brief_id`	No	The Decision Brief identifier used in the finished artifact.
`order_id`	No	The private RegLayer order identifier.
`reference`	No	The customer-facing brief reference.
`api_version`	No	The version of the RegLayer agent delivery contract.
`result_kind`	No	The type of structured artifact returned.
`published_at`	No	The timestamp when the result became available.
`delivery_mode`	No	The asynchronous delivery pattern used for this order.
`result_version`	No	The version of the stored structured result.
`poll_after_seconds`	No	Seconds to wait before the next status check, or null when no further polling is needed.
`connection_required`	No	Whether the original connection must remain open.
`delivery_instructions`	No	Instructions for retrieving the result without relying on email.

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already convey readOnly, idempotent, and non-destructive behavior. The description adds the retry condition and the 'still researching' state, which is valuable context beyond the annotations. 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.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a concise two-sentence statement that directly states the purpose and the retry instruction without any fluff. It is front-loaded and effective.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With a comprehensive input schema, an output schema available, annotations covering safety, and a description that includes when to use and retry, the tool is fully contextualized. The sibling tools further clarify differentiation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema provides full descriptions for both parameters (order_id and access_token) at 100% coverage, so the description does not need to add detail. It contributes no additional parameter semantics, but the baseline is 3 given complete schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Read') and the resource ('structured result' of an Instant Brief) and specifies a prerequisite condition ('after status reaches ready'). It is distinct from siblings like get_instant_brief_pdf (likely PDF) and get_instant_brief_status (likely status only).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear timing guidance for when to call (after status ready) and includes a retry instruction ('close the call and retry after 20 seconds'). It does not explicitly name alternative tools for when not to use it, but the sibling context makes the intended usage obvious.

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

get_instant_brief_statusGet Instant Brief statusA

Read-onlyIdempotent

Inspect

Read private order status. If status is researching, close the call and invoke this tool again after 20 seconds.

ParametersJSON Schema

Name	Required	Description	Default
`order_id`	Yes	The order_id returned by the paid Instant Brief purchase request.
`access_token`	Yes	The private RegLayer access token returned with the order. Send it only to RegLayer and never expose it to the end user.

Output Schema

ParametersJSON Schema

Name	Required	Description
`ok`	No	Whether the private status request succeeded.
`error`	No	A machine-readable error label when the request cannot be completed.
`notice`	No	The notice that must travel with RegLayer research outputs.
`status`	No	The current order state, such as researching, ready, or failed.
`message`	No	A human-readable status, authentication, or not-ready message.
`product`	No	The purchased Instant Brief product code.
`brief_id`	No	The Decision Brief identifier used in the finished artifact.
`order_id`	No	The private RegLayer order identifier.
`reference`	No	The customer-facing brief reference.
`api_version`	No	The version of the RegLayer agent delivery contract.
`delivery_mode`	No	The asynchronous delivery pattern used for this order.
`poll_after_seconds`	No	Seconds to wait before the next status check, or null when no further polling is needed.
`connection_required`	No	Whether the original connection must remain open.
`delivery_instructions`	No	Instructions for retrieving the result without relying on email.

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already declare read-only and idempotent behavior, and the description adds a specific polling behavior (retry after 20 seconds) not present in the annotations. It also reinforces the 'private' nature of the status, which is relevant for token handling. No contradictions found.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, front-loaded with the core purpose and then the key retry rule. No fluff, every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple status-check tool with full parameter schema and an output schema (not shown but indicated), the description covers the essential purpose and a critical behavioral nuance. No significant gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema description coverage is 100%, with both parameters fully described. The tool description adds no extra parameter meaning; it only implies the access token is needed for private access, which is already in the schema. Baseline of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action is to read the private order status, which distinguishes it from sibling tools like get_instant_brief_result and get_instant_brief_pdf. It also mentions a specific status ('researching'), adding useful context beyond a generic 'get status'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides a clear retry instruction when status is 'researching' (close the call and invoke after 20 seconds), which guides the agent's polling behavior. It does not explicitly contrast with alternatives, but the tool's purpose is obvious from context and sibling names.

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

list_instant_brief_productsList RegLayer Instant BriefsA

Read-onlyIdempotent

Inspect

List the Instant Brief available to agents.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`notice`	Yes	The notice that must travel with RegLayer research outputs.
`products`	Yes	The Instant Brief products currently available to agents.
`delivery_mode`	Yes	The delivery pattern used after payment.
`payment_protocol`	Yes	The machine-payment protocol used at the purchase endpoint.
`purchase_endpoint`	Yes	The REST endpoint that accepts the paid brief request.
`poll_after_seconds`	Yes	The recommended interval between private status checks.
`connection_required`	Yes	Whether the purchase connection must remain open while research runs.
`delivery_instructions`	Yes	Instructions for storing credentials, polling, and retrieving the finished brief.

TDQS

A4/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is clear. The description adds the 'available to agents' scope, which is useful context about the returned subset, but beyond that it discloses no additional behavioral traits such as pagination or ordering.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single short sentence of eight words, front-loaded with the action and resource. Every word earns its place, with no redundancy or unnecessary detail.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a no-parameter, read-only listing tool with an output schema and clear annotations, the description is sufficiently complete. It doesn't mention edge cases or error conditions, but those are not expected for a simple list operation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, so the baseline per the rubric is 4. There is no parameter ambiguity to resolve, and the description does not need to explain any parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool lists available Instant Briefs for agents, using the verb 'List' and specifying the resource 'Instant Brief'. It distinguishes from sibling tools like get_instant_brief_pdf or prepare_instant_brief_request by being a simple listing operation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for discovering which Instant Briefs are available to the agent, but does not explicitly state when to use it versus alternatives like prepare_instant_brief_request. No exclusions or alternative references are provided, so the guidance is only implicit.

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

list_reglayer_productsList RegLayer agent productsA

Read-onlyIdempotent

Inspect

List the regulatory research products available to agents. Use an Instant Brief for a question and Check for supplied working materials.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`ok`	Yes

TDQS

A3.8/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds scope ('available to agents') and product-type semantics, but it does not disclose additional behavior such as auth requirements, rate limits, or what the response contains. 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.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences with no filler. The first sentence front-loads the action and resource, and the second adds compact, relevant guidance about the product types. Every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

This is a simple, zero-parameter listing tool with a rich set of annotations and an output schema present. The description explains what is listed, the agent-facing scope, and the distinction between the two product types it covers. Nothing critical is missing for an agent to call it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, so the baseline is 4. There are no parameter descriptions needed, and the schema fully covers the empty parameter set.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb and resource: 'List the regulatory research products available to agents.' It clearly identifies what the tool returns and distinguishes the two product categories by mentioning 'Instant Brief' and 'Check.' However, it does not explicitly contrast itself with the sibling 'list_instant_brief_products,' so sibling differentiation is only implicit.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The second sentence provides useful context: 'Use an Instant Brief for a question and Check for supplied working materials.' This helps an agent decide between product types, but it does not explicitly state when to call this tool versus alternatives such as list_instant_brief_products, nor does it mention any exclusions.

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

prepare_check_requestPrepare a Check purchaseA

Read-onlyIdempotent

Inspect

Return the paid REST request shape for screening one or two supplied materials. The agent price is $0.99.

ParametersJSON Schema

Name	Required	Description	Default
`material_count`	Yes
`total_characters`	Yes	Combined readable-text character count after extracting the supplied materials.

Output Schema

ParametersJSON Schema

Name	Required	Description
`ok`	Yes

TDQS

A4/5.0

Behavior4/5

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

Annotations already establish read-only, idempotent, and non-destructive behavior. The description adds meaningful context beyond those annotations: the operation is paid ($0.99) and returns only a request shape rather than executing the screening. This is useful behavioral disclosure.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences with no filler. The core behavior is front-loaded, and the price detail is relevant and succinctly placed.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple two-parameter, read-only, idempotent tool with an output schema, the description is nearly complete: it gives purpose, material-count limit, and cost. It could more explicitly distinguish itself from prepare_instant_brief_request, but the title and sibling context reduce that gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema describes total_characters well, and the description's 'one or two supplied materials' partially conveys material_count's meaning. With only 50% schema coverage, the description compensates somewhat but leaves the exact relationship between the supplied materials and the two numeric parameters implicit.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly identifies the verb (Return), the resource (paid REST request shape for screening), and the scope (one or two supplied materials). It distinguishes itself from the get_* sibling tools, which fetch PDFs/results rather than preparing a request.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies use when preparing a check-screening request for one or two materials, and the title separates it from prepare_instant_brief_request. However, it does not explicitly state when not to use this tool or name a preferred alternative.

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

prepare_instant_brief_requestPrepare a RegLayer brief purchaseA

Read-onlyIdempotent

Inspect

Validate the scope and return the REST purchase shape. Payment occurs through HTTP 402 on the REST endpoint.

ParametersJSON Schema

Name	Required	Description	Default
`product`	Yes	The RegLayer Instant Brief product code.
`jurisdictions`	Yes	The distinct regulatory geographies the Decision Brief should cover.

Output Schema

ParametersJSON Schema

Name	Required	Description
`error`	Yes	A scope correction message, or null when the request is valid.
`price`	Yes	The selected product, price, and geographic limits.
`valid`	Yes	Whether the selected product and jurisdictions form a valid purchasable scope.
`notice`	Yes	The notice that must travel with RegLayer research outputs.
`product`	Yes	The RegLayer Instant Brief product code.
`endpoint`	Yes	The REST endpoint to call to create and pay for the brief.
`after_payment`	Yes	What the agent must do after payment succeeds.
`jurisdictions`	Yes	The normalized scope supplied for validation.
`required_headers`	Yes	HTTP headers required by the purchase endpoint.
`required_body_fields`	Yes	Fields that must be present in the purchase request body.

TDQS

A3.6/5.0

Behavior3/5

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

Annotations already declare readOnlyHint and idempotentHint, so the operation is known to be safe. The description adds context about payment occurring via HTTP 402 on the REST endpoint, which clarifies the flow without contradicting annotations. However, it doesn't elaborate on validation specifics or 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.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences with no unnecessary words. Purpose is front-loaded, and the behavioral note about payment is placed effectively.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the two parameters, output schema, and annotations, the description is adequate. It clearly states the action and a key behavioral aspect (payment via 402), though it could mention what validation entails or typical constraints.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema provides full documentation for both parameters (product and jurisdictions) with descriptions, so the description doesn't need to add param details. 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.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states it validates scope and returns a REST purchase shape, distinguishing it from sibling tools that fetch PDFs/results/status or list products. The title reinforces the purchase preparation purpose, though 'scope' could be more specific.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance on when to use this vs alternatives. The description implies it's a preparatory step before a purchase, and mentions HTTP 402 on the REST endpoint, but doesn't explicitly state the usage flow or exclusions. Siblings are distinct, so usage is somewhat implied.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

5 tool updatesAug 26, 2026
- Addedget_check_pdf
- Addedget_check_result
- Addedget_check_status
- Addedlist_reglayer_products
- Addedprepare_check_request

5 tool updatesAug 19, 2026

Changedget_instant_brief_pdf2 fields changed

changedInput schema / properties / order_id / description

Previous value: -"The order_id returned by the paid Instant Decision Brief purchase request."New value: +"The order_id returned by the paid Instant Brief purchase request."

changedOutput schema / properties / product / description

Previous value: -"The purchased Instant Decision Brief product code."New value: +"The purchased Instant Brief product code."

Changedget_instant_brief_result2 fields changed

changedInput schema / properties / order_id / description

Previous value: -"The order_id returned by the paid Instant Decision Brief purchase request."New value: +"The order_id returned by the paid Instant Brief purchase request."

changedOutput schema / properties / product / description

Previous value: -"The purchased Instant Decision Brief product code."New value: +"The purchased Instant Brief product code."

Changedget_instant_brief_status2 fields changed

changedInput schema / properties / order_id / description

Previous value: -"The order_id returned by the paid Instant Decision Brief purchase request."New value: +"The order_id returned by the paid Instant Brief purchase request."

changedOutput schema / properties / product / description

Previous value: -"The purchased Instant Decision Brief product code."New value: +"The purchased Instant Brief product code."

Changedlist_instant_brief_products2 fields changed

changedOutput schema / properties / products / description

Previous value: -"The Instant Decision Brief products currently available to agents."New value: +"The Instant Brief products currently available to agents."

changedOutput schema / properties / products / items / properties / code / description

Previous value: -"The RegLayer Instant Decision Brief product code."New value: +"The RegLayer Instant Brief product code."

Changedprepare_instant_brief_request3 fields changed

changedInput schema / properties / product / description

Previous value: -"The RegLayer Instant Decision Brief product code."New value: +"The RegLayer Instant Brief product code."

changedOutput schema / properties / price / properties / code / description

Previous value: -"The RegLayer Instant Decision Brief product code."New value: +"The RegLayer Instant Brief product code."

changedOutput schema / properties / product / description

Previous value: -"The RegLayer Instant Decision Brief product code."New value: +"The RegLayer Instant Brief product code."

2 tool updatesAug 19, 2026

Changedlist_instant_brief_products3 fields changed

addedOutput schema / properties / products / items / properties / code / const
```
Added value: +"instant_brief"
```

changedOutput schema / properties / products / items / properties / code / description

Previous value: -"The RegLayer Instant Decision Brief product code: instant_one for exactly one jurisdiction, or instant_three for two or three jurisdictions."New value: +"The RegLayer Instant Decision Brief product code."

removedOutput schema / properties / products / items / properties / code / enum
```
Removed value: -[
-  "instant_one",
-  "instant_three"
-]
```

Changedprepare_instant_brief_request9 fields changed

addedInput schema / properties / product / const
```
Added value: +"instant_brief"
```

changedInput schema / properties / product / description

Previous value: -"The RegLayer Instant Decision Brief product code: instant_one for exactly one jurisdiction, or instant_three for two or three jurisdictions."New value: +"The RegLayer Instant Decision Brief product code."

removedInput schema / properties / product / enum

Removed value: -[
-  "instant_one",
-  "instant_three"
-]

addedOutput schema / properties / price / properties / code / const
```
Added value: +"instant_brief"
```

changedOutput schema / properties / price / properties / code / description

Previous value: -"The RegLayer Instant Decision Brief product code: instant_one for exactly one jurisdiction, or instant_three for two or three jurisdictions."New value: +"The RegLayer Instant Decision Brief product code."

removedOutput schema / properties / price / properties / code / enum
```
Removed value: -[
-  "instant_one",
-  "instant_three"
-]
```
addedOutput schema / properties / product / const
```
Added value: +"instant_brief"
```

changedOutput schema / properties / product / description

Previous value: -"The RegLayer Instant Decision Brief product code: instant_one for exactly one jurisdiction, or instant_three for two or three jurisdictions."New value: +"The RegLayer Instant Decision Brief product code."

removedOutput schema / properties / product / enum

Removed value: -[
-  "instant_one",
-  "instant_three"
-]

5 tool updatesAug 17, 2026

Changedget_instant_brief_pdf3 fields changed

addedInput schema / properties / access_token / description

Added value: +"The private RegLayer access token returned with the order. Send it only to RegLayer and never expose it to the end user."

addedInput schema / properties / order_id / description

Added value: +"The order_id returned by the paid Instant Decision Brief purchase request."

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "https://json-schema.org/draft/2020-12/schema",
+  "additionalProperties": {},
+  "properties": {
+    "api_version": {
+      "description": "The version of the RegLayer agent delivery contract.",
+      "type": "string"
+    },
+    "authentication": {
+      "description": "The authorization header required to download the PDF.",
+      "type": "string"
+    },
+    "brief_id": {
+      "description": "The Decision Brief identifier used in the finished artifact.",
+      "type": "string"
+    },
+    "connection_required": {
+      "description": "Whether the original connection must remain open.",
+      "type": "boolean"
+    },
+    "delivery_instructions": {
+      "description": "Instructions for retrieving the result without relying on email.",
+      "type": "string"
+    },
+    "delivery_mode": {
+      "description": "The asynchronous delivery pattern used for this order.",
+      "type": "string"
+    },
+    "error": {
+      "description": "A machine-readable error label when the request cannot be completed.",
+      "type": "string"
+    },
+    "message": {
+      "description": "A human-readable status, authentication, or not-ready message.",
+      "type": "string"
+    },
+    "notice": {
+      "description": "The notice that must travel with RegLayer research outputs.",
+      "type": "string"
+    },
+    "ok": {
+      "description": "Whether the private status request succeeded.",
+      "type": "boolean"
+    },
+    "order_id": {
+      "description": "The private RegLayer order identifier.",
+      "type": "string"
+    },
+    "pdf_url": {
+      "description": "The authenticated endpoint for downloading the finished PDF.",
+      "format": "uri",
+      "type": "string"
+    },
+    "poll_after_seconds": {
+      "anyOf": [
+        {
+          "maximum": 9007199254740991,
+          "minimum": -9007199254740991,
+          "type": "integer"
+        },
+        {
+          "type": "null"
+        }
+      ],
+      "description": "Seconds to wait before the next status check, or null when no further polling is needed."
+    },
+    "product": {
+      "description": "The purchased Instant Decision Brief product code.",
+      "type": "string"
+    },
+    "reference": {
+      "description": "The customer-facing brief reference.",
+      "type": "string"
+    },
+    "status": {
+      "description": "The current order state, such as researching, ready, or failed.",
+      "type": "string"
+    }
+  },
+  "required": [
+    "pdf_url",
+    "authentication"
+  ],
+  "type": "object"
+}

Changedget_instant_brief_result3 fields changed

addedInput schema / properties / access_token / description

Added value: +"The private RegLayer access token returned with the order. Send it only to RegLayer and never expose it to the end user."

addedInput schema / properties / order_id / description

Added value: +"The order_id returned by the paid Instant Decision Brief purchase request."

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "https://json-schema.org/draft/2020-12/schema",
+  "additionalProperties": {},
+  "properties": {
+    "api_version": {
+      "description": "The version of the RegLayer agent delivery contract.",
+      "type": "string"
+    },
+    "brief_id": {
+      "description": "The Decision Brief identifier used in the finished artifact.",
+      "type": "string"
+    },
+    "connection_required": {
+      "description": "Whether the original connection must remain open.",
+      "type": "boolean"
+    },
+    "delivery_instructions": {
+      "description": "Instructions for retrieving the result without relying on email.",
+      "type": "string"
+    },
+    "delivery_mode": {
+      "description": "The asynchronous delivery pattern used for this order.",
+      "type": "string"
+    },
+    "error": {
+      "description": "A machine-readable error label when the request cannot be completed.",
+      "type": "string"
+    },
+    "message": {
+      "description": "A human-readable status, authentication, or not-ready message.",
+      "type": "string"
+    },
+    "notice": {
+      "description": "The notice that must travel with RegLayer research outputs.",
+      "type": "string"
+    },
+    "ok": {
+      "description": "Whether the private status request succeeded.",
+      "type": "boolean"
+    },
+    "order_id": {
+      "description": "The private RegLayer order identifier.",
+      "type": "string"
+    },
+    "poll_after_seconds": {
+      "anyOf": [
+        {
+          "maximum": 9007199254740991,
+          "minimum": -9007199254740991,
+          "type": "integer"
+        },
+        {
+          "type": "null"
+        }
+      ],
+      "description": "Seconds to wait before the next status check, or null when no further polling is needed."
+    },
+    "product": {
+      "description": "The purchased Instant Decision Brief product code.",
+      "type": "string"
+    },
+    "published_at": {
+      "description": "The timestamp when the result became available.",
+      "type": "string"
+    },
+    "reference": {
+      "description": "The customer-facing brief reference.",
+      "type": "string"
+    },
+    "result": {
+      "additionalProperties": {},
+      "description": "The complete structured Decision Brief when research is ready.",
+      "propertyNames": {
+        "type": "string"
+      },
+      "type": "object"
+    },
+    "result_kind": {
+      "description": "The type of structured artifact returned.",
+      "type": "string"
+    },
+    "result_version": {
+      "anyOf": [
+        {
+          "type": "string"
+        },
+        {
+          "type": "number"
+        }
+      ],
+      "description": "The version of the stored structured result."
+    },
+    "status": {
+      "description": "The current order state, such as researching, ready, or failed.",
+      "type": "string"
+    }
+  },
+  "type": "object"
+}

Changedget_instant_brief_status3 fields changed

addedInput schema / properties / access_token / description

Added value: +"The private RegLayer access token returned with the order. Send it only to RegLayer and never expose it to the end user."

addedInput schema / properties / order_id / description

Added value: +"The order_id returned by the paid Instant Decision Brief purchase request."

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "https://json-schema.org/draft/2020-12/schema",
+  "additionalProperties": {},
+  "properties": {
+    "api_version": {
+      "description": "The version of the RegLayer agent delivery contract.",
+      "type": "string"
+    },
+    "brief_id": {
+      "description": "The Decision Brief identifier used in the finished artifact.",
+      "type": "string"
+    },
+    "connection_required": {
+      "description": "Whether the original connection must remain open.",
+      "type": "boolean"
+    },
+    "delivery_instructions": {
+      "description": "Instructions for retrieving the result without relying on email.",
+      "type": "string"
+    },
+    "delivery_mode": {
+      "description": "The asynchronous delivery pattern used for this order.",
+      "type": "string"
+    },
+    "error": {
+      "description": "A machine-readable error label when the request cannot be completed.",
+      "type": "string"
+    },
+    "message": {
+      "description": "A human-readable status, authentication, or not-ready message.",
+      "type": "string"
+    },
+    "notice": {
+      "description": "The notice that must travel with RegLayer research outputs.",
+      "type": "string"
+    },
+    "ok": {
+      "description": "Whether the private status request succeeded.",
+      "type": "boolean"
+    },
+    "order_id": {
+      "description": "The private RegLayer order identifier.",
+      "type": "string"
+    },
+    "poll_after_seconds": {
+      "anyOf": [
+        {
+          "maximum": 9007199254740991,
+          "minimum": -9007199254740991,
+          "type": "integer"
+        },
+        {
+          "type": "null"
+        }
+      ],
+      "description": "Seconds to wait before the next status check, or null when no further polling is needed."
+    },
+    "product": {
+      "description": "The purchased Instant Decision Brief product code.",
+      "type": "string"
+    },
+    "reference": {
+      "description": "The customer-facing brief reference.",
+      "type": "string"
+    },
+    "status": {
+      "description": "The current order state, such as researching, ready, or failed.",
+      "type": "string"
+    }
+  },
+  "type": "object"
+}

Changedlist_instant_brief_products1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "https://json-schema.org/draft/2020-12/schema",
+  "additionalProperties": false,
+  "properties": {
+    "connection_required": {
+      "description": "Whether the purchase connection must remain open while research runs.",
+      "type": "boolean"
+    },
+    "delivery_instructions": {
+      "description": "Instructions for storing credentials, polling, and retrieving the finished brief.",
+      "type": "string"
+    },
+    "delivery_mode": {
+      "const": "asynchronous_polling",
+      "description": "The delivery pattern used after payment.",
+      "type": "string"
+    },
+    "notice": {
+      "description": "The notice that must travel with RegLayer research outputs.",
+      "type": "string"
+    },
+    "payment_protocol": {
+      "description": "The machine-payment protocol used at the purchase endpoint.",
+      "type": "string"
+    },
+    "poll_after_seconds": {
+      "description": "The recommended interval between private status checks.",
+      "exclusiveMinimum": 0,
+      "maximum": 9007199254740991,
+      "type": "integer"
+    },
+    "products": {
+      "description": "The Instant Decision Brief products currently available to agents.",
+      "items": {
+        "additionalProperties": false,
+        "properties": {
+          "amount_cents": {
+            "description": "The purchase price in the smallest currency unit, currently US cents.",
+            "maximum": 9007199254740991,
+            "minimum": 0,
+            "type": "integer"
+          },
+          "code": {
+            "description": "The RegLayer Instant Decision Brief product code: instant_one for exactly one jurisdiction, or instant_three for two or three jurisdictions.",
+            "enum": [
+              "instant_one",
+              "instant_three"
+            ],
+            "type": "string"
+          },
+          "currency": {
+            "description": "The lowercase ISO 4217 currency code used for payment.",
+            "type": "string"
+          },
+          "delivery": {
+            "description": "How the finished brief is delivered and its normal completion window.",
+            "type": "string"
+          },
+          "max_jurisdictions": {
+            "description": "The maximum number of distinct jurisdictions accepted for this product.",
+            "exclusiveMinimum": 0,
+            "maximum": 9007199254740991,
+            "type": "integer"
+          },
+          "min_jurisdictions": {
+            "description": "The minimum number of distinct jurisdictions accepted for this product.",
+            "maximum": 9007199254740991,
+            "minimum": 0,
+            "type": "integer"
+          },
+          "name": {
+            "description": "The customer-facing name of the brief product.",
+            "type": "string"
+          }
+        },
+        "required": [
+          "code",
+          "name",
+          "amount_cents",
+          "currency",
+          "min_jurisdictions",
+          "max_jurisdictions",
+          "delivery"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "purchase_endpoint": {
+      "description": "The REST endpoint that accepts the paid brief request.",
+      "format": "uri",
+      "type": "string"
+    }
+  },
+  "required": [
+    "products",
+    "purchase_endpoint",
+    "payment_protocol",
+    "delivery_mode",
+    "connection_required",
+    "poll_after_seconds",
+    "delivery_instructions",
+    "notice"
+  ],
+  "type": "object"
+}

Changedprepare_instant_brief_request4 fields changed

addedInput schema / properties / jurisdictions / description

Added value: +"The distinct regulatory geographies the Decision Brief should cover."

addedInput schema / properties / jurisdictions / items / description

Added value: +"A country, US state, or other regulatory geography to cover, written as a clear human-readable name."

addedInput schema / properties / product / description

Added value: +"The RegLayer Instant Decision Brief product code: instant_one for exactly one jurisdiction, or instant_three for two or three jurisdictions."

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "https://json-schema.org/draft/2020-12/schema",
+  "additionalProperties": false,
+  "properties": {
+    "after_payment": {
+      "additionalProperties": false,
+      "description": "What the agent must do after payment succeeds.",
+      "properties": {
+        "connection_required": {
+          "description": "Whether the agent must keep the original request connection open while research runs.",
+          "type": "boolean"
+        },
+        "instruction": {
+          "description": "The complete asynchronous retrieval instructions for the agent.",
+          "type": "string"
+        },
+        "poll_after_seconds": {
+          "description": "How long the agent should wait between private status checks.",
+          "exclusiveMinimum": 0,
+          "maximum": 9007199254740991,
+          "type": "integer"
+        }
+      },
+      "required": [
+        "connection_required",
+        "poll_after_seconds",
+        "instruction"
+      ],
+      "type": "object"
+    },
+    "endpoint": {
+      "description": "The REST endpoint to call to create and pay for the brief.",
+      "format": "uri",
+      "type": "string"
+    },
+    "error": {
+      "anyOf": [
+        {
+          "type": "string"
+        },
+        {
+          "type": "null"
+        }
+      ],
+      "description": "A scope correction message, or null when the request is valid."
+    },
+    "jurisdictions": {
+      "description": "The normalized scope supplied for validation.",
+      "items": {
+        "description": "A country, US state, or other regulatory geography to cover, written as a clear human-readable name.",
+        "minLength": 1,
+        "type": "string"
+      },
+      "type": "array"
+    },
+    "notice": {
+      "description": "The notice that must travel with RegLayer research outputs.",
+      "type": "string"
+    },
+    "price": {
+      "additionalProperties": false,
+      "description": "The selected product, price, and geographic limits.",
+      "properties": {
+        "amount_cents": {
+          "description": "The purchase price in the smallest currency unit, currently US cents.",
+          "maximum": 9007199254740991,
+          "minimum": 0,
+          "type": "integer"
+        },
+        "code": {
+          "description": "The RegLayer Instant Decision Brief product code: instant_one for exactly one jurisdiction, or instant_three for two or three jurisdictions.",
+          "enum": [
+            "instant_one",
+            "instant_three"
+          ],
+          "type": "string"
+        },
+        "currency": {
+          "description": "The lowercase ISO 4217 currency code used for payment.",
+          "type": "string"
+        },
+        "delivery": {
+          "description": "How the finished brief is delivered and its normal completion window.",
+          "type": "string"
+        },
+        "max_jurisdictions": {
+          "description": "The maximum number of distinct jurisdictions accepted for this product.",
+          "exclusiveMinimum": 0,
+          "maximum": 9007199254740991,
+          "type": "integer"
+        },
+        "min_jurisdictions": {
+          "description": "The minimum number of distinct jurisdictions accepted for this product.",
+          "maximum": 9007199254740991,
+          "minimum": 0,
+          "type": "integer"
+        },
+        "name": {
+          "description": "The customer-facing name of the brief product.",
+          "type": "string"
+        }
+      },
+      "required": [
+        "code",
+        "name",
+        "amount_cents",
+        "currency",
+        "min_jurisdictions",
+        "max_jurisdictions",
+        "delivery"
+      ],
+      "type": "object"
+    },
+    "product": {
+      "description": "The RegLayer Instant Decision Brief product code: instant_one for exactly one jurisdiction, or instant_three for two or three jurisdictions.",
+      "enum": [
+        "instant_one",
+        "instant_three"
+      ],
+      "type": "string"
+    },
+    "required_body_fields": {
+      "description": "Fields that must be present in the purchase request body.",
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    "required_headers": {
+      "additionalProperties": false,
+      "description": "HTTP headers required by the purchase endpoint.",
+      "properties": {
+        "Content-Type": {
+          "description": "The required request content type.",
+          "type": "string"
+        },
+        "Idempotency-Key": {
+          "description": "A unique stable value that makes purchase retries safe.",
+          "type": "string"
+        }
+      },
+      "required": [
+        "Content-Type",
+        "Idempotency-Key"
+      ],
+      "type": "object"
+    },
+    "valid": {
+      "description": "Whether the selected product and jurisdictions form a valid purchasable scope.",
+      "type": "boolean"
+    }
+  },
+  "required": [
+    "valid",
+    "product",
+    "jurisdictions",
+    "price",
+    "error",
+    "endpoint",
+    "required_headers",
+    "required_body_fields",
+    "after_payment",
+    "notice"
+  ],
+  "type": "object"
+}

5 tool updatesAug 17, 2026
- First observedget_instant_brief_pdf
- First observedget_instant_brief_result
- First observedget_instant_brief_status
- First observedlist_instant_brief_products
- First observedprepare_instant_brief_request

Frequently Asked Questions

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

Discussions

No comments yet. Be the first to start the discussion!

Related MCP Connectors

Obsidian Regulatory MCPOAuth
io.github.richbile
Verified, tier-0 regulatory data for AI across 850+ official sources and 50+ jurisdictions.
Legal & Compliance Government Data Open Data
2
ampel B
io.tooloracle
AmpelOracle — 50-tool compliance traffic-light: Go/Caution/Stop signals for ESG, MiCA, AML.
Legal & Compliance Finance Cryptocurrency
502
Hackford MCPOAuth
com.hackforddata
Regulated-firm intelligence for FCA and SEC search, enrichment, relationships and saved workflows.
Finance Legal & Compliance Government Data
1
Judikatura MCP — Slovak Court Decisions
io.github.adakov589
Slovak court decisions as MCP tools. 12,000+ decisions, GDPR-compliant, pseudonymized, SLA-backed.
Legal & Compliance Government Data
2

Related MCP Servers

Obsidian Regulatory MCP
Legal & Compliance Research & Data Search
richbile
A
license
Not graded
quality
B
maintenance
Provides AI assistants with verified regulatory data from 850+ official sources across 50+ jurisdictions, enabling accurate compliance research.
Updated 3 months ago (2026-06-18 08:51 UTC)
MIT
bidda-mcp
AI & Machine Learning Legal & Compliance RAG Systems
Bidda-Ai
A
license
A
quality
C
maintenance
Source-verified regulatory and compliance intelligence: 10,000+ obligations across 39 pillars, each grounded in a primary legal source with a content hash. Covers the EU AI Act, GDPR, DORA, NIS2, HIPAA, Basel III and the MITRE ATT&CK/ATLAS families.
Updated 25 days ago (2026-08-12 13:45 UTC)
25
1
MIT
lr-labs
Legal & Compliance Finance
abhinandansethi
A
license
Not graded
quality
B
maintenance
Provides deterministic cross-border tax analysis by compiling law into machine-evaluable conditions, enabling assessments of permanent establishment, transfer pricing, and verification of tax research.
Updated 24 days ago (2026-08-13 21:26 UTC)
MIT
hive-mcp-audit-readiness
Legal & Compliance
srotzin
A
license
Not graded
quality
C
maintenance
Computes multi-jurisdictional AI compliance readiness scores with sourced penalty math, enabling gap analysis and audit tier recommendations.
Updated 4 months ago (2026-05-04 01:26 UTC)
MIT

Try in Browser

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

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4/5.0

Disambiguation4/5

The paired get_check_* and get_instant_brief_* tools are clearly separated by product prefix, and prepare_* tools have distinct purposes. The only slight overlap is list_reglayer_products, which appears to be the broader catalog containing the Instant Brief products listed by list_instant_brief_products.

Naming Consistency5/5

Every tool follows a predictable verb_noun pattern with get_, list_, and prepare_ prefixes and product-specific suffixes. The Check and Instant Brief groups are symmetrically named, making the API surface easy to navigate.

Tool Count5/5

Ten tools is well-scoped for a dual-product regulatory research server. Each tool covers a distinct step in the workflow: product discovery, request preparation, status polling, result retrieval, and PDF download.

Completeness5/5

The tool surface forms a complete workflow: list products, prepare a purchase request, poll status, then retrieve structured results and authenticated PDFs. No obvious dead ends or missing operations within the stated domain.

Resources

Need Help?