How do I use Qingflow MCP (CRUD)?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Qingflow MCP (CRUD) Query all records in app 'my_app' with field 1003 between 2026-01-01 and 2026-01-31" 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.

Qingflow MCP (CRUD)

by 853046310

Overview Schema Source Related Servers Score Discussions

JavaScript

Remote

Qingflow MCP (CRUD)

This MCP server exposes a canonical, agent-native public surface:

qf_tool_spec_get
qf_form_get
qf_field_resolve
qf_value_probe
qf.query.plan
qf.query.rows
qf.query.record
qf.query.aggregate
qf.query.export
qf.records.mutate

Legacy tools still exist internally for compatibility logic, but they are no longer advertised via listTools().

It intentionally excludes delete for now.

Setup

Runtime requirement:

Node.js >=18

Install dependencies:

npm install

Set environment variables:

export QINGFLOW_BASE_URL="https://api.qingflow.com"
export QINGFLOW_ACCESS_TOKEN="your_access_token"

Optional:

export QINGFLOW_FORM_CACHE_TTL_MS=300000
export QINGFLOW_REQUEST_TIMEOUT_MS=18000
export QINGFLOW_EXECUTION_BUDGET_MS=20000
export QINGFLOW_ADAPTIVE_PAGING=1
export QINGFLOW_ADAPTIVE_MIN_PAGE_SIZE=20
export QINGFLOW_ADAPTIVE_TARGET_PAGE_MS=1200
export QINGFLOW_EXPORT_MAX_ROWS=10000
export QINGFLOW_EXPORT_DIR="/tmp/qingflow-mcp-exports"

Related MCP server: ragic-mcp

Run

Development:

npm run dev

Build and run:

npm run build
npm start

Run tests:

npm test

Command Line Usage

qingflow-mcp still defaults to MCP stdio mode:

qingflow-mcp

Use CLI mode for quick local invocation:

# list all available tools
qingflow-mcp cli tools

# machine-readable tool list
qingflow-mcp cli tools --json

# canonical plan -> execute
qingflow-mcp cli call qf.query.plan --args '{
  "kind":"rows",
  "query":{
    "app_key":"your_app_key",
    "select":[1001,1002],
    "where":[{"field":1003,"op":"between","from":"2026-01-01","to":"2026-01-31"}],
    "limit":20
  }
}'

# then execute with returned plan_id
qingflow-mcp cli call qf.query.rows --args '{"plan_id":"plan_xxx"}'

CLI Install

Global install from GitHub:

npm i -g git+https://github.com/853046310/qingflow-mcp.git

Install from npm (pinned version):

npm i -g qingflow-mcp@0.7.0

Or one-click installer:

curl -fsSL https://raw.githubusercontent.com/853046310/qingflow-mcp/main/install.sh | bash

Safer (review script before execution):

curl -fsSL https://raw.githubusercontent.com/853046310/qingflow-mcp/main/install.sh -o install.sh
less install.sh
bash install.sh

MCP client config example:

{
  "mcpServers": {
    "qingflow": {
      "command": "qingflow-mcp",
      "env": {
        "QINGFLOW_BASE_URL": "https://api.qingflow.com",
        "QINGFLOW_ACCESS_TOKEN": "your_access_token"
      }
    }
  }
}

Recommended Flow

qf_apps_list to pick app.
qf_form_get to inspect field ids/titles.
qf_field_resolve for field-name to que_id mapping.
qf_value_probe when the agent needs candidate field values and explicit match evidence.
qf_record_create or qf_record_update.
If create/update returns only request_id, call qf_operation_get to resolve async result.

Full calling contract (Chinese):

Canonical Usage

Public agent flow is now:

qf_form_get / qf_field_resolve when field mapping is unclear
qf_value_probe when field value candidates are unclear
qf.query.plan
Execute the returned plan_id with:
- qf.query.rows
- qf.query.record
- qf.query.aggregate
- qf.query.export
- qf.records.mutate

