Enables architecting, validating, scaffolding, and generating code for WMilvus vector database applications, including schema validation, design pattern search, CRUD generation, and vector search code references.
Click on "Deploy 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., "@wmilvus-mcp generate CRUD code for my Milvus product embeddings"
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.
wmilvus-mcp is the Model Context Protocol (MCP) server for architecting, validating, scaffolding, and generating code for WMilvus vector database applications.
Component | Technology |
Language | Python 3.10+ |
Protocol Core | Model Context Protocol (MCP) |
Server Framework | FastMCP (mcp.server.fastmcp) |
Validation Engine | AST & Pydantic 2.x |
Testing Framework | pytest, pytest-cov |
Code Formatting | ruff |
Related MCP server: mcp-server-milvus
validate_model_schema — Validate Pydantic models for WMilvus compatibility.
search_wmilvus_pattern — Search production-ready WMilvus design patterns.
deploy_wmilvus_scaffolding — Deploy a complete WMilvus vector application structure.
get_wmilvus_architect_blueprints — Runnable code reference for CRUD, vector search, range search, batch ingestion, async client, and ghost audit log.
get_wmilvus_architect_manual — Comprehensive architectural manual for Milvus memory and vector indexing.
generate_wmilvus_crud — Generate ready-to-run CRUD code for WMilvus models.
generate_mcp_client_config — Generate JSON configuration snippet for Anthropic Claude, Antigravity, or Cursor.
Run the server via stdio:
pip install -e .
wmilvus-mcp --startExecute tests inside an isolated Docker container:
./run_tests_docker.shCalculate code coverage:
./run_coverage.shDeploys a professional WMilvus vector application project structure.
| Name | Required | Description | Default |
|---|---|---|---|
| target_dir | Yes | ||
| project_name | No | wmilvus_project | |
| scaffold_type | No | standard |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It never says whether existing files in target_dir are overwritten, whether directories are created, what permissions are needed, or whether the operation is reversible — all critical for a tool that writes a project structure to disk. The single sentence discloses no behavior beyond the obvious.
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?
One short, front-loaded sentence with no padding or redundancy. It is efficient, though its brevity is under-specification rather than deliberate concision.
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?
An output schema exists, so return values need not be described, but for a filesystem-mutating scaffold tool with no annotations, 0% parameter coverage, and an unexplained scaffold_type default, the description leaves the agent missing too much to invoke it confidently.
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 mentions none of the three parameters. In particular scaffold_type defaults to 'standard' with no enum or explanation of valid values, and the required target_dir's expected form is undefined; the description does nothing to compensate for the schema gap.
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?
States a specific verb ('Deploys') and resource ('WMilvus vector application project structure'), so an agent can tell it creates a project skeleton. It does not distinguish itself from siblings like generate_wmilvus_crud or get_wmilvus_architect_blueprints, and 'professional' is filler, but the core purpose is unambiguous.
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 statement of when to use this tool, when not to, or which sibling to prefer (e.g. generate_wmilvus_crud vs this scaffolding tool). Usage must be inferred entirely from the name and the word 'Deploys'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate MCP Client JSON configuration snippet for Anthropic Claude, Antigravity, or Cursor.
| Name | Required | Description | Default |
|---|---|---|---|
| command | No | python3 | |
| server_name | No | wmilvus-mcp |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden, yet it discloses nothing beyond the output type. It does not say whether a file is written or only text is returned, whether the generated snippet is a template versus a validated config, or what happens with unsupported clients.
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?
A single tight sentence with the action and object front-loaded and the client targets appended. No filler, though it is arguably too short to be fully useful.
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?
An output schema exists, so return-value explanation is not required, and the tool is simple (2 optional params). However, with 0% schema coverage and no annotations, the two parameters are completely unexplained anywhere in the definition, leaving a real gap.
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% — both parameters only expose a title and a default. The description never mentions 'command' or 'server_name', so it adds no meaning about how the command is embedded or what the server name is used for.
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?
Clear verb ('Generate') plus specific resource ('MCP Client JSON configuration snippet') and even names the supported client targets (Claude, Antigravity, Cursor). It is distinguishable from the wmilvus-oriented siblings, though it never explicitly contrasts itself with them.
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 when-to-use guidance, no prerequisites, and no mention of alternatives. The agent must infer the use case entirely from the tool name and the enumerated client targets.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate ready-to-run WMilvus CRUD code snippet.
| Name | Required | Description | Default |
|---|---|---|---|
| fields | No | id:str,name:str | |
| model_name | No | VectorEntity | |
| vector_dim | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are supplied, so the description carries the full behavioral burden. "Ready-to-run" hints the output is executable, but it never says whether the snippet is merely returned as text or written to disk, what imports/framework it targets, or any side effects — all things an agent needs before invoking a code generator.
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?
A single front-loaded sentence with zero padding — the intent is delivered immediately. It is appropriately sized in form, though its brevity is partly under-specification rather than true economy.
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?
An output schema exists, so return-value structure need not be restated. But for a three-parameter generation tool with no annotations and no parameter documentation, the definition omits selection criteria, input format, and behavioral expectations — too much is missing for an agent to call it confidently.
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?
All three parameters sit at 0% schema description coverage, and the description mentions none of them. Critically, the colon-delimited syntax of "fields" (only inferable from the default value "id:str,name:str") and the role/units of model_name and vector_dim are explained nowhere, so the agent must guess the expected format.
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?
States a specific verb ("Generate") and resource ("WMilvus CRUD code snippet"), so the agent knows this produces code rather than validating, searching, or deploying. It does not, however, distinguish itself from sibling generators like generate_mcp_client_config or deploy_wmilvus_scaffolding, which is the only thing keeping it from a 5.
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 gives no when-to-use guidance, no prerequisites, and never names an alternative. With siblings such as deploy_wmilvus_scaffolding and generate_mcp_client_config occupying adjacent space, the absence of routing guidance is a real gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Complete reference with runnable code examples for every WMilvus feature.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden but only describes content type. It does not state that the operation is read-only, whether authentication is required, or how the response is structured, beyond the fact that it contains runnable code examples.
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 with no wasted words. It communicates the core content directly.
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?
An output schema exists, so return values need not be explained. However, the description does not help the agent distinguish this tool from get_wmilvus_architect_manual, and with no annotations or parameters, that missing context leaves a gap for correct tool selection.
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 takes zero parameters, so there are no parameter semantics to document. The baseline for a zero-parameter tool is 4; the description neither adds nor detracts from that.
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 artifact returned: a complete reference with runnable code examples for every WMilvus feature. It does not explicitly contrast itself with the sibling get_wmilvus_architect_manual, so sibling differentiation is absent.
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 about when to use this tool instead of alternatives such as get_wmilvus_architect_manual or search_wmilvus_pattern. The description only characterizes the content, leaving selection criteria implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Architectural manual explaining vector indexing, Milvus memory management, and forensic audit logs.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It never states that this is a static, zero-argument read that returns documentation, nor gives any sense of the payload size or token cost of pulling a whole manual into context — a meaningful omission for a retrieval tool whose main cost is context bloat.
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?
A single efficient sentence with the three covered topics front-loaded after the resource name. No filler. It is terse to the point of under-specification, but nothing is wasted.
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?
The output schema exists, so return values need not be explained, and the topic list tells the agent what subject matter to expect. What is missing is the routing signal distinguishing this manual from get_wmilvus_architect_blueprints and any indication of scope, which is the main thing an agent needs before spending context on it.
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 takes zero parameters, so the baseline of 4 applies. There is nothing further the description could add about arguments.
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 names the resource (an architectural manual) and enumerates the topics it covers (vector indexing, Milvus memory management, forensic audit logs), so the content is identifiable. However, it omits an explicit verb such as 'retrieves' or 'returns' and gives no differentiation from the sibling get_wmilvus_architect_blueprints, leaving the agent to guess which of the two reference-fetchers to call.
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 statement of when to consult this manual, no prerequisites, and no mention of the sibling tools that overlap with it (get_wmilvus_architect_blueprints, search_wmilvus_pattern). The agent must infer usage purely from topic keywords.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for production-ready WMilvus architectural patterns in the catalog.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. 'Search' implies a non-destructive read, but nothing is said about matching behavior, result limits, ranking, or pagination; the only behavioral hint is the implicit read semantics of the 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?
A single front-loaded sentence with no filler or redundancy. It is efficient, though its brevity edges into under-specification rather than tightness.
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?
An output schema exists, so return values need not be explained, and the tool is a simple one-parameter search. Still, the undocumented query semantics and absent routing versus sibling retrieval tools leave meaningful gaps for correct invocation.
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 single required 'query' parameter has no description anywhere. The description does not clarify whether the query is a natural-language phrase, keyword list, pattern name, or filter expression, so the schema gap is not compensated.
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?
States a specific verb (Search) and a specific resource (WMilvus architectural patterns) with scoping qualifier (production-ready, in the catalog). However, it does not distinguish itself from near-siblings such as get_wmilvus_architect_blueprints, leaving the search-vs-retrieve boundary ambiguous.
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 when-to-use guidance, no mention of when to prefer this over get_wmilvus_architect_blueprints or get_wmilvus_architect_manual, and no exclusions. An agent must guess which sibling to call for pattern discovery versus retrieval.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Validate a Pydantic model definition for WMilvus vector storage compatibility.
| Name | Required | Description | Default |
|---|---|---|---|
| model_code | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden, and it discloses nothing: no statement that validation is non-mutating, no indication of whether failures raise, return a list of errors, or block a subsequent deploy. Only the word 'validate' weakly implies a read-only check. This is a significant gap for a tool with zero annotation coverage.
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?
A single front-loaded sentence that states verb, object, and compatibility target with no filler. It is well sized, though its brevity is achieved partly by omitting information the tool actually needs.
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?
An output schema exists, so return values need not be explained, and the tool is simple with one parameter. However, with no annotations and no stated workflow position, the description leaves an agent guessing about input format, expected outcomes, and when validation is warranted.
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?
There is one parameter (model_code) with 0% schema description coverage, so the schema contributes nothing about its format. The description's phrase 'Pydantic model definition' hints at what model_code should contain, but it does not clarify whether it is raw source text, a fully-qualified class path, or something else.
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?
States a specific verb (validate) and resource (Pydantic model definition) with a domain qualifier (WMilvus vector storage compatibility). It is clearly distinguishable from the sibling generation, search, and deploy tools. It stops short of naming any sibling explicitly, so a 4 rather than a 5.
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 guidance on when to call this tool, whether it should precede deploy_wmilvus_scaffolding or generate_wmilvus_crud, or what preconditions the model code must meet. The agent must infer usage entirely from the name and one-line purpose.
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.0deploy_wmilvus_scaffoldinggenerate_mcp_client_configgenerate_wmilvus_crudget_wmilvus_architect_blueprintsget_wmilvus_architect_manualsearch_wmilvus_patternvalidate_model_schemaScored across 7 tools
Most tools have clearly distinct purposes, but the reference-oriented tools (get_wmilvus_architect_blueprints, get_wmilvus_architect_manual, search_wmilvus_pattern) have some conceptual overlap. Descriptions help distinguish code examples, conceptual manual, and searchable patterns, so an agent can mostly select correctly.
All tool names use consistent snake_case and follow a verb_noun pattern (validate_, search_, deploy_, get_, generate_). The inclusion of 'wmilvus' varies slightly but does not break predictability.
Seven tools is well-scoped for a specialized WMilvus development-assistant server. Each tool appears to earn its place without excessive redundancy or missing obvious operations.
The surface covers validation, search, scaffolding, reference documentation, code generation, and MCP client configuration for WMilvus development. Minor gaps may exist, such as runtime vector operations, but the stated development-assistant purpose is largely covered.
327 dev tools via REST API and MCP. Generate Dockerfiles, schemas, K8s, APIs, and more.
Generate a typed SDK, CLI, and MCP server from any OpenAPI or GraphQL spec, and keep them current.
Build multi-tenant apps over MCP. Schemas, CRUD, deploys — access control enforced server-side.
Hosted MCP server for AI-driven data ops. Create apps, manage schemas, and CRUD structured data.
