Taiwan Stock Agent

by clsung

Overview Schema Related Servers Score Discussions

Python

Hybrid

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation3/5
The tools have some clear distinctions (e.g., market overview vs. stock-specific data), but there is notable overlap: get_stock_data, get_realtime_data, and get_price_history all target stock-specific information with ambiguous boundaries. get_best_four_points is distinct but could be confused as part of stock data. The descriptions help differentiate but don't fully resolve the ambiguity.
Naming Consistency4/5
Most tools follow a consistent verb_noun pattern (e.g., get_market_overview, get_price_history, invalidate_cache), which is predictable and readable. However, list_resources and subscribe_resource deviate slightly by not starting with 'get', though they maintain the same snake_case style. This minor inconsistency keeps the naming mostly coherent.
Tool Count5/5
With 8 tools, the count is well-scoped for a stock analysis server, falling within the typical 3-15 range. Each tool appears to serve a distinct purpose in the domain, such as data retrieval, caching, and subscriptions, without feeling excessive or insufficient for the stated functionality.
Completeness3/5
The tool set covers core data retrieval (e.g., real-time, historical, overview) and utility functions (caching, subscriptions), but there are notable gaps: no tools for actions like buying/selling stocks, setting alerts, or analyzing trends beyond the 'best four points'. This limits agent workflows, as the surface is data-focused without operational capabilities.
Average 2.7/5 across 8 of 8 tools scored. Lowest: 2/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 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

