mike-plus

by Zhonghao1995

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation5/5
Each tool has a clearly distinct purpose: reading/setting parameters, model info, three plot types, results listing/reading/summary, and simulation execution. No overlapping functionality.
Naming Consistency5/5
All tools follow a consistent 'mike_verb_noun' pattern (e.g., get_values, plot_network, results_list). The verbs are descriptive and uniformly formatted.
Tool Count5/5
10 tools is well within the ideal 3-15 range. The number covers the essential operations for MIKE+ modeling without being excessive.
Completeness4/5
The toolset covers the core workflow: model info, parameter read/write, simulation run, and results analysis/plotting. Minor gaps include lack of tools for structural model editing or scenario management, but for the intended purpose it is solid.
Average 4/5 across 10 of 10 tools scored. Lowest: 3.3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 16 commits in the last 12 weeks
- Last stable release on June 25, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description should disclose read-only nature and potential side effects. It mentions downsampling and license requirement but omits error behavior or whether it modifies data. The information is minimal.
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, efficient sentence that front-loads the action and provides key details without unnecessary words.
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?
The tool returns data but the description lacks details on the output format beyond 'times+values'. There is no output schema, so more specifics on the structure would be beneficial. The context is partially complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 75%, so description adds some value. It clarifies that max_points caps returned points (default 5000) and mentions 'no license needed' but does not explain the res1d parameter. Baseline 3 is appropriate.
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 extracts one time series from a MIKE+ .res1d file, specifying the output format and downsampling. It distinguishes from sibling tools like mike_get_values and mike_results_list by focusing on a single time series extraction.
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 this tool versus alternatives such as mike_get_values or mike_results_summary. The note 'no license needed' is a positive but does not clarify usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses one behavioral trait ('no license needed') but omits details on side effects (e.g., file overwriting), output format, or return behavior.
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?
Extremely concise: two sentences front-load the action and key condition. Every word adds value with no redundancy.
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 no output schema and moderate complexity, the description provides the essential purpose but lacks details on output expectations (e.g., that it saves a PNG) and examples. It is minimally complete for a tool of this simplicity.
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 coverage is 0%, so description must compensate. It mentions 'quantity at an element' and 'single-panel time-series plot', hinting at parameter roles, but does not explicitly describe each parameter (res1d, quantity, element, out_png) beyond these cues.
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 it renders a single-panel time-series plot, specifying 'house style' and 'no license needed'. It distinguishes from sibling tools like mike_plot_network and mike_plot_rain_flow by focusing on time-series.
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 mentions 'no license needed' as a precondition, but lacks explicit guidance on when to use this tool versus alternatives. The name and context imply timeseries plotting, but no direct comparisons or exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It lacks details on side effects (e.g., file overwriting), error handling for invalid inputs, or limitations. Only mentions 'no license needed' as a behavioral note.
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 extremely concise with three sentences, each adding value: main action, use case, and license note. No redundant or unnecessary information.
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 no annotations or output schema, the description covers the core purpose but omits important context such as error behavior, output format details, and parameter constraints. It is adequate for simple usage but not fully comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must compensate. It mentions '.res1d' as input and implies 'out_png' as output, but does not explicitly define each parameter or provide format/syntax details beyond the schema's basic names.
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 renders a network layout map of a MIKE+ model from a .res1d file, specifying visual elements (lines for pipes, points for nodes) and style (equal-aspect, house style). It effectively distinguishes from sibling tools like mike_plot_timeseries which handle time series.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates the tool is 'good for an overview figure' and mentions 'no license needed', providing context for appropriate use. However, it does not explicitly exclude cases where other tools should be used or mention prerequisites like file existence.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that the tool lists contents (non-destructive), specifies scope (quantities, element counts, time range), and notes 'No license needed'. No behavioral traits like side effects or rate limits are mentioned, but for a read-only list tool, this is sufficient. No contradiction with missing annotations.
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 key information, no extraneous words. Every part contributes to understanding the tool's purpose and output.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given low complexity (one parameter, no output schema), the description adequately covers what the tool lists and returns (quantities, element counts, time range). Missing details like output format (list vs. dictionary) but likely implied; still sufficient for basic understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (single parameter with description). The tool description adds no additional meaning beyond the schema's parameter description ('Path to a .res1d file.'). It does not provide format, constraints, or alternatives, so baseline score of 3 is appropriate.
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 action ('list') and the resource (MIKE+ .res1d file contents), specifying the types of information returned: quantities, element counts with sample ids, and time range. This distinguishes it from sibling tools like mike_get_values or mike_results_summary.
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 over siblings. The description mentions 'No license needed' as a prerequisite, but does not explain when to choose mike_results_list versus mike_get_values, mike_results_summary, or other list-oriented tools. Implied usage but no clear alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Given no annotations, the description declares read-only behavior and license requirement, but lacks details on error handling, performance, or edge cases. Adequate but not comprehensive.
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?
Three sentences, front-loaded with purpose, no wasted words. Efficiently communicates core information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 4-parameter read tool with no output schema, description covers purpose, parameters, read-only nature, and license. Lacks error handling and return format, but sufficient for typical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 75%; description adds context for table examples and optional muids, but does not significantly enhance parameter meaning beyond what schema provides. Adequate.
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 clearly states the tool reads parameter values from MIKE+ tables, specifying the resource (e.g., msm_Link) and action (read). It distinguishes from siblings like mike_set_values by implying a read-write pair.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states read-only and license requirement. Provides usage advice ('Use this to identify current parameter values') but does not explicitly contrast with write alternatives or state when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It discloses that no license is needed and that rainfall is optional. However, it does not detail behavior such as whether the file is overwritten, time alignment handling, or error conditions for missing rain_dfs0. For a plotting tool, these are not critical but a bit more detail would improve transparency.
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 two sentences long, front-loading the main purpose and adding necessary usage details. Every word serves a purpose; no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (5 params, 3 required, no nested objects, no output schema), the description covers the core aspects: data sources, optionality, and licensing. The mention of 'house style' is vague but acceptable for an internal tool. It does not include error handling or data format expectations, but for a plot tool these are secondary.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 80% (4 of 5 parameters have descriptions), so baseline is 3. The description adds context linking res1d to the source file and element to the flow series, but does not provide additional details beyond the schema. For example, the schema already says element is 'Reach/link or node id'. The description does not compensate for the missing description of the res1d parameter in 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 clearly states the tool renders a 'stacked two-panel rainfall-runoff figure' with specific details (rain inverted on top, flow on bottom, house style). Verb 'Render' and resource 'rainfall-runoff figure' are specific, and the description distinguishes it from sibling tools like mike_plot_timeseries which plots generic timeseries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains that flow comes from a .res1d element and rainfall is optional from a .dfs0, giving clear context for when to use this tool. While it does not explicitly state when not to use alternatives, the contrast with sibling tools like mike_plot_timeseries is implicit. The 'No license needed' note is helpful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description bears full burden. It explicitly states 'Read-only' as a key behavioral trait and mentions license requirement. However, it does not describe error behavior (e.g., missing file, invalid model) or output format details.
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?
Description is concise (one sentence with list) and front-loaded with action and output. Could be slightly better structured with bullet points, but overall efficient and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one input and no output schema, description adequately lists returned information categories. It is missing explicit output structure or format, but given tool complexity, it is mostly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with parameter description 'Path to the MIKE+ .sqlite model database.' The description adds no significant additional meaning beyond specifying it's a .sqlite file. Baseline of 3 is appropriate.
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 opens a MIKE+ .sqlite model and reports specific metadata (active simulation, unit system, simulation setups, scenarios, element counts). It distinguishes itself from sibling tools like mike_run or mike_get_values by focusing on model info.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Describes read-only nature and license requirement, but does not explicitly mention when to use this tool vs siblings (e.g., mike_get_values for fetching values). The context is clear but lacks explicit exclusion or alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It transparently discloses that the tool identifies the global maximum over the entire run, which may fall in the warm-up period. This critical behavioral nuance is well explained, though return format details are implied rather than explicit.
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 extremely concise, containing only two sentences and a note. All information is front-loaded and relevant, with no superfluous words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given three parameters, no output schema, and no annotations, the description provides adequate completeness by explaining the output's nature and the warm-up caveat. However, it could be more detailed about the output format or error cases, keeping it from a perfect score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning beyond the input schema by explaining the purpose of skip_hours (excluding warm-up) and quantities (per-quantity summary). Schema coverage is 67%, and the description fills some gaps, especially for the res1d parameter by specifying the file type (.res1d).
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 it provides a per-quantity peak summary with specific fields (peak value, element, chainage, time) from a MIKE+ .res1d file. This distinguishes it from sibling tools like mike_results_list or mike_results_read that serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides practical guidance on warm-up periods and instructs using skip_hours to exclude initial windows, advising to always check peak_time. While it does not explicitly compare to alternatives, the note offers clear usage conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but the description fully discloses behavioral traits: runs headless, returns result file paths and engine log tail, requires MIKE+ and license, and warns of no undo. No contradictions.
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?
Three concise sentences, front-loaded with the main action, no redundant information. Efficiently covers purpose, usage, and warnings.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simulation tool with 3 parameters and no output schema, the description fully covers inputs, safety (run on copy), return info (file paths + log tail), and prerequisites (license).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds meaning: sqlite path should be a copy, simulation is optional with default, timeout default 1800. Adds value beyond 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?
The description clearly states 'Run a MIKE+ simulation headless via the MIKE 1D engine', specifying the verb, resource, and mode. It distinguishes from sibling tools that focus on plotting, retrieving values, or model info.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly mentions using the active simulation by default and the option to specify one, plus a strong warning to always run on a copy. Does not explicitly compare to alternatives, but siblings are distinct in purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses mutation, return of before/after, requirement to use a copy, and license needs. No annotations exist, so description carries full burden and provides essential behavioral context beyond the input schema.
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?
Three well-structured sentences: main purpose, return info, then warnings and usage. Every sentence adds value without redundancy. Front-loaded with action and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers main usage, mutation warning, and return type (before/after). Lacks detail on error handling or return format details, but adequate for a mutation tool with 5 parameters and no output schema given the clear warnings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Description adds meaning to muids (scope the change), all (update all rows, use with care), and values (column-value pairs). However, sqlite and table parameters are not elaborated beyond schema. With 60% schema coverage, description partially compensates but leaves some gaps.
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 'Set' and the resource 'parameter values in a MIKE+ table' with specific scope (element MUIDs). Examples (pipe Diameter, Manning roughness) clarify the function. It distinguishes from sibling tools like mike_get_values by specifying mutation and return of before/after.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use ('Set parameter values'), warns about mutation ('ALWAYS use a copy'), and distinguishes between scoped updates (muids) and bulk updates (all=true). Also notes prerequisite: 'Needs MIKE+ + license'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![Agentic-MIKE-Plus MCP server](https://glama.ai/mcp/servers/Zhonghao1995/Agentic-MIKE-Plus/badges/card.svg)](https://glama.ai/mcp/servers/Zhonghao1995/Agentic-MIKE-Plus)

Score Badge

Copy to your README.md:

[![Agentic-MIKE-Plus MCP server](https://glama.ai/mcp/servers/Zhonghao1995/Agentic-MIKE-Plus/badges/score.svg)](https://glama.ai/mcp/servers/Zhonghao1995/Agentic-MIKE-Plus)

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/Zhonghao1995/Agentic-MIKE-Plus'

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