Deterministic MiniMindsLab utilities for AI agents over MCP.
Developers need to know whether a new API contract breaks existing clients before they merge or publish it.
| Name | Required | Description | Default |
|---|---|---|---|
| strict_mode | Yes | When true, treat type changes, removed required fields, removed paths, enum narrowing, and object-to-non-object changes as breaking. When false, still report them but additive changes may be separated more prominently. | |
| new_contract_json | Yes | Must be valid JSON text representing the proposed contract version. The tool must reject empty input and invalid JSON with a parse error. | |
| old_contract_json | Yes | Must be valid JSON text representing the previous contract version. The tool must reject empty input and invalid JSON with a parse error. | |
| show_path_details | Yes | When true, include full normalized JSON paths for every finding. When false, keep messages concise while preserving path references in structured results. | |
| ignore_additive_changes | Yes | When true, do not include new optional fields, new array members in additive-only contexts, or other non-breaking additions in the visible change lists. |
| Name | Required | Description |
|---|---|---|
| missing_paths | No | |
| enum_violations | No | |
| breaking_changes | No | |
| type_mismatch_paths | No | |
| compatibility_status | No | |
| non_breaking_changes | No | |
| compatibility_summary | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is covered. However, the description adds no behavioral context beyond that—it does not explain what the tool computes, how breaking changes are determined, whether it normalizes inputs, or what the output contains. The description is a problem statement, not a behavior disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, so it is not verbose, but it does not earn its place as a tool description. It conveys a stakeholder motivation rather than actionable information about the tool's function, inputs, or behavior. Conciseness without substance is under-specification.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With five required parameters, an output schema, and at least one closely related sibling tool, the description omits critical context: what operation the tool performs, when it should be selected, and how it differs from other contract-checking tools. The schema and annotations are rich, but the description itself leaves the agent without enough functional context to confidently invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and each of the five parameters is documented with meaningful semantics, including strict_mode, ignore_additive_changes, and validation requirements for the JSON inputs. The description itself adds no parameter-level detail, but the schema carries the full burden effectively, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description communicates a developer need ('know whether a new API contract breaks existing clients') but never states the tool's action or output in operational terms—there is no verb like 'compare,' 'diff,' or 'report.' It is a vague statement of intent rather than a precise tool description, and it does not distinguish this tool from the similarly named sibling json-contract-compatibility-checker.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention the sibling json-contract-compatibility-checker or json-schema-vs-sample-payload-diff-checker, nor does it state when one should choose API-breaking-change-diff-viewer over them. An agent is left to infer usage entirely from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Estimates whether a name badge is readable at social distance and flags text that will likely feel too small or too crowded.
| Name | Required | Description | Default |
|---|---|---|---|
| name_text | Yes | Text is required. Leading and trailing whitespace are trimmed. Empty after trimming is invalid. | |
| role_text | No | Optional text. If provided, it is trimmed. Empty string is treated as blank. | |
| company_text | Yes | Text is required. Leading and trailing whitespace are trimmed. Empty after trimming is invalid. | |
| font_size_pt | Yes | Must be a finite number between 6 and 72. Non-numeric or out-of-range values are invalid. | |
| badge_width_mm | Yes | Must be a finite number between 20 and 300. Values outside the range are invalid. | |
| viewing_distance_cm | Yes | Must be a finite number between 20 and 500. Values outside the range are invalid. |
| Name | Required | Description |
|---|---|---|
| sizing_notes | No | |
| badge_summary | No | |
| crowding_warnings | No | |
| readability_score | No | |
| line_break_suggestions | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, and the description is consistent with them (an estimation operation has no side effects). The description adds genuine behavioral context beyond the annotations: the tool produces a readability estimate and actively flags problem text as 'too small or too crowded,' which tells the agent what kind of output behavior to expect. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence of roughly 20 words that front-loads the primary action ('Estimates whether a name badge is readable at social distance') and appends the secondary flagging behavior. Every word earns its place; there is no repetition of the title or schema content. This is model conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a moderate 6-parameter complexity, but the output schema documents return values, the annotations cover safety/idempotency, and the schema covers all parameter semantics at 100% coverage. The description completes the picture by stating the evaluation purpose and flagging behavior. The only minor gap is the absence of usage guidance, but the full package is nearly complete for correct selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with detailed per-parameter documentation covering ranges, trimming behavior, and required/optional status, so the schema carries the full burden. The description adds only indirect semantic context — 'too small' maps to font_size_pt and 'too crowded' to badge_width_mm — but no parameter-level detail beyond what the schema already provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: it 'estimates whether a name badge is readable at social distance' and 'flags text' that is too small or crowded. This is a precise, unambiguous purpose that clearly distinguishes the tool from its siblings, which operate in the completely different domain of JSON contract and payload-diff checking.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use is implied by the domain — testing badge layouts for readability — and the sibling tools are so unrelated that an agent is unlikely to confuse them. However, the description gives no explicit when-to-use or when-not-to-use guidance, no prerequisites (e.g., needing a badge design draft), and no mention of alternatives. This is acceptable but not actively instructive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Developers need to confirm that a sample API response still matches a contract, including required fields, type expectations, enum constraints, and unexpected shape changes.
| Name | Required | Description | Default |
|---|---|---|---|
| sample_json | Yes | Must be valid JSON text. The sample must be a JSON object, array, string, number, boolean, or null. Missing or invalid JSON must produce a parse error. | |
| strict_mode | Yes | When true, extra paths not allowed by the contract are reported as mismatches whenever additionalProperties is false or omitted for object branches that define properties. When false, extra paths are still listed in extra_paths but do not change overall compatibility unless another required rule fails. | |
| contract_json | Yes | Must be valid JSON text. The contract must be an object. Supported contract keys are name/title, type, required, properties, items, enum, const, additionalProperties, and nested combinations of those. Missing or invalid JSON must produce a parse error. | |
| show_path_details | Yes | When true, mismatch outputs must include explicit JSONPath-like paths such as $.user.name. When false, the report may summarize issues without omitting the required output lists. |
| Name | Required | Description |
|---|---|---|
| extra_paths | No | |
| missing_paths | No | |
| enum_violations | No | |
| type_mismatch_paths | No | |
| compatibility_status | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, and closed-world behavior, so the safety profile is covered. The description adds useful context about what the checker evaluates (required fields, types, enums, shape changes), but it does not describe operational behavior such as failure modes, output structure, or anything beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no wasted words. It is slightly indirect by framing the tool as a developer need rather than an imperative, but it remains concise and adequately structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The input schema is highly detailed and output schema is present, so the structured information covers invocation details and return shape. The main gap is the lack of differentiation from the sibling json-schema diff checker, but the tool definition is otherwise complete enough 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.
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 thoroughly documented with constraints and parse-error behavior. The description adds no parameter-specific meaning, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: confirming that a sample API response matches a contract, specifically calling out required fields, type expectations, enum constraints, and shape changes. This is a specific verb plus resource, but it does not explicitly distinguish itself from the similar sibling json-schema-vs-sample-payload-diff-checker.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: use this tool when you need to validate a sample response against a contract. However, it gives no explicit when-not-to-use guidance and no differentiation from the closely related sibling tool, leaving the agent to infer the boundary between them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
API builders need to see exactly where a sample payload violates a schema or where the schema does not describe real data.
| Name | Required | Description | Default |
|---|---|---|---|
| show_paths | Yes | When true, include JSON Pointer-style instance paths for every mismatch. When false, still compute paths internally but present concise grouped results. | |
| json_schema | Yes | Must be valid JSON text representing a JSON Schema document. If parsing fails, show a schema parse error and skip comparison. | |
| sample_json | Yes | Must be valid JSON text representing an instance payload. If parsing fails, show a sample parse error and skip comparison. | |
| strict_types | Yes | When true, require exact JSON type matches for object, array, string, number, integer, boolean, and null. Integers must still be numbers with no fractional component. When false, permit only JSON Schema-compatible numeric coercion is not performed; comparison remains type-based but integer and number mismatches are reported with lower severity in the summary only. | |
| additional_properties_mode | Yes | Controls handling of object properties not declared by the schema. schema_default uses the schema's own additionalProperties / unevaluatedProperties rules where supported by the tool. allow ignores extra-property violations. forbid reports extra-property paths even if the schema is permissive. |
| Name | Required | Description |
|---|---|---|
| summary | No | |
| enum_violations | No | |
| validation_status | No | |
| missing_field_paths | No | |
| type_mismatch_paths | No | |
| extra_property_paths | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is covered. The description adds a useful behavioral detail: the tool checks both directions, payload-to-schema and schema-to-payload. However, it does not describe output structure, error behavior beyond schema descriptions, or other operational traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one concise sentence with no filler. It is front-loaded with the core value proposition. It is slightly too brief to cover usage context, but as a statement of purpose it is efficient and readable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema, rich parameter descriptions, and safety annotations, so the description does not need to repeat those. The remaining gap is selection context: an agent gets no help deciding between this tool and json-contract-compatibility-checker. Overall it is adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema already documents every parameter in detail. The tool description adds no additional parameter-level meaning. A baseline of 3 is appropriate given that the schema carries the full semantic load.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies a specific purpose: finding where a sample payload violates a JSON Schema and where the schema fails to describe the sample. This is more informative than a tautology and aligns with the tool's name. However, it does not explicitly distinguish itself from the sibling tool json-contract-compatibility-checker, 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to prefer this tool over the sibling json-contract-compatibility-checker, nor are any prerequisites or typical scenarios stated. The description implies a use case but does not say when to use this tool vs alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
api-breaking-change-diff-viewerconference-badge-readability-testerjson-contract-compatibility-checkerjson-schema-vs-sample-payload-diff-checkerClaiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such as io.github.acme/server also needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
Deterministic reasoning stack for AI agents: simulate, decide & compute, plus cross-domain tools.
Machine-readable utilities and datasets for AI agents.
Deterministic web intake and data utilities for autonomous agents.
Agent Replay Debugger MCP — record every agent step + deterministic replay. Step-debugger for
Add one secure layer between your agents and this server.
json-contract-compatibility-checker and json-schema-vs-sample-payload-diff-checker both validate sample payloads against a contract/schema and describe nearly the same mismatch types, making them hard to distinguish. The API breaking-change viewer is distinct, and the badge tester is clearly separate, but the JSON checker pair creates real ambiguity.
All names use lowercase hyphenated compounds and are readable, but the head words are inconsistent (viewer vs checker vs tester) and the prefix structures vary considerably. The naming feels visually consistent at first glance but does not follow a predictable semantic pattern.
Four tools is a reasonable small surface for a utility-focused server. However, two of the API tools are near-duplicates and the conference-badge tool is unrelated, so not every tool earns its place as cleanly as it could.
The API/JSON tools cover core compatibility checks such as breaking changes, response-vs-contract validation, and payload-vs-schema diffing. There are notable gaps though, including request-side validation and any broader contract lifecycle support, while the conference-badge tool is an isolated outlier rather than part of a coherent workflow.