GeezerVison

cubic-dev-ai Bot left a comment •

edited

Loading

Uh oh!

There was an error while loading. Please reload this page.

…es by default

Kalshi picks the verification algorithm from the registered public key: Ed25519 over the
pre-sign text, or RSA-PSS SHA-256 for an RSA key. The signer always passed the sha256 digest
and PSS padding, which Node and Bun refuse for an Ed25519 key, so every authenticated call
with a default key failed before it was sent. The key type is now read from the parsed key
(a PKCS#8 RSA key shares the Ed25519 PEM header), and any other key type is refused.

…tude block

An Amplitude credential holds a project's API key, secret key, and data residency region,
verified by listing the project's events on the region's Dashboard REST host with the Basic
key pair the tools send (Amplitude answers 403 for either key being invalid). The region and
key shapes are checked before any request. Each tool group maps only the params it declares:
analytics tools take both keys and the region, ingestion tools the API key and region, and
User Profile the secret key. The legacy block keeps its inline keys and is hidden from the
toolbar in favor of amplitude_v2.

…lock

A Kalshi credential holds an API key ID and its private key, verified by a free balance read
signed the way the tools sign every authenticated call; a key that cannot sign or a key ID that
would break the header is refused before any request. The tools that sign requests map the
key ID and private key from the credential, while market data stays public, so kalshi_v3
shows the credential picker only on account and trading operations. Token credential fields
gain an optional multiline flag so the connect form keeps a pasted PEM key's line breaks.
kalshi and kalshi_v2 keep their inline keys and now point at kalshi_v3.

…only Splunk block

A Splunk credential holds an authentication token and the management URL, verified by reading
authentication/current-context (documented, no capability needed) through the guarded egress
with the URL normalized as the tools build it; an answer without a user context is not taken as
proof, and certificate verification is never relaxed. The tools send the token whenever one is
set, so the credential policy marks the inline username and password as replaced by the token:
tokenCredentialOAuth gains an optional list of such params, and the saved-credential contract
accepts any token-filled param (not only accessToken) beside them. splunk keeps its inline
connection fields and points at splunk_v2.

…B Insights block

A CB Insights credential holds the client ID and secret, verified by exchanging them at
POST /v2/authorize, the call the tools make before their first request; a success without a
token is not taken as proof, and the error body is never logged. The tools keep minting and
caching their own token per run, so the credential fills the same client ID and secret they
take inline. The lookup's profileUrl is request data sent to api.cbinsights.com, recorded as
such in the saved-credential contract. cbinsights keeps its inline client fields and points at
cbinsights_v2.

The Kalshi signer is exercised by its tests and the CB Insights API base by the saved
credential check, so neither is unused any more.

… param other than accessToken

The saved-credential contract now accepts any credentialParams entry filled with the token beside
tokenReplacesParams (Splunk's authToken), and names that in its error.

…nly Railway block

A Railway credential holds a token, its type (account, workspace, or project), and for a
workspace token the workspace ID. Each type is verified with the read Railway documents for its
scope, since `me` answers only an account token: an account token reads `me`, a workspace token
reads its workspace by ID (passed as a GraphQL variable), and a project token reads
`projectToken` with the Project-Access-Token header the tools send for it. A GraphQL error or a
body without the queried object is not taken as proof. The tools receive the token and its type,
so a project token keeps its own header.

Token credential fields gain an optional flag: an optional field is left out of the required
create fields, the connect form does not require it and omits it when blank, and the secret
builder stores it only when set. Existing descriptors declare no optional field, so their
required fields and stored secrets are unchanged. railway keeps its inline token and points at
railway_v2.

… a credential-only Qdrant block

A Qdrant credential holds a database API key and the instance URL, verified by listing
collections (a read every key may run; a collection-scoped key sees a filtered list) with the
api-key header the tools send, through the guarded egress with the URL normalized as the tools
build it. An answer without a collection list is not taken as proof. The tools receive the key
and the verified URL, so a run reaches only that instance. qdrant keeps its inline URL and
optional key, which a self-hosted instance without an API key still needs, and points at
qdrant_v2.

The successor test matrix counts a field repeated per operation (Qdrant's URL) once.

…builder

The optional flag was honored by the create contract and connect form for any
field, but the secret builder only applied it to the workspace ID and still
required any domain field. Derive both the same way, and store a domain only
when it is required or supplied. No descriptor marks a domain optional today,
so stored secrets are unchanged.

Amplitude's User Profile API documents only Basic authentication with the
project API key and secret key. A saved Amplitude credential now fills the API
key too, and the tool sends Basic auth whenever an API key is present. Inline
calls that pass only the secret key keep the Api-Key header they sent before.

Drop the PKCS#1, query-string, literal newline and auth-header cases, which
restate unchanged behavior or repeat the validator's Ed25519 check.

…v2 block TSDoc

cubic-dev-ai Bot left a comment