tsetmc-mcp

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation5/5
Each tool serves a clearly distinct purpose: reference, market overview, live snapshot, filtering, historical data, order book, etc. Even similar tools like get_market_watch, screen, and run_filter are differentiated by their descriptions (filtered view vs prebuilt screens vs custom filters). No ambiguity in tool selection.
Naming Consistency4/5
Most tools follow a clear verb_noun pattern (e.g., get_quote, run_filter, search_symbol). However, 'market_status_tool' deviates by placing 'tool' at the end instead of using a verb prefix. This is a minor inconsistency in an otherwise coherent naming scheme.
Tool Count5/5
With 13 tools, the server is well-scoped for a stock market data provider. Each tool adds necessary functionality without redundancy. The count is appropriate for covering quoting, history, order book, screening, filtering, symbols, and market status.
Completeness5/5
The tool set covers all essential operations for the domain: live quotes, historical data, order book, money flow, market overview, screening, filtering, symbol resolution, and market status. No obvious gaps; reference tools for fields and filters further enhance completeness.
Average 3.9/5 across 13 of 13 tools scored. Lowest: 2.7/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 6 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.
Tools from this server were used 3 times in the last 30 days.
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?
No annotations provided, so the description must disclose behavioral traits. It mentions that unknown names return a list of available presets/filters, which is helpful, but it does not state side effects (e.g., whether it modifies data), authentication needs, rate limits, or return format. For a tool with zero annotations, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences. The list of presets is clear and front-loaded. No unnecessary words, though the list could be more compact.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, no annotations, and three parameters, the description lacks completeness. It does not describe the return format, behavior of limit and enrich_limit, or how saved filters are managed. The tool's full capability is under-documented.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain parameters. It partially explains the 'name' parameter by listing preset options, but it does not explain 'limit' or 'enrich_limit', leaving their purpose and constraints ambiguous.
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 that the tool runs a saved filter or built-in preset, and lists the preset names. However, it does not differentiate from the sibling tool 'run_filter', which may serve a similar purpose for ad-hoc filters. The purpose is specific and actionable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like 'run_filter' or 'screen'. The description implies it is for saved or preset filters but does not explain the context for choosing this tool over others.
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?
No annotations are provided, so the description must fully disclose behavior. It states this is a reference tool (implying read-only and no side effects), but lacks details on data freshness, output format, or whether it caches results. The minimal disclosure is insufficient for comprehensive 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 extremely concise: two short sentences with key information front-loaded. No redundant or extraneous text, every word adds value.
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?
For a zero-parameter tool with no output schema, the description is somewhat complete but lacks clarity on the scope of fields described. Given the context of many sibling tools, it could specify which tool's fields it covers to be fully complete.
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 zero parameters, and schema coverage is 100% (empty schema). The description does not need to explain parameters, and it correctly omits irrelevant details. This aligns with the baseline expectation.
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 states it is a reference for field meanings and units, which clearly indicates the tool's purpose. However, it does not specify which fields, leaving some ambiguity. It distinguishes from sibling tools by being a documentation tool rather than a data retrieval or filter tool.
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 advises 'call once; don't repeat,' which is a clear usage instruction. However, it does not provide when-to-use or when-not-to-use guidance, nor does it mention alternative tools for similar tasks.
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?
With no annotations, the description carries the burden. It says 'live per call' (non-cached) and '5 levels is the maximum depth,' which are useful behavioral details. However, it does not state auth needs, rate limits, or explicitly confirm it's read-only (though implied). It adds some value but is incomplete.
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 efficient sentences: first front-loads the core purpose, second explains details and behavioral note. No wasted words or 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?
The tool is simple (1 param, no output schema). The description covers essential purpose and data fields. However, without output schema, it could have described the return structure more explicitly (e.g., array of levels). It's adequate but not fully complete.
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?
The single parameter 'symbol' has no schema description (0% coverage). The description adds only 'for one symbol' without clarifying format, allowed values, or how to specify. This is insufficient for an agent to construct valid input without external knowledge.
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 'Live 5-level order book for one symbol' and explains what each level contains (bid/ask price, volume, order count). It also notes an imbalance detection use case. This is specific and distinguishes from siblings like get_quote or get_market_watch.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives. It mentions 'live per call' but gives no guidance on scenarios or exclusions. Siblings like get_quote or get_price_history are not compared, leaving the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so description must disclose behavior. It mentions 'live snapshot' indicating real-time read-only data, but does not detail access restrictions, rate limits, or error conditions. The description is minimal for a tool with no 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?
Description is very concise: two sentences front-loading purpose and listing kinds. Every sentence adds value with no redundancy. The structure is efficient and easy to parse.
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?
With no output schema, the description only briefly hints at return structure (ranked list vs counts). It does not explain the 'limit' parameter's effect or defaults. The tool is simple, so the description is adequate but leaves some questions unanswered.
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 has 0% description coverage, but description adds explicit enum values for 'kind' and explains the behavioral difference between market_breadth and other kinds. The 'limit' parameter is not described, which is a gap, but the description compensates significantly for the main parameter.
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?
Description clearly states the tool screens the market using prebuilt screens. Lists specific kinds (e.g., top_gainers) and explains the output difference between market_breadth and others. However, it does not differentiate from sibling tools like run_filter or run_saved_filter.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description implies usage for quick predefined screens, but does not explicitly state when to use this tool versus alternatives like run_filter or search_symbol. No when-not guidance is 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, the description bears the full burden. It describes the output data but fails to disclose any behavioral traits like idempotency, rate limits, or that this is a read-only operation. The agent lacks safety context.
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 purpose ('at a glance') and lists key outputs. No wasted 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?
For a zero-parameter tool, the description adequately conveys what the tool returns. It could optionally mention format or update frequency, but completeness is sufficient given the tool's simplicity.
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?
There are no parameters (0 params, 100% schema coverage). The baseline for 0 params is 4; the description adds no param info because none exist, 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 that the tool provides a market overview ('at a glance'), specifically listing TEDPIX and the equal-weighted index with last value, change, total market value, and state. This distinguishes it from siblings like get_market_watch or screen, which cover broader data.
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 use for a quick market snapshot but does not explicitly state when to avoid it or mention alternatives. Sibling tool names suggest other specific tools exist, but no comparative guidance is provided.
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, but the description fully discloses that the tool returns buy/sell volumes, counts, and net volume split by investor type. It is a read operation with no destructive behavior indicated. Missing some details like data freshness or auth requirements, but sufficient for a simple data retrieval.
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 short sentences front-loaded with core concept. Includes Persian terminology relevant to users. No redundant or unnecessary text.
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?
No output schema, but the description explains return fields: buy/sell volumes, counts, and legal_net_volume. Covers the key output. Could mention time period or data source, but adequate for a 1-param 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?
Only one parameter 'symbol' with 0% schema description coverage. The description does not elaborate on the symbol parameter beyond context, but it is self-explanatory. Could specify format or allowed values, but the lack is not critical.
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?
Clearly states it returns individual vs institutional money flow for one symbol, with specific verb 'get' and resource 'money flow'. Distinguishes from siblings like get_quote or get_price_history by focusing on this specific metric.
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?
Implied usage for 'smart money' reads but no explicit when-to-use or when-not-to-use. No comparison with alternatives provided. Usage guidance is minimal.
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 carries the full burden. It discloses that the tool returns status, time, session window, and freshness. It does not mention rate limits, authentication needs, or whether the call is safe. Since it is a read-only status check, the transparency is adequate but could be more explicit about its non-destructive nature.
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 sentence that is front-loaded with the key question and immediately lists the return fields. Every part is informative, with no wasted 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 the simplicity of the tool (no parameters, no output schema, no annotations), the description covers the purpose and key output fields. It could be slightly more detailed on formats or cache behavior, but it is sufficient for a straightforward status check.
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?
There are zero parameters, and schema description coverage is 100% trivially. The baseline for zero parameters is 4, and the description adds value by explaining what the tool returns, which is more than just the schema. No parameter details are needed.
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 starts with a clear question 'Is the Tehran market open right now?' which directly states the tool's main use case. It then lists specific return values: open/trading-day status, current Tehran time, session window, and snapshot freshness. This is a specific verb+resource pair, and it distinguishes the tool from siblings which are about filtering, quotes, or history.
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 use case (checking market status) and the output. However, it does not explicitly state when to use this tool versus alternatives like get_quote or get_price_history. No exclusions or when-not-to-use guidance is provided.
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 discloses that the tool runs over live market data, returns matching symbols with a specific structure {rows, matched, returned, normalized, tier, meta}, and that order-book filters enrich a shortlist on demand with a cap. This provides good behavioral transparency for a read-only query tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two paragraphs with front-loaded purpose. It uses examples and lists key points efficiently without wasted words. Could be slightly more structured (e.g., separating parameter descriptions), but overall it is concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (custom syntax, 5 params, no output schema), the description covers the main aspects: syntax, prerequisite, return format, and order-book behavior. However, it omits meanings for 'limit' and 'description' parameters, and the return fields are listed but not explained, leaving some gaps.
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 the description must compensate. It explains 'expression' in detail with examples, mentions 'save_as' for storing filters, and 'enrich_limit' for order-book. However, 'limit' and 'description' are not explained, leaving gaps for two of five parameters. Partial but insufficient compensation.
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 runs a custom stock filter over the live market and returns matching symbols. It distinguishes from siblings like 'run_saved_filter' by emphasizing it's for custom expressions, and mentions 'filter_help' as a prerequisite, making the specific purpose clear.
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 advises calling filter_help first to see available variables, and explains the two syntax options (TSETMC and friendly aliases). It also notes that order-book filters require setting enrich_limit. However, it does not explicitly state when to use this tool versus alternatives like 'screen' or 'run_saved_filter', though the sibling list implies those 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?
With no annotations, the description carries full burden. It discloses normalization of Persian/Arabic characters and digits, and specifies the return format. While it doesn't cover error cases or rate limits, the disclosed behaviors are relevant and helpful.
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, each with a distinct role: purpose, normalization detail, usage guidance and output format. No redundant words, front-loaded with the core action.
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 resolution tool with 2 parameters and no output schema, the description covers input, behavior, output format, and usage order. The return structure is explicitly stated, and sibling list provides context for tool ecosystem.
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 description adds meaning to the 'query' parameter by indicating it accepts symbol names and Persian text. However, the 'limit' parameter is not explained, and schema coverage is 0%, so the description only partially compensates.
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 resolves a Tehran-exchange symbol to its instrument code (insCode), which is a specific verb+resource. It also mentions Persian text normalization, distinguishing it from siblings like 'get_quote' or 'get_price_history' which require an insCode.
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 says 'Use this first when you only know the symbol name,' providing clear when-to-use context. It doesn't explicitly list when not to use, but the phrase implies it's a starting step, and sibling tools are for later stages.
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 discloses key behaviors: it never dumps all rows (always filtered/limited), it comes from a live snapshot, and it returns a structured object {rows, returned, matched, truncated, meta}. It also explains that 'fields' projects specific columns. This provides good transparency into how the tool behaves.
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 concise, using a single paragraph with inline enumeration of options. It is front-loaded with the main purpose and key constraint (always filtered/limited). Every sentence adds value, with no filler 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 has 10 parameters and no output schema, the description adequately covers purpose, filtering options, sort options, return structure, and the live snapshot origin. It leaves a few details implicit (e.g., default sort_by value is 'value' per schema), but overall provides sufficient context 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?
Schema coverage is 0%, but the description compensates by explaining the valid values for sort_by (value, volume, pct_change, last, count), clarifying min_pct/max_pct as percent change, giving codes for flow (1=Bourse, 2=Farabourse, 4=پایه), and describing symbol_contains and fields as column projection. It does not detail all parameters (like descending, limit), but adds significant meaning beyond 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 this tool provides a filtered/sorted view of the whole market from a live snapshot. It uses specific verbs like 'filtered/sorted view' and mentions the Persian term for market watch. It distinguishes itself from siblings like get_index_overview and get_quote by being a broad, filtered market overview.
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 explicitly says the tool is 'ALWAYS filtered and limited' to avoid dumping all rows, implying when to use (for broad overview without overloading). It lists available sort options and filters, giving clear direction on usage. However, it does not explicitly state when not to use it or compare to specific alternatives like search_symbol or run_filter.
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 carries full burden. Discloses that data comes from in-memory snapshot and freshness can be checked via meta fields. Also states prices are in Rial. Could mention idempotency, but sufficient.
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, no fluff. Front-loaded with purpose, then output details. Every sentence adds value. Ideal conciseness.
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?
No output schema, but description adequately explains return fields (prices, volume, ratios) and freshness check. Lacks error handling info, but overall complete for a simple lookup 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?
Schema has 0% description coverage, but description adds meaning: symbol accepts نماد or insCode, clarifying accepted input types beyond the string type. Provides valuable market-specific context.
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?
Clearly states it provides a live price snapshot for one symbol, listing all returned fields (prices, change, volume, EPS, P/E). Distinguishes from siblings like get_market_watch (multiple symbols) and get_price_history (historical).
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 describes when to use (get current price for a single symbol) and mentions checking freshness meta fields. Does not provide explicit alternatives, but sibling names imply differentiation.
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 are provided, but the description accurately portrays the tool as a read-only reference with no side effects. It fully discloses its informational nature.
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, front-loaded with the purpose, and every word adds value. No unnecessary information.
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 is complete: it covers what the tool contains and when to use it.
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?
There are 0 parameters, so schema coverage is trivially 100%. The description does not need to add parameter details, and baseline for 0 parameters is 4.
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 explicitly states that filter_help is a reference for writing filters, listing variables, operators, functions, and presets. It clearly distinguishes itself from execution-oriented siblings like run_filter.
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 directly advises to 'Call this before writing a filter so it uses valid names,' providing explicit guidance on when to use the 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?
Discloses key traits: raw/unadjusted data, newest-last ordering, CSV fallback for large pulls to protect context window, prices in Rial.
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, each adding distinct value, front-loaded with core purpose.
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?
Explains return format variations for CSV case, covers all three parameters, appropriate for tool with no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Adds significant meaning beyond schema: days<=0 means full history, save_csv=True changes return format to file_path/summary/sample.
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 it provides daily OHLCV history for one symbol, raw/unadjusted, newest last. It distinguishes from siblings like get_quote or get_order_book.
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 guidance on days<=0 for full history and CSV behavior for large pulls, but does not explicitly compare to alternatives like get_quote.
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:

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

Score Badge

Copy to your README.md:

[![tsetmc-mcp MCP server](https://glama.ai/mcp/servers/solitraderbusiness/tsetmc-mcp/badges/score.svg)](https://glama.ai/mcp/servers/solitraderbusiness/tsetmc-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/solitraderbusiness/tsetmc-mcp'

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