MCP

Use MCP when your IDE or agent supports MCP servers.

1) Configure your preferred tool

https://sdocs.suiram.dev/api/v1/mcp

2) Restart your tool

After saving the config, restart your IDE/agent so it can discover the sdocs MCP server.

3) Verify with a quick prompt

Search for `Sandbox.Component`, inspect its members, then show the exact signature for `OnUpdate`.

Advanced

The MCP server now behaves like a typical SDK documentation server rather than a generic docs search endpoint. It exposes a small set of structured tools that let an AI agent progressively discover the s&box API using the standard workflow:

1. Search
2. Inspect
3. Read details

In practice, an agent will usually:

1. Call search_docs to find relevant guides and API entities
2. Call read_doc on the best returned handle
3. Inspect the returned references and tips
4. Call read_doc again on any reference that looks relevant
5. Repeat until it has enough exact API and guide context to answer

This makes the s&box documentation MCP feel closer to a .NET API browser, where namespaces, types, and members are returned in a predictable structure instead of as raw page text.

Transport and Payload Format

The remote MCP endpoint uses standard MCP JSON-RPC over Streamable HTTP. That means installation snippets, request envelopes, tool arguments, and discovery metadata still use JSON where MCP clients expect it.

Tool result text fields and docs:// resource bodies are encoded as compact TOON to reduce model-facing token usage while preserving the same structured data model. Resource contents are advertised with mimeType: text/toon.

Compact MCP payloads remove empty fields, avoid repeated raw metadata, and use short readable keys such as sig, uri, params, returns, and guides. Tools default to compact responses. Pass detail: "full" in a tool request only when you need the larger raw field set.

For example, search_docs returns TOON text like this:

results[2]:
  - handle: docs://type/Sandbox.Component
    kind: class
    next: "Call read_doc with this handle to read the API entity and inspect related references."
    source: api
    summary: "A GameObject can have many components, which are the building blocks of the game."
    title: Sandbox.Component
  - handle: docs://guide/scene/components
    kind: guide
    next: "Call read_doc with this handle to read the guide and inspect referenced API symbols."
    source: guide
    title: Components
query: component update loop
returned: 2

API Docs and Guides

The MCP server exposes two connected documentation layers:

• Generated API docs for namespaces, types, and members
• Official Guides fetched live from the s&box docs repository

The relationship is built at runtime. The server scans the upstream guide markdown, looks for symbol mentions in headings, prose, inline code, and code blocks, and then scores which guide pages are most relevant to each API symbol.

That gives agents two useful directions:

1. From an API symbol like Sandbox.Component.OnUpdate(), they can follow related Guides for conceptual context, editor workflows, and practical usage patterns.
2. From a Guide page, they can inspect the related API symbols that the guide discusses and then open the canonical type or member pages.

Use the API docs for exact contracts. Use Guides for surrounding context.

Tool Reference

Tool responses are returned as TOON text to reduce token usage while preserving the same structured data model. The examples below show tool arguments as JSON because MCP clients send tool arguments through JSON-RPC.

Every tool accepts an optional detail field:

{
  "detail": "full"
}

Omit it for compact responses. Use detail: "full" only when the compact result does not include a field you need.

search_docs

Use this first. It searches official Guides and generated API symbols together, including classes, structs, interfaces, enums, constructors, methods, and properties.

Typical input:

{
  "query": "component update loop",
  "limit": 5
}

Typical TOON output includes:

• Mixed guide and API results
• A stable handle for each result
• The result kind, title, URL, summary, and source
• A next tip telling the agent to call read_doc on the handle

Example use:

• Find guides and methods related to Sandbox.Component
• Search for NetworkMode, Ray, SceneTrace, or GameObject without first knowing whether the answer is in a guide, enum, class, method, or property

read_doc

Use this on any handle returned by search_docs or by a previous read_doc response. The handle may point to a guide, enum, class, method, constructor, or property.

Typical input:

{
  "target": "docs://type/Sandbox.Component"
}

Typical TOON output includes:

• The requested guide or API entity
• Exact API details when the target is a symbol
• Guide markdown excerpts when the target is a guide
• Related references with handles
• A tip on each reference explaining when to read it next
• Workflow guidance telling the agent to keep calling read_doc on relevant reference handles

Example use:

• Read docs://guide/scene/components, then read the referenced Sandbox.Component and Sandbox.Component.OnUpdate() handles
• Read docs://type/Sandbox.NetworkMode, then read related guide handles for networking behavior

Resources

The MCP server also exposes canonical docs:// resources for agents that already know the exact target they want to load. These resources complement the tools:

• Use tools for discovery
• Use resources for deterministic page loading

Available resource patterns:

• docs://schema
• docs://namespace/root
• docs://namespace/{name}
• docs://type/{full_name}
• docs://member/{full_name}
• docs://guide/{path}

Examples:

docs://namespace/Sandbox
docs://type/Sandbox.Component
docs://member/Sandbox.Component.OnUpdate
docs://guide/scene/components

Resources return compact TOON documentation pages. Resource wrappers omit transport-only metadata such as the resource MIME type and repeated URI. Depending on the resource, the payload can include:

• Summary and description
• Exact signatures and declarations
• Parameters, return types, and return documentation
• Examples
• Child namespaces, member listings, related guide links, and related API symbol links

Typical usage:

1. Use search_docs to identify relevant handles
2. Use read_doc to read the matching docs://type/..., docs://member/..., or docs://guide/... handle
3. Use the TOON resource payload as the canonical page for that API element or guide

How Agents Use It

For a question like "How do I update a custom component every frame?", a well behaved agent will usually:

1. Use search_docs with a query like component update every frame
2. Use read_doc on the best returned handle
3. Inspect the references and their tip fields
4. Use read_doc again on relevant guide, type, or member handles
5. Repeat until it has enough exact API contracts and guide context to answer

That is the intended MCP interaction model: search broadly, inspect the right symbol, then combine exact API pages with related Guides when the answer needs more than just signatures.