Skip to content

feat(connections)!: a record says type, a header names its scheme and the page takes the client id - #240

Merged
rami-hatoum merged 2 commits into
mainfrom
feat/a-connection-record-says-type-and-the-page-takes-the-client-id
Oct 18, 2026
Merged

rami-hatoum merged 2 commits into
mainfrom
feat/a-connection-record-says-type-and-the-page-takes-the-client-id

Conversation

@rami-hatoum

Copy link
Copy Markdown
Contributor

A connection's record said kind for its transport, mcp or openapi, where every other listing of a server says type. The record says type on the wire, in add_connection's input and in every answer that carries a connection; the ledger's command and facts, whose own type names them, say server_type, as a run's command carries definition_type. kind stays what it is elsewhere: the kind of a credential and the kind of a conflict.

A credential placed in a header, a pasted secret or a reference to the operator's variable, may name a scheme, a token such as Bearer that the runtime writes before the value when it places the credential, so a person pastes the token alone and the server receives Authorization: Bearer <token>, and an operator's variable holds the token alone. A scheme is refused where it does not belong, in a query parameter, in a security scheme of the document, or on a credential that places nothing, and so is a scheme holding $, which would read as the start of a reference; a pasted value that already starts with the scheme is refused with the words to paste the token alone. The scrubber is unaffected, since the person's value is the reference's value, scrubbed whole.

A client_credentials credential's client_id is the org's, so a person may give it on the page with the secret or the key instead of the agent giving it at add time. At add it is optional, and the addition's checks run with a stand-in where it is not yet given; on the page it is required when the credential holds none and refused when it holds one, and the addition's read runs with the given id before anything is kept, so a connection is never connected with an id the runtime would refuse at first use. connection_connected records the id and the fold sets it, so the serving reads one credential shape.

read_link answers the record with link.expires_at, from the expiry the issued link's fact holds, so the page can say how long the person has; approve and give_credential keep answering the record alone, since the link is used up.

The HTTP and MCP references, the self-host page for connections, the connections README and the OpenAPI document say the same. The tool listings grow by the scheme's field and stay under their bounds.

rami-hatoum and others added 2 commits October 18, 2026 16:49
…the page takes the client id

A connection's record named its server's transport kind, beside the kind of its credential and of
a conflict, while a server's settings and search say type. The record, the input of add_connection
and every answer that carries the record now say type, ConnectionTypeSchema, which picks mcp and
openapi from the type of a tool server entry; the command and connection_added say server_type,
since a fact's own type names the fact, as a run's command carries definition_type.

A secret or a reference sent in a header may name its scheme, which the runtime writes and a space
before the value it places, so a person pastes a token alone and an operator's variable holds the
token alone. A scheme is an HTTP token, checked with headerNamePattern of tool-servers, without $,
which the reading of the entry takes for a reference or an escape, and only in a header of a kind
that places a value; each refusal has words of its own. give_credential refuses a value that
starts with the scheme and a space. The scrubber holds the value whole, as a reference's value.

The client id of client credentials is the org's, so add_connection takes client credentials
without one, read with a client id standing in where the reading builds the auth block, and the
person gives it on the page beside the client secret or the private key. give_credential requires
it where the credential holds none, refuses it where it holds one, and reads it as the entry is
read at add time, so no connection is connected with a client id its use would refuse. One that
looks like a credential is refused in words of its own, at /client_id on the page and at
/credential/client_id for the agent, not in the words the settings file gets. The issuer, the
client id, the scope and the algorithm of a private key are placed with $$ for $, as the entry
is, so each is sent as written. connection_connected records a client id given on the page and
the fold sets it on the credential.

read_link answers the record with link.expires_at, from the issued link's fact, so the page can say
how long the person has; approve and give_credential answer the record alone.

The server's tests add their connections with type and read the link's expiry over HTTP, and the
OpenAPI document is regenerated, since its test holds it to what the server serves. The scheme and
the optional client id add 147 bytes to the input of add_connection: /mcp lists its tools in
43,310 bytes of 48,000 and the org endpoint in 12,767 of 13,000.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
… id and when a link ends

The HTTP reference names the record's type, the scheme a secret or a reference sent in a header
may name, which the runtime writes with a space before the value, the client id of client
credentials left to the page, which give_credential takes and refuses where it looks like a
credential, the link and its expires_at that read_link answers, and the refusals of each. The MCP
reference gives the input of add_connection and the scheme and the optional client id of its
credential. The operator's guide to connections names the type, says that the runtime writes the
scheme before the token, so a reference's variable holds the token alone, and that the person
gives a client id left out on the page. The engineering MCP reference and the README of the api
restate the sizes of the listings the server's test measures, and the README of tool-servers says
that its behaviour of a connection runs over both types of server.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
@rami-hatoum
rami-hatoum merged commit 1456a96 into main Oct 18, 2026
19 checks passed
@rami-hatoum
rami-hatoum deleted the feat/a-connection-record-says-type-and-the-page-takes-the-client-id branch October 18, 2026 16:35
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant