SDKs
The LTHN platform favours a thin-client approach: use the published Go and PHP packages when they fit, or call the API and MCP surfaces directly.
PHP
Server-side package lane
Go
CLI and automation lane
HTTP
Raw transport lane
MCP
Agent client lane
What ships with it
Pick the thinnest integration that works
Most clients only need HTTP or MCP. Reach for packages when you want framework conventions baked in.
One contract, multiple transports
The same plans, sessions, scoring, and registry concepts show up in REST, MCP, and package-level integrations.
Good defaults for agent clients
MCP remote configs and API key scopes make it straightforward to onboard a coding agent or assistant.
Documentation first
Package and protocol docs are public, so teams can validate the contract before they commit to an integration style.
Surface area
PHP packages
core/php · lthn/agent · lthn/api · lthn/mcp
Best when you are already inside the Laravel stack and want the same patterns the platform uses internally.
Go tooling
core CLI
Best when the job spans repositories, release automation, or build orchestration.
REST clients
api.lthn.*
Best for backend systems, dashboards, or scripts that want explicit HTTP endpoints and generated OpenAPI docs.
MCP clients
mcp.lthn.*
Best for AI assistants and agent runtimes that already speak the Model Context Protocol.
Choose the right lane
There is no thick, generated SDK layer here by design. The package docs and protocol docs are the contract.
PHP app -> use Core PHP + agent/API/MCP packages
Build tooling -> use Core Go
HTTP client -> call api.lthn.* with scoped API keys
AI assistant -> connect to mcp.lthn.* via MCP remoteRead the contract
Use packages for conventions, and protocols for interoperability.
That split keeps the platform easy to automate without hiding the contract behind code generation.