Skip to main content
Glama
kensaurus

Mushi-Mushi

by kensaurus
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Add an API key

add_byok_key

Add and validate a BYOK API key for supported AI providers in one app; store it encrypted in Supabase Vault, never return the raw key, and quarantine failed probes.

Instructions

Add and immediately validate a BYOK API key for anthropic | openai | openrouter | firecrawl | browserbase | cursor | supabase (a scoped, read-only Supabase access token, checked against the linked supabase_project_ref). The raw key is stored encrypted in Supabase Vault and never returned; failed probes remain quarantined. Optional baseUrl is accepted only for allow-listed OpenAI-compatible HTTPS providers. The key is added to this one app; a key for every app in the organization or every app you own (universal) is added in the console, Settings → AI keys. Write; NOT idempotent.

Input Schema

NameRequiredDescriptionDefault
keyYesThe API key value to add
labelNoHuman-readable label for this key
baseUrlNoAllow-listed OpenAI-compatible HTTPS base URL
priorityNoPriority for ordering (lower = higher priority)
providerYesProvider slug
projectIdYesProject id (`project_id` is accepted too.)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.1.14
    • changedInput schema / properties / provider / enum
      Previous value: -[
-  "anthropic",
-  "openai",
-  "firecrawl",
-  "browserbase",
-  "cursor"
-]New value: +[
+  "anthropic",
+  "openai",
+  "openrouter",
+  "firecrawl",
+  "browserbase",
+  "cursor",
+  "supabase"
+]
  2. Changed1 schema field changedv0.1.12
    • changedInput schema / properties / projectId / description
      Previous value: -"Project id"New value: +"Project id (`project_id` is accepted too.)"
  3. Changed1 schema field changedv0.1.10
    • changedInput schema / $schema
      Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
  4. Addedv0.1.8
  5. Removedv0.1.2
  6. First observedv0.1.0

TDQS

A4.5/5.0
Behavior5/5

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

Adds substantial behavior beyond the annotations: validation runs immediately on add, failures stay 'quarantined', the raw key is encrypted in Supabase Vault and never returned, and baseUrl is restricted to allow-listed OpenAI-compatible HTTPS providers. These are non-obvious consequences an agent could not infer from write/non-idempotent hints alone, and nothing contradicts 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.

Conciseness4/5

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

Four dense sentences, all information-bearing, with the core action front-loaded. It reads slightly run-on due to the parenthetical provider caveat and the console detour, but nothing is filler.

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 a write tool with no output schema, it covers the highest-risk unknowns: the secret is never returned, failures are quarantined, and scope is single-app. It does not say what a successful response contains (key id/label/validation status), which is a modest gap given the absence of an output schema.

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 coverage is 100%, so the baseline is 3, but the description adds real meaning the schema cannot: baseUrl is only valid for allow-listed OpenAI-compatible HTTPS endpoints, and the supabase provider expects a scoped read-only token validated against the linked supabase_project_ref. label/priority are not elaborated, keeping it from a 5.

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 ('Add and immediately validate a BYOK API key') plus the exact provider set, so it is unmistakable against siblings like list_byok_keys, test_byok_key, and remove_byok_key. It also pins the scope ('this one app') and names where the org-wide/universal variant lives instead.

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?

Clear about the condition that selects this tool (single-app key, validated on add) and explicitly routes the broader case away: 'a key for every app in the organization... is added in the console, Settings → AI keys.' It does not explicitly say to use test_byok_key for re-validation or remove_byok_key for cleanup, so it stops short of full alternates coverage.

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

Deploy Server

Other Tools