Planner Example

{
  "kind": "aggregate",
  "query": {
    "app_key": "your_app_key",
    "where": [
      { "field": 1003, "op": "between", "from": "2026-01-01", "to": "2026-01-31" }
    ],
    "group_by": [1003],
    "metrics": [
      { "op": "count" },
      { "column": 1002, "op": "sum" }
    ],
    "strict_full": true
  }
}

Execute Example

{
  "plan_id": "plan_xxx"
}

Rules:

Public execute tools require plan_id.
Optional query / action echo is only used for drift checking.
If execute input drifts from the planned canonical query, the server returns PLAN_DRIFT.
Public filtering uses canonical where[]; legacy filters are no longer part of the public contract.

Aggregate Business Counts

Aggregate business summaries use one canonical count contract:

{
  "summary": {
    "counts": {
      "source_record_count": 370,
      "group_assignment_count": 405,
      "metric_nonnull_record_count": 395
    },
    "primary_metric_total": 12272931.75,
    "primary_metric_missing_count": 10
  }
}

Default answer for “多少单/多少条” must read summary.counts.source_record_count.

Completeness

Canonical completeness is technical-only:

is_complete
raw_scan_complete
scan_limit_hit
fetched_pages
requested_pages
actual_scanned_pages
scanned_pages
scan_limit
has_more
next_page_token
stop_reason
output_truncated
omitted_items
omitted_chars

When strict_full=true, any incomplete result fails with INCOMPLETE_RESULT.

Error Protocol

Failures return structured JSON with a machine-readable error.code, for example:

{
  "ok": false,
  "error": {
    "code": "PLAN_REQUIRED",
    "message": "...",
    "fix_hint": "...",
    "retryable": true
  }
}

Common codes:

PLAN_REQUIRED
PLAN_NOT_READY
PLAN_DRIFT
FORBIDDEN_RUNTIME_ALIAS
VALIDATION_ERROR
INCOMPLETE_RESULT
UPSTREAM_TIMEOUT
UPSTREAM_API_ERROR

Troubleshooting

If you see runtime errors around Headers or missing web APIs:

Upgrade Node to >=18.
Upgrade package to latest:

npm i -g qingflow-mcp@latest

Verify runtime:

node -e "console.log(process.version, typeof fetch, typeof Headers)"

Publish

npm login
npm publish

If you publish under an npm scope, use:

npm publish --access public

Security Notes

Keep QINGFLOW_ACCESS_TOKEN only in runtime env vars; do not commit .env.
Rotate token immediately if it appears in screenshots, logs, or chat history.

Community

Contributing: CONTRIBUTING.md
Security: SECURITY.md
Conduct: CODE_OF_CONDUCT.md

Available Tools

10 tools

qf_field_resolveQingflow Field ResolveB

Read-onlyIdempotent

Resolve natural language field names/aliases into stable que_id mappings for one app.

ParametersJSON Schema

Name	Required	Description	Default
`app_key`	Yes
`query`	No
`queries`	No
`top_k`	No
`fuzzy`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`ok`	Yes
`data`	Yes
`meta`	Yes

TDQS

B3.2/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint and idempotentHint, which cover safety and repeatability. The description adds that it resolves to 'stable que_id mappings', hinting at deterministic behavior, but does not elaborate on error cases, rate limits, or other nuances. Given the annotations, the description is adequate but not exceptional.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single front-loaded sentence that efficiently conveys the core purpose. It is concise without being vague, but could include more detail without losing conciseness. Every word earns its place, but the brevity leaves gaps in other dimensions.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite having output schema, the description lacks essential context for agent decision-making. It does not explain how to use multiple queries, the effect of top_k or fuzzy, or how results are structured. With 5 parameters and no param descriptions, the description is incomplete for proper tool invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 5 parameters with 0% schema description coverage, and the tool description provides no additional meaning for any parameter. It does not explain the purpose of 'query', 'queries', 'top_k', or 'fuzzy', nor how they interact. An agent would have no guidance on parameter usage beyond the schema itself, which is insufficient.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Resolve' and the resource 'natural language field names/aliases' into 'stable que_id mappings for one app'. It precisely defines the tool's function and differentiates from sibling tools like qf.query.* and qf.records.mutate, which handle queries or mutations rather than field name resolution.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies the tool should be used when there is an app key and field names to resolve, but it does not explicitly state when to use it versus alternatives like qf_form_get or qf.query.plan. No exclusions or comparisons are provided, so the guidance is only implied.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

