Private Law Wiki

Server Details

Read-only answers and semantic search for wiki.private.law, served by the Mothership runtime.

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
Uptime: 98.5% over 37 days
Last Tested: 2026-09-23 20:38
Transport: Streamable HTTP · MCP 2025-11-25
URL

TDQS

A4.2/5.0

Scored 2026-09-21 21:20 across 5 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: ask returns a quoted answer, search returns ranked sources, assess_bank_case evaluates a specific complaint scenario, bank_index lists providers, and bank_rating returns one provider's detailed record. The apparent overlaps between ask/search and bank_index/bank_rating are explicitly resolved by the tool descriptions.

Naming Consistency3/5

Tool names are all lowercase snake_case, but they mix conventions: bare verbs (ask, search), a verb-object phrase (assess_bank_case), and noun-noun descriptors (bank_index, bank_rating). The pattern is readable but not consistent.

Tool Count5/5

Five tools is a well-scoped set for this server's dual purpose: retrieving legal wiki content and looking up banking/provider assessments. Each tool covers a distinct function without bloat.

Completeness4/5

The read-only wiki is well covered by ask and search, and banking coverage is served by bank_index, bank_rating, and assess_bank_case. Minor gaps exist, such as no dedicated full-article retrieval or side-by-side provider comparison, but the core workflows are usable without dead ends.

Available Tools

5 tools

askAsk the Private Law wikiA

Read-onlyIdempotent

Inspect

Answer a question by quoting a published wiki article. The answer is extracted verbatim, never generated, and always carries the URL it came from. Returns confident=false with suggested reading when the corpus does not cover the question or when context genuinely conflicts. Bare MSO means the Hong Kong Money Service Operator licence; use Management Services Organization or regulated-practice context for the broader platform concept. Ask in the language you want answered — Russian and English are both first-class.

ParametersJSON Schema

Name	Required	Description	Default
`locale`	No	Corpus language; inferred from the question when omitted.
`question`	Yes	A natural-language question, up to 2000 characters.

Output Schema

ParametersJSON Schema

Name	Required	Description
`answer`	Yes
`locale`	No
`citations`	Yes
`confident`	Yes
`threshold`	No
`topDistance`	No
`refusalReason`	No
`suggestedReading`	Yes
`queryInterpretation`	Yes

TDQS

A4.1/5.0

Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive/openWorld=false, and the description adds substantial behavior beyond them: answers are extracted verbatim and never generated, always carry a source URL, and degrade to confident=false when coverage fails or context conflicts. That is the exact behavioral profile an agent needs to trust or distrust the output.

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?

Four front-loaded sentences that each carry information: core behavior, fallback behavior, a genuinely ambiguous acronym disambiguation, and language handling. Efficient, though the MSO aside is narrow enough to slightly dilute the opening.

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?

An output schema exists, so return shape need not be described, yet the description still explains the semantically important part of the output (verbatim quotes, source URL, confidence flag). Combined with the fallback and ambiguity guidance, an agent has everything needed to call this 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 coverage is 100% with two documented parameters and an enum for locale, so the schema already carries the parameter semantics. The description's language note ('Russian and English are both first-class') is a useful hint but does not explain the locale enum's other values (ko, zh-hant), so it adds little beyond the schema. Baseline 3 applies.

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 a specific verb and resource: answer a question by quoting a published wiki article. That is concrete and distinguishable from a generic retrieval tool. It never names the sibling 'search' or contrasts itself with it, so an agent must infer the boundary between asking and searching.

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 gives clear context on when the tool works (question covered by the corpus) and what happens when it does not (confident=false with suggested reading). The language instruction and MSO disambiguation further guide correct invocation. It stops short of naming the alternative (search) or stating explicit exclusions.

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

assess_bank_caseAssess a problem with a bankA

Read-onlyIdempotent

Inspect

