llms.txt, .well-known and Agent Skills: How TronSave Publishes Itself to AI Agents

An AI agent that lands on a website has the same problem a new developer does: what is this, what can I call, and how do I authenticate? In 2026 there is a small stack of conventional files that answer exactly that — llms.txt, a handful of /.well-known/ descriptors, and an agent-skills manifest. TronSave publishes all of them. This is a tour of what is in each one, why it is there, and the one rule none of these files can enforce.

llms.txt: the human-readable summary

llms.txt sits at the root of a site and does for language models what a good README does for a developer: one paragraph of what this is, then curated links with a sentence of context each. It is Markdown, not a schema, and that is the point — it is meant to be read, not parsed.

TronSave’s has four sections. A one-line summary of the product. Key pages — home, market, tools, FAQ — each with a description of what is actually there. A Developers & AI agents block linking the API reference, the API catalog, the MCP server card, the agent-skills index, and the auth document. And Legal: terms, privacy, risk disclaimer.

The useful discipline here is curation. A sitemap lists every URL; llms.txt lists the ten that matter and says why. If your file needs a scrollbar, it has stopped doing its job.

The .well-known directory

Where llms.txt is prose, /.well-known/ is machine-readable. Five files, each answering a different question:

api-catalog — the machine/human split

RFC 9727 defines a linkset: each API gets an anchor, then links describing it. TronSave publishes two anchors — the REST v2 API and the MCP endpoint — and each carries both a service-desc and a service-doc:

{
  "linkset": [
    {
      "anchor": "https://api.tronsave.io/v2",
      "service-desc": [ { "href": ".../api-reference.md",  "type": "text/markdown" } ],
      "service-doc":  [ { "href": ".../api-reference",     "type": "text/html"     } ]
    },
    {
      "anchor": "https://mcp.tronsave.io/mcp",
      "service-desc": [ { "href": ".../mcp/server-card.json", "type": "application/json" } ],
      "service-doc":  [ { "href": ".../api-reference/mcp",    "type": "text/html"        } ]
    }
  ]
}

The distinction is the valuable part. service-doc is the HTML page a person reads. service-desc is the machine-readable description — here, Markdown for the REST reference and JSON for the MCP card. An agent follows service-desc and skips the marketing chrome entirely.

oauth-protected-resource — even without OAuth