qf_form_getQingflow Form GetC

Read-onlyIdempotent

Get form metadata and compact field summaries for one app.

ParametersJSON Schema

Name	Required	Description	Default
`app_key`	Yes
`user_id`	No
`force_refresh`	No
`include_raw`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`ok`	Yes
`data`	Yes
`meta`	Yes

TDQS

C2.7/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint and idempotentHint as true, which cover safety. The description adds no behavioral details beyond the annotations, such as the effect of force_refresh or include_raw parameters.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is very concise at one sentence, but it may be too brief for the tool's complexity. It is front-loaded with the main action, but lacks elaboration.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has four parameters, sibling tools, and an output schema, the description is insufficient. It does not cover parameter semantics, return values, or how it fits into a workflow, making it incomplete for effective use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

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 of the four parameters (app_key, user_id, force_refresh, include_raw). This fails to add meaning beyond the schema, leaving the agent uninformed.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Get' and the resource 'form metadata and compact field summaries for one app', providing a specific purpose. However, 'compact field summaries' is somewhat vague, and it does not explicitly differentiate from sibling tools like qf_field_resolve.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives no guidance on when to use this tool versus alternatives (e.g., qf.query.record). It lacks any context about prerequisites or typical use cases, leaving the agent to infer usage.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

qf.query.aggregateQingflow Canonical Query AggregateB

Read-onlyIdempotent

Aggregate records through the canonical DSL and return metrics_by_column plus query handle resources.

ParametersJSON Schema

Name	Required	Description	Default
`plan_id`	Yes
`query`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`ok`	Yes
`data`	Yes
`meta`	No

TDQS

B3.1/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and idempotentHint=true, covering safety. The description adds value by stating the return type (metrics_by_column and query handle resources), but it does not explain pagination, error behavior, or other traits beyond what annotations imply.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, self-contained sentence. It is concise and front-loaded, containing no redundant information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite having an output schema (not shown), the tool has a complex nested input schema and no parameter descriptions. The description lacks essential context about the DSL structure, parameter constraints, and usage scenarios, making it incomplete for an agent to reliably construct a valid query.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description must compensate, but it provides no parameter details at all. It mentions 'canonical DSL' but does not explain the required fields (e.g., group_by, metrics) or optional parameters, leaving the agent with no semantic guidance.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it aggregates records using the 'canonical DSL' and specifies the return type ('metrics_by_column plus query handle resources'). This distinguishes it from sibling tools like qf.query.rows (for rows) and qf.query.record (for single records), though it does not explicitly contrast them.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for aggregation tasks, but it provides no explicit guidance on when to use this tool versus alternatives, nor does it mention prerequisites or exclusions. The context from sibling names offers some implicit differentiation.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

qf.query.exportQingflow Canonical Query ExportA

Read-onlyIdempotent

Export canonical row queries and return resource links instead of large inline payloads.

ParametersJSON Schema

Name	Required	Description	Default
`plan_id`	Yes
`query`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`ok`	Yes
`data`	Yes
`meta`	No

TDQS