The complaint desk's deterministic assessment for a frozen account, a closure notice, a document request, a stuck payment or a refused application: what to do now, the escalation ladder of the bank's jurisdiction (bank complaint, ombudsman or regulator, data access request) with each rung judged for this client — open now, after the bank replies, conditional or not open to them — and linked to its primary source, plus deadlines, cautions and the help that fits. Also returns the letters to send — the formal complaint that starts the bank's clock and the data access request, in English with bracketed placeholders the person fills in themselves — and the dates that follow if they go out today. Pass holder whenever it is known: an ombudsman's door depends on whose account it is. Information, not legal advice. Never submit a person's contact details; hand them the complaint URL instead.

ParametersJSON Schema

Name	Required	Description
`stage`	Yes
`today`	No	The client's current date (YYYY-MM-DD) for the calendar. Optional; defaults to the server's date.
`amount`	Yes
`holder`	No	Whose account it is. Optional; without it eligibility is stated, not decided.
`locale`	No
`problem`	Yes
`sanctions`	Yes	Russia or Belarus nexus of the client.
`jurisdiction`	Yes	Where the bank or the neobank's licence sits.

Output Schema

ParametersJSON Schema

Name	Required	Description
`letters`	Yes
`service`	Yes
`verdict`	Yes
`articles`	Yes
`calendar`	Yes
`cautions`	Yes
`headline`	Yes
`deadlines`	Yes
`escalation`	Yes
`firstSteps`	Yes
`complaintUrl`	Yes

TDQS

A4.5/5.0

Behavior5/5

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

