Teloa's resource format describes capabilities through types, versions, composition, and dependencies. An entry can be organized around an employee, team, application, skill, or MCP connection; extension packages provide distribution. Users choose more than a name: they also take on responsibilities, methods, and conditions of use.
We want the marketplace to help people fill the gap in front of them and understand what preparation remains. An existing employee missing a checking method calls for a different choice from work that has no continuing owner. Directing both toward a large solution adds duplicate configuration and makes the actual missing part harder to identify.
Identify the gap before choosing a resource type
Suppose an independent developer preparing a release wants to check the documentation for completeness. An existing documentation employee may know how to write but lack a release-checking method. The work may have no lasting owner at all. Or the method and owner may both exist, while change information in another system remains inaccessible.
These three situations suggest different places to look:
| Gap in the work | What to examine first | What to confirm before adoption |
|---|---|---|
| An owner exists, but checking steps are missing | A separately available skill or method | Whether it covers the missing checks and can be adopted by the existing role |
| The work recurs without an owner | An employee with explicit responsibilities and delivery requirements; a team when division of work is needed | Whether responsibilities overlap and which material, methods, and tools are required |
| Material cannot be obtained from another system | A connection or tool capability suitable for that source | Whether the source is supported, how authentication works, and who may use it within which scope |
Minimal sufficient adoption means introducing the capabilities needed to address the problem, together with their necessary dependencies. It need not be one resource or smaller than a complete solution. Every component should have a purpose. If documentation review only lacks a procedure, another employee with the same responsibility usually adds another contributor to coordinate. When research and review genuinely need to work together, an explicit division of responsibilities may save the effort of organizing them from scratch.
Composition gives people something concrete to inspect
“Documentation assistant” can help someone discover an entry, but says too little about adoption scope. It may provide a role definition alone or also reference skills, material, and connections. Composition and dependency information let the user examine how the employee works, which parts are supplied, and which they must prepare themselves.
Ordinary applications and connections can also depend on accounts, services, and configuration. Teloa additionally needs to explain how employees, methods, and tools fit together. Adopting a skill changes a procedure; adding an employee also creates a continuing responsibility; adopting a team calls for understanding several roles' division of work. Clear types are more useful than one vague meaning of “installation complete.”
A resource's source version and license also affect the choice. Inspectable definitions let people assess whether a checking method suits the job and whether they want to take on its preparation and maintenance, rather than decide from a description of promised results alone.
Visible composition has limits. Capabilities supplied by one extension package keep their shared installation ownership; they are not arbitrary copies that can each be uninstalled independently. A smaller starting point requires a resource actually offered separately, with its dependencies met. A composition format does not make every solution freely separable and recombinable.
A selected capability still needs to reach the original work
Suppose a suitable release-checking skill is found. After adding its content, the existing employee still needs to adopt the corresponding version and receive the actual material for this job. A connection entry needs its own authentication and configuration, followed by confirmation that it can obtain permitted material. Different resources have different preparation requirements rather than one mandatory installation sequence.
Teloa's marketplace handles discovery and distribution; existing resource services handle adoption and maintenance. Responsibilities are inspected with employees, methods viewed and revised as skills, and connection status checked through its configuration. Resource details, sources, and actual operation results together explain how far adoption has progressed. A capability mentioned in a description still needs to be assessed against what that entry currently supports.
This division lets users inspect content before making an operational choice. Viewing details, comparing requirements, and preparing drafts can help them decide. Installation, replacement, enabling, and authorization use their corresponding operations. Looking for a method need not also accept other changes the user has yet to decide on.
Assess the choice against the original gap
Return to the documentation review. After the method is adopted, do checks now cover the applicable version and supporting changes that were previously missed? Is it easier for the owner to review the result? Material still unavailable may point to the connection. Complete material left unchecked points instead to the method and whether it was actually adopted.
The marketplace's professional value lies in this explainable choice. People arrive with a gap in their work, can understand how candidates address it, and can see the conditions they still need to prepare. By the next release, what remains should be a working method suited to the original job, rather than a collection of entries still waiting to be used.