A3.5/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint and idempotentHint as true. The description adds that it returns resource links, which is useful but does not delve into other behavioral traits like pagination or error handling.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single clear sentence, front-loaded with the main purpose, and contains no extraneous information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite having output schema and annotations, the description is too brief for a tool with many nested parameters, offering no guidance on when to use various query options or what the returned resource links contain.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

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, leaving complex nested objects like query entirely undocumented.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool exports canonical row queries and returns resource links, distinguishing it from siblings like qf.query.rows that return inline payloads.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage via 'instead of large inline payloads' but does not explicitly state when to use or provide alternatives among similar siblings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

qf.query.planQingflow Canonical Query PlanB

Read-onlyIdempotent

Preflight canonical query DSL, normalize loose inputs, translate into internal tools and estimate whether the query is ready for a final conclusion.

ParametersJSON Schema

Name	Required	Description	Default
`kind`	Yes
`query`	No
`action`	No
`probe`	No
`resolve_fields`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`ok`	Yes
`data`	Yes
`meta`	No

TDQS

B3.3/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations (readOnlyHint: true, idempotentHint: true) already declare safety and idempotency. The description adds behavioral context: it normalizes, translates into internal tools, and estimates readiness. This goes beyond annotations by explaining what the tool does to the query, which helps the agent understand the transformation process.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence, front-loaded with the core action ('Preflight canonical query DSL'), and no redundant words. Every phrase earns its place (normalize, translate, estimate).

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite having an output schema, the description is insufficient for the tool's complexity. It provides a high-level overview but lacks details on how to structure the query/action objects or interpret results. Parameters are undocumented, and the agent lacks guidance for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate, but it does not. None of the five parameters (kind, query, action, probe, resolve_fields) are explained. The description mentions 'normalize loose inputs' but does not link to any parameter. An agent cannot infer parameter semantics from the description alone.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Preflight canonical query DSL, normalize loose inputs, translate into internal tools and estimate whether the query is ready for a final conclusion.' It uses specific verbs and resources (canonical query DSL, internal tools) and distinguishes itself from sibling tools like qf.query.rows or qf.query.aggregate by emphasizing the preflight/normalization role.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance on when to use this tool versus alternatives (e.g., direct querying tools). The description implies it's a preflight step, but does not specify conditions or exclusions. An agent would have to infer usage context without clear direction.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

qf.query.recordQingflow Canonical Query RecordC

Read-onlyIdempotent

Fetch one record through the canonical DSL and return a query handle.

ParametersJSON Schema

Name	Required	Description	Default
`plan_id`	Yes
`query`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`ok`	Yes
`data`	Yes
`meta`	No

TDQS

C2.7/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint and idempotentHint. Description adds that it returns a query handle rather than the record directly, which is useful. However, no other behavioral traits (e.g., effect on system, pagination) are disclosed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

One sentence, front-loaded with action and resource. It is concise but could be more informative without losing brevity. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite output schema and annotations, the description lacks details about the canonical DSL, query handle semantics, and parameter usage. For a tool with nested parameters, more guidance is needed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

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 parameter (plan_id, query object). Agents cannot understand what plan_id expects or how to structure the query. This is a critical gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it fetches one record via 'canonical DSL' and returns a query handle. While it distinguishes from sibling tools like qf.query.rows (bulk fetch) and qf.query.aggregate (aggregation), it does not explicitly contrast them.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use or avoid this tool. No mention of alternatives or prerequisites. The description only states what it does, not when to choose it over siblings like qf.query.rows for multiple records.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

qf.query.rowsQingflow Canonical Query RowsC

Read-onlyIdempotent

Query rows through the canonical DSL and return query handles plus resource links.

ParametersJSON Schema

Name	Required	Description	Default
`plan_id`	Yes
`query`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`ok`	Yes
`data`	Yes
`meta`	No

TDQS