Annotations already declare readOnly, idempotent, and non-destructive, and the description adds meaningful behavioral detail beyond them: deterministic logic, conditional eligibility for each escalation rung ('open now, after the bank replies, conditional or not open to them'), and the dependency of the ombudsman's door on `holder`. It also discloses the 'Information, not legal advice' boundary and the instruction to avoid submitting contact details, which is actionable agent behavior.

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 and long, but it is front-loaded with the core purpose and then progressively adds outputs, conditions, cautions, and agent instructions. Every clause adds information; however, the single massive paragraph is harder to parse than structured bullets, so it is not perfectly concise.

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 an 8-parameter, high-complexity tool with an output schema, the description is remarkably complete: it covers the problem types, assessment output, escalation ladder, letters, dates, cautions, and the `holder` sensitivity. It leaves `stage`, `amount`, and `locale` semantics mostly to enum names and schema, but no critical calling context appears to be missing.

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 only 50%, so the description carries partial weight. It adds real meaning to `holder` (why it matters: 'an ombudsman's door depends on whose account it is') and to `problem` by listing the five problem types in prose. It does not explain `stage`, `amount`, or `locale`, but their enum names are largely self-descriptive and the output schema likely covers the rest.

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 a specific verb and resource: 'deterministic assessment for a frozen account, a closure notice, a document request, a stuck payment or a refused application.' It enumerates the exact outputs (escalation ladder, letters, dates, cautions) which makes the tool's scope unmistakable and clearly distinct from siblings like search, bank_index, and bank_rating.

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 gives clear operational guidance: 'Pass holder whenever it is known' and 'Never submit a person's contact details; hand them the complaint URL instead.' It does not explicitly name alternative tools or state when not to use this tool, but the context of use is clear enough that an agent would know when to invoke it.

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

bank_indexThe private.law Bank IndexA

Read-onlyIdempotent

Inspect

List providers of banking for international clients with their standing in the Bank Index: a ranking per product (business account, private banking, personal account, digital assets, payments and FX, banking infrastructure, trade finance), tier, composite score 0–100, data coverage and watch flag. Filter by product, tier or a standardised client profile; without a product each provider shows its best standing. Scores are computed from dated, sourced data points; unrated providers are listed too. Use bank_rating for one provider with its evidence.

ParametersJSON Schema

Name	Required	Description
`tier`	No
`limit`	No	Default 25.
`locale`	No
`product`	No	Rank under this product; a provider appears in every product it offers.
`profile`	No	Only providers whose verdict for this profile is yes or case-by-case.

Output Schema

ParametersJSON Schema

Name	Required	Description
`total`	Yes
`method`	Yes
`providers`	Yes
`generatedAt`	Yes

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already establish readOnly, idempotent, and non-destructive behavior. The description adds useful behavioral context: unrated providers are listed, scores are computed from dated/sourced data points, and without a product each provider shows its best standing. 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.

Conciseness5/5

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

The description is three dense sentences with no filler. It front-loads the core purpose, then covers filtering behavior, computation methodology, unrated providers, and the sibling alternative. 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?

With an output schema present, annotations covering safety profile, and no required parameters, the description is complete enough for a listing tool. It covers default product behavior, unrated providers, and the single-provider alternative without needing to restate return fields.

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 60%, and the description partially compensates by explaining product-absence behavior and mentioning the product/tier/profile filter dimensions. However, it adds little semantic value for limit and locale, which remain mostly self-explanatory or covered by schema defaults.

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 'List', names the resource 'providers of banking for international clients', enumerates the fields shown, and explicitly differentiates from bank_rating. An agent can immediately understand what this tool returns and how it differs from its siblings.

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

Usage Guidelines5/5

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

The description explicitly directs users to bank_rating 'for one provider with its evidence', providing a clear alternative for a different use case. It also explains the default behavior when no product filter is supplied, which is valuable usage guidance.

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

bank_ratingOne provider in the Bank Index, with evidenceA

Read-onlyIdempotent

Inspect

Return one provider's full record: its standing under every product it offers (tier, composite, coverage), pillar scores, every indicator value with its source, date and verification level, the standardised profile verdicts, flags and a provenance object with a ready citation. Also returns the complaint-desk URL for that provider.

ParametersJSON Schema

Name	Required	Description	Default
`slug`	Yes	The provider card slug, e.g. mercury.

Output Schema

ParametersJSON Schema

Name	Required	Description
`slug`	Yes
`tier`	Yes
`flags`	Yes
`watch`	Yes
`review`	Yes
`pillars`	Yes
`coverage`	Yes
`headline`	Yes
`products`	Yes
`profiles`	Yes
`complaint`	Yes
`composite`	Yes
`standings`	Yes
`indicators`	Yes
`provenance`	Yes

TDQS

A3.9/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 value by enumerating exactly what the record includes (sources, dates, verification levels, provenance citation, complaint-desk URL), which goes beyond the annotation metadata. 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.

Conciseness4/5

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

The description is a single sentence that front-loads the main purpose and then lists the components in a structured, parenthetical manner. It is detailed but not padded; every clause adds relevant information. Slightly long, but appropriate for the complexity of the return payload.

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, the description does not need to define the return structure. It covers the full scope of what the tool returns, including provenance and the complaint-desk URL. Missing explicit error-handling or prerequisites, but for a read-only tool with one parameter, this is largely complete.

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 already provides full coverage (100%) for the single 'slug' parameter with an example, so the description adds no additional parameter-level meaning. Per the rubric, baseline 3 is appropriate when the schema 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 states a specific verb ('Return') and a precise resource ('one provider's full record'), listing the major components (tier, composite, coverage, pillar scores, indicator values, verdicts, flags, provenance). It differentiates from the sibling bank_index by explicitly limiting scope to a single provider.

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 when to use this tool (when you need one provider's full record) but does not explicitly mention alternatives like bank_index or search, nor does it state when not to use it. The context is clear but no exclusions or routing guidance is given.

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

searchSearch the Private Law wikiA

Read-onlyIdempotent

Inspect

Rank published articles for a query and return them with titles and URLs. Use when you want sources to read rather than a single answer. Search is sense-aware: bare MSO promotes only the Hong Kong Money Service Operator owner, professional-industry context promotes the regulated-practice platform, and genuinely conflicting context returns both with an explicit interpretation object.

ParametersJSON Schema

Name	Required	Description
`limit`	No	Default 5.
`query`	Yes	Search terms or a question.
`locale`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`hits`	Yes
`queryInterpretation`	Yes

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive, so the description rightly focuses on behavior beyond them: sense-aware disambiguation of 'MSO' and the fact that conflicting context yields both results plus an explicit interpretation object. This is genuinely useful context an agent cannot get from the annotations, though it does not cover result-count or locale-related behavior.

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?

Three sentences, front-loaded with purpose and usage before the denser disambiguation detail. The final sentence is long and example-heavy but each clause earns its place by clarifying real ambiguity resolution.

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, the description need not explain return values, and it covers purpose, usage, and the non-obvious disambiguation behavior. It omits any mention of locale handling or the default/maximum result count, which are minor gaps given the schema covers limit.

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 67%; query and limit are documented in the schema, but locale (an enum) has no description anywhere. The description illuminates how query context is interpreted (sense awareness) but says nothing about limit or locale, so it adds only partial meaning over the structured fields.

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?

States a specific verb and resource (ranks published articles in the Private Law wiki) and clearly distinguishes itself from the 'ask' sibling by offering sources to read rather than a single answer. An agent can route between the two tools without opening either schema.

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

Usage Guidelines5/5

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

Explicitly gives the selection condition: 'Use when you want sources to read rather than a single answer,' which names the alternative behavior (the 'ask' sibling) it is contrasted against. Nothing about when to pick this tool is left to inference.

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.

1 tool updateSep 21, 2026

Changedassess_bank_case4 fields changed

addedInput schema / properties / today

Added value: +{
+  "description": "The client's current date (YYYY-MM-DD) for the calendar. Optional; defaults to the server's date.",
+  "pattern": "^\\d{4}-\\d{2}-\\d{2}$",
+  "type": "string"
+}

addedOutput schema / properties / calendar

Added value: +{
+  "items": {
+    "properties": {
+      "date": {
+        "type": "string"
+      },
+      "label": {
+        "type": "string"
+      }
+    },
+    "required": [
+      "label",
+      "date"
+    ],
+    "type": "object"
+  },
+  "type": "array"
+}

addedOutput schema / properties / letters

Added value: +{
+  "items": {
+    "properties": {
+      "body": {
+        "type": "string"
+      },
+      "kind": {
+        "enum": [
+          "complaint",
+          "data_request"
+        ],
+        "type": "string"
+      },
+      "purpose": {
+        "type": "string"
+      },
+      "title": {
+        "type": "string"
+      }
+    },
+    "required": [
+      "kind",
+      "title",
+      "purpose",
+      "body"
+    ],
+    "type": "object"
+  },
+  "type": "array"
+}

changedOutput schema / required

Previous value: -[
-  "headline",
-  "verdict",
-  "firstSteps",
-  "escalation",
-  "deadlines",
-  "service",
-  "cautions",
-  "articles",
-  "complaintUrl"
-]New value: +[
+  "headline",
+  "verdict",
+  "firstSteps",
+  "escalation",
+  "deadlines",
+  "calendar",
+  "letters",
+  "service",
+  "cautions",
+  "articles",
+  "complaintUrl"
+]

1 tool updateSep 21, 2026

Changedassess_bank_case8 fields changed

addedInput schema / properties / holder

Added value: +{
+  "description": "Whose account it is. Optional; without it eligibility is stated, not decided.",
+  "enum": [
+    "individual",
+    "small_business",
+    "company"
+  ],
+  "type": "string"
+}

addedOutput schema / properties / escalation / items / properties / source
```
Added value: +{
+  "type": "string"
+}
```

addedOutput schema / properties / escalation / items / properties / status

Added value: +{
+  "enum": [
+    "open",
+    "later",
+    "conditional",
+    "closed"
+  ],
+  "type": "string"
+}

addedOutput schema / properties / escalation / items / properties / statusNote
```
Added value: +{
+  "type": "string"
+}
```
addedOutput schema / properties / escalation / items / properties / who
```
Added value: +{
+  "type": "string"
+}
```

changedOutput schema / properties / escalation / items / required

Previous value: -[
-  "name",
-  "when",
-  "how"
-]New value: +[
+  "name",
+  "when",
+  "how",
+  "who",
+  "status",
+  "statusNote"
+]

addedOutput schema / properties / verdict
```
Added value: +{
+  "type": "string"
+}
```

changedOutput schema / required

Previous value: -[
-  "headline",
-  "firstSteps",
-  "escalation",
-  "deadlines",
-  "service",
-  "cautions",
-  "articles",
-  "complaintUrl"
-]New value: +[
+  "headline",
+  "verdict",
+  "firstSteps",
+  "escalation",
+  "deadlines",
+  "service",
+  "cautions",
+  "articles",
+  "complaintUrl"
+]

3 tool updatesSep 17, 2026
- Addedassess_bank_case
- Addedbank_index
- Addedbank_rating

2 tool updatesSep 11, 2026

Changedask2 fields changed

changedOutput schema / properties / citations / items / properties / provenance / properties / version / description

Previous value: -"Revision of exactly the material served: article snapshot content hash (the HTML ETag value) or dataset version. Null when unknown."New value: +"Revision of exactly the material served: for an article the snapshot content hash (the HTML ETag value); for a dataset record the dataset revision it was published in, since the published file is named by the hash of its own content and meta.version plus datasets/index.json resolve that filename. Null when unknown."

changedOutput schema / properties / suggestedReading / items / properties / provenance / properties / version / description

Previous value: -"Revision of exactly the material served: article snapshot content hash (the HTML ETag value) or dataset version. Null when unknown."New value: +"Revision of exactly the material served: for an article the snapshot content hash (the HTML ETag value); for a dataset record the dataset revision it was published in, since the published file is named by the hash of its own content and meta.version plus datasets/index.json resolve that filename. Null when unknown."

Changedsearch1 field changed

changedOutput schema / properties / hits / items / properties / provenance / properties / version / description

Previous value: -"Revision of exactly the material served: article snapshot content hash (the HTML ETag value) or dataset version. Null when unknown."New value: +"Revision of exactly the material served: for an article the snapshot content hash (the HTML ETag value); for a dataset record the dataset revision it was published in, since the published file is named by the hash of its own content and meta.version plus datasets/index.json resolve that filename. Null when unknown."

2 tool updatesSep 10, 2026

Changedask4 fields changed

addedOutput schema / properties / citations / items / properties / provenance

Added value: +{
+  "description": "Origin of one record: stable id, clean canonical URL, publisher, the exact published revision served, a ready citation, primary sources and review status.",
+  "properties": {
+    "canonical_url": {
+      "description": "Published location without tracking parameters.",
+      "format": "uri",
+      "type": "string"
+    },
+    "cite_as": {
+      "type": "string"
+    },
+    "contract": {
+      "const": "wiki-provenance/1",
+      "type": "string"
+    },
+    "id": {
+      "description": "<locale>:<slug> for an article, <dataset>:<record id> for a dataset row.",
+      "type": "string"
+    },
+    "primary_sources": {
+      "items": {
+        "properties": {
+          "name": {
+            "type": "string"
+          },
+          "url": {
+            "type": [
+              "string",
+              "null"
+            ]
+          }
+        },
+        "required": [
+          "name",
+          "url"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "publisher": {
+      "properties": {
+        "name": {
+          "type": "string"
+        },
+        "url": {
+          "format": "uri",
+          "type": "string"
+        }
+      },
+      "required": [
+        "name",
+        "url"
+      ],
+      "type": "object"
+    },
+    "verification_status": {
+      "enum": [
+        "verified",
+        "pending",
+        "unknown"
+      ],
+      "type": "string"
+    },
+    "version": {
+      "description": "Revision of exactly the material served: article snapshot content hash (the HTML ETag value) or dataset version. Null when unknown.",
+      "type": [
+        "string",
+        "null"
+      ]
+    }
+  },
+  "required": [
+    "contract",
+    "id",
+    "canonical_url",
+    "publisher",
+    "version",
+    "cite_as",
+    "primary_sources",
+    "verification_status"
+  ],
+  "type": "object"
+}

changedOutput schema / properties / citations / items / required

Previous value: -[
-  "slug",
-  "url"
-]New value: +[
+  "slug",
+  "url",
+  "provenance"
+]

addedOutput schema / properties / suggestedReading / items / properties / provenance

Added value: +{
+  "description": "Origin of one record: stable id, clean canonical URL, publisher, the exact published revision served, a ready citation, primary sources and review status.",
+  "properties": {
+    "canonical_url": {
+      "description": "Published location without tracking parameters.",
+      "format": "uri",
+      "type": "string"
+    },
+    "cite_as": {
+      "type": "string"
+    },
+    "contract": {
+      "const": "wiki-provenance/1",
+      "type": "string"
+    },
+    "id": {
+      "description": "<locale>:<slug> for an article, <dataset>:<record id> for a dataset row.",
+      "type": "string"
+    },
+    "primary_sources": {
+      "items": {
+        "properties": {
+          "name": {
+            "type": "string"
+          },
+          "url": {
+            "type": [
+              "string",
+              "null"
+            ]
+          }
+        },
+        "required": [
+          "name",
+          "url"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "publisher": {
+      "properties": {
+        "name": {
+          "type": "string"
+        },
+        "url": {
+          "format": "uri",
+          "type": "string"
+        }
+      },
+      "required": [
+        "name",
+        "url"
+      ],
+      "type": "object"
+    },
+    "verification_status": {
+      "enum": [
+        "verified",
+        "pending",
+        "unknown"
+      ],
+      "type": "string"
+    },
+    "version": {
+      "description": "Revision of exactly the material served: article snapshot content hash (the HTML ETag value) or dataset version. Null when unknown.",
+      "type": [
+        "string",
+        "null"
+      ]
+    }
+  },
+  "required": [
+    "contract",
+    "id",
+    "canonical_url",
+    "publisher",
+    "version",
+    "cite_as",
+    "primary_sources",
+    "verification_status"
+  ],
+  "type": "object"
+}

changedOutput schema / properties / suggestedReading / items / required

Previous value: -[
-  "slug",
-  "url"
-]New value: +[
+  "slug",
+  "url",
+  "provenance"
+]

Changedsearch2 fields changed

addedOutput schema / properties / hits / items / properties / provenance

Added value: +{
+  "description": "Origin of one record: stable id, clean canonical URL, publisher, the exact published revision served, a ready citation, primary sources and review status.",
+  "properties": {
+    "canonical_url": {
+      "description": "Published location without tracking parameters.",
+      "format": "uri",
+      "type": "string"
+    },
+    "cite_as": {
+      "type": "string"
+    },
+    "contract": {
+      "const": "wiki-provenance/1",
+      "type": "string"
+    },
+    "id": {
+      "description": "<locale>:<slug> for an article, <dataset>:<record id> for a dataset row.",
+      "type": "string"
+    },
+    "primary_sources": {
+      "items": {
+        "properties": {
+          "name": {
+            "type": "string"
+          },
+          "url": {
+            "type": [
+              "string",
+              "null"
+            ]
+          }
+        },
+        "required": [
+          "name",
+          "url"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "publisher": {
+      "properties": {
+        "name": {
+          "type": "string"
+        },
+        "url": {
+          "format": "uri",
+          "type": "string"
+        }
+      },
+      "required": [
+        "name",
+        "url"
+      ],
+      "type": "object"
+    },
+    "verification_status": {
+      "enum": [
+        "verified",
+        "pending",
+        "unknown"
+      ],
+      "type": "string"
+    },
+    "version": {
+      "description": "Revision of exactly the material served: article snapshot content hash (the HTML ETag value) or dataset version. Null when unknown.",
+      "type": [
+        "string",
+        "null"
+      ]
+    }
+  },
+  "required": [
+    "contract",
+    "id",
+    "canonical_url",
+    "publisher",
+    "version",
+    "cite_as",
+    "primary_sources",
+    "verification_status"
+  ],
+  "type": "object"
+}

changedOutput schema / properties / hits / items / required

Previous value: -[
-  "slug",
-  "url"
-]New value: +[
+  "slug",
+  "url",
+  "provenance"
+]

2 tool updatesAug 17, 2026

Changedask4 fields changed

changedOutput schema / properties / citations / items / properties / distance / type
```
Previous value: -"number"New value: +[
+  "number",
+  "null"
+]
```

addedOutput schema / properties / queryInterpretation

Added value: +{
+  "properties": {
+    "ambiguous": {
+      "type": "boolean"
+    },
+    "choices": {
+      "items": {
+        "properties": {
+          "description": {
+            "type": "string"
+          },
+          "locale": {
+            "type": "string"
+          },
+          "sense": {
+            "enum": [
+              "hong_kong_money_service_operator",
+              "regulated_practice_management"
+            ],
+            "type": "string"
+          },
+          "slug": {
+            "type": "string"
+          },
+          "title": {
+            "type": "string"
+          },
+          "url": {
+            "type": "string"
+          }
+        },
+        "required": [
+          "sense",
+          "slug",
+          "locale",
+          "title",
+          "description",
+          "url"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "message": {
+      "type": "string"
+    },
+    "sense": {
+      "enum": [
+        "hong_kong_money_service_operator",
+        "regulated_practice_management",
+        "comparison",
+        "ambiguous"
+      ],
+      "type": "string"
+    },
+    "term": {
+      "enum": [
+        "MSO"
+      ],
+      "type": "string"
+    }
+  },
+  "required": [
+    "term",
+    "sense",
+    "ambiguous",
+    "message",
+    "choices"
+  ],
+  "type": [
+    "object",
+    "null"
+  ]
+}

changedOutput schema / properties / suggestedReading / items / properties / distance / type
```
Previous value: -"number"New value: +[
+  "number",
+  "null"
+]
```

changedOutput schema / required

Previous value: -[
-  "confident",
-  "answer",
-  "citations",
-  "suggestedReading"
-]New value: +[
+  "confident",
+  "answer",
+  "citations",
+  "suggestedReading",
+  "queryInterpretation"
+]

Changedsearch3 fields changed

changedOutput schema / properties / hits / items / properties / distance / type
```
Previous value: -"number"New value: +[
+  "number",
+  "null"
+]
```

addedOutput schema / properties / queryInterpretation

Added value: +{
+  "properties": {
+    "ambiguous": {
+      "type": "boolean"
+    },
+    "choices": {
+      "items": {
+        "properties": {
+          "description": {
+            "type": "string"
+          },
+          "locale": {
+            "type": "string"
+          },
+          "sense": {
+            "enum": [
+              "hong_kong_money_service_operator",
+              "regulated_practice_management"
+            ],
+            "type": "string"
+          },
+          "slug": {
+            "type": "string"
+          },
+          "title": {
+            "type": "string"
+          },
+          "url": {
+            "type": "string"
+          }
+        },
+        "required": [
+          "sense",
+          "slug",
+          "locale",
+          "title",
+          "description",
+          "url"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "message": {
+      "type": "string"
+    },
+    "sense": {
+      "enum": [
+        "hong_kong_money_service_operator",
+        "regulated_practice_management",
+        "comparison",
+        "ambiguous"
+      ],
+      "type": "string"
+    },
+    "term": {
+      "enum": [
+        "MSO"
+      ],
+      "type": "string"
+    }
+  },
+  "required": [
+    "term",
+    "sense",
+    "ambiguous",
+    "message",
+    "choices"
+  ],
+  "type": [
+    "object",
+    "null"
+  ]
+}

changedOutput schema / required

Previous value: -[
-  "hits"
-]New value: +[
+  "hits",
+  "queryInterpretation"
+]

3 tool updatesAug 8, 2026

Changedask3 fields changed

addedInput schema / properties / locale

Added value: +{
+  "description": "Corpus language; inferred from the question when omitted.",
+  "enum": [
+    "ru",
+    "en",
+    "ko",
+    "zh-hant"
+  ],
+  "type": "string"
+}

changedInput schema / properties / question / description

Previous value: -"Question in English, <= 2000 chars"New value: +"A natural-language question, up to 2000 characters."

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "answer": {
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "citations": {
+      "items": {
+        "properties": {
+          "distance": {
+            "type": "number"
+          },
+          "slug": {
+            "type": "string"
+          },
+          "title": {
+            "type": "string"
+          },
+          "url": {
+            "type": "string"
+          }
+        },
+        "required": [
+          "slug",
+          "url"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "confident": {
+      "type": "boolean"
+    },
+    "locale": {
+      "type": "string"
+    },
+    "refusalReason": {
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "suggestedReading": {
+      "items": {
+        "properties": {
+          "distance": {
+            "type": "number"
+          },
+          "slug": {
+            "type": "string"
+          },
+          "title": {
+            "type": "string"
+          },
+          "url": {
+            "type": "string"
+          }
+        },
+        "required": [
+          "slug",
+          "url"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "threshold": {
+      "type": "number"
+    },
+    "topDistance": {
+      "type": [
+        "number",
+        "null"
+      ]
+    }
+  },
+  "required": [
+    "confident",
+    "answer",
+    "citations",
+    "suggestedReading"
+  ],
+  "type": "object"
+}

Removedget_offer

Changedsearch5 fields changed

removedInput schema / properties / k

Removed value: -{
-  "default": 5,
-  "maximum": 10,
-  "minimum": 1,
-  "type": "integer"
-}

addedInput schema / properties / limit

Added value: +{
+  "description": "Default 5.",
+  "maximum": 20,
+  "minimum": 1,
+  "type": "integer"
+}

addedInput schema / properties / locale

Added value: +{
+  "enum": [
+    "ru",
+    "en",
+    "ko",
+    "zh-hant"
+  ],
+  "type": "string"
+}

addedInput schema / properties / query / description
```
Added value: +"Search terms or a question."
```

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "hits": {
+      "items": {
+        "properties": {
+          "distance": {
+            "type": "number"
+          },
+          "slug": {
+            "type": "string"
+          },
+          "title": {
+            "type": "string"
+          },
+          "url": {
+            "type": "string"
+          }
+        },
+        "required": [
+          "slug",
+          "url"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    }
+  },
+  "required": [
+    "hits"
+  ],
+  "type": "object"
+}

1 tool updateAug 3, 2026
- Changedget_offer1 field changed
  - addedInput schema / required
```
Added value: +[
+  "query"
+]
```
1 tool updateJul 29, 2026
- Changedget_offer1 field changed
  - removedInput schema / required
```
Removed value: -[
-  "query"
-]
```
1 tool updateJul 28, 2026
- Addedget_offer
2 tool updatesJul 24, 2026
- First observedask
- First observedsearch

Related MCP Connectors

CanonicAI — cited Answers corpus A
com.canonicai
Read-only hosted MCP over CanonicAI's cited Answers corpus on canonicai.com.
Search RAG Systems
31
ezelOAuth
ai.ezel
Search U.S. case law, fetch opinions, and ask matter-aware legal questions over your documents.
Legal & Compliance Search
2
kvasir — verifiable German, Austrian, Swiss & EU lawOAuth
legal.kvasir
Resolve, search and verify legal citations against the official sources, with provenance.
Legal & Compliance Search
2
Listen to Sadhu A
app.listentosadhu
Read-only semantic search over Vedic scripture verses, commentaries, and recorded lectures.
Art & Culture Search Education & Learning Tools
212

Related MCP Servers

Enterprise Knowledge MCP
RAG Systems Vector Databases Search
IntuzSmitP
F
license
Not graded
quality
C
maintenance
Provides read-only, citation-backed semantic search and retrieval-augmented generation over enterprise documents via standardized MCP tools, with local embeddings for privacy.
Updated a month ago (2026-08-27 06:09 UTC)
-
AI Knowledge Base MCP Server
RAG Systems Search
Alpha-W0lf
A
license
B
quality
B
maintenance
Provides read-only hybrid RAG search and discovery over a local-first AI knowledge corpus, enabling semantic and keyword search, browse, digest, and status tools.
Updated a month ago (2026-08-25 03:01 UTC)
4
PolyForm Noncommercial 1.0.0
OmniClip RAG MCP Server
RAG Systems Search
EllisMorrow
A
license
Not graded
quality
A
maintenance
Read-only local-first MCP server enabling AI assistants to semantically search private Markdown, PDF, and Tika-backed knowledge bases without data upload.
Updated a month ago (2026-08-08 15:38 UTC)
45
MIT
braintube-mcp
Knowledge & Memory Search RAG Systems
lildaddyo
F
license
A
quality
B
maintenance
Persistent knowledge-base MCP server. Semantic search with source citations over saved YouTube videos, podcasts, articles and PDFs — one endpoint for every MCP-capable AI client.
Updated 2 days ago (2026-09-21 22:55 UTC)
28
-

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?