RFC 9728 metadata usually accompanies an OAuth deployment. TronSave does not use OAuth, and publishes the descriptor anyway: it names the resource (https://api.tronsave.io/v2), points at the documentation, and states that bearer credentials go in a header. A client that looks for this file finds an answer rather than a 404, which is worth more than strict conformance.

auth.md — the honest answer for non-OAuth services

Because there is no OAuth flow to discover, the real authentication story lives in a self-contained auth.md. It is specific in the way that actually saves an integrator time:

• The REST API takes your key in a lowercase apikey header.
• The MCP server takes it in an authorization header with the ApiKey scheme.
• A TRON wallet signature is the third route — and the document states plainly that you never send a private key, only the signature.

Those first two are a genuine trap: same credential, two different headers, two different casings, depending on which surface you are calling. Writing it down is the difference between a five-minute integration and an afternoon of 401s.

The file also admits what does not exist. There is no programmatic OAuth dynamic-registration endpoint, so it explains how a human obtains a key instead — connect a wallet on the site, or use the Telegram bot. An agent_auth block then summarises the same facts in structured form: identity type anonymous, credential type api_key, plus a link to the registration docs.

The MCP server card

A compact descriptor of the TronSave MCP server: name and version, transport (http-streamable) with its endpoint and methods, a capabilities block declaring tools: true and resources/prompts false, the two supported auth schemes with the exact header format, and pointers to a quickstart and the docs.

Declaring the capabilities you do not have is not filler. An agent that knows there are no resources or prompts stops looking for them.

The agent-skills manifest

The newest layer. agent-skills/index.json follows the agentskills.io discovery schema and advertises one skill, tronsave-api, of type skill-md — a Markdown document an agent can load as working instructions:

{
  "$schema": "https://schemas.agentskills.io/discovery/0.2.0/schema.json",
  "skills": [
    {
      "name": "tronsave-api",
      "type": "skill-md",
      "url": "https://tronsave.io/.well-known/agent-skills/tronsave-api/SKILL.md",
      "digest": "sha256:bc8a8647...9141b"
    }
  ]
}

Note the digest. The manifest carries a SHA-256 of the skill file, so a client can verify it fetched what the site intended to publish. Skills are instructions an agent will act on, which makes them worth integrity-checking in a way a marketing page never is.

The rule no manifest can enforce

Every file above is a snapshot. The service keeps moving.

A concrete example from this very stack: the skills manifest describes the MCP server as exposing 27 typed tools. Ask the live server today and tools/list returns 29. The skill document’s example handshake also pins an older protocol revision than the server currently negotiates, and the server card lists GET among its transport methods while the quickstart notes that GET is deliberately disabled.

None of that is a bug in the agent’s path — it is the normal drift between a published document and a running service. The lesson generalises to every integration of this kind: use the manifests for discovery, and the server for truth. Enumerate capabilities at runtime with tools/list rather than hard-coding a count you read in a file, and let the handshake negotiate the protocol version instead of asserting one.

What an agent should do with credentials

Discovery ends at authentication, and the session model deserves one paragraph because it is the part with real consequences. Logging in produces one of two session types with different reach: an ApiKey session is scoped to internal-account operations, while a signature session is wallet-bound and required for user-identity tools and most platform mutations. An API key will not silently gain you signature-level access; it simply fails on those tools.

Both produce a session id that travels in a header on every later call, and both should be treated as secrets. A leaked session id lets someone act with that session’s rights until it expires — which is precisely why the narrower ApiKey session is the right default for autonomous work.

If you are building this for your own site

The stack is small enough to ship in an afternoon:

1. /llms.txt — a summary paragraph and curated links with context. Keep it short.
2. /.well-known/api-catalog — one anchor per API, each with a machine description and a human doc.
3. /.well-known/oauth-protected-resource — publish it even without OAuth.
4. An auth document — exact header names and casing, and how a human gets a credential.
5. An MCP server card if you run a server, declaring capabilities you lack as well as those you have.
6. An agent-skills manifest with a digest, if you publish skills.
7. /.well-known/security.txt — with an expiry date you will actually renew.

Then wire one thing into your release process: regenerate the manifests when the service changes. The files are cheap to publish and easy to forget.

FAQ

Is llms.txt a standard?

It is a widely adopted convention rather than an IETF standard. The /.well-known/ files alongside it — api-catalog, protected-resource metadata, security.txt — are actual RFCs.

Does publishing these files help SEO?

Not directly. They help agents and assistants use your service correctly once they arrive. Treat them as integration documentation with a conventional address, not as a ranking factor.

Should I publish an api-catalog if I only have one API?

Yes — the value is the predictable location, not the number of entries. One anchor with a machine-readable description is enough.

Why publish protected-resource metadata without OAuth?

Because clients look for it regardless. Answering with the resource identifier and how credentials are passed is more useful than a 404, even when the answer is “we do not do OAuth.”

How do I get a TronSave API key?

Connect a TRON wallet on the site and sign in, or use the Telegram bot’s user-info section. There is no programmatic registration endpoint — the auth document says so rather than leaving you to discover it.

Where do I start if I just want to use the API?

The official SDKs wrap it in five languages, and the API automation guide covers the raw endpoints. Discovery files are for agents that must find their own way.

Bottom line

Making a service legible to an AI agent is not a new discipline so much as an old one with a new audience: say what you are, list what you expose, be exact about credentials, and admit what you do not support. The files are conventional and the effort is small. The part that takes real discipline is keeping them true — because an agent will believe your manifest right up until the moment the server disagrees with it.

Point an agent at it: the MCP endpoint is https://mcp.tronsave.io/mcp (with a testnet endpoint alongside it) — see our MCP server guide for login and the tool families, then watch it price against the live energy market.

TronSave publishes this blog and the discovery files described here. File contents, tool counts, and protocol revisions reflect what was published and what the live server returned at the time of writing, and will change — enumerate at runtime rather than relying on the figures quoted above. This is not financial advice.