# Docs for coding tools (/docs/agent-resources)



Use these files when a coding assistant, client generator, or contract validator needs the public
API definition without the rendered site navigation.

| Resource               | URL                                                        | Best use                                                    |
| ---------------------- | ---------------------------------------------------------- | ----------------------------------------------------------- |
| OpenAPI 3.1            | [`/openapi/doctronic-v1.json`](/openapi/doctronic-v1.json) | Operations, parameters, schemas, responses, and server URLs |
| Documentation index    | [`/llms.txt`](/llms.txt)                                   | Discover documentation pages and their Markdown URLs        |
| Complete documentation | [`/llms-full.txt`](/llms-full.txt)                         | Load the public documentation as one text resource          |
| Page Markdown          | `/llms.mdx/docs/{page}/content.md`                         | Load one documentation page without site navigation         |

For example, the Markdown version of this page is available at
[`/llms.mdx/docs/agent-resources/content.md`](/llms.mdx/docs/agent-resources/content.md).

## Choose the right source [#choose-the-right-source]

Use OpenAPI as the contract for HTTP operations and JSON shapes. Use the Markdown documentation
for workflow guidance, SSE compatibility rules, and production considerations.

The SSE stream is represented as `text/event-stream` in OpenAPI. Its published event examples and
the [streaming guide](/docs/conversations/streaming) define the event names and payloads that an
integration should recognize.

## Download the contract [#download-the-contract]

```bash
curl --fail --location \
  "https://docs.doctronic.ai/openapi/doctronic-v1.json" \
  --output doctronic-openapi.json
```

Validate the downloaded file before using it to update a generated client, schema validator, or
tool definition. Review contract changes before deployment rather than updating production
behavior automatically.

## Keep runtime credentials separate [#keep-runtime-credentials-separate]

These resources describe the API but do not grant API access. Runtime calls still require a
Bearer token provisioned manually by Doctronic and, for user-scoped operations, the correct
`X-Doctronic-User-ID`.

Keep the token in an organization-controlled backend. Do not place it in a model prompt, browser
session, client application, generated artifact, trace, or documentation corpus.

## Control automated callers [#control-automated-callers]

If an automated system can initiate API calls:

* Allow only the operations required for its workflow.
* Resolve the user identity in trusted backend code.
* Validate requests against OpenAPI before sending them.
* Define product-controlled handling for any emitted `guardian` and `skill_code.cta` events.
* Use documented idempotency keys for supported mutations and reconcile unsupported operations
  before replaying them.
* Record operation and outcome metadata without copying unrestricted patient content.
* Keep a human-visible fallback for errors and unknown events.

The documentation formats do not change the clinical API's authorization or safety boundaries.

## MCP and tool calling [#mcp-and-tool-calling]

Doctronic does not currently publish a public MCP server. If your application exposes Doctronic
operations to an agent or tool-calling model, put a narrow tool in your backend instead of giving
the model an organization token. The backend should resolve the patient, enforce an operation
allowlist, validate input against OpenAPI, and return only the fields required by the calling
workflow.

The public API does not provide delegated agent authorization. A caller must not select an
arbitrary `X-Doctronic-User-ID` or expand its own permissions.

## Related documentation [#related-documentation]

* [Access and environments](/docs/access-and-environments)
* [API reference](/docs/api-reference)
* [Patient context and handoffs](/docs/patient-context-and-handoffs)
* [Handle safety and escalation](/docs/guides/safety-and-escalation)
* [Production readiness](/docs/production-readiness)