Skip to main content
Doctorine
Menu

Agent-ready APIs

Publish agent-readable API context now; design executable tools deliberately.

Doctorine publishes llms.txt and llms-full.txt for entitled public portals from the same canonical OpenAPI model used for human reference. An internal MCP emitter and portal route exist in code, but neither has a customer-accessible production path yet.

For developers

Portal · examples · typed SDK methods

For agents

llms.txt today · MCP design guidance

“Agent-ready” needs an exact output

The phrase can hide several different jobs. A model may need readable documentation context, a client may need structured portal resources, or an agent may need tools that can invoke API operations. Those surfaces have different security and deployment requirements. Doctorine names them separately instead of treating every machine-readable file as an autonomous agent.

The common foundation is the canonical OpenAPI graph. Operation identity, input shape, response shape, and security requirements begin with the same source used for human reference and SDK methods. This reduces semantic drift, but it does not remove the need for authorization, credential handling, consent, rate limits, and runtime monitoring.

Two shipped context files, two held MCP paths

Matching the surface to the task prevents documentation context, executable tools, and access control from being collapsed into one unsafe assumption.

  • llms.txt

    Use
    Language models reading public API documentation
    Derived from
    Published portal content and API reference
    Boundary
    Available on entitled public portals; intentionally absent on private portals.

  • llms-full.txt

    Use
    Tools that need a fuller text representation
    Derived from
    The same public portal release
    Boundary
    A readable content surface, not permission to invoke the API.

  • MCP package emitter (held)

    Use
    Teams building an API-action server from OpenAPI
    Derived from
    An internal, tested emitter over canonical operations
    Boundary
    No customer-accessible CLI command or cloud dispatch path exists yet. This is not marketed as shipped.

  • Portal MCP route (held)

    Use
    Clients retrieving spec-accurate docs and API resources
    Derived from
    A portal-worker implementation that is not configured on production portals
    Boundary
    The live token and OAuth onboarding path is incomplete, so this is not a customer-accessible surface.

Operation mapping

What the internal emitter proves—and what it does not ship

Doctorine's internal emitter resolves operations from the canonical model. Its tests show that names, descriptions, inputs, outputs, and authentication requirements can be mapped into a deterministic package. The product does not yet expose that emitter through a customer CLI command or the live SDK factory, so the implementation is engineering evidence—not availability.

A future generation path still would not decide who may call the API. The deploying team chooses where the server runs, how credentials are obtained, which scopes are allowed, and what confirmation an action requires. The design goal is contract fidelity and reproducibility, not a claim that agent security is solved automatically.

Follow the OpenAPI-to-MCP design guide

Tool-design review

  1. Stable operation identity

    A tool should stay attached to the operation it represents even when a title, grouping, or file path changes.

  2. Explicit input shape

    Parameters, request bodies, security requirements, and error outcomes need concrete schemas instead of prose guesses.

  3. Narrow tool purpose

    One coherent operation per tool is easier to select and constrain than a generic execute-anything wrapper.

  4. Authentication outside the description

    A clear tool schema does not replace credential storage, user consent, authorization, or runtime policy.

Keep human and machine explanations together

A portal guide can explain why and when to call an operation. OpenAPI describes the structured request and response. An SDK gives application developers an idiomatic client, while an MCP package can give an agent a structured tool surface. Keeping both designs attached to stable operation identities makes future review possible without pretending the held path is available.

Readiness review

Separate content readiness from execution readiness

Publishing useful text for retrieval is a lower-risk job than authorizing an agent to change production state. Evaluate them independently. For context, inspect whether the public files are current, readable, and linked to canonical portal content. For tools, threat-model one operation with real side effects and trace identity, credential scope, confirmation, audit, revocation, and failure handling before choosing any generation path.

  • Is the job retrieval or action?

    Documentation context helps a model explain an API. An executable tool additionally needs credentials, authorization, input validation, user consent, and runtime controls.

  • Can every tool be bounded?

    Review the precise operation, scopes, side effects, confirmation requirement, rate limits, and failure behavior instead of exposing a generic request proxy.

  • Does the contract describe reality?

    A deterministic mapping preserves schema truth; it cannot repair stale descriptions, missing error shapes, or undocumented authorization rules.

  • Who owns production operation?

    The deploying team must own hosting, secrets, logs, revocation, incident response, and the policy that decides whether an action is permitted.

Failure modes worth designing first

A tool name can collide after normalization, an optional parameter can become required, an operation can acquire a destructive side effect, or a token can carry more scope than the tool needs. A client may retry an unsafe action, log a secret, or select a plausible but incorrect operation. Stable operation identity and explicit schemas reduce mapping errors, but deployment policy must still constrain blast radius and make denial safer than a guessed invocation.

What Doctorine can prove

Product claims reviewed by Doctorine engineering.

Doctorine publishes llms.txt and llms-full.txt for entitled public portals. The MCP emitter has deterministic internal tests, but there is no customer-facing CLI command or cloud factory dispatch. The portal MCP implementation is not configured as a live production customer path.

Inspect the live text surface

Doctorine's marketing website publishes a manually maintained, downloadable discovery artifact at the canonical /llms.txt path. It proves that this public file is live, not that a customer portal generation run succeeded. It links only to public content and is not an MCP endpoint.

Open Doctorine's live llms.txt example

Inspect the operations before an agent uses them.

Import an OpenAPI contract, review the public agent context it can support today, and use the implementation guide to plan executable tools safely.

Import an OpenAPI spec