Skip to main content
Glama

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
BSP_API_URLNoOverride BSP API base URL (default: https://api.biologicalsovereigntyprotocol.com).
BSP_NETWORKNoNetwork to use: mainnet or testnet (default: mainnet).
BSP_BEO_DOMAINYesThe user's BSP identity domain (e.g. alice.bsp). Required.
BSP_IEO_API_KEYNoAPI key for IEO-scoped operations (bsp_list_beos, bsp_list_ieos, bsp_submit_biorecord).
BSP_PRIVATE_KEYNoHex-encoded Ed25519 private key required for write tools (bsp_lock_beo, bsp_unlock_beo, bsp_destroy_beo, bsp_revoke_all_tokens).
BSP_REGISTRY_URLNoOverride relayer/registry endpoint (default: https://api.biologicalsovereigntyprotocol.com).
BSP_CONSENT_TOKEN_IDNoToken ID issued by the BEO holder. Required for data access tools.

Instructions

Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.

This server publishes no instructions, or was last inspected before Glama recorded them.

Capabilities

Features and capabilities supported by this server

Protocol revision2025-11-25

CapabilityDetails
tools
{}

Tools

Functions exposed to the LLM to take actions

NameDescription
bsp_get_biorecordsA

Read BioRecords from the user's BEO (biological identity). Requires an active ConsentToken with READ_RECORDS intent. Returns biological measurements in BSP format with values, units, reference ranges, and collection timestamps.

bsp_get_beo_summaryA

Get a structured overview of the user's biological profile — what categories of data exist, how many records per category, most recent measurement dates, and overall data completeness. Requires active session consent. Use this before bsp_get_biorecords to understand data scope.

bsp_resolve_biomarkerA

Look up information about a specific BSP biomarker code — name, category, level, and clinical context. Public taxonomy data — no consent required.

bsp_list_categoriesA

List all BSP taxonomy categories with level information. Public data — no consent required. Use this to understand what biological data categories exist and which are relevant for a user's health question.

bsp_lock_beoA

Emergency lock — freezes the BEO immediately. No reads or writes permitted while locked. Only the BEO holder can lock or unlock. Requires the private key configured in BSP_PRIVATE_KEY.

bsp_unlock_beoA

Unlock a previously locked BEO. Requires the BEO holder's private key.

bsp_destroy_beoA

IRREVERSIBLE — Permanently destroy a BEO (LGPD Art. 18 / GDPR Art. 17). Nullifies public key, revokes all ConsentTokens, releases domain. The user MUST confirm before executing this tool.

bsp_revoke_all_tokensA

Emergency revocation — revokes ALL active ConsentTokens for a BEO. No institution will be able to access any data after this.

bsp_check_consentA

Check the current consent configuration — which BEO is connected, which data categories and intents are authorized, and when the token expires. Run this first to understand what data you are allowed to access in this session.

bsp_list_beosB

List BEOs accessible to the configured IEO

bsp_list_ieosB

List registered IEOs on the BSP network

bsp_verify_consentB

Verify if a ConsentToken is valid and has the required intent

bsp_submit_biorecordA

Submit a BioRecord for a BEO (requires SUBMIT_RECORD consent)

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A3.9/5.0

Scored across 13 tools

Disambiguation4/5

Most tools target clearly distinct resources and actions: BEO lifecycle, consent, records, taxonomy, and network listings. The only real ambiguity is between bsp_check_consent and bsp_verify_consent, though their descriptions distinguish session-level configuration from validating a specific token.

Naming Consistency5/5

All tools share the bsp_ prefix and follow a consistent verb_noun pattern: list_beos, get_biorecords, submit_biorecord, destroy_beo, lock_beo, revoke_all_tokens, etc. Even near-synonyms like check and verify do not break the naming scheme.

Tool Count5/5

13 tools is well-scoped for this domain and each tool maps to a distinct operation: discovery, consent checking, record reads/writes, taxonomy lookup, and emergency controls. There is no obvious redundancy or padding.

Completeness4/5

Core workflows are well covered: list available entities, check/verify consent, summarize and read BioRecords, submit new records, resolve biomarkers, and handle emergency lock/revoke/destroy actions. Minor gaps exist, such as no explicit consent token issuance or update/delete for individual records, but these may reasonably be outside the server's intended role.

Maintenance

ActivityInactive
ResponsivenessNo issues