C2.6/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description adds minimal behavioral context beyond annotations (readOnlyHint, idempotentHint). It states the return type (query handles and resource links), but does not disclose pagination, error handling, or other behaviors. Given annotations cover safety, a score of 3 is appropriate.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence, which is concise but too brief for a complex tool. Important details about parameters and usage are omitted, making it insufficiently informative.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (2 parameters, nested schema, output schema, multiple siblings), the description is severely incomplete. It fails to explain the canonical DSL, parameter roles, pagination, or any usage context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description provides no explanation of the parameters (plan_id, query object) despite 0% schema description coverage. The complex nested query object with many subfields is left entirely undocumented, which is a significant gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool queries rows using the canonical DSL and returns query handles plus resource links. It distinguishes from sibling tools by specifying the DSL and return type, but does not explicitly differentiate from other query tools like qf.query.aggregate.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives (e.g., qf.query.aggregate, qf.query.record). The description lacks any context about prerequisites or selection criteria.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

qf.records.mutateQingflow Canonical Records MutateC

Canonical write entry for create/update operations.

ParametersJSON Schema

Name	Required	Description	Default
`plan_id`	Yes
`action`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`ok`	Yes
`data`	Yes
`meta`	No

TDQS

C2.6/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate write behavior (readOnlyHint=false, idempotentHint=false). The description adds no additional behavioral context such as authentication, authorization, or side effects beyond confirming it is a write entry.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence, which is concise but overly brief. It front-loads the purpose but omits critical details, making it minimally acceptable but not well-structured for an AI agent.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (2 parameters, nested objects, no parameter descriptions, and an output schema not detailed in the description), the description is extremely incomplete. It fails to explain how to construct the action object or use fields and answers, leaving the agent without essential context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description provides no explanation of the two parameters (plan_id and action object) or their semantics. The complex nested structures in the schema are left entirely undocumented, forcing the agent to rely solely on raw JSON.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it is a 'canonical write entry for create/update operations', specifying the verb (write) and resource (records). However, it does not differentiate from sibling tools like qf.query.record or qf_field_resolve, which are read-oriented.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for create/update operations but provides no explicit guidance on when not to use or alternatives. It does not exclude read operations or other mutations like delete, leaving the agent to infer boundaries from the sibling list.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

qf_tool_spec_getQingflow Tool Spec GetA

Read-onlyIdempotent

Return MCP tool parameter requirements, limits, aliases and minimal examples for agent prompt grounding.

ParametersJSON Schema

Name	Required	Description	Default
`tool_name`	No
`include_all`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`ok`	Yes
`data`	Yes
`meta`	Yes

TDQS

A3.7/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already provide readOnlyHint and idempotentHint. The description adds specific return content (requirements, limits, aliases, examples) which complements annotations and clarifies what the tool does beyond a simple read.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence that is front-loaded and to the point. However, it omits parameter details which could be included without much bloat.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the output schema exists and annotations are present, the description is partially complete. However, with zero schema description coverage and no explanation of parameters, it does not fully compensate for the missing detail.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

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 two parameters (tool_name, include_all). While parameter names are somewhat intuitive, the description fails to add meaning or constraints beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description explicitly states the tool returns 'MCP tool parameter requirements, limits, aliases and minimal examples', which is a specific verb+resource. It clearly distinguishes from sibling tools that handle forms, queries, or records.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Description implies usage context (agent prompt grounding) but does not specify when to use this tool versus alternatives, nor does it provide exclusions or prerequisites.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

qf_value_probeQingflow Value ProbeA

Read-onlyIdempotent

Probe likely field values for one app field, with explicit match mode and matched value evidence.

ParametersJSON Schema

Name	Required	Description	Default
`app_key`	Yes
`field`	Yes
`query`	No
`match_mode`	No
`limit`	No
`scan_max_pages`	No
`page_size`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`ok`	Yes
`data`	Yes
`meta`	Yes

TDQS

