Vascueの公開ドキュメント（医療オペレーション、クリニック向けAIフロントデスク、プロバイダー側の保険請求自動化、Cliniko連携、セキュリティ、事例、料金）を検索するModel Context Protocolサーバーです。
同等の2つの形態があります：
ホステッド版（常に最新）： https://www.vascue.io/mcp/search - ストリーミングHTTP、認証不要。
自己完結型（このリポジトリ）： python server.py - 公開ページのバンドルスナップショット（content/、リリースごとにscripts/fetch_content.pyで更新）に対するローカルBM25検索。実行時にネットワーク呼び出しがないためオフラインでも動作し、ディレクトリビルドのリリースで実行されるものです。
エンドポイント： https://www.vascue.io/mcp/search（ストリーミングHTTP、認証不要）
サーバーカード： https://www.vascue.io/.well-known/mcp/server-card.json
レジストリ名： io.vascue/public-knowledge-search
運営： Vascue Limited（ISO 27001認証取得）
公開コンテンツのみ。 このサーバーは公開された製品・教育ページのみをインデックス化します。患者情報、請求書類、クリニックの認証情報、予約リクエストを送信しないでください。エージェントベースのクリニック予約は別の研究パイロットであり、公開APIではありません。
ストリーミングHTTPに対応したMCPクライアントは、エンドポイントに直接接続できます。
Claude Code
claude mcp add --transport http vascue-search https://www.vascue.io/mcp/searchCursor / Claude Desktop / その他のstdio専用クライアント（mcp-remote経由）
{
"mcpServers": {
"vascue-search": {
"command": "npx",
"args": ["-y", "mcp-remote", "https://www.vascue.io/mcp/search"]
}
}
}自己完結型ローカルサーバー（stdio、バンドルスナップショット、ネットワーク不要）
pip install -r requirements.txt
python server.pyDocker（自己完結型サーバーをビルド）
docker build -t vascue-public-knowledge-search .
docker run -i --rm vascue-public-knowledge-searchRelated MCP server: Cliniko MCP Server
ツールは1つ、認証不要、読み取り専用です。
searchVascueの公開ページに対するハイブリッド（キーワード＋ベクトル）検索。一致した抜粋とその正規のhttps://www.vascue.io/... URLを返すため、回答で出典を引用できます。
入力 | 型 | 備考 |
|
| 自然言語の質問またはキーワード（例：「Vascueは保険請求の事前承認をどのように処理しますか」） |
|
| デフォルトはhybrid。 |
|
| デフォルトは8。 |
|
| デフォルトは0.35。 |
|
| 含める隣接チャンク数。 |
クエリの書き換えと再ランキングはサーバー側で無効化されています。サーバーはソースチャンクのみを返し、生成された回答は返さないため、引用なしにVascueの声明として提示されることはありません。レート制限：クライアントあたり毎分60リクエスト。
呼び出し例：
{ "name": "search", "arguments": { "query": "Cliniko integration for AI front desk" } }エンドポイントは、vascue.ioの承認済み公開Markdownエクスポートに対するCloudflare AI Searchインスタンスによって支えられています（https://www.vascue.io/.well-known/ai-search.jsonのサービス記述子に、何がインデックス化され、何がされないかが記載されています）。
docker build -t vascue-public-knowledge-search .
node scripts/smoke.mjs docker run -i --rm vascue-public-knowledge-search # initialize -> tools/list
node scripts/smoke.mjs npx -y mcp-remote https://www.vascue.io/mcp/search --transport http-onlyCIはプッシュのたびと毎週、同じビルドとスモークテストを実行するため、上記のバッジはエンドポイントの健全性インジケーターを兼ねています。
ソースからサーバーをビルドするディレクトリ（例：Glama）は自己完結型を実行します。生成されるビルドイメージは異なるため（pipなしのuv管理Python、またはPEP 668の外部管理システムPython）、明示的なvenvを使用してください：
ビルド手順：["uv venv /opt/venv && uv pip install --python /opt/venv/bin/python -r requirements.txt"]
CMD：["/opt/venv/bin/python", "server.py"]
環境変数は不要。
通常のpipが存在する場合は、単純なpip install -r requirements.txt + ["python", "server.py"]でも動作します。
pip install -r requirements.txt
SMOKE_CALL_QUERY="Cliniko integration" node scripts/smoke.mjs python server.py # local server
node scripts/smoke.mjs python bridge.py # stdio bridge to the hosted endpoint
python scripts/fetch_content.py # refresh the content/ snapshothttps://www.vascue.io/llms.txt
https://www.vascue.io/openapi.json（公開・読み取り専用のコンテンツAPI）
https://www.vascue.io/.well-known/agent-skills/index.json（エージェントスキル。vascue-io/skillsにもあります）
このリポジトリ（README、マニフェスト、Dockerfile）はMITライセンスです。エンドポイントが提供するコンテンツはVascueの公開ウェブサイトのコンテンツです。
Keyword (BM25) search over a bundled snapshot of vascue.io's public pages: healthcare-operations guides, the AI front desk for clinics, provider-side insurance-claims automation, Cliniko and Nookal integration, security and compliance pages, case studies, pricing and blog posts.
Use it to answer questions about what Vascue offers, how its products work and what it has published. One topic per call; cite the returned page URL for every excerpt you use.
Returns {"chunks": [...]} ordered by relevance; each chunk has url (the canonical https://www.vascue.io/... page), title, score (0-1 relative to the best match) and text (a Markdown excerpt). An empty list means the snapshot does not mention the topic - say so rather than guessing. The index is a point-in-time copy of the public site; https://www.vascue.io/mcp/search is the always-current hosted twin.
Runs fully locally: read-only, idempotent, no network calls, no authentication. Public content only: never send patient information, claim documents, clinic credentials or booking requests. It cannot book appointments or look up clinic data.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | What to look for, as a natural-language question or keywords, e.g. "how does claims pre-authorisation work" or "Cliniko integration". 3-15 words works best; one topic per call. | |
| max_num_results | No | Maximum excerpts to return (default 8). |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover read-only, idempotent, non-destructive. The description adds substantial context beyond those: it runs fully locally with no network calls and no authentication, it is a point-in-time snapshot with an always-current hosted twin, and it imposes a data-sensitivity contract ('never send patient information, claim documents, clinic credentials or booking requests'). This safety framing is exactly the kind of behavioral disclosure that annotations alone do not convey.
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?
Though long, every sentence earns its place: purpose, content scope, usage constraints, return format, snapshot caveat, hosted twin, execution model, and safety contract are each distinct and non-redundant. The high-level purpose is front-loaded before the supporting detail, and the safety constraints are positioned last with a clear warning nature. There is zero filler or repetition of annotation content.
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?
For a search tool with an output schema, the description is fully sufficient: it explains the relevance ordering and score semantics ('0-1 relative to the best match'), specifies the empty-list meaning, flags the snapshot-versus-live-site distinction, and defines the safety envelope. Even though an output schema exists, the description voluntarily clarifies return-value semantics, which removes any ambiguity about how to interpret results. Nothing an agent needs to call and use it correctly is missing.
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% — both `query` and `max_num_results` have detailed schema descriptions including the 3-15 word recommendation and default/maximum values. The description largely reinforces the schema's 'one topic per call' advice rather than adding new parameter-level meaning. It does clarify the return structure (chunks with url/title/score/text and relevance ordering), but that is output semantics more than parameter semantics, so the high-coverage baseline 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 states a specific verb and resource — 'Keyword (BM25) search over a bundled snapshot of vascue.io's public pages' — and enumerates the exact content domains covered (guides, clinic products, integrations, security/compliance, case studies, pricing, blog). This is far beyond a tautology; an agent knows precisely what content the tool can reach and that it operates over a snapshot, not the live site. No siblings exist, so the specificity of the resource alone distinguishes it cleanly.
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?
Usage context is explicit: 'Use it to answer questions about what Vascue offers, how its products work and what it has published,' with operational constraints — 'One topic per call; cite the returned page URL for every excerpt you use.' It also states clear negative capabilities ('It cannot book appointments or look up clinic data') and behavior on empty results ('say so rather than guessing'). Since there are no sibling tools to route among, this fully satisfies the when/when-not guidance dimension.
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.
v0.1.0searchWith only one tool, there is no risk of confusion between tools. The 'search' tool's purpose is unambiguous and clearly scoped to a specific domain (Vascue public knowledge).
The single tool is named 'search', which is a simple, clear verb that perfectly matches its function. There is no inconsistency to evaluate, and the name is intuitive.
The server provides exactly one tool, which is slightly below the typical 3-15 tool range. However, given the narrow purpose of 'Public Knowledge Search', a single search tool is well-scoped and earns its place, making the count appropriate.
The tool covers the entire domain of knowledge search for Vascue's public pages, including search, relevance ranking, and citation of sources. There are no obvious missing operations for its stated purpose; it is a complete, focused toolkit.
Hosted MCP server for Cliniko — patients, appointments, availability, and invoices for AI agents.
Search the SiteGPT documentation: setup, features, API reference, troubleshooting.
Search and fetch AgendaForge public documentation and marketing content. No authentication needed.
Docs Q&A: search 169 data and AI guides, fetch any page as markdown. Read-only, keyless.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/vascue-io/public-knowledge-search'
If you have feedback or need assistance with the MCP directory API, please join our Discord server