Skip to main content
Glama
kensaurus

Mushi-Mushi

by kensaurus
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

List your API key pool

list_byok_keys
Read-onlyIdempotent

List BYOK API keys grouped by provider to see which are validated, active, pending, legacy, shared, or rate-limited. Read-only; add new keys with add_byok_key.

Instructions

List the BYOK API keys this project uses, grouped by provider (anthropic | openai | openrouter | firecrawl | browserbase | cursor | supabase). Returns pooled { keys: [{ id, provider_slug, label, priority, status, cooldown_until, test_status, key_hint, base_url, last_tested_at, last_used_at, scope }] } where scope is project (this app), organization (every app in its organization) or universal (every app its organization owner owns); they are tried in that order, after the legacy credential. Also read-only { legacyKeys } metadata for credentials saved before the pooled lifecycle — never the raw secret. Read-only. Use to see which keys are validated, active, pending, legacy, shared, or rate-limited; use add_byok_key to add one.

Input Schema

NameRequiredDescriptionDefault
projectIdYesProject id (`project_id` is accepted too.)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.1.12
    • changedInput schema / properties / projectId / description
      Previous value: -"Project id"New value: +"Project id (`project_id` is accepted too.)"
  2. 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"
  3. Addedv0.1.8
  4. Removedv0.1.2
  5. First observedv0.1.0

TDQS

A4.2/5.0
Behavior4/5

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

Goes well past the annotations by disclosing the pooled resolution ordering (project -> organization -> universal, 'tried in that order, after the legacy credential') and explicitly stating the raw secret is never returned. The repeated 'Read-only' sentence only restates readOnlyHint=true, but the ordering and secret-exclusion details are real added value that annotations cannot convey.

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?

Purpose is front-loaded in the first clause, and every subsequent clause carries operational information. It is dense and somewhat run-on, packing a pseudo-schema field list and scope definitions into one paragraph, which slightly hurts scanability but not content value.

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 no output schema, the description correctly assumes the burden of describing the return shape, including the key object fields, the three scope tiers, and the legacyKeys metadata. Nothing an agent needs to interpret or invoke this single-parameter read is missing.

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?

Only one parameter with 100% schema description coverage, so the schema already documents projectId and its alias. The description implies the project scoping ('this project uses') but adds no syntax or constraint detail beyond the schema, making 3 the correct baseline.

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 (List) and resource (BYOK API keys for this project) plus the grouping dimension by provider, with the provider slugs enumerated. An agent can immediately distinguish it from add_byok_key, remove_byok_key, and test_byok_key in the sibling set.

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?

Explicitly names the trigger ('Use to see which keys are validated, active, pending, legacy, shared, or rate-limited') and routes the write-path to a sibling ('use add_byok_key to add one'). It stops short of naming when-not conditions or pointing at remove_byok_key/test_byok_key, so it is clear but not fully exhaustive.

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