A3.5/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint and idempotentHint true. The description adds behavioral details about match modes and evidence in results, going beyond annotations without contradicting them.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence with no wasted words. Every element (probe, likely field values, match mode, evidence) adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite having an output schema and annotations, the description is too brief to fully guide an agent. It omits details on how probing works, what evidence looks like, or how parameters interact, leaving gaps for a 7-param tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% with 7 parameters. The description only mentions 'match mode' generally but does not explain other parameters like app_key, field, query, limit, etc., failing to compensate adequately.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses the specific verb 'probe' to indicate exploratory search, names the resource 'likely field values for one app field', and mentions explicit match modes and matched evidence, which distinguishes it from siblings like qf_field_resolve that may not offer match modes.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description does not explicitly state when to use this tool over alternatives like qf_field_resolve or when not to use it. It only implies usage for probing field values, but lacks guidance on context or exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

10 tool updatesv0.7.0May 28, 2026
- First observedqf_field_resolve
- First observedqf_form_get
- First observedqf_tool_spec_get
- First observedqf_value_probe
- First observedqf.query.aggregate
- First observedqf.query.export
- First observedqf.query.plan
- First observedqf.query.record
- First observedqf.query.rows
- First observedqf.records.mutate

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

B3.1/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose. Query tools (aggregate, export, plan, record, rows) are separated from non-query tools (field resolve, form get, mutate, spec get, value probe), and even within queries, each serves a unique function.

Naming Consistency2/5

Naming convention is inconsistent: some tools use underscores (qf_field_resolve, qf_form_get, qf_tool_spec_get, qf_value_probe) while others use dot notation (qf.query.aggregate, qf.query.export, etc.). This mixed pattern can confuse an agent.

Tool Count5/5

10 tools is appropriate for a CRUD server with advanced query capabilities. Each tool serves a well-defined purpose without excessive overlap.

Completeness2/5

Significant gaps exist: no explicit delete operation (qf.records.mutate only mentions create/update), no listing tools for forms or apps, and no field management beyond resolving. This will cause agent failures when delete or listing is needed.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

mcpOAuth
com.formester
Give AI agents access to form submissions — read, search, update, and process file attachments.
App Automation Databases Customer Data Platforms
2
mcp-serverOAuth
com.make
Give your AI agents the tools to build, manage, and run automation workflows.
App Automation Developer Tools Workplace & Productivity
2
FormBuilderOAuth
com.formbuilder
Create and publish online forms, read responses and add webhooks on formbuilder.com from AI agents.
App Automation Workplace & Productivity
1
OleanderOAuth
dev.oleander
The all-in-one data stack for agents. Upload files, run SQL, evolve tables, and render charts.
Databases Data Platforms Data Visualization
2

Related MCP Servers

FileMaker Data API MCP Server
Databases Developer Tools
fsans
A
license
B
quality
D
maintenance
Provides AI agents with direct access to FileMaker databases through the FileMaker Data API, enabling natural language interactions for querying, managing records, and database introspection.
Updated 9 months ago (2025-11-27 11:15 UTC)
28
10
3
MIT
ragic-mcp
Databases Developer Tools
EthanH9977
A
license
A
quality
C
maintenance
Enables AI agents to interact with Ragic databases via MCP protocol, supporting form exploration, data CRUD, approval, and locking operations.
Updated 22 days ago (2026-08-17 07:37 UTC)
11
MIT
FormIO MCP Server
Content Management Systems Data Platforms
MCP-Forge
F
license
Not graded
quality
D
maintenance
Enables AI agents to interact with the FormIO API for dynamic form creation, submission management, and user roles using natural language.
Updated a year ago (2025-07-16 12:18 UTC)
-
mcp-dynamics-365
CRM Databases
dave-palt
A
license
Not graded
quality
D
maintenance
Enables AI agents to perform CRUD operations, query data, fetch schemas, and execute custom operations on Microsoft Dynamics 365 CRM entities.
Updated 7 months ago (2026-02-19 10:34 UTC)
20
2
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/853046310/qingflow-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server