Extensibility · Architecture

What an agent can reach, and what it must be given first

The list of things an agent could connect to is a catalog. The list of things it has been given is a configuration. Confusing the two is how an agent reaches somewhere nobody intended.

Last updated September 28, 2026

September 18, 2026 · Extensibility · Architecture · 6 min read

Three separate mechanisms decide what a ClearFrame agent can do. They are worth keeping apart because each is configured in a different place and fails in a different way.

The three mechanisms

Skills

Packaged instructions and procedures the agent loads to approach a kind of work. ClearFrame ships built-in skills, and the interface names them individually.

MCP servers

Connections to systems outside the project: a database, an issue tracker, a browser. Each is a distinct integration with its own credentials.

The provider catalog

The models the agent can call. Choosing among them is a separate decision from choosing what it can reach.

A catalog is not a configuration

The distinction that prevents most accidents: being listed is not being connected. A catalog containing an integration tells a reader what is possible, not what is active. Every entry has to be added deliberately, and until it is, the capability is inert.

ClearFrame's Store presents MCP servers this way rather than as a set of switches flipped on by default. One entry in it exists purely for this reason: a plugin to discover and inspect MCP servers before connecting them, described as a way to explore public registry metadata and understand what a server does.

That is an unusual thing to ship as a feature — a tool whose only job is to help you decide whether to use a different tool — and it is the right shape. The step that gets skipped when browsing a catalog is reading what the thing does.

Skills are named, not implied

A skill is not a vague increase in competence. ClearFrame's built-in skills are discrete, named packages: a code-review skill, a website-shipping skill, and others, each with an identifier and a stated purpose. Loading one is an event with a name attached.

The practical consequence is that "the agent reviewed the changes" is a claim open to checking against what was loaded, rather than a description of observed behaviour. When skills are anonymous additions to a prompt, that check is not available.

Where the boundary is enforced

Capability and permission are separate questions, and ClearFrame answers them in different places. What an agent can reach is a matter of configuration; what it may do with what it reaches is the access level, which is set per task and capped at a scope the user grants.

A task that has been given a database connection and is running at workspace access has a reachable system it may not write to. Those are two controls on the same action, and neither is a substitute for the other. The access model is described in its own note.

What the agent does not reach

The default is the important part. A fresh task reaches the project folder and whatever models the account is configured for. It does not reach a database, an issue tracker or a browser until someone adds that integration, and the interface says which servers are connected rather than implying a general capability.

This is also where remote execution sits, and it is a different boundary again. Where remote runs are enabled, they use a separate workspace and local files are not uploaded automatically. A remote run having a network connection does not mean it has your files.

Stated limits

A listed integration may not be connectable. A catalog entry can describe a service ClearFrame cannot connect to directly, and the Store marks those as setup-with-the-publisher rather than offering a button that does nothing.
Credentials are per connection. Adding an integration is a deliberate act with its own authentication, not a global switch.
An installed capability is not a verified one. Adding a server means the agent can reach it. It does not mean the server behaves as its description claims, which is why inspection precedes connection.

The catalog is someone else’s information

Much of what a catalog contains was written by the publisher of the integration rather than by the tool presenting it. The description of what a server does, the setup it needs and the access it expects all originate elsewhere, and a catalog that presents them as its own claims takes responsibility for facts it cannot check.

ClearFrame’s Store draws that line in the interface. Entries ClearFrame genuinely cannot connect carry a discovery listing with a link to the publisher and a statement that external setup comes from the publisher or a compatible MCP server. No install button is offered for something it cannot install. An entry that cannot be acted on says so, and the action it offers is to read about it.

The same discipline the product applies to its own claims, directed outward: describe what is the case, and where a fact belongs to someone else, say whose it is.