Skip to main content
Glama

Zhiji Daily Report — Market Brief

Server Details

Daily A-share market brief with LG phase signals. No auth required.

Status
Healthy
Last Tested
Transport
Streamable HTTP
URL

Glama MCP Gateway

Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.

MCP client
Glama
MCP server

Full call logging

Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.

Tool access control

Enable or disable individual tools per connector, so you decide what your agents can and cannot do.

Managed credentials

Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.

Usage analytics

See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.

100% free. Your data is private.
Tool DescriptionsB

Average 3.2/5 across 5 of 5 tools scored.

Server CoherenceA
Disambiguation4/5

Most tools have distinct purposes: arena-signal for global markets, phase-signal for A-share, ji-sensing for SoTI. However, daily-brief and signal-latest both aggregate multiple signals, creating potential confusion despite different descriptions.

Naming Consistency5/5

All five tools follow a consistent hyphen-separated lowercase pattern (e.g., arena-signal, daily-brief). The naming convention is uniform and predictable.

Tool Count5/5

With 5 tools, the server is well-scoped for a daily report domain. Each tool covers a specific aspect without being excessive or insufficient.

Completeness4/5

The tool set covers the main areas: global signals, A-share phase, SoTI, and aggregate reports. Minor gaps exist, such as lack of individual index queries or historical data, but the core daily reporting needs are met.

Available Tools

5 tools
arena-signalBInspect

Global market phase signal from Signal Arena (CN/HK/US markets).

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden for behavioral disclosure. It only states the tool provides a signal, with no details on data freshness, side effects, authentication requirements, or output nature. This is insufficient for informed agent selection.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence that front-loads key information (global, market, phase signal, regions). Every word adds value with zero waste.

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?

While the tool is simple (no parameters, no output schema), the description lacks explanation of what a 'phase signal' means or what format the output takes. This gap may hinder agent understanding, but the brevity is somewhat justified by 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?

No parameters exist in the schema, so the description does not need to add parameter-level meaning. Baseline of 4 applies as the tool is correctly represented as requiring no input.

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 it provides a global market phase signal for CN/HK/US markets. It specifies the source (Signal Arena) and scope, making the purpose clear. However, it does not differentiate from sibling tool 'phase-signal', which may serve a similar function.

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 usage guidance is provided. The description does not indicate when to use this tool over alternatives like 'phase-signal' or 'signal-latest', nor does it specify prerequisites or exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

daily-briefBInspect

Aggregated daily brief combining phase_signal + ji_sensing + indices.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, and the description is minimal. It does not disclose behavioral traits such as data freshness, caching, or size limits, beyond stating it is an aggregation.

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 concise and to the point, with no wasted words.

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 description is incomplete for a tool that presumably has an output. It mentions three components but does not describe the output format or what 'indices' means. Without an output schema, more context is needed.

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, so the schema coverage is 100%. The description adds no additional parameter meaning but that is acceptable given the lack of parameters. Baseline of 4 applies per rubric.

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's an aggregated daily brief combining phase_signal, ji_sensing, and indices. It clearly identifies the resource and distinguishes from sibling tools that are individual signals.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus the sibling tools (arena-signal, ji-sensing, phase-signal, signal-latest). No when-to-use or when-not-to-use information is provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

ji-sensingAInspect

System of Thought Integration (SoTI) measurement — frozen/comfort/creative_edge zone detection.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided. Description does not disclose behavioral traits like read-only, destructive, or side effects. It only states the measurement purpose without behavioral 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?

Single sentence, front-loaded with the acronym and expansion, then lists zones. No unnecessary words, efficient and clear.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Adequate for a zero-parameter tool with no output schema. But lacks explanation of what SoTI is or what the zones mean, which could aid agent comprehension. Sibling tools suggest broader context is available.

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?

Input schema has zero parameters, so schema coverage is 100%. Baseline is 4. Description adds meaning by explaining the tool's purpose (measurement and zone detection), which is useful despite no params.

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 measures System of Thought Integration (SoTI) and detects frozen/comfort/creative_edge zones. It uses a specific verb ('measurement') and a distinct resource, differentiating it from sibling tools like arena-signal or phase-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?

No guidance on when to use this tool versus alternatives such as phase-signal or signal-latest. Missing context about the appropriate scenario for measuring SoTI vs other signals.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

phase-signalBInspect

A-share HS300 phase transition signal (Phi, D, chi, delta_F, SoTI, state). Real-time Landau-Ginzburg framework analysis.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so the description must carry full behavioral disclosure. It mentions 'Real-time Landau-Ginzburg framework analysis' implying a computational process, but does not specify read-only nature, latency, data dependencies, or any side effects. Insufficient for an agent to understand behavioral 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?

Description is a single sentence, efficiently conveying the core purpose and signal components. No extraneous words; front-loaded with the key information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no parameters, no output schema, and the tool's complexity (financial signal analysis), the description is somewhat complete but lacks details about output format, usage context, or how the signal is delivered. For a specialized tool, more context would help an agent decide when to invoke it.

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 tool has zero parameters, and schema description coverage is 100% (since no params). The description adds value by listing the signal components (Phi, D, chi, etc.), providing meaning beyond the empty schema. However, it does not explain the format or interpretation of these components, so baseline 3 is appropriate.

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 provides 'A-share HS300 phase transition signal' with specific components (Phi, D, chi, etc.), distinguishing it from sibling tools like 'signal-latest' which likely provide different signals. It uses a specific verb implied by the noun 'signal' but does not explicitly say 'generates' or 'returns', slightly reducing clarity.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus siblings such as 'arena-signal' or 'ji-sensing'. No mention of alternative tools or contexts where this signal is appropriate or not. The description lacks any usage direction.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

signal-latestBInspect

Complete signal payload including phase_signal + ji_sensing + indices. Single-call convenience endpoint.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

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 behavioral traits. The description only mentions the payload content and convenience, but does not specify whether the operation is read-only, destructive, requires authentication, or has rate limits. For a tool that likely performs a read operation, this lack of transparency is a significant gap.

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 consists of two short sentences that immediately convey the tool's purpose and key differentiator. There is no extraneous information, and the most important point (what the tool returns) is presented first. 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?

Given the tool's simplicity (no parameters, no output schema), the description provides the essential information about the payload composition. However, it lacks clarity on what 'latest' means (e.g., by timestamp or some other criterion) and does not describe the output format or any typical behaviors. It is minimally adequate but could be more 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 the schema coverage is 100% by default. According to the guidelines, this yields a baseline score of 4. The description does not need to add parameter-level information since there are none, so it adequately handles this dimension.

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 returns a 'complete signal payload' that includes specific components (phase_signal, ji_sensing, indices) and distinguishes itself as a 'single-call convenience endpoint' compared to sibling tools like phase-signal and ji-sensing. However, it lacks an explicit verb like 'retrieve' or 'get', and the differentiation from siblings could be more direct.

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 implies that this tool is a convenient alternative to calling multiple individual tools (phase-signal, ji-sensing) by calling it a 'single-call convenience endpoint'. However, it does not explicitly state when to use this tool versus alternatives, nor does it provide any 'when not to use' guidance or prerequisites. The guidance is minimal.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Discussions

No comments yet. Be the first to start the discussion!

Try in Browser

Your Connectors

Sign in to create a connector for this server.

Resources