# Meridiaan Docs
> Reference documentation for Meridiaan.
Source: https://docs.meridiaan.io/
Meridiaan
# Your project's source of truth, served to your Agents over MCP
Decisions, constraints, what was tried and dropped: written once, and served to
the Agents you already work with. They read it, they keep it current, and they
stop asking you to explain the project from the beginning.
**Your Agent knows how the project is built, because it builds it with you.**
You shape the knowledge base around what you have to make: the [Collections](collections.md) you
want, and the instructions that say how each one wants to be written. Your Agent
receives them with every answer, writes inside those rules, and what the project
knows grows as the project does.
**One knowledge base, whichever Agent you use.** It lives outside any single
tool and travels over MCP. A small local model for the easy work, a frontier one
for the hard part, the same knowledge underneath both, and it stays where it is
when you change client.
**Nothing to build to get there.** No MCP server to write and deploy, no
repository or filesystem to set up first. You create a [Workspace](workspaces.md), you connect
it, you work.
**Users and Agents in the same place.** Owner, Editor and Viewer, a seat to
write, and reading that never asks for one. What an Agent writes, your team
sees, and the other way round.
Set it up in minutes, and stop re-explaining your project.
[meridiaan.io](https://meridiaan.io) is where you start. This site is the
documentation: every page is served as HTML and as its own Markdown source, for
you and for the models you work with.
## Start here
- [What Meridiaan is](what-is-meridiaan.md): what it does, who it is for, and
how it works, in three minutes.
- [Use cases](use-cases.md): the situations Meridiaan is good for, from a new
project to a client's Workspace to a line of research.
- [The entities](concepts.md): [Organizations](organizations.md), Workspaces, Collections and
[Documents](documents.md), and how an Agent reaches them.
- [Roles](roles.md): what an Owner, an Editor and a Viewer can do.
- [Connect an Agent](connect.md): the address, the two ways to authenticate,
and how the configuration is handed to you.
- [The tools an Agent receives](tools.md): what an Agent can read and write
once it is connected, and what stays with you.
- [Entities instructions](instructions.md): which entities carry instructions,
what each one is for, and how to write the ones that matter.
- [Persona, the personal Workspace](persona.md): the Workspace that is about
you rather than about a project.
- [Context optimization](context.md): how the product keeps an Agent's context
small, and what you can do to keep it smaller.
- [External tools](integrations.md): how knowledge written somewhere else
reaches a Workspace.
- [Plans and seats](plans.md): the four plans, what a seat is, what the caps
are, and what happens when you move to a smaller plan.
- [Support](support.md): the address to write to, and what to put in the email
so the exchange is short.
---
Source: https://docs.meridiaan.io/what-is-meridiaan/
# What Meridiaan is
## What Meridiaan does
Meridiaan holds what a project knows, and serves it to the Agents you already
work with. You write it once, in one place, and from then on your Agent reads
it and keeps it up to date while you work, instead of being told the same
things at the start of every session.
It is not a shelf of documents to read. Every [Workspace](workspaces.md) is exposed as a
standard MCP server, so an Agent asks it questions and writes back to it in the
middle of a task, without you pasting context into a prompt.
You do not build any of that server yourself: the protocol and the
infrastructure are ours, what is inside is yours.
## Who Meridiaan is for
Whoever builds something of their own, alone or in a small team, with or
without clients. Not necessarily a software developer: what the project is
about can be research, hardware, an engineering job, as long as the material is
the project's own.
- **Whoever develops software** keeps decisions, operating instructions and
what has been done where the Agent can reach them.
- **Whoever builds Agents** gets a memory for them, with the protocol already
implemented and nothing to host.
- **Whoever builds with AI without being a developer** starts from what their
assistant can already do, and adds a place where its answers stay.
- **Whoever needs to know how a project is going** asks in plain language,
through an Agent someone has already connected, instead of reading
documentation.
## How Meridiaan works
Users and Agents work on the same Workspace, from two different doors:
Three steps, and the second is the one that lasts.
A **Workspace** is one project. Inside it, **[Collections](collections.md)** group the [Documents](documents.md)
of the same kind, and each Collection can carry the instructions that say how
it wants to be written: the Agent receives them when it connects, so the rule
travels with the Collection instead of living in a prompt someone has to
remember.
Then you connect. Every Workspace has its own address and its own token, and
any tool that speaks MCP can use them.
Where to go from here:
- [Connect an Agent](connect.md), if you want to try it now.
- [Organizations, Workspaces, Collections and Documents](concepts.md), for what
each of those words means.
- [Roles](roles.md) and [Plans and seats](plans.md), for who can do what and
what it costs.
---
Source: https://docs.meridiaan.io/use-cases/
# Use cases
Each situation below names who it is for, and works with the product as it is
today. Each one has a page of its own, with the shape it would take: a
[Workspace](workspaces.md), the people around it, and the [Collections](collections.md) that case would open.
- [A Developer building their own Product](developer.md): The project lasts months, the decisions accumulate, and the reasons behind them live in chats that nobody reopens.
- [A Freelancer working across several Projects](freelancer.md): Four clients, four projects, each with its own history.
- [An Agency running a Project for a Client](agency.md): Three people, four clients, each with its own stack, its own vocabulary and its own history of what was decided and why.
- [A Researcher carrying a Line of Study](researcher.md): Hypotheses, protocols, results, and the results that were discarded together with the reason, which is the part that normally gets lost.
- [A Product Team deciding what to build](product-team.md): Positioning, who it is for, what to charge, where to be seen: decided once, argued over for a week, and then living in a deck nobody opens.
- [A Team building Agents](agents-team.md): Here Meridiaan is not a documentation tool.
- [A Team building Hardware, or anything physical](hardware.md): A hardware product, a building, an engineering job.
- [A Knowledge Base used as a Living Log](living-log.md): Some [Documents](documents.md) are there to say what happened recently.
- [Whoever needs to know how a Project is going](following-a-project.md): A founder, a manager, whoever is not doing the work but has to answer for it.
- [Whoever writes about the Product](writing-about-the-product.md): Positioning, features, who it is for, what was decided about pricing.
---
Source: https://docs.meridiaan.io/developer/
# A Developer building their own Product
The project lasts months, the decisions accumulate, and the reasons behind them
live in chats that nobody reopens.
[Collections](collections.md) for what deserves to be separated. Each one carries the instructions
that say how it wants to be written, and every Agent receives them on
connecting, so the rule holds even when you are working at midnight and do not
feel like being rigorous.
What changes: the Agent stops asking you to re-explain the project, and stops
inventing a convention you abandoned in March.
---
Source: https://docs.meridiaan.io/freelancer/
# A Freelancer working across several Projects
Four clients, four projects, each with its own history. Each one gets its own
[Workspace](workspaces.md), with the [Collections](collections.md) that project needs, and the Agent you connect to
one reaches that one only.
What belongs to no project in particular — the way you want to be answered, the
conventions you apply to your own work, the checks you want before a risky
change — goes in [Persona](persona.md), the personal Workspace, which the Agent
carries with it into whatever it is working on.
---
Source: https://docs.meridiaan.io/agency/
# An Agency running a Project for a Client
Three people, four clients, each with its own stack, its own vocabulary and its
own history of what was decided and why. Every time a project comes back after
six months, someone spends a day reconstructing it.
One [Workspace](workspaces.md) per client, and inside it what that client imposed and what was
promised.
Each Workspace has its own address and its own credentials, so an Agent
connected to one client cannot reach another's.
What changes: the answer to "why is it done this way here" comes from the
record, not from whoever happens to remember. And a new person on the team is
invited as an Editor on the one Workspace they work on, and sees nothing else.
---
Source: https://docs.meridiaan.io/researcher/
# A Researcher carrying a Line of Study
Hypotheses, protocols, results, and the results that were discarded together
with the reason, which is the part that normally gets lost.
An Agent answers on the state of the research without you rebuilding the picture
each time, and what it reads is your material, not a public archive.
What changes: six months later, the question "did we already try this" has an
answer.
---
Source: https://docs.meridiaan.io/product-team/
# A Product Team deciding what to build
Positioning, who it is for, what to charge, where to be seen: decided once,
argued over for a week, and then living in a deck nobody opens. Six months
later the landing page says one thing and the pricing page another.
One [Workspace](workspaces.md) for the product itself, with the decisions and the reasons behind
them, the profiles it is for, what was chosen about price and distribution, and
the questions still open. Each decision names the option that was discarded, so
the next person does not reopen it from scratch.
The people are not all the same here. Whoever leads decides and reads more than
they write; whoever carries the product writes most of what is there; whoever
communicates it reads it to know what to say. They are three roles on the same
Workspace, and the roles are the ones the product already has: an Owner, and
Editors beside them.
What changes: whoever writes the next landing page asks what the positioning
says and gets the version with its reasons attached, instead of the version
somebody remembers. And when a decision is revised, what gets rewritten is the
[Document](documents.md) that carried it.
---
Source: https://docs.meridiaan.io/agents-team/
# A Team building Agents
Here Meridiaan is not a documentation tool. It is memory for the Agents you
build: the protocol is implemented, the infrastructure is ours, and what an
Agent learns has somewhere to live that outlasts a session.
Any client that speaks MCP connects, so the same knowledge can be queried by the
Agent you ship and by the assistant you use to build it.
---
Source: https://docs.meridiaan.io/hardware/
# A Team building Hardware, or anything physical
A hardware product, a building, an engineering job. Project decisions,
constraints, the revisions of a component and why each one happened, site notes
and the history of variants.
What changes: "why was it built this way" gets answered from the record instead
of from the person who was there, and that person can go on holiday.
---
Source: https://docs.meridiaan.io/living-log/
# A Knowledge Base used as a Living Log
Some [Documents](documents.md) are there to say what happened recently. The [Workspace](workspaces.md) stops
being a manual and becomes a record you can question, which works the same way
for maintenance notes on something that already exists.
---
Source: https://docs.meridiaan.io/following-a-project/
# Whoever needs to know how a Project is going
A founder, a manager, whoever is not doing the work but has to answer for it.
They ask in plain language, through an Agent someone has already connected, and
get an answer built on what the project actually knows.
This case models nothing of its own: the shape it reads is the one somebody else
built. In the drawing the two people who write are faint on purpose, because
what matters here is the third one.
Worth saying plainly: this is a way of receiving, not a way in. Connecting a
client is a technical step, and whoever only wants answers relies on someone
else having done it.
---
Source: https://docs.meridiaan.io/writing-about-the-product/
# Whoever writes about the Product
Positioning, features, who it is for, what was decided about pricing. The
[Workspace](workspaces.md) answers instead of the people building the thing, who were going to
answer three days later anyway.
---
Source: https://docs.meridiaan.io/concepts/
# The entities
What a project knows lives in nested things: an [Organization](organizations.md), the [Workspaces](workspaces.md) it
owns, the [Collections](collections.md) inside them, and the [Documents](documents.md) inside those. The first one
is the only one you may never meet, and that is by design. Beside them, inside
the same Workspace, sits the Workbench: what says how the work is done, rather
than what the project knows.
Each one has a page of its own:
- **[Organization](organizations.md)** owns the Workspaces. It is what the plan
is attached to and where the seats are counted. It stays out of sight while
you are alone, and appears when somebody else comes in.
- **[Workspace](workspaces.md)** is one project's knowledge base, with its own
MCP address and its own key. Users are invited one Workspace at a time.
- **[Collection](collections.md)** groups the Documents of the same kind, with
the statuses they move through and the instructions that say how that
Collection wants to be written.
- **[Document](documents.md)** is the unit of content: a title, a summary and
the content, plus a status when its Collection defines a workflow.
And, in the Workbench:
- **[Command](commands.md)** is a reusable text you invoke by name, with the
arguments it declares.
- **[Skill](skills.md)** is a piece of know-how an Agent picks up when the
condition written on it applies.
- **[Loop](loops.md)** is a recurring round of work, written down so an Agent
can pick it up instead of waiting to be told.
Changing the shape of a Workspace, which means creating, renaming or deleting a
Collection and writing its instructions, is reserved to the Owner. Whoever
collaborates works on the Documents inside the Collections that exist. Role by
role, that is on the [Roles](roles.md) page, and what the instructions of each
entity are for is on [Entities instructions](instructions.md).
---
Source: https://docs.meridiaan.io/organizations/
# Organization
An Organization owns [Workspaces](workspaces.md). It is what the plan is attached to, and it is
where the seats that allow Users to write are counted.
Every account has one from the day it is created, and it stays out of sight
while you are the only person in it. Working alone, you will not see the word
anywhere, and nothing asks you to deal with it.
It shows up when it starts to make a difference, which is when someone else
comes in. Open one of your Workspaces to another person and that Workspace moves
into a shared Organization of yours, created at that first invitation. If you
already share another Workspace with the same person, that existing Organization
is used instead of opening a second one.
From then on Meridiaan names the Organization wherever an action depends on
which one you are using, and stays quiet everywhere else. It never becomes a
level you navigate through: you still open a Workspace, not an Organization that
contains it.
## What the first invitation does to a Workspace
A few things follow from this:
- **A shared Organization starts without a plan**, and a Workspace under it
cannot be written to until one is chosen. This is a stated condition, not a
failure: whoever administers the Organization resolves it by picking a plan.
- **It starts without a name**, and shows its identifier until someone gives it
one. The name is read by everyone inside it.
- **One person can administer more than one**, each with its own plan and its
own bill.
- **Being Admin of an Organization and Owner of a Workspace are two different
things**, at two different levels. Whenever one of the two words appears, it
says what it is Admin of, or Owner of.
Who pays, what a seat is and who takes one are on the
[Plans and seats](plans.md) page. What sits inside an Organization is described
on [Workspace](workspaces.md).
---
Source: https://docs.meridiaan.io/workspaces/
# Workspace
A Workspace is one project's knowledge base. It holds the [Collections](collections.md), the Users
invited to it, and the connection an Agent uses to reach it: every Workspace has
its own MCP endpoint, protected by a key of its own.
## An invitation is to one Workspace, and there is no limit to how many you are in
An invitation gives access to the Workspace it names, with the role it names,
and to nothing else: the other Workspaces of the same [Organization](organizations.md) stay
invisible, personal ones included.
Nothing stops the same person from being in many. You can be an Editor in some
Workspaces and a Viewer in others at the same time, each invitation standing on
its own. What is counted is not how many Workspaces you are in: writing takes a
seat from whoever owns the Workspace, reading takes none, and the caps are on
the [Plans and seats](plans.md) page.
The same holds for Agents. A client can keep several Workspaces connected at
once, because each one has its own address and its own credentials, and each
connection reaches its own Workspace and no other. How a client gets connected
is on [Connect an Agent](connect.md).
## Two shapes: Simplified and Structured
A **Structured** Workspace has the Collections you create, each with its own name,
its own statuses and its own instructions.
A **Simplified** Workspace has a single Collection that is never named, so
nothing asks you to choose where a [Document](documents.md) goes, and the instructions are
presented as a setting of the whole place. The personal Workspace,
[Persona](persona.md), is a Simplified one with a job of its own.
Which text an Agent receives in each case is on
[Entities instructions](instructions.md).
## What a Workspace holds
The Collections inside it, described on [Collection](collections.md), and the
Documents inside those, on [Document](documents.md). Who owns the Workspace and
who the plan belongs to is on [Organization](organizations.md).
---
Source: https://docs.meridiaan.io/collections/
# Collection
A Collection groups [Documents](documents.md) of the same kind inside a [Workspace](workspaces.md). A Workspace
about a piece of software may keep its decisions in one Collection, its open
questions in another and its technical reference in a third.
Two things make a Collection more than a folder.
## A workflow, when it has one
A Collection can define the statuses its Documents move through, and a Document
can only take one of those. A Collection without a workflow has no statuses at
all.
An Agent receives those statuses together with the name and the identifier of
the Collection, so it can file a Document in the right state without being told
what the states are.
## Instructions written by the Owner
They say how that Collection wants to be written, and the Agent receives them
when it connects, so the rule travels with the Collection instead of living in a
prompt someone has to remember. How to write ones that are worth their length is
on [Entities instructions](instructions.md).
## Who decides which Collections exist
The Owner decides which Collections exist, what they are called and whether they
are exposed to Agents at all. What an Agent can do with them once connected is
on [The tools an Agent receives](tools.md), and what goes inside them is on
[Document](documents.md).
---
Source: https://docs.meridiaan.io/documents/
# Document
A Document is the unit of content: a title, a summary of what it is about, and
the content itself. When its [Collection](collections.md) defines a workflow, the Document also
carries one of those statuses.
## The summary is what an Agent reads first
When an Agent lists a Collection it receives the titles and the summaries, never
the content, and it decides from those which Documents to open in full. A
summary that says what the Document is about, in the words it would be searched
with, is what keeps an Agent from opening five Documents to find one.
The same applies to search: it runs on titles, summaries and identifiers, not on
the content.
## Archiving instead of deleting
Documents can be archived when they stop being current, which keeps them
readable without leaving them in the way, and a single Document can be kept out
of what the Agents see.
An Agent has no way to delete a Document: archiving is the only way it has to
take something out of the way. The full list of what an Agent can and cannot do
is on [The tools an Agent receives](tools.md).
## Where Documents live
Inside a [Collection](collections.md), which decides the statuses they can take
and the instructions that say how they should be written. How to keep what
reaches an Agent small is on
[Context optimization](context.md).
---
Source: https://docs.meridiaan.io/instructions/
# Entities instructions
Instructions are text attached to a thing rather than to a prompt. Every Agent
receives them when it connects, so the rule holds for whoever writes there,
today and in six months, without anyone remembering to paste it anywhere.
Two entities carry them, the [Workspace](workspaces.md) and the [Collection](collections.md). A [Document](documents.md) does not:
what plays that role for a Document is its summary, which an Agent reads before
deciding whether to open it.
## Workspace
**The description** says what this Workspace is about. An Agent receives it when
it connects, before anything else, and it is what orients it: whether it has
opened a product, a piece of research or a client's project.
**The instructions**, in a Simplified Workspace. There, the single Collection is
never named, so the same instructions field is presented as a setting of the
whole place and written with `update_workspace_instructions`. In a Structured
Workspace that level does not exist: the instructions live on each Collection.
The personal Workspace, Persona, is a Simplified one with a job of its own, and
it has [a page to itself](persona.md).
## Collection
**The instructions of a Collection** are the ones that matter most in daily use.
They say how that Collection wants to be written, and every Agent receives them
together with the name, the identifier and the statuses of that Collection.
Only the Owner writes them, and only in a Structured Workspace.
### Form: rules addressed to whoever writes
An Agent already knows what a Collection is called. What it does not know is how
you want it written.
Write them addressed to whoever writes, in the imperative, and be specific about
what a good Document of that kind contains:
> Every Decision says what was chosen and why. Name the option that was
> discarded and the reason. Link by identifier the Document the decision comes
> from. Do not describe the implementation: that goes in the technical
> reference.
Compare it with the version that says nothing:
> This Collection contains the decisions taken on the project.
The second one costs the same characters as the first and changes nothing about
what gets written.
### Length limit: five hundred characters
Instructions stop at five hundred characters, and it is not an arbitrary limit:
they are served at every connection, for every Collection of the Workspace. A
long text is paid for at every connection, by every Agent.
The useful test is to reread them and remove every line that says something the
name of the Collection already says.
### What to include, and what to leave out
- **What a Document of this kind must contain**, in one or two sentences.
- **What it must not contain**, when you have seen it go wrong. This is the part
that saves the most, because an Agent does not know your rejected drafts.
- **How things link to each other**, if a Document of this Collection normally
points at another one.
- **The vocabulary to use**, when a word of yours has a precise meaning.
What is not worth putting in: anything that changes often, the history of the
project, and the explanation of what the Collection is, which its name already
gives.
## When a change takes effect
At the next connection, on both levels. An Agent that is already running
keeps what it received when it connected, so after changing any of these you
restart the session.
---
Source: https://docs.meridiaan.io/commands/
# Command
A Command is a reusable text you write once and invoke by name. It lives in the
Workbench of a [Workspace](workspaces.md), beside the Skills and the Loops, and not inside a
[Collection](collections.md): it is not something the project knows, it is something you do with
the project.
## Arguments are what makes it parametric
A Command without arguments is a text you recall. A Command with arguments is a
text with holes in it, and each argument declares its name, what it is for and
whether it is required.
Those declarations are not a convention that every client interprets its own
way: they travel with the Command, so the client knows what to ask you before
it sends anything.
## How a Command reaches your client
Through the protocol's own prompt methods, the pair that lists them and fetches
the one you picked. That is why a Command does not take a slot in the list of
tools an Agent receives: it arrives on a different channel, and the list of
tools stays as short as it is described on
[The tools an Agent receives](tools.md).
## Versions, and what the Agent installs
Every change makes a version, and a version is a photograph that does not
change afterwards. It matters because a Command can end up written to disk
inside your harness: what is installed there is a copy, and the version stamp
inside it is what lets an Agent notice it is behind.
Meridiaan writes nothing on your machine. It hands the body and where it goes;
whoever has the file system does the rest.
---
Source: https://docs.meridiaan.io/skills/
# Skill
A Skill is a piece of know-how an Agent picks up when it needs it: how a
release is cut here, how a review is written, what to check before touching the
schema. It lives in the Workbench of a [Workspace](workspaces.md), beside the Commands and the
Loops.
## What it is for is as important as what it says
A Skill carries, besides its body, the condition that says when it is worth
loading. That line is what an Agent reads first, and it is what decides whether
the Skill is ever used: a body written well under a vague condition never gets
picked up.
## How a Skill reaches an Agent
The protocol has no native channel for this, so a Skill does not arrive on its
own: the Agent asks for it. One generic tool answers for the whole Workbench —
without arguments it returns the list, a name and a when-to-use line each, and
with an identifier it returns the body.
That shape is deliberate: the list costs a few dozen characters per entry, and
the body is paid for only by whoever actually needs it. It is the same
reasoning as [Context optimization](context.md).
## One Skill, several harnesses
The body stays neutral, without the folder conventions of any particular
harness. What is specific to each one is the translation at install time, done
by the Agent that has the file system: you write it once, and the same Skill
can land in more than one place.
Every change makes a version, and the version stamp inside an installed copy is
what lets an Agent notice that what it has on disk is older than what is here.
---
Source: https://docs.meridiaan.io/loops/
# Loop
A Loop is a recurring round of work written down: the checks you run before a
release, the sweep over what changed since yesterday, the pass over the open
questions. It lives in the Workbench of a [Workspace](workspaces.md), beside the Commands and
the Skills.
## Meridiaan does not run it
A Loop is a text that leads an Agent to iterate, not a job that something here
executes. Nothing in Meridiaan wakes up on a schedule: the cadence belongs to
the harness you work in, and a Loop is the definition it picks up.
This is the line the product holds everywhere: it strengthens the harness you
already use rather than replacing it.
## The condition of use is what starts it
Today a recurring round starts because a person types a command, which means
somebody has to remember. A Loop carries the condition that says when it
applies, and that is what lets an Agent pick it up when it recognises the
moment.
Which is why a Loop with a well written body and a vague condition never runs:
the condition weighs as much here as it does on a [Skill](skills.md).
## How a Loop reaches an Agent
The same way a Skill does, because the protocol has no channel of its own for
either: one generic tool for the whole Workbench, the list first, the body on
request. What the Workbench holds is described on [Skill](skills.md).
---
Source: https://docs.meridiaan.io/connect/
# Connect an Agent to a Workspace
Every [Workspace](workspaces.md) is exposed as a standard MCP server, so any tool that speaks the
protocol can read and write it. You configure the connection once, and from then
on the Agent works on its own.
## Connection requirements: address and credentials
**The address of that Workspace**, in the form
`https://mcp.meridiaan.io/mcp/`, is on the Connection page of the
Workspace inside Meridiaan. Each Workspace has its own, so a client that refuses
two servers at the same address can still hold several of them.
**Then a way to authenticate**, and there are two. They work on that same
address, neither excludes the other, and the next section describes them.
One address and one token, and the client is in:
The list of tools travels once, when the connection opens. That is why a
[Collection](collections.md) created later does not show up in a session that is already running.
## Authentication methods: Workspace token or OAuth
**The token of the Workspace**, sent as a Bearer token. It is on the Connection
page, it does not expire, and it is rotated by hand. Whatever configures your
client has to hold it, which is why it ends up written in a file or in the
settings of that client.
**OAuth 2.1**, where no secret is ever pasted anywhere. A client that speaks it
needs the address and nothing else: it is refused once, the refusal tells it
where to ask, it registers itself, and it opens a browser where you confirm what
it will be allowed to do on that Workspace. The Agent receives a token bound to
that Workspace, which expires and is renewed on its own, and you can revoke it
from Meridiaan without touching any configuration.
Both ways are live and neither is going away. The choice is made by your client
more than by you: if it speaks OAuth, it will use it by itself, and if it does
not, the token is there. **Which of the clients listed below speak OAuth has not
been verified one by one**, and the Connection page does not hand out a ready
made OAuth configuration yet.
## Configuration methods
These are the ways the token is handed to you, at three levels of effort, so
whoever does not find their own tool goes down one step instead of being stuck.
A client that authenticates with OAuth needs none of them: the address is
enough.
1. **One click.** A button opens the client and creates the entry already
filled in. Today it exists for Cursor, VS Code and LM Studio. Two things are
worth knowing before you press it: the token travels inside the address of
the button, so it ends up in the history of that client, and the button
always installs the entry globally, because none of those three accepts a
destination.
2. **A ready made block.** The configuration already written in the shape your
tool expects, and the place where it goes, which is the part that changes
most from tool to tool. There are entries for editors, for command line
tools, for desktop applications, for those who write the Agent themselves in
Python, LangChain or LangGraph, and a generic one.
3. **The minimal formula.** The address and the token, named as such, for
whoever knows their own client better than we do.
**A tool that is not in the list connects just the same.** What makes a client
work is that it speaks MCP, not that we know its name, and the generic entry is
written for exactly that case.
**Claude Desktop takes a different path**, and it is the one worth writing down
because it is the least obvious: you add it from Settings and then Connectors,
as a custom connector whose authentication is set to none, with an
authorization header added by hand. That feature is in beta on Anthropic's side
and is available on their paid plans.
## Transport and protocol revisions
The transport is
[Streamable HTTP](https://modelcontextprotocol.io/specification/2025-03-26/basic/transports):
one endpoint, one POST per message, a plain JSON answer. The stream that the
specification lets a server open on GET is not offered here, and the server
keeps no session state of its own, so nothing stays open between one call and
the next.
On the protocol itself the server is dual era, in the sense the
[MCP specification](https://modelcontextprotocol.io/specification/2026-07-28)
gives that word: it negotiates the revision while
the connection opens, and answers both clients that stopped at the revisions up
to 2025-11-25 and clients on the current 2026-07-28. A client of either era
works without you migrating anything.
---
Source: https://docs.meridiaan.io/tools/
# The tools an Agent receives
When an Agent connects to a [Workspace](workspaces.md) it receives a list of tools, and that
list is what it can do there. It is built for the person whose token opened the
connection: their role, whether they hold a seat, and how the Workspace is set
up. A Viewer receives four tools, an Editor six, an Owner nine.
The list travels once, when the connection opens, so a change of role or a new
[Collection](collections.md) shows up in the next session, not in the one already running.
## Protocol standards and security
The tools are built on the current MCP specification, and the server speaks two
eras of it on the same address: it negotiates the revision while the connection
opens, and answers both clients that stopped at
[revision 2025-11-25](https://modelcontextprotocol.io/specification/2025-11-25)
and clients on the current
[revision 2026-07-28](https://modelcontextprotocol.io/specification/2026-07-28).
The transport is
[Streamable HTTP](https://modelcontextprotocol.io/specification/2025-03-26/basic/transports),
introduced with revision 2025-03-26. Nothing has to be migrated on your side,
and a client of either era works next to the other.
Security is part of that design rather than a layer added on top:
- **Two ways to authenticate on the same address**, the token of the Workspace
or [OAuth 2.1](https://datatracker.ietf.org/doc/draft-ietf-oauth-v2-1/) with
[PKCE, RFC 7636](https://www.rfc-editor.org/rfc/rfc7636). The document that
lets a client discover the second one by itself follows
[RFC 9728, OAuth 2.0 Protected Resource Metadata](https://www.rfc-editor.org/rfc/rfc9728),
and clients register themselves without a shared secret, as
[RFC 7591](https://www.rfc-editor.org/rfc/rfc7591) describes.
- **A token is bound to one Workspace.** The expected recipient is built from
the address that was called, so a token that is valid but issued for another
Workspace does not get in, and the identifier in the address is not
decorative.
- **The server decides how a token is signed**, and accepts one signature
algorithm only. A token does not get to declare how it should be verified.
- **The role is read at every call**, so losing a role or a seat has effect
immediately. What a role cannot use is both missing from its list of tools and
refused if it is invoked anyway, which is why an already open session cannot
do more than it should.
- **Anything unexpected denies.** An authentication path that breaks before
deciding is a path nobody knows which way it fails.
## Workspace Level
### Read
- **`get_workspace_informations`** is the door, and every role receives it. It
gives the name and the description of the Workspace and, in a Structured one,
the list of its Collections with their identifiers, their statuses and their
instructions. The Agent takes the Collection identifiers from here, so it
usually calls this first.
### Write
- **`update_workspace_instructions`** writes the instructions that every Agent
receives on connecting. Only the Owner receives it, and only in a Simplified
Workspace, where the single Collection is never named and that text reads as a
setting of the whole place.
## Collection Level
Only the Owner receives these, because they change the shape of the Workspace
rather than its content, and they exist only in a Structured Workspace.
### Read
- **`get_available_collection_types`** lists the kinds of Collection that can be
opened, and says which ones the Workspace already has.
### Write
- **`create_collection`** opens a new one, with its name and its statuses.
- **`update_collection_instructions`** writes the instructions of a Collection,
the ones every Agent receives when it connects.
## Document Level
### Read
Every role receives these three, Viewer included, and reading never requires a
seat.
- **`list_documents`** lists the [Documents](documents.md) of one Collection with their title
and their summary, never the content. It can filter by status, include the
archived ones, and it says when it has cut a long list.
- **`search_documents`** searches titles, summaries and identifiers, never the
content. The Collection is optional: without it, it searches the whole
Workspace.
- **`get_document`** reads one Document in full, content included. An archived
Document comes back too.
Two of these say what a Document is about without opening it, which is why the
summary you write matters: it is what an Agent reads before deciding what to
open.
### Write
Only an Owner or an Editor receives these two, and writing also requires a seat.
- **`create_document`** creates a Document inside a Collection.
- **`update_document`** changes a Document, archives it and brings it back. It
requires the timestamp of the version the Agent read, so two Agents working
at the same time cannot overwrite each other in silence.
Whoever can write but holds no seat keeps the reading tools and loses these two,
and the refusal says so: it talks about the seat, not about the role.
## Actions not available to an Agent
- **Delete a Document.** Archiving is the only way an Agent has to take
something out of the way, and an archive is not a bin.
- **Move a Document to another Collection.** It is done from the web app.
- **Rename, deactivate or delete a Collection.** An Agent can open one and
write its instructions, the rest stays with whoever owns the Workspace.
- **Give someone a seat.** Seats are assigned by whoever administers the
[Organization](organizations.md) that pays for them.
Who can do what, role by role, is on the [Roles](roles.md) page. How a client
gets connected in the first place is on [Connect an Agent](connect.md).
---
Source: https://docs.meridiaan.io/workbench-commands/
# Commands
The thing you ask for every week, written once and given a name. You type the
name, the Agent gets the full text, and nobody pastes three paragraphs from a
note again.
## It asks you what it needs
A Command declares its arguments — what they are called, what they are for,
whether they are required — so your client asks you for them before sending
anything. The same Command covers every release, every client, every month,
because what changes is passed in instead of being rewritten.
## It does not cost the Agent anything
Commands travel on the prompt channel of the protocol, not among the tools an
Agent receives. Which matters more than it sounds: everything in that list is
paid for in context on every single connection, and this list does not grow
when you write your tenth Command.
## Everyone gets the good version
A Command lives in the [Workspace](workspaces.md), not on one laptop. Whoever
joins finds it, whoever improves it improves it for everyone, and every change
keeps a version, so going back is reading, not remembering.
What a Command is and how it reaches a client is on [Command](commands.md).
---
Source: https://docs.meridiaan.io/workbench-skills/
# Skills
How a release is cut here. What to check before touching the schema. The things
you explain to whoever arrives, and then explain again to the Agent, at the
start of every session.
Write them once, say when they apply, and the Agent goes and gets them by
itself.
## Nothing is paid for until it is needed
The Agent first receives the list: a name and a line saying when the Skill
applies, a few dozen characters each. The body — the long part, the one with
the detail — travels only for the Skill it actually opens.
So a Workspace can hold twenty Skills without twenty of them weighing on every
conversation.
## Written once, installed wherever you work
The body stays neutral: no folder convention belonging to one tool. It is the
Agent that translates it when it installs it, so the same Skill lands in the
places you work in, and changing client does not mean writing it again.
Every change makes a version, and an installed copy carries the stamp of the one
it came from — which is how an Agent notices that the copy on disk is behind.
What a Skill is and how it reaches an Agent is on [Skill](skills.md).
---
Source: https://docs.meridiaan.io/workbench-loops/
# Loops
The round you do every Monday. The sweep over what changed. The checks before a
release. Work that is not hard, only regular — and that gets skipped exactly
when the week is busy.
## It starts because the moment came
A Loop carries the condition that says when it applies, so the Agent picks it up
when it recognises the moment, instead of waiting for somebody to type the
usual thing. The round is written down: the steps, and when it is done.
Which is why the condition is worth as much as the body. Written vaguely, the
Loop never starts.
## Your harness keeps the cadence
Meridiaan runs nothing and schedules nothing: it holds the definition and its
versions. Deciding when, and doing it, stays where it already is — in the
harness you work in.
That line is deliberate. This is a product that strengthens what you already
use, and does not ask you to move your work into it.
What a Loop is and how it reaches an Agent is on [Loop](loops.md).
---
Source: https://docs.meridiaan.io/context/
# Context optimization
A model does not get better as its context grows. Past a certain point it gets
worse, and this is measured rather than felt: accuracy drops when what matters
sits in the middle of a long input instead of at its edges ([Liu et al., *Lost
in the Middle*, TACL 2024](https://arxiv.org/abs/2307.03172)), reasoning
degrades at input lengths far below the technical maximum a model advertises
([Levy, Jacoby and Goldberg, ACL 2024](https://arxiv.org/abs/2402.14848)), and
the context a model can actually use is shorter than the one written on its box
([Hsieh et al., *RULER*, COLM 2024](https://arxiv.org/abs/2404.06654)).
Whatever your Agent reads before it starts working is paid for on every call, in
tokens and in attention.
Meridiaan is built around that. Most of what follows is not a setting you turn
on, it is how the tools behave, and knowing it changes how you write.
## Summaries are read before content
A [Document](documents.md) carries a title, a summary and the content. **The tools that list
and search never return the content**: an Agent scanning a [Collection](collections.md) reads
titles and summaries, decides, and only then opens what it needs in full.
So the summary is not decoration, it is the selector. A Collection of forty
Documents can be scanned for a few hundred tokens, and the one Document that
matters gets read whole. A Collection whose summaries all say "notes about the
project" forces the opposite: the Agent opens everything, or guesses.
## Instructions are written once, not repeated in prompts
The instructions of a Collection travel to every Agent at connection, together
with the list of Collections. They are not pasted into a prompt, they are not
repeated per request, and they are not something each person on the team has to
remember to include.
That is why they stop at five hundred characters. They are served on every
connection, so their cost is real and bounded on purpose, and the limit is what
keeps them a rule rather than a document.
## The surface an Agent receives is sized to its role
An Agent does not receive ten tool definitions and then get refused. It
receives the tools its role allows: four for a Viewer, six for an Editor, nine
for an Owner. Schemas and descriptions are tokens like everything else, and
tools that would only ever be refused are not worth their characters.
## Answers are bounded by design
- Lists are capped, and they say so when they cut, instead of returning
everything and hoping.
- Archived Documents are out of listings unless they are asked for, so material
you have set aside stops being paid for.
- A search returns matches, never the body of every match.
## What you can keep out of the Agent's view
- **Archive what is no longer current.** Nothing is deleted, and it stops
arriving in the default listings.
- **Keep a single Document out of what Agents see**, when it is internal to the
team rather than useful to a model.
- **Expose a Collection to Agents, or do not.** A Collection that an Agent has
no business reading costs nothing if it is not exposed.
## What repeats is stable, which is what caching needs
Inside one session, the list of tools and the [Workspace](workspaces.md) description do not
change: they travel once, at connection, and stay identical for the whole
session. That is exactly the shape that prompt caching on the model side is
able to reuse, and Meridiaan does nothing that breaks it.
The counterpart is worth knowing: a Collection created mid session does not
appear in that session. It is the same property seen from the other side, and
reconnecting is enough.
## Where the opening claim comes from
The three measurements above are not ours, and they are worth reading before
deciding how much context to give an Agent:
- [Liu, Lin, Hewitt, Paranjape, Bevilacqua, Petroni and Liang, *Lost in the
Middle: How Language Models Use Long Contexts*, TACL
2024](https://arxiv.org/abs/2307.03172), on where inside a long input a model
stops paying attention.
- [Levy, Jacoby and Goldberg, *Same Task, More Tokens: the Impact of Input
Length on the Reasoning Performance of Large Language Models*, ACL
2024](https://arxiv.org/abs/2402.14848), on reasoning that degrades with
length alone, with the task held fixed.
- [Hsieh, Sun, Kriman, Acharya, Rekesh, Jia, Zhang and Ginsburg, *RULER: What's
the Real Context Size of Your Long-Context Language Models?*, COLM
2024](https://arxiv.org/abs/2404.06654), on the distance between the declared
context window and the usable one.
## What this means when you write
- Write the summary as if it were the only thing read, because most of the time
it is.
- Keep one kind of thing per Collection, so that a status filter narrows a read
instead of an Agent reading everything to sort it out.
- Put in the instructions what would otherwise be repeated in every prompt, and
nothing else.
- Archive what is stale, on the day it goes stale.
---
Source: https://docs.meridiaan.io/persona/
# Persona, the personal Workspace
Every account gets one [Workspace](workspaces.md) that is not about a project: it is called
Persona, it is created with the account, and there is exactly one per person.
What goes in it is the part of your context that does not belong to any single
project: how you want an Agent to work with you, the conventions you keep across
everything you do, the preferences you would otherwise repeat at the start of
every session.
## Why it exists separately
A rule like "explain the mechanism, not the function names" is true on every
project you have. Written inside one Workspace it would hold there and nowhere
else, and you would write it again in the next one.
Persona is the place where that kind of rule is written once. An Agent connected
to it carries your way of working into whatever it is doing.
## What belongs in it, and what does not
**In it:** how you want to be addressed and answered, what you want checked
before a risky change, the conventions you apply to your own work, the tools and
habits that follow you from project to project.
**Not in it:** the rules of one project, its data model, its vocabulary, the
state of its work. Those belong to that project's Workspace, and putting them
here makes them arrive where they do not apply, on every other project you
touch.
It is the same distinction the whole product is built on, applied to yourself:
what is general goes where it is general, what belongs to one place stays in
that place.
## How it is shaped
Persona is a Simplified Workspace: one [Collection](collections.md), no statuses, no Collection
level to manage. You write [Documents](documents.md) in it and that is all there is to it.
Like every Workspace it has its own address and its own credentials, so an Agent
connects to Persona the way it connects to anything else, and many people keep
it connected next to the project they are working on.
## Its instructions
Persona carries the instructions of a Simplified Workspace, written with
`update_workspace_instructions`, and every Agent that connects to it receives
them. They are the right place for the one line that says how the Documents in
here should be written and read.
What they should not become is a copy of the Documents themselves: five hundred
characters that tell an Agent how to use this Workspace are worth more than five
hundred characters that try to summarise it.
---
Source: https://docs.meridiaan.io/integrations/
# External tools
Part of what a project knows is already written somewhere else: a Notion space,
an Obsidian vault, a repository, the notes of whoever has been on the project
longest. This page says how that material reaches a [Workspace](workspaces.md), and what is
possible today.
## What is possible today
There is no automatic import yet. A Workspace is filled by the Agent you work
with, which writes [Documents](documents.md) while you work, and that includes the material you
already had.
A Workspace is a standard MCP server, so a client can keep Meridiaan connected
next to the MCP server of the tool you are coming from, and carry the content
across in one session: the Agent reads there and writes here, with the
instructions of the [Collection](collections.md) telling it how each Document should be written.
How a client gets connected is on [Connect an Agent](connect.md).
## Two ways of bringing knowledge in
**Importing** copies the content in. From that moment it is Documents of a
Collection, it is searched, cited and kept up to date like everything else, and
the tool it came from is no longer needed.
**Reading live** leaves the content where it is and goes to fetch it when
somebody asks. Nothing is stored, and what the source changes is visible
immediately.
The rule Meridiaan follows is which of the two the source deserves: it is
imported when the source is being abandoned, it is read live when the source
goes on living.
## Importing from a tool you are leaving
An Obsidian vault on your disk, or a Notion space you are moving away from, ends
when you stop opening it. That material is imported: it becomes Documents, and
what you leave behind is the tool, not what you wrote in it.
This is not available yet, and the section will say so until it is.
## Reading a source that stays alive
A source that goes on being used by other people, with its own MCP server, does
not need Meridiaan in the middle: a client can connect that server directly,
next to the Workspace. Notion is one of these. Putting the same thing behind
Meridiaan would add tools to every connection, and every tool is paid for in
context on each one, which the [context optimization](context.md) page goes
into.
The case that does deserve it is a Git repository, because the value is not in
reading the files: it is one address whatever the provider, a credential
governed by the Workspace, and search across any branch. It is planned, and it
is not available yet.
## Asking for a source
Which sources come first is decided on what gets asked for. If you are moving
from a tool and you need the content in, write to
[support@meridiaan.io](mailto:support@meridiaan.io) naming it.
---
Source: https://docs.meridiaan.io/plans/
# Plans and seats
Whoever owns the [Workspaces](workspaces.md) pays, not the person invited to collaborate on
them. You are invited, you come in and you read without paying anything; to
write, you take one of the seats bought by whoever invited you.
You pick a plan from inside the app, in the window where the plan is changed,
or from the buttons on the Pricing page of the public site: both roads lead to
a checkout. The Free plan comes with signing up.
## The four plans
| | Free | Solo | Studio | Team |
|---|---|---|---|---|
| Price per seat, per month | 0 | 9 € | **12 €** instead of 15 € | **19 €** instead of 25 € |
| Seats you can buy | 1, fixed | 1, fixed | as many as you need | as many as you need |
| Workspaces | 1 | 5 | 5 | unlimited |
| [Documents](documents.md) per Workspace | unlimited | unlimited | unlimited | unlimited |
| Readers per Workspace | 0 | 3 | unlimited | unlimited |
| Agent requests per month | 2,000 | unlimited | unlimited | unlimited |
The launch price is held for twelve months from the day you subscribe.
**Free and Solo are single seat plans**, and the seat is yours. Whoever needs
someone else who writes moves to Studio: since the price is per seat, that is
the only difference between Solo and Studio.
**Studio and Team differ on how many Workspaces you can have**, not on how many
people fit. There is no cap on the seats you can buy, deliberately: adding a
person should cost one person.
## Seats and Workspace membership
A seat is the right to write. It is bought by whoever owns the Workspaces and
given to a person, and whoever writes in a Workspace takes a seat from whoever
owns it, never from their own account.
Two things that are easy to confuse:
- **the seat** says that a person can write, and it is what is paid for;
- **being a member of a Workspace** says what they have access to, and it is
what governs what they see.
Giving someone a seat does not open everything to them: they see the Workspaces
they were invited to, and nothing else. **Whoever only reads takes no seat and
costs nothing**, which is why the readers per Workspace are counted separately.
## How the caps are measured
**Workspaces** are counted on whoever pays, across all the Workspaces they own.
The personal Workspace, the one that exists from the day you sign up, does not
count.
**Readers per Workspace** is the only cap measured on a single Workspace. On
Free there are none, so on Free you cannot share anything.
**Agent requests** are capped only on Free, at two thousand a month. On the
paid plans they are not counted against you and no counter is shown: the
product works when Agents ask a lot, so a number on screen would only make you
hold back. Fair use applies.
## Inviting someone, and what it costs
!!! note "Not in production yet"
This is decided and not yet built. Today an invitation does not move
anything: what follows is how it will behave, written here so that the rule
is known in advance rather than discovered.
**Inviting someone who only reads changes nothing.** The Workspace stays where
it is, no [Organization](organizations.md) is created, and the only limit that counts is the number
of readers of that Workspace: three on Solo, none on Free.
**Inviting someone who writes moves the Workspace into a shared Organization.**
Whoever invites chooses which of their own it lands in, among those that still
have room. If one of them already has a plan, the Workspace lands there and uses
the seats already bought, with no second subscription.
**If there is none, one is created at that moment, and it is created without a
plan.** Until a plan is chosen, nobody writes in that Workspace, its owner
included. It is a stated condition rather than a failure, and it is resolved by
choosing a plan, which can be done during the invitation itself.
**That choice does not come undone.** There is no way to move a Workspace
between your own Organizations, so the destination is picked once.
## Moving to a smaller plan
Nothing is ever deleted, and reading stays on. What you lose is writing and the
wider collaboration, and where something has to give, you choose.
| What you do | What happens |
|---|---|
| From Team to Studio, with more than five Workspaces | All stay readable, the ones beyond the fifth become read only. The most recently used stay writable, and whoever administers can change that choice. |
| You reduce the seats you bought | Nobody is removed. Whoever is left without a seat keeps reading, and whoever administers chooses who keeps the seats. |
| From Studio to Solo | Solo has one seat, so everyone else stays a member and stops writing. Readers beyond the third on a Workspace stop reading until someone is removed or the plan goes back up. |
| To Free, with more than one Workspace | The active Workspace stays full, the others become read only, and collaborators become inactive. |
| A payment fails | You get between seven and fourteen days, with warnings by email, before anything becomes read only. |
| You go back up | Everything returns as it was, because nothing was ever deleted. |
---
Source: https://docs.meridiaan.io/roles/
# Roles
Three roles exist on a [Workspace](workspaces.md), and a person gets one of them on each
Workspace they are invited to. Being Owner of one Workspace says nothing about
the others.
The line between them is content against container: whoever collaborates works
on the [Documents](documents.md), whoever owns the Workspace decides which containers exist and
how Agents are told to work in them.
| | Owner | Editor | Viewer |
|---|---|---|---|
| Read every Document | yes | yes | yes |
| Create and change a Document | yes | yes | no |
| Archive a Document and bring it back | yes | yes | no |
| Move a Document to another Collection | yes | yes | no |
| Open, rename, delete a Collection | yes | no | no |
| Write the instructions of a Collection | yes | no | no |
| Expose a Collection to Agents, or hide it | yes | no | no |
| Invite someone, and remove them | yes | no | no |
## Writing requires a seat
The role says what a person has access to. The seat says that they can write,
and it is the part that is paid for. An Editor without a seat keeps reading,
in the web app and through an Agent, and the refusal they get talks about the
seat rather than about the role.
A Viewer never needs a seat: reading costs nothing.
## Owner of a Workspace and Admin of an Organization
**Owner** is of a Workspace. **Admin** is of the [Organization](organizations.md) that owns the
Workspaces and pays for the seats. Today they are usually the same person,
because whoever creates a Workspace owns it and administers the Organization it
was created in, but they are two levels and not two grades of the same thing.
Wherever one of the two words appears, it says what it is Owner of, or Admin
of. If it does not, it is a mistake worth reporting.
## Roles on the Agent side
The same rules hold on the Agent side, and an Agent gets the tools its role
allows: four to read for anyone, two more to write for whoever holds a seat,
and the [Collection](collections.md) level only for an Owner. The page on
[the tools an Agent receives](tools.md) lists them one by one.
---
Source: https://docs.meridiaan.io/support/
# Support
Write to [support@meridiaan.io](mailto:support@meridiaan.io). It is read by the
people who build Meridiaan, and there is no form to fill in first.
## What to put in the email
Four things, and the more precise they are the shorter the exchange:
- **What you were doing**, in one sentence: the action, and where you were when
you did it.
- **What came back.** If you received a refusal or an error, copy it whole. They
are written to be readable, and one of them usually places the problem on its
own.
- **Which [Workspace](workspaces.md)**, by name, and whether you are its Owner.
- **Which client**, when the problem is on the Agent side: the tool you
connected, and whether it was a session you had just opened or one that had
been running for a while.
Screenshots help when the problem is something you saw, and are not needed when
you can copy the text instead.
## If the problem is this documentation
Write to the same address, and say which page. A page that describes something
the product no longer does is a defect like any other, and it is the kind we
want reported: from inside, the pages look right until someone reads them
against the product.
---
