The AppFlowy Cloud MCP Server allows you to interact with AppFlowy Cloud to manage workspaces, databases, rows, and documents through the following capabilities:
Authentication: Login with email and password to obtain access/refresh tokens, and refresh expired tokens.
Workspace Operations: List all workspaces for the authenticated user and get workspace folder metadata.
Database Operations: List all databases within a workspace and retrieve the fields/schema of a specific database.
Row Operations: List row IDs, get detailed row information (optionally including document content), create new rows with cell values and optional markdown documents, and upsert rows (update existing or create new, with support for pre-hash validation).
Document Operations: Create, update, get, duplicate, search, publish, unpublish, import, and manage collaborative documents and pages.
Supports using Markdown for document content when creating or updating rows in AppFlowy Cloud databases.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@AppFlowy Cloud MCP Server list all my workspaces and their databases"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A Model Context Protocol (MCP) server for interacting with AppFlowy Cloud API, providing tools for workspace, database, and row operations.
Authentication: Login and refresh token management
Workspace Operations: List all workspaces
Database Operations: List databases, get database fields
Row Operations: List rows, get row details, create rows, upsert rows
Related MCP server: Dify Management MCP
The server uses in-memory token storage. To authenticate:
Use appflowy_login with your email and password
The tokens are stored automatically
Use appflowy_refresh_token when the access token expires
appflowy_login(request: LoginRequest) - Login to AppFlowy Cloud
appflowy_refresh_token(request: RefreshTokenRequest) - Refresh access token
appflowy_list_workspaces() - List all workspaces
appflowy_get_workspace_folder(workspace_id: str, depth: int | None = None, root_view_id: str | None = None) - Get workspace folder metadata
appflowy_list_databases(workspace_id: str) - List databases in a workspace
appflowy_get_database_fields(workspace_id: str, database_id: str) - Get database fields
appflowy_list_rows(workspace_id: str, database_id: str) - List row IDs
appflowy_get_row_details(workspace_id: str, database_id: str, row_ids: str, with_doc: bool = False) - Get row details
appflowy_create_row(workspace_id: str, database_id: str, request: RowCreateRequest) - Create a new row
appflowy_upsert_row(workspace_id: str, database_id: str, request: RowUpdateRequest) - Update or create row
appflowy_create_collab(...)
appflowy_update_collab(...)
appflowy_get_collab(...)
appflowy_get_collab_json(...)
appflowy_batch_create_collab(...)
appflowy_full_sync_collab(...)
appflowy_web_update_collab(...)
appflowy_create_page_view(...)
appflowy_get_page_view(...)
appflowy_append_block_to_page(...)
appflowy_create_orphaned_view(...)
appflowy_duplicate_page(...)
appflowy_create_quick_note(...)
appflowy_list_quick_notes(...)
appflowy_search_documents(...)
appflowy_publish_page(...)
appflowy_unpublish_page(...)
appflowy_import_zip(file_path: str)
appflowy_create_import_task(...)
uv run python main.pyLogin:
request = LoginRequest(email="your@example.com", password="your_password")
response = appflowy_login(request)List workspaces:
workspaces = appflowy_list_workspaces()Get database fields:
fields = appflowy_get_database_fields("workspace_id", "database_id")Create a row:
row_request = RowCreateRequest(cells={"Field_Name": "Value"}, document="Optional markdown")
result = appflowy_create_row("workspace_id", "database_id", row_request)The server maintains tokens in memory. For production use, consider adding persistent storage (Redis, database, etc.) and proper error handling.
if you are slef hosting and you want the mcp to work just added as env in where you get you AI
Create a new row in a database.
| Name | Required | Description | Default |
|---|---|---|---|
| workspace_id | Yes | ||
| database_id | Yes | ||
| request | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description only states 'Create', which implies mutation but fails to disclose whether duplicate rows are allowed, required permissions, or result format. Lacks behavioral details beyond the action verb.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence is concise but overly minimal for a tool with nested parameters. It states purpose but does not earn its place by adding value beyond the name. Could include parameter hints without significant length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 3 parameters (one nested object), no output schema, no annotations, and multiple sibling tools, the description is insufficient. Agent lacks details on parameter relationships, behavior, and when to invoke.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and description does not explain any parameter—workspace_id, database_id, or the nested request object. Agent cannot infer what to provide for 'cells' or 'document'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Create a new row in a database' with specific verb and resource. However, it does not differentiate from the sibling tool 'appflowy_upsert_row', which also creates rows. Missing contextual distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives like 'appflowy_upsert_row' or 'appflowy_list_rows'. Agent receives no context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get fields of a specific database.
| Name | Required | Description | Default |
|---|---|---|---|
| workspace_id | Yes | ||
| database_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose any behavioral traits such as side effects, authentication requirements, or error handling. The agent has no insight into what happens if the database doesn't exist or if permissions are insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, making it concise. However, it is too brief and omits critical context, crossing from concise to under-specified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and minimal description, the agent lacks information about the return format, error scenarios, or whether the tool is read-only. For a simple get operation, the description should at least state that it returns field definitions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description adds no explanation of the workspace_id and database_id parameters beyond their types. The agent must guess their purpose from names alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Get fields of a specific database,' which clearly identifies the verb (get) and resource (database fields). It distinguishes from sibling tools like appflowy_get_page and appflowy_get_row_details by targeting fields rather than whole objects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, limitations, or scenarios where siblings might be preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get details of specific rows by IDs.
| Name | Required | Description | Default |
|---|---|---|---|
| workspace_id | Yes | ||
| database_id | Yes | ||
| row_ids | Yes | ||
| with_doc | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It fails to explain behavior such as error handling, permission requirements, or the effect of the 'with_doc' parameter. The agent cannot anticipate side effects or constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, which sacrifices necessary information. While concise in word count, it is under-specified and does not earn its place by providing adequate guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters, no schema coverage, and no output schema, the description is severely inadequate. It fails to cover essential context like return structure, parameter formats, or use cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description provides no parameter explanations. Even the key parameter 'row_ids' is only implicitly mentioned. 'workspace_id', 'database_id', and 'with_doc' are not described at all.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the verb 'Get details' and resource 'rows' with a specific criterion 'by IDs', which clearly differentiates from sibling tools like appflowy_list_rows or appflowy_get_updated_rows. However, it does not elaborate on what 'details' include.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidelines provided. The description does not indicate when to use this tool versus alternatives, nor does it mention prerequisites or fallback strategies.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all databases in a workspace.
| Name | Required | Description | Default |
|---|---|---|---|
| workspace_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description lacks behavioral details such as pagination, error handling, or the structure of the response. It simply says 'list' without elaboration.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: one sentence with no wasted words. Front-loaded with the action and scope.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations, output schema, and parameter descriptions, the description is insufficiently complete. It omits details about the output format, pagination, and what constitutes a 'database'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'workspace_id' has no description in the schema, and the tool description adds no meaning. Schema description coverage is 0%, so the description fails to compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List all databases in a workspace' with a specific verb and resource. However, it does not differentiate from sibling tools like appflowy_list_spaces or appflowy_list_rows, which might cause confusion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. The description does not explain what a 'database' is in AppFlowy or mention prerequisites like needing a workspace ID.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all row IDs in a database.
| Name | Required | Description | Default |
|---|---|---|---|
| workspace_id | Yes | ||
| database_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description only states 'list all row IDs', implying a read-only operation but lacks details on pagination, limits, ordering, or permissions. Does not disclose any behavioral traits beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with no wasted words. Front-loaded with the core action and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given low complexity (2 params, no output schema), the description is too minimal. Lacks output format, prerequisites, and does not clarify that it only returns IDs versus full row details, which is relevant given sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain the parameters beyond their names. workspace_id and database_id are somewhat descriptive but no guidance on how to obtain them or their role in the list operation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb 'list' and resource 'row IDs in a database', specifying what is returned. It distinguishes from sibling tools like appflowy_get_row_details and appflowy_get_updated_rows, though could be more explicit about returning all rows without filtering.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives. Does not mention when-not-to-use, prerequisites, or refer to sibling tools like appflowy_get_updated_rows or appflowy_get_row_details.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all workspaces for the authenticated user.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full burden. It implies a read-only operation but does not disclose any behavioral traits such as pagination, sorting, or whether it includes archived workspaces. The description is minimal but acceptable for a simple list operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that efficiently conveys the tool's purpose. Every word earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters, no output schema, and the tool's simplicity, the description is largely complete. It specifies the resource (workspaces) and scope (authenticated user). A minor gap is the lack of clarity on what information is returned (e.g., just names vs. full details).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema coverage is 100%. The description adds no parameter-specific meaning because none are needed, achieving the baseline of 4 for zero parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and the resource 'workspaces' with the scope 'for the authenticated user'. It distinguishes from sibling tools like list_spaces by explicitly naming a different entity type. However, it does not explain how workspaces differ from spaces, which could cause ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidelines are provided. The description does not indicate when to use this tool versus alternatives such as list_spaces. An explicit note about preferring this for workspace-level listing would be helpful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Login to AppFlowy Cloud and get access token. Returns access token and refresh token.
| Name | Required | Description | Default |
|---|---|---|---|
| request | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It compensates partially by describing the return values (access and refresh tokens) since no output schema exists, but it omits critical security context (handling passwords), error scenarios (invalid credentials), and token expiration behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two efficient sentences that are front-loaded with the most critical information (action and return values). Every sentence earns its place, though the extreme brevity contributes to gaps in other dimensions like parameter documentation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an authentication tool with zero schema descriptions and no output schema, the description is insufficient. It omits security warnings for password handling, workflow context (relationship to refresh_token), and fails to document the required credentials parameters that the schema leaves undescribed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must explain the parameters, but it fails entirely. It does not mention that 'email' and 'password' are required within the 'request' object, leaving the agent to infer this solely from the naked schema structure without semantic context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Login to AppFlowy Cloud') and the specific outputs ('access token and refresh token'). It implicitly distinguishes itself from the sibling 'appflowy_refresh_token' by specifying that it returns both tokens, suggesting this is the initial acquisition method.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool versus the sibling 'appflowy_refresh_token', nor does it state that this should be invoked before other tools that require authentication. It lacks prerequisites (e.g., valid credentials must exist) and exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Refresh access token using refresh token.
| Name | Required | Description | Default |
|---|---|---|---|
| request | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It merely restates the action without indicating side effects, authentication requirements, or failure modes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded and succinct, but it is too brief to provide value beyond the tool name. It meets the minimum threshold for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool, the description lacks details on return values, prerequisites, and typical workflows, making it incomplete for reliable agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. The description mentions 'refresh token' but does not explain its purpose, how to obtain it, or its relationship to other tokens, leaving the agent uninformed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('refresh') and resource ('access token'), and it is distinct from all sibling tools which focus on pages, rows, spaces, and other data operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives like login. The agent is left to infer context from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update existing row or create if it doesn't exist.
| Name | Required | Description | Default |
|---|---|---|---|
| workspace_id | Yes | ||
| database_id | Yes | ||
| request | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It only states the upsert operation but does not disclose that it modifies data, whether it is idempotent, or what happens on conflict. Minimal transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, front-loading the core action. However, it is too brief and sacrifices necessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of annotations, output schema, and parameter explanations, the description fails to provide a complete understanding of the tool's usage. The nested request object is left unexplained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain any parameters. The agent receives no help understanding workspace_id, database_id, or the request object with pre_hash, cells, and document.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs an upsert operation on a row, combining update and create. However, it does not differentiate from sibling tools like appflowy_create_row, which also creates rows, and it does not mention how it identifies existing rows (likely via pre_hash).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as appflowy_create_row for only creation or appflowy_get_row_details for reading. The description lacks context about prerequisites or scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0appflowy_create_rowappflowy_get_database_fieldsappflowy_get_row_detailsappflowy_list_databasesappflowy_list_rowsappflowy_list_workspacesappflowy_loginappflowy_refresh_tokenappflowy_upsert_rowScored across 9 tools
Each tool has a clearly distinct purpose targeting specific resources and actions - authentication (login/refresh), workspace listing, database operations, and row CRUD. There's no overlap or ambiguity between tools like list_databases vs list_rows or create_row vs upsert_row.
All tools follow a perfect 'appflowy_verb_noun' pattern consistently throughout. The naming convention is uniform with clear action-object relationships, making the tool set predictable and easy to understand.
With 9 tools, this server provides comprehensive coverage for AppFlowy Cloud operations without being overwhelming. The count is well-scoped for database/workspace management with authentication support, making each tool earn its place.
The tool set covers authentication, workspace listing, database discovery, and full row CRUD operations with upsert capability. The only minor gap is the lack of explicit database/workspace creation/deletion tools, but agents can still accomplish core workflows with the available operations.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Manage Appwrite projects, databases, auth, storage, functions, and messaging; search Appwrite docs
The agent-native cloud: database, functions, AI, storage, computers. 50 tools, one API key.
Shared Timill Cloud server: query and edit your work-platform data with full per-user RBAC.
Run AI models, create deployments, and manage predictions via cloud API
