Public working proposal · documentation system design
Building Euler’s documentation knowledge system
Euler already has a meaningful public MCP surface. The opportunity is to make that knowledge easier for people to scan, trust, and use—then give the team a system for keeping it current as the product changes.
View the working Euler prototype · See the proposal · View Euler’s public MCP reference
What this is: a self-initiated portfolio prototype built from Euler’s public website and public MCP materials. It is not an official Euler property, product audit, or statement of internal plans. Product behavior, terminology, security guidance, and customer priorities would need validation with the responsible team.
The useful thing already exists
Euler’s public MCP materials expose real capability: connection guidance, a structured tool catalog, access context, and a changelog. That is a strong starting point. The missing piece is not raw information. It is an experience that helps a customer or partner answer a few practical questions quickly:
What can I do?
Start with the outcome a person is trying to achieve, not a wall of fields.
What do I need first?
Put access, prerequisites, and safe setup steps before the contract details.
What comes back?
Explain results, exceptions, and next steps in human language.
Who keeps this correct?
Connect the public page to an owner, a source, and a change-review trigger.
What I found in the public material
The public MCP reference and structured manifest are useful source material. The issue is presentation: fields and their explanations can be densely wrapped together, which makes it harder to distinguish the purpose of a tool from its inputs, access limits, and outcomes.
That is not a complaint about having technical detail. The detail matters. It needs a second layer around it: task context, readable examples, grouped inputs, plain-language results, and a route to troubleshooting.
The proposal
1. Give each tool a human-first reference page
The first page should answer the question a person has before they open a schema.
The user outcome and the right time to use the tool.
Connection, role, consent, or prerequisite information.
A plain-language example that reflects a real task.
Meaningful result fields, exceptions, and next steps.
Parameters, data types, and the contract—close at hand, not first.
The prototype uses the public list_accounts material as an example: account access and consent context come first; the raw parameter table stays available for a builder who needs it.
2. Organize documentation around three reader needs
Learn and launch
Concepts, account connection, roles, access, terminology, and a safe first success.
Complete a task
Outcome-led guides such as submit a referral, diagnose access, manage communications, or review fund requests.
Build and maintain
MCP/API reference, integrations, errors, changes, migrations, and internal implementation playbooks.
This is the same pattern I would use for product help, API quickstarts, integration guidance, release notes, and support content. The reader starts where their question starts—not where the implementation happens to be stored.
3. Treat content as a maintained system
For a first technical writer, this is the leverage point. A good article helps once. A content model, ownership map, and review process keep help accurate after the next product change.
What I would do first
| First 30 days | Result |
|---|---|
| Inventory existing public, product, support, and engineering sources | A source-of-truth map, terminology baseline, and prioritized content backlog |
| Rework the highest-value MCP/tool references into the human-first pattern | A small, testable reference model rather than an abstract redesign |
| Build the connection and first-success path | A clearer route from setup to a usable result |
| Establish owners and change triggers | A lightweight way to prevent new content from going stale |
The approach behind the prototype
I start by making the strange thing clear. I use the available evidence, separate what is confirmed from what needs review, and build a working content model before choosing a publishing platform or writing a large pile of pages.
That means a documentation function can begin with what the company already has—schemas, product workflows, support questions, changelogs, and customer language—then turn those inputs into an organized system the product team can keep using.
It is to make the right information easier to find, easier to use, and easier for the next person to maintain.