platty Docs

What Platty MCP is

Platty is not a separate app. It ships as an MCP (Model Context Protocol) server. Connect Platty to the AI you already use — Claude, Claude Code, Cursor, your in-house agent — and that AI starts answering by querying your company's SSOT (Single Source of Truth) as a tool.

The AI gets three things.

• Knowledge — Search and read the business documents, specs, and glossary built from the code.
• Trace — Follow the code graph to see screen→API→DB connections and the impact of changes.
• Memory — Read the knowledge (memories) your team has left behind, and store new knowledge.

Connect

Get the MCP endpoint address and an auth token from your administrator. Access is granted by administrators per team and per project.

Claude Code

claude mcp add platty --transport http \
  https://mcp.<your-company>.platty.app \
  --header "Authorization: Bearer <your token>"

Cursor · Claude app · Other MCP clients

Register the same endpoint and token in each client's MCP settings. Once the platty_* tools show up in the tool list, you're connected.

Teams building in-house agents use the same endpoint as everyone else. There is no separate setup for people and agents — same SSOT, same tools.

First question

Once connected, just ask the AI. You don't need to know the tool names. The AI queries the SSOT on its own.

# Ask it like this
"When and on what basis are seller settlements paid out?"

# Internally, the AI moves in this order
platty_document_search("settlement payout criteria")   → finds the relevant business rule
platty_document_get(...)                               → checks the rule text and its evidence
platty_graph_trace(...)                                → traces the settlement batch job to its actual code location

Answers come with evidence (code locations and documents) and freshness (which commit they reflect). Without evidence, the AI answers "not confirmed".

Core concepts — the SSOT layers

Platty analyzes your code and builds the layers below automatically. Higher layers are business language; lower layers are closer to the code.

Every layer connects up and down. You can start from an epic and go down through business rules → specs → code locations, or go the other way and move from code up to the business work it belongs to.

Core concepts — evidence and freshness

• Evidence. Every statement in the SSOT carries a source reference backing it. Each document also includes a list of what could not be confirmed with evidence.
• Freshness. Every document carries the source commit it came from and whether it is current. When code changes, the affected parts are re-analyzed, and stale documents are marked as stale. Check the current state with platty_context_status.

Core concept — Trust level

Every edge in the graph carries a source level.

Answers show which level the evidence sits at. No link is ever marked confirmed arbitrarily.

Core concept — Memory

Knowledge that isn't in the code — why a decision was made, operational know-how, what a term actually means — is stored as memory. While talking with the AI, just say "Add this to Platty." Memory can be attached to any project, epic, or document. It starts in the proposed state and moves up in trust level once confirmed. The level is shown alongside the memory whenever it is used in an answer.

Tool reference — projects and status

Tool reference — navigation and search

Tool reference — specs and impact analysis

Tool reference — Terminology

Tool reference — Code

Tool reference — Data

Tool reference — Memory

Guide — asking the system questions

There is only one trick to asking good questions. Ask in your own words. The glossary translates your department's language into standard terms, so you don't need to know the code terminology.

• "What conditions delay settlement for trial crew campaigns?" — in plain business language
• "What does this error code mean?" — wherever you saw it: code, screen, or docs
• When the answer comes back, check the evidence. The evidence code locations and freshness come with it. If you get "not confirmed", that area simply has no evidence yet — the answer was not filled in with guesswork.

Guide — Check change impact

Ask before you change anything. "If I change this column (or this API, this rule), what gets affected?"

1. The AI connects the scope of impact with platty_spec_impact_resolve and platty_graph_trace.
2. Results come in three kinds — confirmed relationships (proven in the graph), candidates (unconfirmed, with reasons), and needs further checking (dynamic patterns and the like).
3. For candidates and unconfirmed stretches, the AI reads the original code directly (readonly_workspace_shell) to fill in the gaps.

Guide — Unify terminology

Every department calls the same thing by a different name. The glossary knows that marketing's "trial crew", engineering's "purchase campaign", and data's pcamp_id are the same thing. Register new synonyms with alias_add, or just say in conversation, "our team calls this ○○, remember that."

Guide — Query data

Ask something like "show me last month's settlement totals by campaign" and the AI confirms what the tables mean from the SSOT, then builds and runs a read-only query. The answer includes which tables it chose and why, so you can verify where the numbers came from.

Guide — Capture knowledge

When knowledge worth keeping comes up in conversation, say so on the spot. "Add this to Platty." It is saved as a memory anchored to the relevant epic or document. Saved knowledge starts in the proposed state and moves up in trust level once a colleague confirms it. If you saved something by mistake, say "delete that memory" to remove it.

Guide — agent workflows

The call order we recommend when building an in-house agent or a coding agent.

# 1. Get oriented — go broad
platty_project_overview_get → platty_document_search

# 2. Narrow down — business context
platty_epic_get → platty_document_get (business rules and use cases)

# 3. Get precise — specs and code
platty_spec_get → platty_spec_impact_resolve → platty_graph_trace

# 4. Check the source — only when needed
platty_code_search → platty_readonly_workspace_shell

The principle is top down. Start from business documents, then move to specs, then to code. That saves tokens without losing context. Digging through code from the start is a last resort.

Policy — Security principles

• Read-only. Platty's access to code and databases is read-only. It does not run production code or change data.
• Nothing stored. Prompts sent to the LLM, source snippets, and raw requests and responses are not stored. Logs keep only minimal metadata.
• Permissions. Access is managed per project and per team. Projects you can't see can't be queried.
• Deployment. On-premise and private cloud are supported, and you can run it on your own LLM infrastructure (AWS Bedrock, Azure OpenAI, and others).

Admin guide — Coming soon

Documentation for the SSOT management system (coverage visualization, manual linking, trust level management, MCP connection and security management) will be published along with the feature release.