midas-mcp

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation4/5
Each tool has a clear primary purpose, and the descriptions make boundaries mostly clear. However, get_asset_info and get_asset_price both provide current price information, and get_assets vs get_portfolio could be confused at a glance, though they serve different levels of detail.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern with snake_case (get_*, sell_asset, buy_asset, cancel_order). The verbs are simple and predictable, making the API easy to navigate.
Tool Count5/5
10 tools is well-scoped for a trading platform MCP, covering portfolio viewing, order placement, order management, and market data. Each tool has a distinct role and none seem redundant or unnecessary.
Completeness4/5
The core trading lifecycle is covered: see positions, place orders, cancel pending orders, view quotes, and get technical analysis. Minor gaps include lack of order history (executed trades) and no way to modify an order (though cancel+replace works), and no symbol search, but these are not critical dead ends.
Average 4.1/5 across 10 of 10 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 11 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
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

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint, so the tool is known to be safe and non-mutating. The description adds useful context about the contents (asset types and fields) but does not disclose additional behavioral traits such as pagination or ordering.
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, concise sentence that directly lists the action, scope, and returned fields. No wasted words.
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?
Given the simplicity of the tool (no parameters, no output schema), the description fully covers what it returns. It states the asset categories and specific fields, making it sufficient for an agent to use the tool correctly.
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 tool has no parameters, so the schema provides all needed information. Per the rubric, zero parameters warrants a baseline score of 4.
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 lists all open positions and specifies the asset types and return fields. However, it does not explicitly differentiate from the sibling tool get_portfolio, which might also list positions, so it lacks explicit sibling differentiation.
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 is used to view open positions with detailed cost and value info, but it gives no explicit guidance on when to prefer this over alternatives like get_portfolio or get_asset_info.
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?
Annotations indicate a mutation (readOnlyHint=false) but destructiveHint=false; the description adds the constraint that only pending orders can be cancelled, which is useful. However, it doesn't disclose side effects or irreversibility, and without an output schema the agent is left uncertain about the result.
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?
Two sentences, front-loaded with the action and an actionable tip to find the ID. No wasted words or repetition of structured fields.
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?
Adequate for a simple mutation tool, but it lacks return value information and error conditions. It relies on the schema for parameter details and doesn't explain what happens after cancellation, leaving gaps for an agent.
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 meaningful descriptions for both parameters, including the source of order_id. The description adds no additional parameter-level semantics beyond what the schema already provides.
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 'cancel' with 'pending order' and 'order id', clearly distinguishing it from sibling buy/sell/view tools. It precisely states the action and resource.
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?
It states the tool is for cancelling pending orders and explicitly directs users to get_pending_orders to find the id, providing clear context. However, it doesn't mention explicit exclusions or alternatives for non-pending orders.
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?
The annotations already declare readOnlyHint and openWorldHint, which convey that this is a safe, read-only operation. The description adds the specific output fields (full name, market, description, current price) but does not discuss error handling, response format, or other behavioral traits. This adds some value beyond the annotations, appropriate for a 3.
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, concise sentence that front-loads the action and lists the returned data types without any unnecessary words or repetition.
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 read-only lookup with one parameter and no output schema, the description adequately specifies the returned information (full name, market, description, current price). It doesn't provide the exact response format or error behavior, but given the simplicity and annotation coverage, it is sufficiently 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?
The schema has 100% coverage for the single parameter 'symbol' with the description 'Ticker or company name to look up.' The tool description adds no additional parameter semantics, so the baseline 3 applies.
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 'Get' and identifies the resource as 'descriptive information about an instrument' with the additional output of current price. This clearly distinguishes it from siblings like get_asset_price (which focuses solely on price) and get_assets (which lists assets).
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 establishes clear context for when to use the tool: when both descriptive information and current price are needed. It doesn't explicitly name alternatives or state exclusions, but the content makes the distinction obvious, so it earns a 4 rather than a 5.
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?
Annotations already declare readOnlyHint=true, which covers the safety profile. The description adds useful behavioral context by specifying the returned data (previous close, percent change, session open) and implies the tool provides both price and market state, going beyond just the annotation.
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, well-structured sentence that front-loads the core action ('Get the current trade price') followed by a concise list of additional data. No unnecessary words or redundant 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 simple read-only tool with one required parameter, the description is fairly complete. It names the key return fields, though it does not provide an exhaustive output format or mention error cases like inactive symbols. Given no output schema exists, the description partially compensates by listing primary data points.
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?
The input schema fully describes both parameters (symbol and currency) with detailed explanations, achieving 100% coverage. The description itself adds no additional parameter semantics, so the 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 verb ('Get'), the resource ('current trade price for a symbol'), and the specific data points included (previous close, percent change, market session open). This distinguishes it from siblings like get_technicals and get_chart, which focus on different data sets.
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 fetching current price data but does not explicitly mention when to use this tool over alternatives like get_asset_info or get_chart. There are no exclusions or alternative recommendations, though the purpose itself makes the use case obvious.
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?
Annotations already declare readOnlyHint=true, and the description's 'Get' is consistent. The description adds valuable context beyond annotations by detailing the specific data returned (TRY value, P/L, cash, buying power) and the account split (Turkish vs. US). It does not disclose rate limits or error conditions, but the read-only nature is covered.
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, well-structured sentence that front-loads the main purpose ('Get overall portfolio value'), then lists the specifics. Every word earns its place; no fluff, no 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?
For a no-parameter, read-only tool without an output schema, the description does a good job covering what is returned. It lists all major output components and account types. However, it could be more precise about currencies for cash balances or whether the output is a snapshot, but this is a minor gap for such a simple tool.
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 input schema has zero properties, so there are no parameters to describe. The baseline for 0 params is 4, and the description does not attempt to explain parameters, which 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's function with a specific verb ('Get') and resource ('overall portfolio value'), and enumerates the exact outputs: value in TRY, today's profit/loss, cash balances, and buying power for both Turkish and US accounts. This distinguishes it from sibling tools like get_assets, which focus on individual assets.
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 provides no explicit guidance on when to use this tool relative to others, nor any exclusions or alternatives. While it is implied for portfolio overview, it does not mention that get_assets handles asset-level detail or that buy/sell tools handle transactions, leaving usage to inference.
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?
Annotations already declare readOnlyHint=true, so the description does not need to restate that. It adds behavioral context by specifying that the tool returns order IDs intended for cancellation, and clarifies the order status. This goes beyond the annotations and helps the agent anticipate the output. 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?
The description is a single concise sentence that front-loads the action and includes a relevant detail (order IDs for cancellation). No redundant wording or filler, earning a top score.
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 parameter and no output schema, the description provides enough context: it lists pending orders and notes the inclusion of order IDs. It does not explain the full response format or edge cases (e.g., empty results), but these are minor given the tool's simplicity and the readOnlyHint annotation.
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?
The schema has 100% coverage for the single parameter 'symbol' with a clear description. The tool description adds no new parameter-level information beyond restating that it's a symbol. Since schema coverage is high, baseline is 3; the description does not meaningfully enrich the parameter semantics.
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 a specific verb ('List') and resource ('orders for a symbol') and clarifies the status ('still waiting to execute'), which distinguishes it from sibling tools like get_assets and cancel_order. Including the purpose ('for cancellation') further sharpens the tool's role.
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 implies the use case: when you need to see pending orders for a symbol and obtain their IDs for cancellation. It does not explicitly say 'use this instead of X', but the mention of 'for cancellation' hints at the workflow with the sibling cancel_order, and the context is clear. No explicit exclusions, but adequate.
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?
Annotations already declare readOnlyHint=true, so the agent knows this is a safe read operation. The description adds value by detailing exactly which indicators are computed, giving insight into the tool's behavior and output. It does not mention error handling or rate limits, but for a read-only computation tool, the listed indicators provide strong behavioral transparency beyond the annotation.
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 and front-loads the purpose ('Compute a full technical-analysis snapshot'). The first sentence is a dense list of indicators, but each item is meaningful and directly describes outputs. The second sentence gives actionable context (feed into scan formula). No filler or redundant 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?
Given the tool has no output schema, the description compensates by enumerating all outputs (indicators, ranges, levels). It also mentions 'daily price history' and the interval default via the schema. It does not describe potential errors or edge cases, but for a 2-parameter read-only tool with a comprehensive output list, this is nearly complete. Slight deduction for lacking explicit mention of what happens with insufficient data.
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?
The input schema has 100% coverage for both parameters (symbol and interval), including descriptions and an enum for interval. The description adds no parameter-specific details beyond the schema, such as format, constraints, or examples. Therefore, the baseline of 3 applies.
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 a specific verb ('Compute') and clearly identifies the resource ('technical-analysis snapshot for a symbol'), then enumerates a comprehensive list of indicators (RSI, SMA/EMA, MACD, Bollinger Bands, ATR, volatility, 52-week range, swing-pivot levels, volume-vs-average). This distinguishes it from sibling tools like get_chart or get_asset_price, which serve different data 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 clear context for when to use the tool: 'Feed this into the scan scoring formula in CLAUDE.md.' This implies a specific use case (technical analysis for stock scanning) but does not explicitly mention alternatives or when not to use it. Since it names a downstream integration, it offers more than mere implication, but lacks explicit 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?
Annotations already declare readOnlyHint=true and openWorldHint=true, covering the safety profile. The description adds the 'raw series' distinction but does not disclose return ordering, pagination, or any additional side-effect behavior beyond the 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?
The description is two sentences, starts with an action verb and resource, and has zero filler words. Every clause earns its place, including the sibling-tool alternative.
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 simple read-only chart fetch, the description plus rich schema and annotations are sufficient. It names the output fields, distinguishes from the computed-indicator sibling, and the schema covers limits/intervals/defaults; no output schema is necessary.
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?
All three parameters in the schema have complete descriptions (100% coverage), so the schema already documents symbol, limit, and interval. The description only restates the symbol context and does not add parameter-level semantics beyond what the schema carries.
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 states a specific action and resource: 'Get raw OHLCV candles for a symbol,' and lists the exact fields returned. It also names the sibling tool 'get_technicals' for comparison, making the purpose unmistakable.
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?
The description explicitly provides usage guidance: use get_technicals for computed indicators, and use this tool 'only when you need the raw series.' This clearly separates the two sibling tools' use cases.
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?
The annotations already indicate a destructive, non-read-only action. The description adds valuable behavior beyond annotations: the order value cap, the market-order/limit-price distinction, and the queueing-outside-market-hours note. No contradiction with 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?
Three short sentences, each carrying essential information. The first sentence states the action, the second a critical constraint, and the third covers two useful behaviors. No redundancy or filler.
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 description covers the core purpose, key constraints, and market-hours behavior. However, with no output schema, it does not mention what the tool returns (e.g., order confirmation, order ID), which is a gap for an agent needing to confirm the action succeeded.
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 description coverage is 100%, so parameters are already well documented. The description further clarifies limit_price by stating it should be omitted for a market order, and the order-value threshold indirectly relates to quantity and price, adding practical meaning.
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 opens with 'Place a SELL order', using a specific verb and resource. It clearly distinguishes from the sibling buy_asset and other tools, and the name sell_asset reinforces the intent.
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?
Provides concrete usage context: the ₺5000 value refusal, the choice between market and limit orders, and the market-hours queueing behavior. It does not explicitly name alternatives, but the context is clear enough for an agent to know when to invoke this tool.
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?
Annotations already flag this as a destructive write operation, but the description adds crucial non-obvious behaviors: the ₺5000 order value refusal threshold, the queueing of off-hours orders for the next session, and the market vs. limit order distinction. This goes beyond what annotations convey.
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 deliver the core purpose and constraints with no filler. The structure front-loads the action and follows with conditional behaviors.
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?
With no output schema, the description does not mention what the tool returns after order placement, and it omits details like rejection handling or sufficient-funds requirements. However, it covers the main operational constraints (value cap, market hours, market/limit behavior) and the schema handles parameter definitions, making it adequate for a moderately simple tool.
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?
The input schema already provides full descriptions for all three parameters, including the note that limit_price is optional for market orders. The description restates the market-order instruction but adds no new parameter-specific semantics beyond the schema; the ₺5000 limit is a global constraint, not parameter-specific.
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 opens with 'Place a BUY order', immediately specifying the action and resource. It clearly distinguishes from siblings like sell_asset and read-only getters. The additional instructions about limit price and market hours reinforce the tool's specific purpose.
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 clear operational context: the ₺5000 value cap, market-order instructions, and BIST trading hours. However, it does not explicitly compare with sell_asset or other order-management tools, so there are no exclusions or alternative guidance beyond the implied buy intent.
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:

[![midas-mcp MCP server](https://glama.ai/mcp/servers/ahmetdenizyilmaz/midas-mcp/badges/card.svg)](https://glama.ai/mcp/servers/ahmetdenizyilmaz/midas-mcp)

Score Badge

Copy to your README.md:

[![midas-mcp MCP server](https://glama.ai/mcp/servers/ahmetdenizyilmaz/midas-mcp/badges/score.svg)](https://glama.ai/mcp/servers/ahmetdenizyilmaz/midas-mcp)

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/ahmetdenizyilmaz/midas-mcp'

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