cti-mcp

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation4/5
Most tools have clearly distinct purposes, but there is slight overlap between get_upcoming_catalysts and get_kr_pharma_pipeline (both relate to clinical trials) and between evaluate_trading_signal and score_stock (both produce scores). Descriptions help clarify the differences, but an agent might occasionally misselect.
Naming Consistency4/5
The majority of tools follow a get_* pattern, but there are deviations like evaluate_trading_signal, search_pharma_trials, score_stock, and ping. All use snake_case consistently, so the naming is readable and predictable, just not perfectly uniform.
Tool Count5/5
10 tools is a well-scoped number for a server covering both clinical trial data and technical stock analysis. Each tool serves a distinct function, and there is no unnecessary bloat or deficiency.
Completeness5/5
The tool set covers the full range of the domain: clinical trial catalysts, pipeline overview, trial search, technical indicators, advanced strategies, signal evaluation, scoring breakdown, competition analysis, and a comprehensive analyze_stock wrapper. No obvious gaps in the workflow.
Average 3.3/5 across 10 of 10 tools scored. Lowest: 2.7/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
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits, but it only states the ranking criterion. It does not mention what the overview contains, how phases are handled, whether the data is current, or any default limits. This is insufficient for a tool that likely accesses a data source.
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 conveys the tool's primary purpose. It is front-loaded and contains no filler or redundant information, making it highly efficient.
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?
The tool is simple, but the description lacks essential context such as what data is actually returned, how the 'phase' filter works, and what the default ranking count is. Without an output schema, the description should compensate, but it does not.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description does not mention the 'top' or 'phase' parameters at all. The parameter names are somewhat self-explanatory, but the description adds no meaning beyond the bare schema, leaving the agent to guess at allowed values and behavior.
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 indicates the tool returns an overview of the Korean pharma pipeline ranked by active clinical trials, which is specific enough to infer the core function. However, it does not explicitly distinguish itself from sibling tools like search_pharma_trials or get_upcoming_catalysts, so it misses the 5-level differentiation.
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 search_pharma_trials for granular trial details. There is no mention of prerequisites, typical use cases, or exclusion criteria, leaving the agent without context for tool selection.
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 does not mention whether the tool is read-only, what data sources it uses, what the output format is, or any side effects. It merely states it performs analysis, leaving the agent uncertain about the tool's behavior beyond the 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys the core purpose and usage instruction without redundancy. It is appropriately sized for a tool of this complexity, though it could have included more detail without being verbose.
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?
With no output schema and no annotations, the description should explain what the tool returns or any prerequisites. It currently only describes the action and inputs, not the output or conditions, making it incomplete for an agent to fully understand the tool's behavior and results.
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 schema already describes both symbol and sponsor with 100% coverage, so the baseline is 3. The description adds value by explicitly stating they are alternatives ('or') and providing an example symbol (e.g., '005930'), which clarifies usage beyond the individual property descriptions. However, it doesn't explain precedence or behavior if both are provided.
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 it performs 'Full clinical trial + market analysis for a Korean pharma company,' which is a specific purpose that differentiates it from sibling tools focused on narrower aspects like technicals or catalysts. It also provides usage instruction (provide symbol or sponsor name). However, it lacks an explicit verb like 'analyze,' but 'analysis' serves that role, making the 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 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_technicals or get_competition_analysis. It only states what it does and what to provide, without explaining the appropriate context or exclusions. Given the presence of sibling tools, this ambiguity creates confusion.
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 must carry the full burden of behavioral disclosure. It mentions the indicators and asset type, but does not describe output format, pagination, limitations, or the meaning of the 'range' parameter. The read-only nature is implied by 'Get' but not explicitly stated.
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, waste-free sentence that front-loads the core purpose. It earns its place, though it could include more context without becoming unnecessarily verbose.
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 has two parameters (one required, one optional) and no output schema, the description is too thin. It does not explain the range parameter, the expected return structure, or any edge cases, making it incomplete for reliable autonomous invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not compensate. It implicitly references 'symbol' but completely ignores the optional 'range' parameter. This leaves the agent without adequate information to set parameters correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get'), the resource ('technical indicators'), specific indicators (RSI, Bollinger Bands, Volume Ratio), and the target asset type (Korean pharma stock). This is sufficiently specific to distinguish it from sibling tools like get_technical_strategies.
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. There is no mention of scenarios where technical indicators would be preferred over get_technical_strategies or evaluate_trading_signal, and no exclusion criteria.
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 says 'List' and does not explain side effects, permissions, rate limits, or return behavior. Although it implies a read-only operation, it omits details like whether specific parameters are required or what the output format looks like.
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, clear sentence that directly states the tool's function without unnecessary fluff. It front-loads the key action and resource. However, it is slightly under-specified for a tool with three parameters, but this is not a conciseness issue; the sentence itself is well-structured.
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 has 3 parameters, no annotations, and no output schema, the description is too minimal to be fully complete. It explains the general purpose but leaves parameter meanings and expected response undefined. The description is adequate for a basic understanding but lacks necessary context for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 3 parameters (phase, months, symbol) with 0% schema description coverage, and the description does not explain any of them. It only refers to 'N months' without clarifying the 'months' parameter, and 'phase' and 'symbol' are completely unexplained. The description adds no meaning beyond the parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('List') and resource ('upcoming clinical trial catalysts (completion dates)'), and it narrows the scope to Korean pharma companies within a given time frame. This distinguishes it from siblings like get_kr_pharma_pipeline or search_pharma_trials, which likely cover broader pipeline or trial searches.
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 by defining the scenario (upcoming catalysts within N months), but it does not explicitly mention when to use this tool instead of alternatives such as search_pharma_trials or get_kr_pharma_pipeline. There are no exclusions or conditional guidance, so the usage context is implied but not explicit.
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 carry the full burden of behavioral disclosure. It states that the tool 'returns all competing sponsors,' indicating a read-only output, but does not reveal potential error conditions, data source, ordering, or what happens when no input is given. This minimal transparency is insufficient for a tool with no annotation support.
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 only two sentences, front-loaded with the core purpose and outcome. Every word earns its place, with no redundant phrasing or filler. It is well-sized for a tool with a straightforward function.
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?
The tool has no output schema and no annotations, so the description must provide sufficient context for proper usage. It fails to clarify how the two optional identification parameters (nct_id and condition) interact, what happens if neither is provided, or the structure of the returned sponsor list. This incompleteness could lead to incorrect invocation.
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 covers 100% of parameters with descriptions, so the baseline is 3. The description itself adds little extra meaning beyond the schema, only hinting that 'condition' or 'nct_id' are alternative lookup methods. It does not elaborate on the interplay between parameters, such as whether they are mutually exclusive or combined.
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 identifies the tool's function: mapping the competitive landscape for a condition or trial and returning all competing sponsors. It uses a specific verb ('map') and resource ('competitive landscape'), and the mention of 'sponsors' distinguishes it from sibling tools like get_upcoming_catalysts or analyze_stock.
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 when to use the tool (when needing competitive landscape information), but provides no explicit comparison to alternatives or exclusions. It does not reference any sibling tools or state scenarios where this tool should not be used, leaving the usage context implicit rather than explicit.
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, but it only states the action (run strategies, produce consensus) without detailing output format, execution caveats, or data dependencies. It does not explain what a consensus signal looks like or whether any side effects occur (though 'get' suggests read-only, this is not stated).
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, front-loaded sentence with no redundant words. It packs the core action and the specific strategy list into a compact form, earning its place entirely.
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?
While the description lists the strategies and clarifies the target (Korean pharma stock), it omits crucial context: what the consensus signal means, the output format, and how to interpret results. With no output schema and no annotations, the lack of behavioral details makes the tool difficult to use correctly.
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 100% coverage with descriptions for both 'symbol' (KRX ticker) and 'range' (3mo/6mo/1y, default 6mo). The description adds no additional parameter-specific meaning beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool runs 5 named technical analysis strategies and produces a consensus signal for a Korean pharma stock, making its specific function unmistakable. It distinguishes itself from sibling tools like get_stock_technicals (which likely provides generic technicals) and evaluate_trading_signal (which evaluates a single signal) by focusing on multi-strategy consensus.
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 gives no explicit guidance on when to use this tool versus alternatives. It does not mention when-not-to-use or reference sibling tools, leaving the user to infer applicability solely from the strategy names and the Korean pharma stock qualifier.
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 full burden. It discloses the output includes six scoring components and the decision, which gives insight into behavior. However, it does not explicitly state whether this is a read-only operation, nor does it mention any permissions or side effects. This is moderate transparency but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence that conveys purpose and output. Every word is purposeful with no redundancy, making it highly concise and efficiently structured.
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 tool with two parameters and no output schema, the description is largely complete. It explains what the tool does and what the return includes (six components and a decision). It does not elaborate on the scoring methodology or parameter optionality, but given the schema coverage, it is sufficient for basic invocation.
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 both 'symbol' and 'sponsor' described adequately. The description adds no new parameter semantics; it only contextualizes the domain. Since the schema already handles parameter meaning, the baseline of 3 applies.
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 indicates the tool provides a score breakdown for a Korean pharma company, showing all 6 scoring components and the decision. While it lacks an explicit verb like 'Get' or 'Calculate,' the intent is unambiguous. The focus on 'Korean pharma company' distinguishes it from sibling tools like get_stock_technicals or evaluate_trading_signal.
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 versus alternatives. It mentions 'for a Korean pharma company' which implies a niche context, but it does not state when to prefer this over siblings like analyze_stock or evaluate_trading_signal, nor does it give conditions or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the scoring engine, the data window split (D-60~D-30 early, D-30~D-day late), and the output metrics, but does not explicitly state read-only behavior, error handling, or response format beyond the grade/metrics.
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 focused sentences: the first states the action and required inputs/outputs, the second explains the data window. No wasted words; structure is front-loaded 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?
For a 9-parameter tool with no output schema, the description covers the main inputs and window semantics plus expected output grade/return/win rate. However, it omits the optional phase parameter and does not specify the exact output structure, leaving moderate 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?
The schema already describes all 9 parameters with 100% coverage, including early/late definitions and units. The description adds the overall D-60 to D-day window concept, but mostly reiterates what the schema already provides, so it adds marginal value.
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 opens with 'Evaluate a trading signal using the 10-combo scoring engine,' clearly stating the verb and resource. It specifies the output (STRONG_BUY~AVOID grade with expected return and win rate) but does not explicitly differentiate from sibling tools like score_stock or analyze_stock.
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 when to use this tool: when you have institutional/foreign/short-selling data to evaluate a trading signal. However, it offers no explicit guidance on when to avoid it or how it compares to siblings like score_stock or get_technical_strategies.
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 transparency burden. It discloses the symbol resolution behavior, but this info is already in the parameter schema. It does not describe side effects, rate limits, return format, or any limitations. For a search tool, it is likely read-only, but that is not stated.
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 short sentences with no redundant information. It front-loads the core purpose and adds a key behavioral detail. Every word earns its place.
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 has 5 optional parameters and no output schema. The description clarifies the scope (Korean pharma, ClinicalTrials.gov) and the symbol resolution, but it does not describe the return format, error handling, or any limitations. It is adequate for a straightforward search but leaves some contextual 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 description coverage is 100%, so each parameter is well-documented. The tool description adds no additional parameter meaning beyond what's in the schema; the symbol resolution is already noted in the symbol parameter description. 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 clearly states the tool's function: searching ClinicalTrials.gov for Korean pharma company trials. It uses a specific verb ('Search'), identifies the resource and scope, and the symbol-to-sponsor resolution adds a distinguishing feature relative to sibling tools focused on stock analysis.
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 when to use the tool (when searching for Korean pharma trials) but provides no explicit guidance on alternatives or exclusions. Sibling tools are unrelated, so the purpose is clear, but there is no explicit 'use when' or 'vs alternatives' statement.
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 the burden of disclosing behavior. It states that the tool returns 'pong', which is the primary behavior. For a trivial ping tool, this is sufficient transparency, though it doesn't mention latency or side effects (which are minimal anyway).
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, using a single short sentence with a dash for clarity. Every word is purposeful, and it maintains high scannability.
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 tool's minimal complexity (no parameters, no output schema, simple purpose), the description is complete. It fully explains what the tool does and what to expect in response.
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, which is fully covered by the empty schema. The baseline for 0 params is 4, and the description adds no parameter information, but none is 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 clearly identifies the tool as a health check that returns 'pong', which is specific and differentiates it from the domain-specific sibling tools. The verb 'returns' and resource 'pong' make the action unambiguous.
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?
While there is no explicit 'when to use' statement, the health check purpose is self-evident. The description implies usage for verifying service liveness, and no alternatives are needed given the tool's simplicity. This is clear context with no exclusions.
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:

[![trading-by-clinical-trial MCP server](https://glama.ai/mcp/servers/hjsh200219/trading-by-clinical-trial/badges/card.svg)](https://glama.ai/mcp/servers/hjsh200219/trading-by-clinical-trial)

Score Badge

Copy to your README.md:

[![trading-by-clinical-trial MCP server](https://glama.ai/mcp/servers/hjsh200219/trading-by-clinical-trial/badges/score.svg)](https://glama.ai/mcp/servers/hjsh200219/trading-by-clinical-trial)

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/hjsh200219/trading-by-clinical-trial'

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