Directory layout
A typical project looks like this:.hyperterse
package.json
app
adapters
primary-db.terse
cache-store.terse
tools
get-user
config.terse
input-validator.ts
data-mapper.ts
get-weather
config.terse
handler.ts
Root configuration
The.hyperterse file contains service-level settings: name, version, server port, log level, cache defaults, and build options. It does not contain adapter or tool definitions — those live in app/.
When you run hyperterse start or hyperterse build without arguments, the CLI looks for .hyperterse in the current directory. See Root configuration reference for the complete field specification.
Adapter discovery
The compiler scansapp/adapters/*.terse at build time. Each file defines exactly one adapter. The filename (without extension) becomes the adapter’s identifier, unless the file explicitly sets a name field.
See Adapters for how adapters work, and Adapter configuration reference for the field specification.
Tool discovery
The compiler scansapp/tools/*/config.terse at build time. Each config.terse file defines one MCP tool. The directory name becomes the tool name, unless the file explicitly sets a name field.
Every tool must define either a database connection (use) or a handler script (handler). Tools with neither are rejected during validation.
See Tools for execution models, and Tool configuration reference for the field specification.
Script resolution
Script paths in tool configs are resolved relative to the tool directory. You can declare them explicitly, or rely on convention-based discovery. Common conventions includehandler.ts, input.ts, and output.ts.
See Scripts for the full script model.
Vendor dependencies
If your tool scripts import npm packages, add apackage.json at the project root and install your dependencies. Build output includes everything needed to run scripts, so deployment does not depend on node_modules/ being present.