{
  "markdown": "# AXF\n\n**Fit the repository once. Let every agent follow the same paved path.**\n\nAn agent can read your code. It still has to rediscover how this repository\nwants to be built, tested, searched, diagnosed, and operated. The clues are\nusually scattered across scripts, package tasks, prose, CI, and human memory.\n\nAXF (Agent eXoskeleton Framework) turns that repeated local ceremony into\nsmall, self-describing capabilities. Fit the exoskeleton deliberately once;\nlater agents can discover the right route, inspect its contract, and run it\nwithout rebuilding the procedure from scratch.\n\n```text\nrecurring repository ceremony\n          ↓ fit once\ninspectable AXF capabilities\n          ↓ reuse\nagent discovers → inspects → runs\n```\n\nAXF is a traffic cop, not a replacement vocabulary. It preserves a provider's\nexisting command family by default, then projects or normalizes only the parts\nthat need a clearer agent-facing contract. The goal is not to automate\njudgment. It is to spend less judgment on reconstructing the same route.\n\n## The five caller concepts\n\nYou do not need the framework vocabulary to use a fitted repository:\n\n- **Workspace** — the repository context whose operating paths you need. In\n  root-sensitive contracts, AXF distinguishes the project root used for\n  discovery from the execution root used as the runtime working directory.\n- **Module** — a reusable capability pack, such as the built-in `echo` module\n  or a repository-owned validation pack.\n- **Capability** — one named operation with declared arguments, output modes,\n  side effects, lifecycle, policies, and an execution target.\n- **Inspect** — read the complete contract before execution.\n- **Run** — execute through that contract after checking its effects and\n  authority requirements.\n\nThe smallest proof of life is:\n\n```sh\nnpm install --global @smartergpt/axf\naxf doctor\naxf list --compact\naxf inspect echo say\naxf run echo say --message hello\n```\n\nAXF 2.1.3 is published under Apache-2.0; earlier npm releases retain their\npublished terms. Outside a fitted workspace, with no root override, this example\ndiscovers the bundled manifests in the installed package. `doctor` reports that project root\nseparately from the current execution directory. An explicit `AXF_PROJECT_ROOT`\noverrides discovery; an empty directory without an `axf.workspace.json` marker\nhas no capabilities. A fitted repository normally adds its own capabilities;\n`echo.say` only proves that the registry, resolver, adapter, and executor are connected.\n\n## Before and after fitting\n\nBefore AXF, a new agent searches multiple instruction files, reverse-engineers\npackage scripts, guesses the safe validation subset, and repeats that work in\nthe next session.\n\nAfter a deliberate fit, the repository can expose stable entries such as\n`context`, `check`, and `handoff`. A caller starts with `axf guide`, inspects\nthe selected capability, and runs the repository-owned route. AXF makes the\nroute visible; the repository still owns it.\n\n## Is this repository a fit?\n\nAXF helps when:\n\n- agents repeatedly guess which build, test, or validation command applies;\n- the same repository facts must be rediscovered before editing;\n- local safety rules live in scattered prose, convention, or human memory;\n- brittle shell chains keep being rebuilt for repo-specific chores.\n\nAXF is probably not a fit when one obvious command already covers the work,\nthe ceremony is unlikely to recur, or the provider surface changes faster than\nthe team can maintain a capability contract.\n\nThe adoption question is:\n\n> Does this repository have repeated local operating ceremony that is worth\n> fitting once into stable, inspectable agent capabilities?\n\nFor a bounded, strictly read-only assessment, give an agent this prompt:\n\n```text\nEvaluate whether this repository is a fit for AXF by following\ndocs/agent-evaluation.md. Do not install AXF, edit files, scaffold or promote\ncapabilities, invoke MCP tools, or run repository code. Inspect only the\nexisting scripts, package tasks, documentation, agent instructions, CI and\nplatform/runtime constraints. Identify repeated mistakes and existing overlap,\nthen return exactly one verdict: adopt, pilot, defer, or not a fit. Include the\nevidence, expected fitting cost, ongoing drift cost, authority boundaries, and\nthe smallest reversible pilot. Do not perform the pilot without separate\napproval.\n```\n\nSee [Agent fit evaluation](docs/agent-evaluation.md) for the evidence checklist,\nverdict definitions, and response template.\n\n## Choose your path\n\n| You are... | Start here | Your job |\n|---|---|---|\n| A caller or coding agent | [Caller guide](docs/callers.md) | Discover, inspect, and run capabilities someone else fitted. |\n| An integration author | [Integration author guide](docs/integration-authors.md) | Fit existing repository or provider ceremony into stable capabilities. |\n| An AXF framework author | [Framework author guide](docs/framework-authors.md) | Change loaders, resolution, adapters, policy, MCP, or other AXF internals. |\n\nStop at the caller guide unless you are responsible for fitting a provider or\nchanging AXF itself. The complete audience map is in\n[Documentation layers](docs/12-layered-docs.md).\n\n> Status: **alpha**. The core loop is in place: scout, inspect, execute,\n> scaffold, and promote capabilities through one contract. Manifest version\n> `axf/v0` is the current alpha contract.\n\n## What AXF is not\n\nAXF is not a universal command catalog, a source of authorization, a\nreplacement for provider identity, a substitute for review, or an MCP-only\nproduct. MCP is one agent-facing surface over the same registry and execution\npath.\n\n## Install and MCP\n\n### License\n\nAXF is licensed under the [Apache License, Version 2.0](./LICENSE.md),\nincluding commercial and organizational use under its terms. Preserve the\napplicable [notices](./NOTICE.md). Earlier releases retain their applicable terms.\n\nSmarterGPT was founded by Joseph Gustavson (Guffawaffle). See\n[stewardship](./GOVERNANCE.md), [contributing](./CONTRIBUTING.md), and\n[project identity](./BRAND.md). Code licensing does not grant runtime authority.\n\nThe npm package name is `@smartergpt/axf`. It installs two bins:\n\n- `axf` — the CLI entrypoint, including the stdio MCP launch subcommand `axf mcp`\n- `axf-mcp` — the stdio MCP server entrypoint\n\nMCP clients may launch `axf-mcp` directly. For registry-driven or\npackage-driven launch, prefer `axf mcp` so the package can stay centered\non the base `axf` command surface. Both entrypoints start the same stdio\nMCP server. The server exposes exactly one MCP tool named `axf`, and\nthat tool routes into AXF's existing capability surface for the bound\nworkspace.\n\n### Global install\n\n```sh\nnpm install --global @smartergpt/axf\n```\n\nThen use either bin directly:\n\n```sh\naxf doctor\naxf mcp\naxf-mcp\n```\n\nAudit a Codex MCP package pin before assuming the configured server matches the\ninstalled CLI:\n\n```sh\naxf integrate codex --check\naxf integrate codex --write\naxf integrate codex --check --smoke\n```\n\nWrites are scoped to the AXF package spec in Codex `config.toml`; restart or\nreopen Codex afterward. For one-call AXF + Lex bootstrap, including the\nexplicit `off | shadow` KnowledgeFrame provider rollout, see the packaged\n`templates/session-context` workspace recipe and\n[`docs/13-repo-onboarding.md`](docs/13-repo-onboarding.md).\n\n### Repo-local dev launch\n\nFrom a local clone, run the bins directly with Node:\n\n```sh\nnode /path/to/axf/bin/axf.js doctor\nnode /path/to/axf/bin/axf.js mcp\nnode /path/to/axf/bin/axf-mcp.js\n```\n\nA repo-local MCP configuration can either call the direct MCP bin or the\nCLI subcommand. Prefer the CLI subcommand when the client supports\ncommand arguments cleanly:\n\n```json\n{\n  \"mcpServers\": {\n    \"axf\": {\n      \"command\": \"node\",\n      \"args\": [\"/path/to/axf/bin/axf.js\", \"mcp\"],\n      \"cwd\": \"/path/to/project\",\n      \"env\": {\n        \"AXF_PROJECT_ROOT\": \"/path/to/project\",\n        \"AXF_EXECUTION_ROOT\": \"/path/to/project\"\n      }\n    }\n  }\n}\n```\n\nDirect-bin configs remain valid:\n\n```json\n{\n  \"mcpServers\": {\n    \"axf\": {\n      \"command\": \"node\",\n      \"args\": [\"/path/to/axf/bin/axf-mcp.js\"],\n      \"cwd\": \"/path/to/project\",\n      \"env\": {\n        \"AXF_PROJECT_ROOT\": \"/path/to/project\",\n        \"AXF_EXECUTION_ROOT\": \"/path/to/project\"\n      }\n    }\n  }\n}\n```\n\n### npm / npx launch\n\nPublished-package smoke tests must run from a clean directory such as\n`/tmp`, not from the AXF repo root. Running from the repo root can let\n`npx` or `npm exec` pick up a repo-local or globally installed `axf`\nbinary instead of the package-installed one.\n\nThe registry-friendly launch shape is `axf mcp`, but the direct MCP bin\nremains valid for manual configurations. These equivalent package-driven\nforms use the published npm package:\n\n```sh\nnpx -y --package @smartergpt/axf axf doctor\nnpx -y --package @smartergpt/axf axf mcp\nnpx -y --package @smartergpt/axf axf-mcp\n\nnpm exec --yes --package @smartergpt/axf -- axf doctor\nnpm exec --yes --package @smartergpt/axf -- axf mcp\nnpm exec --yes --package @smartergpt/axf -- axf-mcp\n```\n\n### Windows-native launch\n\nFor registry-style Windows MCP configs, prefer the base `axf.cmd`\nlauncher with `mcp` as an argument:\n\n```json\n{\n  \"mcpServers\": {\n    \"axf\": {\n      \"command\": \"axf.cmd\",\n      \"args\": [\"mcp\"],\n      \"cwd\": \"C:\\\\src\\\\my-project\",\n      \"env\": {\n        \"AXF_PROJECT_ROOT\": \"C:\\\\src\\\\my-project\",\n        \"AXF_EXECUTION_ROOT\": \"C:\\\\src\\\\my-project\"\n      }\n    }\n  }\n}\n```\n\nDirect-bin `.cmd` configs are still valid:\n\n```json\n{\n  \"mcpServers\": {\n    \"axf\": {\n      \"command\": \"axf-mcp.cmd\",\n      \"args\": [],\n      \"cwd\": \"C:\\\\src\\\\my-project\",\n      \"env\": {\n        \"AXF_PROJECT_ROOT\": \"C:\\\\src\\\\my-project\",\n        \"AXF_EXECUTION_ROOT\": \"C:\\\\src\\\\my-project\"\n      }\n    }\n  }\n}\n```\n\n### WSL / Linux launch\n\nFor registry-style WSL/Linux MCP configs, prefer the base `axf` command\nwith `mcp` as the first argument:\n\n```json\n{\n  \"mcpServers\": {\n    \"axf\": {\n      \"command\": \"axf\",\n      \"args\": [\"mcp\"],\n      \"cwd\": \"/home/user/src/my-project\",\n      \"env\": {\n        \"AXF_PROJECT_ROOT\": \"/home/user/src/my-project\",\n        \"AXF_EXECUTION_ROOT\": \"/home/user/src/my-project\"\n      }\n    }\n  }\n}\n```\n\nDirect-bin configs remain valid:\n\n```json\n{\n  \"mcpServers\": {\n    \"axf\": {\n      \"command\": \"axf-mcp\",\n      \"args\": [],\n      \"cwd\": \"/home/user/src/my-project\",\n      \"env\": {\n        \"AXF_PROJECT_ROOT\": \"/home/user/src/my-project\",\n        \"AXF_EXECUTION_ROOT\": \"/home/user/src/my-project\"\n      }\n    }\n  }\n}\n```\n\nWSL users should use a native WSL AXF install on `PATH`, not Windows npm\nshims or npm's `_npx` cache. Optional shared packs that launch native\nCLIs should follow the same rule: prefer Linux-native tools earlier on\nPATH and avoid crossing into Windows shims from WSL.\n\n### Root binding\n\n`axf`, `axf mcp`, and `axf-mcp` resolve the active project root and\nexecution root in this order:\n\n1. explicit `--project-root` and `--execution-root`\n2. `AXF_PROJECT_ROOT` and `AXF_EXECUTION_ROOT`\n3. legacy CLI aliases: `--workspace`, `--registry-workspace`, `--execution-workspace`\n4. legacy environment aliases: `AXF_WORKSPACE`, `AXF_REGISTRY_WORKSPACE`, `AXF_EXECUTION_WORKSPACE`\n5. nearest `axf.workspace.json` from `cwd`\n6. nearest `axf.workspace.json` from the installed script location\n7. `cwd` fallback\n\nFor `axf run`, unprefixed root flags are global only before the subcommand;\nafter `run` they are capability-owned. Non-run commands retain their legacy\nplacement because they have no downstream argument owner. The\n`--axf-project-root`, `--axf-execution-root`, and `--axf-workspace`\nspellings are accepted later in the AXF-controlled portion of a command.\nAfter an `axf run ... --` boundary, root-like names belong to the capability.\n\n### Run argument ownership\n\nAXF reserves the `--axf-*` namespace for framework controls and leaves\nnatural public argument names to capabilities. Use an explicit boundary\nwhen the ownership should be visible in the command itself:\n\n```sh\naxf --project-root /repo run global.logs.query \\\n  --axf-json --axf-any-lifecycle -- \\\n  --json --limit 20 --workspace downstream-name\n```\n\nOptions before `--` are AXF run controls. Options after `--` are public\ncapability arguments: AXF still parses them, validates and coerces them with\n`argsSchema`, maps them through `argMap`, and executes them through the\ndeclared adapter. The boundary never enables raw or schema-bypassing argv.\nThe same name may appear on both sides with different ownership, but a\nduplicate within either explicit section is rejected.\n\nExisting no-boundary invocations such as `axf run echo say --message hello`\nremain supported. In that compatibility form, legacy `--json`,\n`--any-lifecycle`, and `--allow-draft` remain AXF controls unless the\ncapability explicitly declares the same argument. Use `--axf-json` and\n`--axf-any-lifecycle` when AXF ownership must be unambiguous.\n\n### Agent-first discovery\n\nStart with the bounded workspace guide instead of requesting every full\nmanifest:\n\n```sh\naxf guide\naxf guide context --json\naxf list --compact --search lex --limit 20 --json\naxf explain global.lex\naxf inspect global.lex.status --json\n```\n\nThe MCP router exposes the same `guide`, compact/search `list`, `explain`, and\n`inspect` results. `guide` returns workspace- or family-declared context,\nvalidation, and handoff entrypoints without executing them. Compact list\nentries retain lifecycle, side effects, and source provenance while omitting\nfull schemas and execution targets until `inspect`.\n\nAI agents are the primary consumer of MCP results, so AXF defaults to\n`responseDetail: \"compact\"`: the deterministic minimum safe envelope with\ncapability data, actionable errors, warnings, and required safety state.\nRequest `responseDetail: \"standard\"` for an expanded canonical result or\n`responseDetail: \"diagnostic\"` explicitly when investigating provenance,\nworkspace binding, or launch behavior. Invocation traces stay out of normal\nsuccess and failure results. Diagnostic framework metadata is redacted for\nsensitive field names and values. Response detail never truncates, redacts, or\notherwise transforms capability-owned `data`.\n\n```json\n{\n  \"operation\": \"run\",\n  \"responseDetail\": \"compact\",\n  \"target\": { \"id\": \"global.lex.status\" },\n  \"args\": {}\n}\n```\n\nThe `compact` list option and `responseDetail` are intentionally separate:\n`compact` selects summarized capability entries, while `responseDetail`\ncontrols the surrounding agent-facing response envelope. A default compact\nMCP `list` response is independently bounded to 25 results when `limit` is\nomitted; this does not enable the list item `compact` option. Supply an\nexplicit `limit` to replace that bound, or explicitly request `standard` or\n`diagnostic` without a limit to opt out of the default bound.\n\nAXF 2.0 changes the implicit MCP response from the pre-2.0 rich envelope to\n`compact`. Callers that consume provenance or launch metadata must request\n`diagnostic`; callers that need the expanded result without invocation traces\ncan request `standard`.\n\nAXF project and execution roots are filesystem discovery/execution bindings,\nnot tenant, repository, workspace, grant, or authorization evidence. Ambient\nroot environment variables remain compatibility/configuration inputs only;\nAXF never treats them as authority. Security-sensitive hosts should pass roots\nexplicitly and authorize the operation before invoking AXF. Provider-owned\nidentity and authorization stay with the provider; AXF does not require Lex or\nreconstruct Lex authority.\n\nSee [Agent Discovery and Workflow Guide](docs/15-agent-discovery-and-workflow-guide.md)\nfor recommendation declarations, missing-capability diagnostics, and CLI/MCP\nexamples.\n\nCapabilities may also return validated, typed continuations when their immediate result leaves an\nexact external operation in progress. The first continuation kind routes through\n`global.wait.external`, whose process-bound GitHub providers observe explicit required checks for\none exact commit SHA or a pull request review from one exact reviewer identity. See\n[Awaitable completions](docs/16-awaitable-completions.md) for descriptor,\nauthority, cancellation, and outcome boundaries.\n\nWhen discovery and execution should use the same repo, set both\n`AXF_PROJECT_ROOT` and `AXF_EXECUTION_ROOT` to the same path. When they\nshould differ, set them independently. Legacy `AXF_WORKSPACE` remains a\ncompatibility alias that binds both roots to one path.\n\nFor MCP clients, set `cwd` to the intended caller execution directory and\nset `AXF_PROJECT_ROOT` / `AXF_EXECUTION_ROOT` explicitly when possible.\nThat keeps manifest discovery and caller-facing execution deterministic.\n\nSet `AXF_MACHINE_ROOT` when you want a user- or machine-scoped AXF root\nto contribute optional shared packs across projects. Project-root\nfamilies shadow machine-level families with the same family name.\n\nFrom any directory once installed:\n\n```sh\naxf doctor\naxf list\naxf inspect echo say\naxf run echo say --message hello\naxf scout --check\naxf run toy echo say --message hello\naxf init capability global.acme.status\n```\n\n`axf doctor` reports the workspace source it selected and, under WSL,\nwarns when `axf`, `lex`, `node`, or `npm` resolve through Windows PATH\nentries under `/mnt/c/...`.\n\n### MCP routing and governance\n\nThe MCP server exposes one tool named `axf`. Supported operations are:\n\n- `help`\n- `guide`\n- `list`\n- `explain`\n- `inspect`\n- `run`\n- `doctor`\n- `scout_check`\n\nThose operations route into AXF's manifest-backed discovery, resolver,\nlifecycle, policy, adapter, and executor paths. MCP does not add a\nsecond governance model or a raw shell bypass around AXF.\n\nAXF MCP is intentionally not full CLI parity yet. The CLI remains the\nauthoritative mutation and control plane for commands such as `init`,\n`promote`, `demote`, `scout --write`, and other registry/materialization\nflows.\n\nCapabilities such as `global.echo.say` are not\nseparate MCP tools. Use `operation=help` to learn the router contract,\n`operation=list` to discover capabilities, and `operation=inspect`\nbefore `operation=run`. Treat capability\n`lifecycleState`, `sideEffects`, `policies`, and workspace binding as\npart of the execution contract.\n\n`scout_check` is AXF's MCP-specific read-only structured scout\ndiagnostics surface. It is not intended to promise literal CLI parity\nwith `axf scout --check`.\n\nRegistry and manifest updates still happen through normal AXF CLI and\nfilesystem/control-plane flows. The MCP server reloads registry state\nper request, so external AXF updates become visible on later MCP calls\nwithout restarting the server.\n\nFull CLI parity may be considered later behind explicit policy and\napproval gates.\n\nShared packs appear through AXF only when the bound AXF project root or\nmachine layer discovers or mounts those capabilities.\n\n## What's wired up\n\n### Built-in adapters\n\nAXF ships two public built-in adapter types:\n\n- **`internal`** — runs handlers in-process (`adapters/internal/`)\n- **`cli`** — generic subprocess dispatcher with stdout JSON parsing\n  (`adapters/cli/`)\n\nShared command families use the same adapter contract as project-owned\ncapabilities. A shared pack can use the generic `cli` adapter, a\nprovider adapter, or an internal handler, but AXF core does not require\nthat pack as a runtime dependency.\n\n### Built-in capabilities\n\n| Capability | Provider | Lifecycle | Notes |\n|---|---|---|---|\n| `global.echo.say` | internal | active | smallest in-process capability example |\n| `global.wait.timed` | wait | active | process-bound suspension for 1 second through 30 minutes; elapsed time does not claim external completion |\n| `global.wait.external` | wait | active | process-bound observation of typed external completions; GitHub exact-head checks and pull request reviews are bundled providers |\n| `global.await.external` | await | active | deprecated compatibility alias for `global.wait.external` from the published 2.0.0 contract |\n\nOptional shared packs, including a Lex pack, can be added at machine or\nproject scope. They route through the same resolver, lifecycle, policy,\nadapter, and executor path without defining the framework itself.\n\n### Toolspaces\n\n- **`toy`** — smallest mount example; re-mounts `echo.say` with a local default\n\n## Repo onboarding\n\nThe recommended repo flow is:\n\n1. Add `axf.workspace.json` at the repo root so workspace binding is explicit.\n2. Add shared packs intentionally at machine or project scope when a repo wants them.\n3. Add repo-specific capabilities separately under `manifests/capabilities/` or `manifests/families/`.\n4. Keep MCP optional; AXF works as a plain CLI capability router without it.\n5. Mark mutating capabilities with `sideEffects: \"write\"`. AXF does not yet have a first-class `approvalRequired` field, so approval gates stay a repo policy or review convention for now.\n\nSee [`docs/13-repo-onboarding.md`](docs/13-repo-onboarding.md) for the concrete onboarding pattern and platform notes.\n\n## How to add a new provider\n\nThe contract is open. First decide whether the provider needs a command family,\na selective materialized override, or a provider adapter. The\n[Integration author guide](docs/integration-authors.md) contains that decision\npath. A provider adapter is only needed when the generic CLI route cannot\nexpress the provider's argument, envelope, failure, or output contract.\n\nWhen a provider adapter is justified, the scaffold starts in `draft`:\n\n```sh\n# 1. Scaffold a draft provider adapter (only if the provider has an\n#    envelope or quirks the generic cli adapter shouldn't carry):\naxf init adapter --kind provider acme --composes cli\n\n# 2. Scaffold each capability:\naxf init capability global.acme.status\n\n# 3. Edit the drafts, then:\naxf doctor\naxf inspect global.acme.status --json\n```\n\nThe four canonical prompts under [`prompts/`](prompts/) walk an agent\nthrough discovery → planning → scaffolding → review against the actual\nfile contract. JSON-first providers can usually use the generic `cli`\nadapter directly; provider adapters are for wrappers that need envelope,\nerror, or argument normalization beyond the generic route.\n\nRunning a non-active capability requires an explicit lifecycle opt-in and can\nstill execute real provider effects. Do that only after inspection and the\nrepository's normal approval process. Lifecycle changes validate manifests;\nthey do not perform the review.\n\n## Layout\n\n```\naxf.workspace.json               # workspace marker\nbin/axf.js                      # CLI entrypoint\nsrc/cli/                        # CLI parsing + main dispatch\nsrc/core/                       # registry, resolver, executor, adapters, doctor, policy\nadapters/<type>/                # type adapters (internal, cli, ...)\nadapters/<provider>/            # optional provider adapters for wrapped CLIs\nmanifests/capabilities/         # capability manifests\nmanifests/toolspaces/           # toolspace mount manifests\nprompts/                        # canonical prompts for agent-authored adapters\ndocs/                           # architecture, contract, lifecycle, prompts\ntest/                           # node:test suite\n```\n\n## Documentation\n\nStart with the path for your current job:\n\n- [Caller guide](docs/callers.md) — discover, inspect, and run fitted\n  capabilities.\n- [Integration author guide](docs/integration-authors.md) — fit recurring\n  repository or provider ceremony while preserving provider vocabulary.\n- [Framework author guide](docs/framework-authors.md) — change AXF internals\n  and cross-surface contracts.\n- [Awaitable completions](docs/16-awaitable-completions.md) — return typed\n  continuations and observe exact external completion without scheduling it.\n\n[Documentation paths](docs/12-layered-docs.md) routes each audience to the\nrelevant reference documents. Use the\n[read-only agent fit evaluation](docs/agent-evaluation.md) before onboarding an\nundecided repository.\n\n## Tests\n\n```sh\nnpm test\n```\n\nUses Node's built-in `node:test`; no external test runner is required.\n\n## What is intentionally **not** here\n\n- a broad command-alias layer\n- privileged integration paths\n- a plugin marketplace\n- mandatory remote execution or MCP support\n- agent-generated capabilities that auto-promote\n",
  "bytes": 24221,
  "sha": "1c3a82c3d6327d6f795f6d8e749b69ad6efd93046da895481333f6f925869429",
  "repo_slug": "guffawaffle/axf",
  "fonte": "repo",
  "truncated": false,
  "api": "https://agentalog.com/api/listings/mcp_dev_smartergpt_axf_6bab96ad/readme"
}