Behavior1/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 of behavioral disclosure. However, it offers no information about traits like read-only status, destructive potential, rate limits, authentication needs, or response format. This is inadequate for a tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is appropriately concise, but it is under-specified rather than efficiently informative. It fails to front-load critical details, making it less helpful despite its brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete. It does not explain what 'market overview' includes, how it differs from sibling tools, or what the return values are, leaving significant gaps for the agent to understand the tool's context and usage.
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 0 parameters, and the schema description coverage is 100%, so no parameter information is needed. The baseline for this scenario is 4, as the description does not need to compensate for any parameter gaps, though it also adds no value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get market overview information' restates the tool name 'get_market_overview' in a tautological manner without specifying what 'market overview' entails or distinguishing it from sibling tools like get_realtime_data or get_stock_data. It provides a vague purpose without concrete details about what resource or data is retrieved.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as get_realtime_data or get_stock_data. The description lacks any context, prerequisites, or exclusions, leaving the agent with no information to differentiate this tool from its siblings.
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 the full burden of behavioral disclosure. It only states the action ('Get...analysis') without detailing traits like whether it's read-only, requires authentication, has rate limits, or what the analysis output entails (e.g., format, data types). This leaves significant gaps in understanding the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, straightforward sentence that is front-loaded and wastes no words. However, it's overly concise to the point of under-specification, lacking necessary details for clarity and completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of an analysis tool with no annotations, 1 parameter at 0% coverage, and no output schema, the description is incomplete. It doesn't explain what 'Best Four Points' means, the analysis scope, return values, or behavioral traits, making it inadequate for effective tool use.
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 input schema has 1 parameter with 0% description coverage, and the description does not add any meaning beyond the schema. It mentions 'a specific stock' but doesn't explain the 'stock_code' parameter's format, valid values, or semantics, failing to compensate for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool 'Get Best Four Points analysis for a specific stock,' which provides a verb ('Get') and resource ('analysis'), but it's vague about what 'Best Four Points' entails—it could refer to technical indicators, price levels, or other metrics without clarification. It doesn't distinguish from siblings like get_stock_data or get_price_history, leaving ambiguity in purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as get_stock_data or get_price_history. The description implies it's for analysis of a specific stock, but it doesn't specify contexts, prerequisites, or exclusions, offering minimal direction for selection among sibling tools.
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 carries the full burden of behavioral disclosure. It states the tool invalidates cache 'for fresh data', implying a mutation that refreshes data, but doesn't specify what gets invalidated (e.g., all cache, specific resources), whether it's destructive, permission requirements, or rate limits. This leaves critical behavioral traits unclear for a mutation tool.
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 with no wasted words. It's front-loaded with the core action ('Invalidate resource cache') and purpose ('for fresh data'), making it easy to parse quickly. Every part of the sentence contributes to understanding the tool's intent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a mutation operation with one parameter), lack of annotations, no output schema, and 0% schema coverage, the description is incomplete. It doesn't cover parameter usage, behavioral details like side effects, or what happens after invalidation. For a cache-invalidation tool, this leaves too many gaps for reliable agent use.
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 schema description coverage is 0%, with one parameter ('resource_pattern') undocumented in the schema. The description doesn't mention parameters at all, failing to compensate for the schema gap. It doesn't explain what 'resource_pattern' means, its format, or how it affects the invalidation, leaving the parameter's purpose ambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Invalidate resource cache for fresh data' states the tool's purpose with a specific verb ('invalidate') and resource ('cache'), but it's somewhat vague about what exactly gets invalidated. It doesn't clearly distinguish this from sibling tools like 'list_resources' or 'subscribe_resource' which might also involve cache operations. The purpose is understandable but lacks precision about scope and boundaries.
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 guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., after data updates), exclusions, or how it relates to sibling tools like 'get_realtime_data' or 'list_resources'. Without any usage context, the agent must infer when this tool is appropriate, which could lead to misuse.
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 the full burden of behavioral disclosure. It states the tool retrieves historical data but lacks details on permissions, rate limits, data format, or potential side effects. This is a significant gap for a data retrieval tool, as it doesn't clarify if it's read-only, requires authentication, or has other constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no wasted words, making it easy to parse and front-loaded with the core purpose. It efficiently communicates the essential action without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a data retrieval tool with no annotations, no output schema, and low parameter coverage, the description is incomplete. It doesn't address return values, error handling, or behavioral traits, leaving the agent with insufficient information to use the tool effectively beyond a basic understanding.
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 description mentions 'specific stock' and 'historical price data', which loosely maps to the 'stock_code' and 'period' parameters. However, with 0% schema description coverage and two parameters, it doesn't explain what 'stock_code' format to use (e.g., ticker symbol), what 'period' values are valid (e.g., '1mo', '1y'), or how the data is returned. This fails to compensate for the lack of schema details.
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's purpose with a specific verb ('Get') and resource ('historical price data for a specific stock'), making it easy to understand what it does. However, it doesn't distinguish this tool from sibling tools like 'get_stock_data' or 'get_realtime_data', which might offer similar or overlapping functionality.
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 guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'get_stock_data' or 'get_realtime_data', nor does it specify prerequisites, exclusions, or contexts for usage, leaving the agent to infer based on tool names alone.
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 carries the full burden of behavioral disclosure. It mentions 'real-time data' but does not specify details like data freshness, rate limits, authentication needs, or error handling. This leaves significant gaps in understanding how the tool behaves beyond its basic action.
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 directly states the tool's function without unnecessary words. It is front-loaded and appropriately sized, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a data retrieval operation with no annotations or output schema), the description is incomplete. It lacks details on return values, error conditions, or behavioral traits, making it insufficient for an AI agent to fully understand how to use the tool effectively in context.
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 input schema has 0% description coverage, with only a parameter 'stock_code' documented structurally. The description adds minimal semantics by implying the parameter is for a stock, but it does not explain format (e.g., ticker symbol), constraints, or examples, failing to compensate for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'real-time data for a specific stock,' making the purpose understandable. However, it does not distinguish this tool from siblings like 'get_stock_data' or 'get_price_history,' which might also retrieve stock-related information, leaving some ambiguity about uniqueness.
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 guidance on when to use this tool versus alternatives such as 'get_stock_data' or 'get_price_history.' It lacks context about prerequisites, exclusions, or specific scenarios, offering only a basic statement of function without usage instructions.
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 the full burden of behavioral disclosure. It states the action ('Get') but doesn't clarify if this is a read-only operation, requires authentication, has rate limits, or what the output format might be. For a tool with zero annotation coverage, this leaves significant gaps in understanding its 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?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, making it easy to parse quickly, though it could benefit from more detail given the lack of other documentation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of financial data tools, no annotations, no output schema, and low schema coverage, the description is incomplete. It doesn't address what 'detailed information' includes, how results are returned, or any prerequisites, making it inadequate for an agent to use this tool effectively without additional context.
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 schema description coverage is 0%, and the description doesn't add any meaning beyond the input schema. It mentions 'a specific stock' but doesn't explain what 'stock_code' represents (e.g., ticker symbol, format examples like 'AAPL' or 'GOOGL'), leaving the parameter semantics unclear and undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('detailed information about a specific stock'), making the purpose understandable. However, it doesn't distinguish this tool from potential siblings like 'get_realtime_data' or 'get_price_history', which might also provide stock information with different scopes or formats.
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 guidance on when to use this tool versus alternatives like 'get_realtime_data' or 'get_price_history'. It lacks context about what makes this tool unique, such as whether it returns comprehensive data, real-time updates, or historical trends, leaving the agent to guess based on tool names alone.
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 the full burden of behavioral disclosure. It mentions 'caching and notifications' but lacks details on permissions, rate limits, side effects, or response format. This is inadequate for a subscription tool that likely involves ongoing processes or network operations.
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 with no wasted words. It's front-loaded with the core action and purpose, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a subscription tool (likely involving state changes or network calls), no annotations, no output schema, and poor parameter coverage, the description is incomplete. It doesn't address what happens after subscription, error conditions, or how it integrates with caching/notifications.
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 compensate. It doesn't explain the 'resource_uri' parameter beyond what the schema provides (just a string). No details on format, examples, or how it relates to 'resource updates' are given, leaving the parameter's meaning unclear.
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 action ('Subscribe') and purpose ('to resource updates for caching and notifications'), making the tool's function understandable. It doesn't differentiate from siblings like 'invalidate_cache' or 'list_resources', but it's not vague or tautological.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'invalidate_cache' or 'list_resources'. The description implies usage for caching and notifications but doesn't specify contexts, prerequisites, or exclusions, leaving the agent to infer when it's appropriate.
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 the full burden of behavioral disclosure. It states the tool lists resources but doesn't describe how it behaves—e.g., whether it's read-only, if it requires authentication, rate limits, pagination, or what the output format looks like. For a tool with zero annotation coverage, this leaves significant gaps in understanding its operational traits.
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 directly states the tool's purpose without unnecessary words. It's front-loaded with the core action and resource, making it easy to scan and understand quickly. Every part of the sentence contributes value by specifying scope ('all available MCP resources') and additional details ('with templates and examples').
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 tool's simplicity (0 parameters, no output schema, no annotations), the description is adequate but has clear gaps. It explains what the tool does but lacks behavioral context and usage guidelines. For a basic listing tool, it meets the minimum viable standard but doesn't provide enough information for optimal agent use without additional inference.
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 0 parameters with 100% coverage, so the schema fully documents that no inputs are required. The description adds no parameter information, which is appropriate here. Since there are no parameters, the baseline score is 4, as the description doesn't need to compensate for any gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('List') and resource ('all available MCP resources'), specifying what the tool does. It adds detail about including 'templates and examples', which helps differentiate it from generic listing tools. However, it doesn't explicitly distinguish from sibling tools like 'get_stock_data' or 'get_market_overview', which appear to be more specific resource-fetching operations.
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 guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, context for usage, or comparisons to sibling tools like 'get_stock_data' or 'subscribe_resource'. Users must infer usage from the purpose alone, which is insufficient for effective tool selection.
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:

[![tw-stock-agent MCP server](https://glama.ai/mcp/servers/clsung/tw-stock-agent/badges/card.svg)](https://glama.ai/mcp/servers/clsung/tw-stock-agent)

Score Badge

Copy to your README.md:

[![tw-stock-agent MCP server](https://glama.ai/mcp/servers/clsung/tw-stock-agent/badges/score.svg)](https://glama.ai/mcp/servers/clsung/tw-stock-agent)

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/clsung/tw-stock-agent'

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