F
licenseNot graded
qualityB
maintenanceVAST validation MCP server that checks ad tags against IAB VAST specifications, returning structured JSON with rule IDs, XPath locations, and spec references.
18
-
RTBlint
Server Details
Validate OpenRTB bid requests and responses against IAB specs. ARTF, Rust core.
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
- Transport
- Streamable HTTP
- URL
- Repository
- aleksUIX/rtblint
- GitHub Stars
- 1
Available Tools
6 toolsget_adcp_capabilitiesARead-onlyIdempotentInspect
AdCP protocol discovery. Returns the AdCP releases this agent speaks and the bid-stream conformance metrics it computes. Call this first when wiring rtblint into an agentic buying pipeline: it declares the experimental measurement protocol and the metric ids (openrtb_error_count, openrtb_warning_count, openrtb_conformance_rate) that validate_bid_request and validate_bid_response produce. Part of the Ad Context Protocol (AdCP 3.1) specification.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| ext | No | Caller extension object. Accepted and ignored; declared so envelope fields do not trip strict request-wrapper validation. | |
| context | No | Caller-supplied context object. Echoed back unchanged in the response. | |
| protocols | No | Filter which per-protocol capability blocks are returned. Does not narrow supported_protocols, which declares what the agent implements. | |
| adcp_version | No | Release-precision AdCP version the caller pins (for example "3.1"). When the pin is not in supported_versions the call returns a VERSION_UNSUPPORTED error naming the releases that would work. When omitted, the highest supported release is served. | |
| idempotency_key | No | AdCP 3.1 carries an idempotency key on every task request, reads included. This agent has no mutating surface and no replay store, so the key is accepted and ignored rather than rejected as an unknown field. | |
| adcp_major_version | No | Deprecated in favour of adcp_version. AdCP major version the caller's payloads conform to. When omitted, assumes the highest supported major. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| status | Yes | |
| operator | No | |
| adcp_version | Yes | |
| supported_protocols | Yes |
TDQS
A4.2/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds context beyond these by declaring the tool as 'experimental' measurement protocol, noting it is 'Part of the Ad Context Protocol (AdCP 3.1) specification,' and specifying which metric IDs it produces. This enriches the agent's understanding without contradicting the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences: a one-line purpose, a when-to-use directive, and a protocol/spec note. It is front-loaded and every sentence contributes essential information without repetition or fluff.
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 rich output schema, full parameter documentation, and strong annotations, the description is complete enough. It explains the tool's role in the pipeline, names specific outputs, and identifies the protocol specification. However, it could briefly mention that the output schema details the return structure, but the output schema itself already covers that, so it earns a solid 4.
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 baseline is 3. The description itself does not elaborate on parameter semantics beyond the schema; it mentions metric IDs in the context of output, not parameters. Since the schema already thoroughly documents all 6 parameters, the description adds no additional value here.
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 opens with 'AdCP protocol discovery' and clearly states it returns 'the AdCP releases this agent speaks and the bid-stream conformance metrics it computes.' This uses a specific verb (discovery/returns) and resource (AdCP releases/metrics), distinguishing it from sibling validation tools like validate_bid_request.
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 explicitly directs when to use the tool: 'Call this first when wiring rtblint into an agentic buying pipeline.' It also links to sibling tools by naming the metrics produced by validate_bid_request and validate_bid_response. However, it does not explicitly state when not to use it or name an alternative for this discovery role, 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.
list_openrtb_versionsARead-onlyIdempotentInspect
List every OpenRTB version id this build can validate against, from 2.0 through the monthly 2.6 snapshots. Call this before pinning version on a validate_* tool.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| versions | Yes |
TDQS
A4.5/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false. The description adds meaningful context by specifying the version range (2.0 through monthly 2.6 snapshots) and the build-specific nature of the list. This goes beyond the structured annotations without contradicting them.
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: the first states the core function, the second provides usage guidance. It is front-loaded, with no filler or repetition. 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 list/discovery tool with no parameters, a clear output schema, and strong annotations, the description adequately covers what the tool does, when to use it, and the expected scope. There are no missing pieces that would hinder correct invocation.
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, and the schema is empty. With a parameter count of 0, the baseline is 4; the description need not explain parameter meanings. It focuses on the purpose, which 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 identifies the action ('List every OpenRTB version id'), the resource (versions this build can validate against), and the scope (from 2.0 through monthly 2.6 snapshots). It also distinguishes this discovery tool from the validate_* siblings by framing it as a prerequisite for them.
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 explicitly states when to use the tool: 'Call this before pinning version on a validate_* tool.' This provides clear context and establishes a relationship with the sibling tools. However, it does not explicitly state when not to use it or mention alternatives beyond the implicit validate_* family.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
validate_artf_requestARead-onlyIdempotentInspect
Validate an ARTF (IAB Tech Lab Agentic Real Time Framework) RTBRequest envelope: required members, lifecycle and payload coherence, tmax plausibility, originator and applicable_intents enums, plus full OpenRTB validation of the bid request and bid response it carries. The carried payloads are protobuf JSON, so they are validated in that dialect.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| payload | Yes | The ARTF RTBRequest envelope as a raw JSON string. | |
| version | No | OpenRTB version id to validate against (default 2.6-202606). One of: 2.0, 2.1, 2.2, 2.3, 2.3.1, 2.4, 2.5, 2.6-202204, 2.6-202210, 2.6-202211, 2.6-202303, 2.6-202309, 2.6-202402, 2.6-202409, 2.6-202501, 2.6-202505, 2.6-202606, 3.0 |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| valid | Yes | |
| issues | Yes | |
| version | Yes | |
| payload_type | Yes |
TDQS
A4.4/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds valuable behavioral context about what validation is performed (lifecycle, tmax plausibility, enums, full OpenRTB validation) and that payloads are treated as protobuf JSON. This goes beyond the annotations without contradicting them.
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 compact and front-loaded: the first sentence states the primary purpose and key validation areas, the second clarifies the protobuf JSON dialect. Every clause adds value with no redundancy or fluff, making it highly efficient.
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?
The description covers the main validation aspects thoroughly and is complemented by annotations and an output schema. It could be slightly more explicit about when to choose this over sibling tools, but for a validation tool with rich annotations and output schema, it is substantially complete.
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?
Schema description coverage is 100%, so baseline is 3. The description adds meaningful context for the payload parameter by explaining that carried payloads are protobuf JSON and validated in that dialect, and that both the bid request and bid response inside the envelope are fully validated. This goes beyond the schema's simple field descriptions.
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 ('Validate') and names the exact resource ('ARTF RTBRequest envelope'), then enumerates the validation dimensions (required members, lifecycle, payload coherence, tmax plausibility, enums, OpenRTB validation). This clearly distinguishes it from sibling tools like validate_bid_request and validate_bid_response by focusing on the envelope and its carried payloads.
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 makes clear it is for validating an ARTF RTBRequest envelope, including its carried bid request and bid response. It implies that standalone bid request/response validation should use sibling tools, but it does not explicitly state when-not-to-use or name alternatives. Context is clear but lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
validate_artf_responseARead-onlyIdempotentInspect
Validate an ARTF RTBResponse mutation set against the RTBRequest it answers: envelope id echo, declared intent against applicable_intents, operation and payload coherence, and whether each semantic path (/imp/{id}, /imp/{id}/pmp/deals/{id}, /user/data/segment, /seatbid/{seat}/bid/{id}) resolves to something the auction actually carries. With apply=true the mutations are written into the payloads and revalidated, reporting the OpenRTB findings the mutations introduced. Call this before proposing mutations to an orchestrator.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| apply | No | Apply the mutations and revalidate the result (default false). Returns the mutated payloads and the findings the mutations introduced, with pre-existing findings filtered out. | |
| payload | Yes | The ARTF RTBResponse as a raw JSON string. | |
| version | No | OpenRTB version id to validate against (default 2.6-202606). One of: 2.0, 2.1, 2.2, 2.3, 2.3.1, 2.4, 2.5, 2.6-202204, 2.6-202210, 2.6-202211, 2.6-202303, 2.6-202309, 2.6-202402, 2.6-202409, 2.6-202501, 2.6-202505, 2.6-202606, 3.0 | |
| rtb_request | Yes | The ARTF RTBRequest envelope this response answers, as a raw JSON string. Required: a mutation is only meaningful relative to the auction it targets. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| valid | Yes | |
| issues | Yes | |
| applied | Yes | |
| version | Yes | |
| application | No | |
| payload_type | Yes |
TDQS
A4.1/5.0
Behavior4/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 valuable context about apply=true causing mutations to be written and revalidated, reporting introduced findings, which goes beyond the annotations without contradicting them.
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 dense but well-structured, front-loaded with the primary purpose followed by specific validation checks, conditional behavior, and usage guidance. It's slightly long but every sentence adds meaningful information without redundancy.
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?
With an output schema present and full parameter coverage, the description sufficiently covers the tool's purpose, usage context, conditional apply behavior, and the specific validation paths. It's complete for an agent to understand when and how to invoke it, though slightly more detail on return structure could be added.
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 coverage is 100%, so all parameters are described in the schema. The description adds context about the validation logic and the relationship between payload and rtb_request, but doesn't provide additional parameter-level meaning beyond what the schema already gives, so it stays at baseline.
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 validates an ARTF RTBResponse mutation set against its RTBRequest, listing specific checks like envelope id echo and semantic path resolution. It distinguishes itself from sibling validators by focusing on mutation sets and referencing the orchestrator use case.
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?
It explicitly says 'Call this before proposing mutations to an orchestrator,' giving a clear when-to-use directive. The specific focus on ARTF RTBResponse mutation sets implies when this is appropriate versus other validators, though it doesn't explicitly exclude alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
validate_bid_requestARead-onlyIdempotentInspect
Validate an OpenRTB 2.x bid request JSON payload against a tracked spec version. Returns structured issues with rule ids, severities, and JSON paths.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| dialect | No | JSON dialect the payload is written in. spec-json (default) types flag fields such as imp.secure, regs.coppa and pmp.private_auction as integers, the way the OpenRTB specification does. proto-json follows the IAB OpenRTB protobuf schema, which declares 28 of those fields bool, so true/false is correct there and an integer is the error. Use proto-json for anything that came off a gRPC bidstream integration. | |
| payload | Yes | The OpenRTB bid request as a raw JSON string. | |
| profile | No | Exchange profile applied on top of the spec. spec (default) is the specification only. google-ab is Google Authorized Buyers OpenRTB: at=3 (FIXED_PRICE) is a valid auction type, and each Imp must carry ext.billing_id. prebid-server is Prebid Server /openrtb2/auction: each Imp must name a bidder or stored request, and wseat/bseat are refused. xandr is Microsoft Monetize outgoing requests: ext.appnexus.seller_member_id and video.ext.appnexus.context. magnite is Magnite xAPI identity fields: imp.ext.rp.zone_id, site/app ext.rp.site_id, publisher.ext.rp.account_id. | |
| version | No | OpenRTB version id to validate against (default 2.6-202606). One of: 2.0, 2.1, 2.2, 2.3, 2.3.1, 2.4, 2.5, 2.6-202204, 2.6-202210, 2.6-202211, 2.6-202303, 2.6-202309, 2.6-202402, 2.6-202409, 2.6-202501, 2.6-202505, 2.6-202606, 3.0 |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| valid | Yes | True when the payload has zero spec errors. |
| issues | Yes | |
| dialect | No | |
| profile | No | |
| version | Yes | |
| payload_type | Yes | |
| cross_validated | No |
TDQS
A4.1/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering safety and idempotency. The description adds value by specifying the behavioral trait of returning 'structured issues with rule ids, severities, and JSON paths', which goes beyond the annotations. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exceptionally concise: two sentences that front-load the core purpose and immediately state the output. Every sentence adds value with no wasted words.
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?
Given the tool's complexity (4 parameters, 1 required, full schema coverage, and an output schema), the description is complete. It mentions the validation target and the return type, which is sufficient. The output schema handles return value details, so no further elaboration is needed.
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 coverage is 100% with detailed parameter descriptions already present (e.g., dialect, profile, version). The description does not add additional semantic information beyond the schema. Baseline 3 is appropriate as the schema already does the heavy lifting.
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 verb 'validate', the resource 'OpenRTB 2.x bid request JSON payload', and the specific action 'against a tracked spec version'. It also mentions the output format, distinguishing it from sibling tools like validate_bid_response (for responses) and validate_artf_request (for ARTF).
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 does not explicitly state when to use this tool versus alternatives (e.g., validate_bid_response for bid responses). While the context of sibling tools and the name imply usage, explicit guidance on when-not-to-use or when to choose a sibling is missing. The description is adequate but lacks comparative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
validate_bid_responseARead-onlyIdempotentInspect
Validate an OpenRTB 2.x bid response JSON payload against a tracked spec version. Optionally cross-validate it against the originating bid request (impid, mtype, adm markup, dealid, seat, and currency coherence). Returns structured issues with rule ids, severities, and JSON paths.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| dialect | No | JSON dialect the payload is written in. spec-json (default) types flag fields such as imp.secure, regs.coppa and pmp.private_auction as integers, the way the OpenRTB specification does. proto-json follows the IAB OpenRTB protobuf schema, which declares 28 of those fields bool, so true/false is correct there and an integer is the error. Use proto-json for anything that came off a gRPC bidstream integration. | |
| payload | Yes | The OpenRTB bid response as a raw JSON string. | |
| profile | No | Exchange profile applied on top of the spec. spec (default) is the specification only. google-ab is Google Authorized Buyers OpenRTB: at=3 (FIXED_PRICE) is a valid auction type, and each Imp must carry ext.billing_id. prebid-server is Prebid Server /openrtb2/auction: each Imp must name a bidder or stored request, and wseat/bseat are refused. xandr is Microsoft Monetize outgoing requests: ext.appnexus.seller_member_id and video.ext.appnexus.context. magnite is Magnite xAPI identity fields: imp.ext.rp.zone_id, site/app ext.rp.site_id, publisher.ext.rp.account_id. | |
| version | No | OpenRTB version id to validate against (default 2.6-202606). One of: 2.0, 2.1, 2.2, 2.3, 2.3.1, 2.4, 2.5, 2.6-202204, 2.6-202210, 2.6-202211, 2.6-202303, 2.6-202309, 2.6-202402, 2.6-202409, 2.6-202501, 2.6-202505, 2.6-202606, 3.0 | |
| bid_request | No | Optional: the originating OpenRTB bid request as a raw JSON string. When supplied, every bid is also cross-checked against the Imp it references. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| valid | Yes | True when the payload has zero spec errors. |
| issues | Yes | |
| dialect | No | |
| profile | No | |
| version | Yes | |
| payload_type | Yes | |
| cross_validated | No |
TDQS
A4.4/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the agent knows it's safe. The description adds value by disclosing that it optionally cross-validates against the bid request for specific fields (impid, mtype, adm markup, etc.) and returns structured issues with rule ids, severities, and JSON paths.
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 concise (3 sentences) and front-loaded with the main purpose. The first sentence covers the core function, the second adds cross-validation detail, and the third describes the return format. No wasted words, though the profile descriptions in the schema could be excessive but are justified for clarity.
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?
Given the tool has an output schema, the agent already knows the return structure. The description covers the validation action, optional cross-validation, and the types of issues returned. This is complete for a validation tool with full annotations and output schema.
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?
Schema description coverage is 100%, so the baseline is 3. The description adds value by explaining the optional cross-validation parameter (bid_request) and detailing what 'profile' values mean for different exchanges (e.g., google-ab requires at=3 and ext.billing_id). The dialect parameter is also well-explained with spec-json vs proto-json differences.
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 validates OpenRTB 2.x bid response JSON payloads against a spec version, with optional cross-validation against a bid request. It distinguishes from siblings like validate_bid_request and list_openrtb_versions by being specific to bid responses and mentioning cross-validation.
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 implies when to use this tool (validating bid responses, optionally with a request for cross-checks) but doesn't explicitly state when not to use it or name alternatives among siblings. However, the context signals list sibling tools, and the purpose is clear enough for an agent to infer usage.
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.
2 tool updates
- Changed
validate_bid_request3 fields changed- changed
Input schema / properties / profile / descriptionPrevious value: -"Exchange profile applied on top of the spec. spec (default) is the specification only. google-ab is Google Authorized Buyers OpenRTB: at=3 (FIXED_PRICE) is a valid auction type, and each Imp must carry ext.billing_id. prebid-server is Prebid Server /openrtb2/auction: each Imp must name a bidder or stored request, and wseat/bseat are refused."New value: +"Exchange profile applied on top of the spec. spec (default) is the specification only. google-ab is Google Authorized Buyers OpenRTB: at=3 (FIXED_PRICE) is a valid auction type, and each Imp must carry ext.billing_id. prebid-server is Prebid Server /openrtb2/auction: each Imp must name a bidder or stored request, and wseat/bseat are refused. xandr is Microsoft Monetize outgoing requests: ext.appnexus.seller_member_id and video.ext.appnexus.context. magnite is Magnite xAPI identity fields: imp.ext.rp.zone_id, site/app ext.rp.site_id, publisher.ext.rp.account_id." - changed
Input schema / properties / profile / enumPrevious value: -[ - "spec", - "google-ab", - "prebid-server" -]New value: +[ + "spec", + "google-ab", + "prebid-server", + "xandr", + "magnite" +] - changed
Output schema / properties / profile / enumPrevious value: -[ - "spec", - "google-ab", - "prebid-server" -]New value: +[ + "spec", + "google-ab", + "prebid-server", + "xandr", + "magnite" +]
- Changed
validate_bid_response3 fields changed- changed
Input schema / properties / profile / descriptionPrevious value: -"Exchange profile applied on top of the spec. spec (default) is the specification only. google-ab is Google Authorized Buyers OpenRTB: at=3 (FIXED_PRICE) is a valid auction type, and each Imp must carry ext.billing_id. prebid-server is Prebid Server /openrtb2/auction: each Imp must name a bidder or stored request, and wseat/bseat are refused."New value: +"Exchange profile applied on top of the spec. spec (default) is the specification only. google-ab is Google Authorized Buyers OpenRTB: at=3 (FIXED_PRICE) is a valid auction type, and each Imp must carry ext.billing_id. prebid-server is Prebid Server /openrtb2/auction: each Imp must name a bidder or stored request, and wseat/bseat are refused. xandr is Microsoft Monetize outgoing requests: ext.appnexus.seller_member_id and video.ext.appnexus.context. magnite is Magnite xAPI identity fields: imp.ext.rp.zone_id, site/app ext.rp.site_id, publisher.ext.rp.account_id." - changed
Input schema / properties / profile / enumPrevious value: -[ - "spec", - "google-ab", - "prebid-server" -]New value: +[ + "spec", + "google-ab", + "prebid-server", + "xandr", + "magnite" +] - changed
Output schema / properties / profile / enumPrevious value: -[ - "spec", - "google-ab", - "prebid-server" -]New value: +[ + "spec", + "google-ab", + "prebid-server", + "xandr", + "magnite" +]
2 tool updates
- Changed
validate_bid_request3 fields changed- changed
Input schema / properties / profile / descriptionPrevious value: -"Exchange profile applied on top of the spec. spec (default) is the specification only. google-ab is Google Authorized Buyers OpenRTB: at=3 (FIXED_PRICE) is a valid auction type, and each Imp must carry ext.billing_id."New value: +"Exchange profile applied on top of the spec. spec (default) is the specification only. google-ab is Google Authorized Buyers OpenRTB: at=3 (FIXED_PRICE) is a valid auction type, and each Imp must carry ext.billing_id. prebid-server is Prebid Server /openrtb2/auction: each Imp must name a bidder or stored request, and wseat/bseat are refused." - changed
Input schema / properties / profile / enumPrevious value: -[ - "spec", - "google-ab" -]New value: +[ + "spec", + "google-ab", + "prebid-server" +] - changed
Output schema / properties / profile / enumPrevious value: -[ - "spec", - "google-ab" -]New value: +[ + "spec", + "google-ab", + "prebid-server" +]
- Changed
validate_bid_response3 fields changed- changed
Input schema / properties / profile / descriptionPrevious value: -"Exchange profile applied on top of the spec. spec (default) is the specification only. google-ab is Google Authorized Buyers OpenRTB: at=3 (FIXED_PRICE) is a valid auction type, and each Imp must carry ext.billing_id."New value: +"Exchange profile applied on top of the spec. spec (default) is the specification only. google-ab is Google Authorized Buyers OpenRTB: at=3 (FIXED_PRICE) is a valid auction type, and each Imp must carry ext.billing_id. prebid-server is Prebid Server /openrtb2/auction: each Imp must name a bidder or stored request, and wseat/bseat are refused." - changed
Input schema / properties / profile / enumPrevious value: -[ - "spec", - "google-ab" -]New value: +[ + "spec", + "google-ab", + "prebid-server" +] - changed
Output schema / properties / profile / enumPrevious value: -[ - "spec", - "google-ab" -]New value: +[ + "spec", + "google-ab", + "prebid-server" +]
6 tool updates
- First observed
get_adcp_capabilities - First observed
list_openrtb_versions - First observed
validate_artf_request - First observed
validate_artf_response - First observed
validate_bid_request - First observed
validate_bid_response
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 asio.github.acme/serveralso 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.jsonon the same origin as the connector, then choose Check HTTP challenge.DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!
Related MCP Connectors
Deterministic validation for AI-generated artifacts: JSON Schema, OpenAPI response, SQL syntax.
Validation suite: EU VAT (VIES), IBAN mod-97, email (MX+disposable), geo place lookup, VIN decode.
EN 16931: validate invoice data or a UBL/CII file, emit UBL or CII XML. XRechnung, Peppol. Not PDF.
Query 70+ ad tech protocols — OpenRTB, VAST, AdCP, AAMP, TCF, GPP — with citations.
Related MCP Servers
- FlicenseNot gradedqualityBmaintenanceValidates OpenAPI documents, JSON Schemas, and JSON payloads. Also compares OpenAPI specs and displays breaking changes.-
- AlicenseAqualityAmaintenanceValidates AI-generated artifacts (JSON, API responses, SQL) against a contract and returns a verdict.1591MIT
- AlicenseAqualityCmaintenanceValidates electronic invoices (XRechnung, ZUGFeRD, Factur-X, Peppol BIS, etc.) against authority-pinned rules and explains failures.221MIT
Try in Browser
Glama MCP Gateway
Add one secure layer between your agents and this server.
TDQS
A4.4/5.0
Disambiguation5/5
Each tool targets a distinct aspect of the RTBlint domain: protocol discovery (get_adcp_capabilities), version enumeration (list_openrtb_versions), ARTF request and response validation (validate_artf_request, validate_artf_response), and OpenRTB payload validation (validate_bid_request, validate_bid_response). The descriptions clearly differentiate their purposes and invocation order.
Naming Consistency5/5
All tools follow a consistent verb_noun pattern: get_adcp_capabilities, list_openrtb_versions, validate_artf_request, validate_artf_response, validate_bid_request, validate_bid_response. The naming is uniform, predictable, and clearly indicates the action and target.
Tool Count5/5
With 6 tools, the set is well-scoped for the domain of RTB validation and protocol discovery. Each tool addresses a necessary function without redundancy or excess, making the server easy to navigate and integrate into an agentic pipeline.
Completeness4/5
The tool set covers key lifecycle steps: discovery, version selection, request validation, response validation, and cross-validation. A minor gap is the lack of a tool for validating mutations that don't involve ARTF, but the ARTF tools handle the core workflow well.