2. Worldview and foundations · Concept guide
What Is Intelligent Access
On a narrow screen, scroll each comparison table horizontally. Focus a table region to scroll with the keyboard.
An AI can explain how to use a system without being able to connect to it, read its data, or perform an operation. Doing those things requires a specific entry point, as well as the right runtime environment and permissions.
In CapaLens, Intelligent Access (IA) means specific endpoints and access capabilities that an AI or large language model application can connect to, invoke, or operate. It covers forms such as MCP, APIs, CLIs, SDKs, and remote connections. The concept answers a practical question: through which entry points can an AI use which external capabilities?
Understanding this concept helps you find suitable tools and interpret the entries, counts, and verification status in a directory.
Intelligent Access is a category of capability
“Intelligent Access” is a concept for organizing and describing these entry points. MCP is a specific protocol, while API, CLI, and SDK describe different forms: programmatic interfaces, command-line tools, and software development kits. They occupy different technical layers and can coexist.
For example, an SDK may wrap a service's API, an MCP server may call an API internally, and a command-line tool may connect to a remote service. Different forms of access can expose overlapping business capabilities.
Here, “intelligent” describes the relationship between an entry point and an AI workflow. It does not require every connected service to have a built-in large language model. A conventional tool can also provide Intelligent Access if it has a clear connection or invocation path that an AI application can use within its authorized scope.
Common forms of access
The table below covers common forms, rather than every possible way to connect.
| Form | What is the entry point? | What should you check when connecting? |
|---|---|---|
| MCP | An MCP server that exposes capabilities to a client, potentially including tools, resources, and prompt templates | Server identity, connection method, client compatibility, and authorization requirements |
| API | A programmatic interface for sending requests and receiving results according to a defined contract | Address, methods, inputs and outputs, authentication, and usage limits |
| CLI | A command-line tool that can be invoked in a terminal or script | Installation method, command arguments, runtime environment, output, and exit status |
| SDK | A software development kit used in a particular programming environment | Package and version, language environment, initialization, and invocation instructions |
| Remote connection | An entry point to a remote host or execution environment | Target environment, connection protocol, identity, permissions, and permitted operations |
The official MCP documentation describes how clients and servers connect, along with capabilities such as tools, resources, and prompt templates. Servers can run locally or remotely, so an MCP entry point cannot simply be equated with “a web address.” MCP architecture
GitHub provides an example of these different forms: it offers a REST API, GitHub CLI for terminals and scripts, and official Octokit libraries for programmatic integration. These entry points support related business capabilities, but their usage and dependencies differ. Getting started with the REST API, GitHub CLI manual, Official client libraries
Remote connections provide another kind of entry point. For example, VS Code Remote SSH can connect to a remote environment and run terminal commands and most workspace extensions there; interface extensions may still run locally. Bringing that environment into an AI workflow also requires suitable execution tools and authorization. The existence of an SSH address alone does not mean that any AI application can use it. VS Code Remote SSH documentation
What counts as an independent access unit?
When organizing an IA directory, it helps to distinguish several objects that are easily confused.
| Object | What does it represent? | How does it relate to access counts? |
|---|---|---|
| Vendor or project | The provider or maintainer of a capability | One provider may offer several independent entry points |
| Source record | A lead or piece of evidence obtained when collecting an entry | Several source records may refer to the same entry point |
| Documentation or presentation page | A place that explains, presents, or summarizes information | One page may describe several entry points |
| Function, method, or subcommand | An operation available within an entry point | It does not automatically become a separate access entry |
| Independent access unit | An independently identifiable object with a clear access path and capability boundary | This is the object that an access count should describe |
Three questions help determine whether something warrants its own entry:
- Is its identity clear? You can explain who provides it, what it is called, and how it differs from other objects.
- Is its entry point specific? There is traceable evidence such as a service address, interface definition, software package, launch command, or connection configuration. A promotional description of a capability alone is insufficient.
- Is its boundary clear? You can explain what it provides, what it depends on, and how it relates to other entry points within the same product.
An API endpoint, MCP server, or installable tool may constitute an independent access unit. The appropriate level of detail depends on its public identity, access boundary, and supporting evidence. A documentation page listing many functions does not establish that each function is a separate access unit.
A product's MCP, API, and CLI should neither be counted separately nor merged solely because of their labels. Assess whether they have independent entry points and configuration boundaries, and record their relationships. Overlapping underlying capabilities do not necessarily make entries duplicates. Different names, languages, or URL formats do not necessarily indicate new entry points either.
One page can contain several access units
The following is an illustrative example. It does not represent CapaLens's current data or any vendor's actual configuration.
Suppose a single documentation page for a data service describes:
- A search MCP server with its own connection instructions.
- A file extraction API with its own address, input and output definitions, and authentication instructions.
- A batch-processing CLI that can be installed, configured, and run independently.
If each meets the criteria for an independent unit, they can form three access entries even though they appear on the same page. Conversely, the same MCP server appearing on an official website, in a code repository, and in a tutorial may still be one unit supported by several sources of evidence.
If the page also lists ten CLI subcommands, that does not automatically add ten more entries. If an accompanying SDK is merely a calling example or wrapper for an existing API, its additional name alone does not justify another entry. Splitting entries requires sufficient evidence of independent identity and access boundaries.
Therefore, the number of URLs, pages, or source records cannot be treated directly as the number of Intelligent Access units.
Access counts should be open to review
A meaningful access count requires deduplication, traceable sources, and clear entry points.
In practice, duplicate records referring to the same unit should be consolidated while retaining their sources. A page should also be checked for multiple independent entry points so that units are not missed. Where similarly named offerings have different maintainers, official and third-party implementations coexist, or multiple deployment forms exist, their relationships should be explained. Names or domain names alone are insufficient grounds for automatic merging.
Published counts should state their date, granularity, and scope. Are they counting access units, vendors, or source records? Do they include inactive entries, entries awaiting verification, or leads without further evidence? Numbers are comparable only when they use consistent definitions.
Traceability does not establish reliability. Entries should distinguish official documentation, official repositories, third-party implementations, and community material wherever possible, so readers can return to the evidence and assess it themselves.
What listing and verification each tell you
A directory helps you discover entry points. Verification provides evidence about using them within a defined scope. When reading an entry, distinguish the following types of information.
| Record type | What does it establish? | What cannot be inferred from it? |
|---|---|---|
| Listed | An entry point's lead, description, and sources have been recorded | That it has connected successfully, works with every client, or is reliably usable |
| Automated checks | Specified checks have been run automatically and their results recorded | That every business workflow succeeds or that the results remain valid indefinitely |
| Manual verification | A person has confirmed specified information, such as identity, documentation, or configuration instructions | That an actual connection or a complete business operation has necessarily been performed |
| Business workflow testing | Actual tests have been performed with a specified account, environment, version, and task | That other accounts, environments, and tasks will produce the same results |
These labels need an accompanying scope and result; their names alone are insufficient. “Checked” differs from “passed the checks.” “A person verified the official source” also differs from “a person completed a business call.” When a test fails, the cause still needs to be distinguished: an inactive entry point, insufficient authorization, environmental restrictions, or unmet test conditions.
An untested entry point should not automatically be classified as unusable, but it cannot be given a reliability guarantee either. Users should consider how recent the evidence is, which environments it applies to, and the risks of their task when deciding whether further verification is needed.
Questions to answer before use
Once you find an entry point, start with these questions:
- Does it fit the task? Do the capabilities it actually exposes cover what you need to do?
- Does your environment support it? Does your AI application have the required client, runtime, execution tools, or adapter?
- Are the permissions appropriate? Which account and authorizations are needed, and can they be limited to what the task requires?
- Is the evidence sufficient? Which information has merely been listed, which has been checked or tested in practice, and what did the most recent verification cover?
- What consequences could the operation have? Could it write data, incur charges, or trigger external actions? Can you try it in a low-risk environment first?
An access path may exist even though your environment does not yet meet its requirements. A capability may also be usable but unsuitable for your current task. Making those distinctions is more helpful than simply attaching a “supports AI” label.
The value of Intelligent Access lies in making external capabilities available through identifiable, connectable, and understandable entry points. For CapaLens, each directory record becomes a useful reference when it clearly explains what the entry point is, how to connect, where the evidence comes from, and how far verification has gone.