Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
36 changes: 36 additions & 0 deletions .well-known/mcp.json
Original file line number Diff line number Diff line change
@@ -0,0 +1,36 @@
{
"name": "getbased",
"description": "MCP server that exposes your getbased health data — blood work context, biomarker sections, and an optional RAG knowledge base — as tools for any MCP-compatible agent. Your data stays on your device; the server reads a read-only context summary, not raw records.",
"version": "0.2.0",
"transport": "stdio",
"hosting": "local",
"homepage": "https://getbased.health",
"documentation": "https://app.getbased.health/docs/guide/agent-access",
"repository": "https://github.com/elkimek/getbased-agents/tree/main/packages/mcp",
"license": "GPL-3.0-only",
"install": {
"pypi": "getbased-mcp",
"command": "getbased-mcp",
"bundle": {
"package": "getbased-agent-stack",
"repository": "https://github.com/elkimek/getbased-agents/tree/main/packages/stack",
"description": "Meta-package that bundles the MCP server with the RAG backend and example Claude Code / Hermes / OpenClaw configs."
}
},
"authentication": {
"type": "token",
"env": "GETBASED_TOKEN",
"description": "Read-only token generated in the getbased app under Settings > Data > Messenger Access. Grants access to lab-context text only — no raw data, no write access. Revocable at any time by regenerating the token."
},
"gateway": "https://sync.getbased.health",
"tools": [
{ "name": "getbased_lab_context", "description": "Full lab summary — biomarkers, ranges, trends, context cards, supplements, goals. Pass a profile to target a specific profile." },
{ "name": "getbased_section", "description": "Get a specific section (e.g. hormones, lipids) or list all available sections. Token-efficient alternative to the full dump." },
{ "name": "getbased_list_profiles", "description": "List available profiles by name and ID." },
{ "name": "knowledge_search", "description": "Semantic search across the active library of your RAG knowledge base. Requires the getbased-rag server; degrades gracefully if unavailable." },
{ "name": "knowledge_list_libraries", "description": "List all knowledge-base libraries and show which is active." },
{ "name": "knowledge_activate_library", "description": "Switch the active knowledge-base library for subsequent searches." },
{ "name": "knowledge_stats", "description": "Per-source chunk counts for the active library — useful for diagnosing missing results." },
{ "name": "getbased_lens_config", "description": "Show the Custom Knowledge Source endpoint configuration used by the getbased app." }
]
}
3 changes: 3 additions & 0 deletions robots.txt
Original file line number Diff line number Diff line change
@@ -1,6 +1,9 @@
# getbased.health robots.txt

# Content Signals — open-source project, all uses welcome
# search: appear in search results | ai-input: ground AI answers (RAG) | ai-train: train AI models
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 Content-Signal is placed inside the User-agent: * record (between the agent directive and the Allow/Disallow lines). Standard robots.txt parsers ignore unknown directives in a record, so crawlers are unaffected. However, if Cloudflare's Content-Signal parser treats this as a per-agent field rather than a global one, the signal may be scoped only to the wildcard agent block rather than applying site-wide. Consider moving it above the first User-agent: line or placing it after all records to make the global intent explicit and future-proof the parsing.

Copy link
Copy Markdown
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Leaving this as-is. Per Cloudflare's Content Signals spec, Content-Signal is a per-record directive — it belongs inside a User-agent group alongside Allow/Disallow, not above the first User-agent: line. Placing it in the User-agent: * record is the documented pattern and applies site-wide via the wildcard. The specific bot records below (OAI-SearchBot, etc.) don't inherit it, but since every signal is yes and those bots are already fully allowed, repeating it there would just be noise.

The vercel.json comment is addressed in 89fb86d (relative URLs).

User-agent: *
Content-Signal: search=yes, ai-input=yes, ai-train=yes
Allow: /
Disallow: /thank-you
Disallow: /blog-template
Expand Down
4 changes: 4 additions & 0 deletions vercel.json
Original file line number Diff line number Diff line change
Expand Up @@ -11,6 +11,10 @@
"key": "Content-Security-Policy",
"value": "default-src 'self'; script-src 'self' 'unsafe-inline' https://umami-iota-olive.vercel.app; style-src 'self' 'unsafe-inline' https://fonts.googleapis.com; font-src 'self' https://fonts.gstatic.com; connect-src 'self' https://api.github.com https://umami-iota-olive.vercel.app; img-src 'self' data:; frame-src 'none'; object-src 'none'; base-uri 'self'"
},
{
"key": "Link",
"value": "</llms.txt>; rel=\"alternate\"; type=\"text/plain\"; title=\"llms.txt\", </.well-known/mcp.json>; rel=\"service-desc\"; type=\"application/json\"; title=\"MCP server card\""
},
Comment thread
greptile-apps[bot] marked this conversation as resolved.
{ "key": "X-Content-Type-Options", "value": "nosniff" },
{ "key": "X-Frame-Options", "value": "DENY" },
{ "key": "Referrer-Policy", "value": "strict-origin-when-cross-origin" },
Expand Down
Loading