mcp-news-briefing
Server Quality Checklist
Latest release: v0.6.0
- Disambiguation4/5
The tools are mostly distinct, covering profile, sources, articles, interactions, and stock-specific features. A few pairs like set_sources/add_sources and watchlist_set/update_focus have slight overlap, but the descriptions provide enough clarity to differentiate them.
Naming Consistency3/5General tools follow a verb_noun pattern (e.g., set_profile, get_sources), but stock-related tools reverse the order to noun_verb (e.g., stock_watchlist_set, stock_alert_set). Additionally, names like interaction_summary and stock_watchlist_custom_sources deviate from a clear verb-based pattern, creating inconsistency across the set.
Tool Count2/5With 29 tools, the server has a very large tool surface. While each tool has a specific purpose, the count exceeds the typical well-scoped range and includes many narrowly-focused stock alert and history tools that could be consolidated, making it feel heavy.
Completeness4/5The toolset covers the core news briefing lifecycle—registration, profile management, sources, article fetching, interaction tracking—and includes a comprehensive stock watchlist/alert/history subsystem. However, there is no way to remove general sources (only add/set), which is a notable gap in source management.
Average 4/5 across 29 of 29 tools scored. Lowest: 2.9/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 Apache 2.0.
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.jsonto 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 carries the full burden of behavioral disclosure. It only says 'view' without specifying read-only behavior, permissions, rate limits, or return format. No additional context is provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that directly states the tool's purpose. No filler or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple tool, but without an output schema, the description does not explain what the returned details contain. It lacks context about the nature of the reading records or how they relate to other briefing tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both 'limit' and 'token' documented. The description itself adds no parameter information, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool views recent reading record details, with a specific verb and resource. It is distinct enough from siblings like briefing_log_interaction, though it doesn't explicitly contrast with them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. The description gives no context about ideal use cases, prerequisites, or exclusions.
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. It only mentions return fields but does not disclose whether the operation is read-only, how user identity (token) affects results, whether results are sorted/deduplicated, or any constraints on the returned data. The description is too sparse to give the agent confidence about 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exactly two sentences: the first states the core action, the second explains return fields and purpose. No redundant wording, no filler. It is well-structured and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and 100% schema coverage, the description is adequate but has gaps. It does not explain how the 'token' parameter affects results (user-specific articles), nor does it mention what happens when no articles exist or how date ranges work. The description refers to future filtering by Claude, but leaves out important context about user scoping.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully documents all three parameters (date, limit, token) with descriptions and defaults. The tool description adds no extra meaning beyond the schema, so the baseline score of 3 applies. The description does not clarify how these parameters interact (e.g., token scoping), but the schema already covers each parameter individually.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a list of already-fetched articles ("获取已抓取的文章列表"), specifies return fields (title, source, summary), and differentiates from sibling tools like briefing_fetch_articles by using "已抓取" (already fetched). The intended downstream use (filtering/analyzing by user preferences) is also explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The context is clear: this tool is for accessing articles that have already been fetched, implying it should be used after a fetch operation. It does not explicitly list when not to use it or mention alternatives, but the phrase "已抓取" provides sufficient usage context without requiring further elaboration.
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 full burden for behavioral transparency. It only says '分析' (analyze) without specifying the data source, whether it modifies anything, or what output format it produces. The lack of details about side effects or return type leaves an agent with significant uncertainty.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that immediately states the purpose and then gives usage triggers. It is efficiently written with no filler or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description provides enough to select the tool among many siblings and gives trigger phrases for invocation, and the schema covers parameters. However, without an output schema or annotations, the lack of details on return format and data source leaves the agent with some uncertainty about what to expect after calling.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with both 'days' and 'token' described, so the baseline is 3. The description does not add any additional parameter semantics beyond what the schema provides, so it neither enhances nor detracts from parameter clarity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '分析用户最近的阅读兴趣趋势' (analyze user's recent reading interest trends). It uses a specific verb plus resource and differentiates from sibling tools like briefing_view_log or briefing_get_articles by focusing on trend analysis. The trigger phrases also help distinguish this from raw log retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit trigger conditions: '用户说「我最近关注了什么」「这周看了些啥」等时调用' (call when the user says these phrases). This gives clear context for when to use the tool, though it does not mention alternative tools or when not to use it, which prevents a top score.
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 full burden of disclosure. It reveals that using this tool involves calling other tools (briefing_stock_alert_trigger, briefing_stock_history_record), performing web searches, deduplicating events, and following strict tone guidelines. It also implies side effects like recording history and triggering alerts, which is far more transparent than a typical tool description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely long, with 12 numbered steps and redundant stylistic instructions (e.g., multiple examples of forbidden phrasing). While it's front-loaded with purpose, the sheer verbosity makes it less concise. Several instructions could be condensed without losing value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the lack of output schema and annotations, the description is remarkably complete for a complex analytical tool. It covers sentiment labeling, alert checking, event deduplication, presentation ordering, summary, divergence detection, and tone restrictions. The only gap is that it doesn't describe the exact structure of the returned news list, but the workflow makes it largely inferable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters (date, limit, token, ticker) are already well-documented. The description adds no additional meaning for these parameters—it doesn't mention them at all. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with a clear verb+resource: '获取已抓取的股票新闻列表' (get fetched stock news list) and states its core purpose '帮用户提前看到风险' (help users see risks early). This clearly distinguishes it from siblings like briefing_get_articles or briefing_stock_fetch, which are more about raw retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a detailed 12-step workflow for how to use the returned data (analyze, label sentiment, verify, check alerts, trigger, record history, etc.), giving strong implied usage context. However, it never explicitly mentions when to use this tool versus alternatives like briefing_get_articles or briefing_stock_fetch, nor does it state exclusions or preconditions.
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 for behavioral disclosure. It only states the action without covering side effects, persistence, authentication requirements, or error behavior, leaving significant transparency gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with useful trigger examples and no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and schema coverage is complete, but the description lacks behavioral details (e.g., what happens after removal, whether it affects the default profile) and there is no output schema. It is minimally complete but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully describes both parameters with 100% coverage, so the description adds no additional parameter meaning. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool removes stocks from a watchlist ('从关注列表中移除股票') and provides concrete trigger phrases, making its purpose unambiguous and distinguishing it from sibling watchlist get/set tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Examples of user intents ('不看 AAPL 了', '把 CBA 从 watchlist 删掉') clearly indicate when to invoke the tool, but it does not explicitly mention alternatives or when not to use it.
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?
Annotations are absent, so the description must disclose behavioral traits itself. It states that it recommends based on '兴趣偏好' (interest preferences) but does not clarify whether this is a read-only operation, how it uses the token, whether it modifies user settings, or what the response format looks like. This lack of side-effect disclosure is a significant gap 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, with the first stating the core purpose and the second giving usage triggers. It is front-loaded, concise, and contains no fluff or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one optional parameter, no output schema, no annotations), the description covers its purpose and usage triggers adequately. However, it omits what the tool returns (e.g., a list of sources) and any note about read-only behavior, which would be valuable in the absence of an output schema and annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%: the only parameter 'token' has a description ('用户token或用户名。留空则自动使用默认身份。'). The tool description adds no additional meaning about parameters beyond the schema, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: '根据用户的兴趣偏好推荐新闻来源' (recommend news sources based on user interests), including specific source types (RSS, Reddit, Hacker News). The verb '推荐' (recommend) distinguishes this from sibling tools like briefing_set_sources and briefing_add_sources, which manage sources rather than suggest them. This makes the tool's purpose 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit trigger examples: '用户说「帮我推荐信源」「有什么好的订阅推荐」等时调用' (call when the user says 'help me recommend sources' or 'any good subscription recommendations'). This gives clear context for when the tool should be invoked, though it does not mention when not to use it or alternative tools for other scenarios.
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 full responsibility. It discloses that it fetches from subscribed sources and explains the hours_back semantics, but it does not describe authentication needs, rate limits, output format, or behavior when no sources are available. This is a moderate level of 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: the first sentence states the main purpose, the second gives usage triggers and time range mappings. Every sentence earns its place, with no redundancy, and it is front-loaded with the most important information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 optional params, no output schema), the description covers the essential context: purpose, trigger phrases, and time range semantics. However, it does not explain how this tool differs from the similar sibling 'briefing_get_articles' or what the return data looks like, which is a minor gap for a no-output-schema tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds little beyond the schema—it repeats the hours_back mapping (24=今天, 168=本周, 720=本月) already present in the parameter description. The token parameter is not elaborated further, so the description provides no additional meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches latest content from subscribed news sources and gives example user utterances ('看看今天的新闻', etc.). It uses a specific verb and resource, but does not differentiate from the sibling tool 'briefing_get_articles', so it loses a point for lacking sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says to call this tool when users ask about today's news, recent highlights, or weekly briefings, and maps time ranges (24=今天, etc.). It provides clear context for when to use but does not mention alternatives or when not to use it, so it falls short of a 5.
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 only mentions switching the default identity but does not explain side effects, persistence, permissions, or reversibility. For a mutation tool, this lack of detail leaves significant behavioral ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that immediately states the action and provides example user triggers. It is concise and free of unnecessary detail, earning high marks for structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter setter with no output schema, the description adequately covers purpose and usage triggers. However, it lacks behavioral details (e.g., whether the change is permanent) which slightly reduces completeness relative to richer tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description covers 100% of the parameter ('token'), explaining it is the token or username to set as default. The tool description adds no additional parameter semantics, 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/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool switches the default identity, with specific trigger phrases that distinguish it from sibling tools like briefing_set_profile. It uses a specific verb ('切换') and resource ('默认身份'), making the purpose 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit user phrases that should trigger this tool, giving clear context for when to use it. However, it does not mention alternatives or situations where this tool should not be used, which would warrant a higher score.
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 behavioral traits. It only states the action and usage examples, but omits whether the dismissal is permanent, requires ownership, or what result is returned. This lack of detail is risky 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that front-loads the verb and includes practical user examples. It is concise with zero redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 2-parameter tool with full schema coverage, the description provides enough context to understand purpose and when to trigger. However, it lacks information about return values or error cases, which is a minor gap given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both 'alert_ids' (list of alert IDs to close) and 'token' (user token or username). The description adds no semantic value beyond the schema—it simply restates the action that maps to alert_ids.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states '关闭一条或多条预警' (close one or more alerts), identifying both the action and resource. It clearly distinguishes this dismiss tool from sibling alert operations like set, update, list, and trigger.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides concrete trigger examples ('第 3 条关了吧', '关掉那个预警') and instructs to invoke when the user expresses such intents. While it doesn't explicitly mention alternatives, the examples give clear contextual guidance.
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 present, so the description must carry the burden of behavioral disclosure. It discloses that a token is returned and that later the token or username can be used for identification, which is useful. However, it does not state side effects such as whether a profile is created, whether registration is idempotent, or whether any user data is persisted beyond the token.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loaded with the action and trigger phrases. Every sentence adds information: the first states the purpose, the second explains the return value and its future use. There is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (one optional parameter, no output schema), the description covers the essential points: when to call, what it does, and what it returns. It could be more complete by clarifying how this tool relates to sibling tools like briefing_create_profile_interactive, but for a simple registration flow it is largely sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is simple and fully documented, with 'name' described as optional. The description adds semantic value by stating that the username can later be used for identification ('后续可以用token或用户名识别身份'), which goes beyond the raw schema. This clarifies the practical role of the only parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states '注册新闻简报服务' (register news briefing service), using a specific verb and resource. It also provides example user utterances, making the tool's purpose evident. However, it does not explicitly differentiate from a sibling tool like briefing_create_profile_interactive, which may perform a similar registration-like action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear when-to-use context: '用户说「帮我注册」「我想开始用简报」等时调用' (call when the user says 'help me register' or 'I want to start using briefing'). This tells the agent exactly when to invoke the tool. It does not mention when not to use it or list alternative tools, stopping short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that existing custom sources are preserved, which is a useful side-effect. However, it does not state whether existing category-based subscriptions are overwritten, which is a key behavioral trait for a 'set' operation. With no annotations, this gap matters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loaded with the primary action and followed by a critical preservation note. No unnecessary wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the trigger condition and preservation of custom sources, but lacks critical details such as whether previous category subscriptions are replaced, what the return value looks like, or error handling. Given no output schema, this is a notable gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with both parameters clearly described. The description adds little beyond the schema, only reinforcing that category_ids are the categories to subscribe to. This meets the baseline but does not add extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action '按分类订阅新闻来源' (subscribe to news sources by category) and provides the specific trigger context ('after user confirms recommended sources'), which distinguishes it from sibling tools like briefing_add_sources or briefing_suggest_sources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says to invoke this tool after user confirmation of recommended sources, tying it to the recommendation workflow. It does not mention when NOT to use it or explicitly name alternatives, but the usage context is well implied.
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 full responsibility for behavioral disclosure. It notes the conditional ticker behavior and the post-fetch pipeline, but does not state whether the operation is read-only, what the return payload is, or any side effects/authentication requirements beyond schema info.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two compact sentences, front-loads the core purpose, and includes trigger phrases and the follow-up call without wasted words. Every clause adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description should cover more ground. It explains role, triggers, and next step, but omits return format, persistence, error handling, and other caveats. It is adequate for a simple fetch, but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All parameters have schema descriptions (100% coverage), so the baseline is 3. The description adds a bit by reinforcing the 'no tickers = whole watchlist' behavior, but largely repeats schema content without deeper semantics for token or hours_back.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches the latest news for followed stocks, using a specific verb and resource. It also provides example user intents and implicitly distinguishes itself from siblings by focusing on the watchlist and pairing with briefing_stock_digest.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit trigger phrases are provided, and the behavior with/without tickers is clearly explained. It also gives a follow-up action (call briefing_stock_digest), but does not explicitly name alternative tools or exclusion criteria, so it falls short of a 5.
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 behavioral disclosure burden. It implicitly indicates a read-only operation with '查看' (view), which is useful, but it lacks details on return format, pagination, or behavior when there are no sources. Given the tool's simplicity, this is minimally adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the main purpose and trigger examples. It 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.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one optional parameter and no output schema. The description implies the tool returns the list of subscribed sources ('查看...哪些新闻来源') but does not explicitly describe the output structure or how the token parameter affects the result. This minor gap prevents a perfect score, but overall the description is sufficient for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter (token) has a complete description in the schema, so the schema covers 100% of parameter semantics. The description adds no additional parameter information, hence the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (查看/view) and the resource (当前订阅的新闻来源/currently subscribed news sources), and includes example user queries that trigger this tool. This distinguishes it from sibling tools like briefing_set_sources and briefing_add_sources, which modify subscriptions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit trigger phrases ('我现在订阅了什么', '看看我的信源') indicating when to call this tool. However, it does not explicitly mention when not to use it or name alternative tools, so it stops short of a 5.
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 provided, the description carries the full burden. It discloses the auto-trigger behavior and the purpose (interest trend analysis), but does not mention side effects, authorization requirements, or return behavior. This is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary purpose, and contains no redundant text. Every sentence contributes to understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple logging tool with a well-documented schema, the description provides sufficient context about when and why it is used. It could mention return behavior or how logged data is stored, but these are not critical given the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description does not add parameter details beyond what the schema already provides, but it aligns the action values with user behaviors mentioned in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool records user reading behavior ('记录用户的阅读行为'), with a specific verb and resource. It also enumerates triggering actions (expand news, discuss, save), which differentiates it from sibling tools like briefing_interaction_summary or briefing_view_log.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says when the tool is called ('当用户展开某条新闻、深入讨论、或收藏时，自动调用'), providing clear context. It does not mention alternatives or when not to use it, but the auto-call triggers are sufficient for this logging tool.
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 the return fields ('状态、触发次数、剩余时间') and implies read-only behavior via '查看', but it does not explicitly state that it is safe/non-destructive, nor does it explain authentication defaults or whether the token parameter is required. The description adds value but lacks complete 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose, and includes practical example phrases. Every word earns its place, with no redundancy or irrelevant details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with 3 optional parameters and no output schema, the description covers the key invocation scenarios and the return contents. It lacks explicit mention of default token handling or result ordering, but these are minor gaps given the simplicity and the schema's coverage. Overall, it is adequately complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each parameter (token, status, ticker) having a clear description. The tool description adds little beyond the schema—it mentions filtering by ticker and status only through examples, which the schema already provides. The baseline of 3 is appropriate since the schema already does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '查看预警列表' (view alert list), with a specific verb and resource. It also provides example user utterances ('我设了哪些预警', 'AAPL 的预警') that map to real invocation scenarios, and the sibling tools (set/update/dismiss/trigger) are distinct actions, making this list tool 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives concrete usage context with example user phrasings, indicating when to call this tool. It does not explicitly mention when not to use it or name alternatives, but the sibling tool names and the clear list-focused purpose provide sufficient guidance for an agent to select it appropriately.
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 full burden, but it only states what fields can be modified and gives trigger phrases. It does not disclose whether the update is partial or full, what happens to unspecified fields, any side effects, or return behavior. This is a mutation tool, so the lack of behavioral detail is a notable 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loading the core purpose and then providing trigger examples. Every sentence is purposeful, with no redundant or filler content. It is concise and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 8 parameters and no output schema, but the description covers the essential selection criteria and user intents. It does not mention edge cases, error handling, or the effect of leaving fields unspecified, but for an update tool, the primary context (modifying an existing alert) is clear from the description and the parameter schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds value by mapping natural-language examples to parameters: 'strict' maps to sensitivity, '延长 3 个月' maps to extend_months, and '加个关键词' maps to add_keywords. This helps the agent translate user intent into parameter values beyond the bare schema definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool modifies an alert's tightness, time window, description, and keywords, clearly identifying the action and resource. The examples ('改成 strict', '延长 3 个月', '加个关键词') make the scope concrete and distinguish it from sibling tools like set (create) and dismiss.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly lists user phrasings that should trigger this tool, e.g., '那条预警改成 strict', '延长 3 个月', '加个关键词', which serves as clear when-to-use guidance. It does not name alternatives or exclusions, but the examples effectively convey the update context versus create/dismiss siblings.
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 must carry the behavioral burden. It uses '查看' (view) which implies a read-only operation, and it specifies the returned content (list and focus configuration). However, it doesn't disclose any other behavioral traits such as authentication defaults, error handling, or side effects, which are absent but also not surprising for a get 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly concise, comprising two sentences: one stating the function and one giving usage triggers. Every sentence is purposeful and front-loaded, with no extraneous content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with one parameter and no output schema, the description adequately covers what the tool returns and when to invoke it. It doesn't specify the response structure, but that's not necessary given the simplicity and the absence of an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100% for the single parameter 'token', which already explains its meaning and default behavior. The tool description adds no additional parameter semantics, 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/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: to view the list of followed stocks and their focus configurations. It uses a specific verb ('查看' = view) and resource ('关注的股票列表'), and it distinguishes this from sibling tools like set, remove, and update_focus.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit trigger phrases ('用户说...等时调用') for when to use the tool, making the usage context clear. However, it doesn't explicitly mention when not to use it or name alternative tools for modification, though the siblings are obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the transparency burden and does well by disclosing the auto-recommend flow, return of recommendations for confirmation, and the optin consent/notice requirement. It doesn't describe whether updates overwrite or merge existing data, but overall it provides meaningful 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded with purpose and trigger phrases. The three short paragraphs each earn their place, though the sector value list could have been left to the schema. It's efficient without being terse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 parameters, no output schema, and no annotations, the description covers the key context: when to call, what happens with optional fields, and the consent flow for optin_sources. It doesn't specify the full return format beyond the focus recommendation, but this is adequately complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds value beyond the schema by explaining the behavior when 'focus' is omitted, clarifying that 'optin_sources' requires explicit user request, and listing common sector values. This meaningfully supplements the parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states '添加或更新关注的股票' (add or update watched stocks), which is a specific verb plus resource. It provides concrete user trigger phrases that distinguish this from other watchlist tools, though it doesn't explicitly differentiate from the sibling 'briefing_stock_watchlist_update_focus'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit trigger examples ('帮我关注苹果', '加一只股票') and states when to call. It also explains conditional behavior for empty focus and optin_sources, including the requirement for explicit user consent. However, it doesn't mention when NOT to use this tool versus alternatives.
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 full burden. It discloses key behavioral traits: partial updates ('只传需要更新的字段，其他保持不变') and the impact on news filtering ('兴趣偏好是新闻过滤的核心依据'). This goes beyond a basic 'update profile' statement and gives meaningful context. It could further explain replace-vs-append semantics for arrays, but the disclosed behaviors are valuable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded: it states the purpose, gives usage triggers, and explains update semantics in two sentences. Every sentence carries useful information with no redundancy or irrelevant details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a setter tool with no output schema, the description covers the core context: what it does, when to use it, and its impact. It lacks details like the optional 'token' parameter semantics (though schema covers it) and any prerequisites (e.g., user must be registered). However, given moderate complexity, it is sufficiently complete for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds semantic value beyond the schema by explaining that only changed fields need to be passed, which is not evident from the schema alone. It also maps user intents to the 'profile' parameter, enriching parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '设置或更新用户的兴趣偏好' (set or update user's interest preferences). It provides specific trigger phrases like '我想关注XX' and '不想再看XX', making the intent clear. However, it does not explicitly distinguish itself from the sibling tool briefing_create_profile_interactive, which likely handles similar profile creation functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit examples of when to invoke the tool (when user says they want to follow/add interest/avoid content) and instructs to pass only changed fields, which is a clear usage rule. It does not mention when not to use it or alternatives like briefing_set_sources, so it lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It does explain the sentiment_score calculation formula and the automatic invocation, which is useful. However, it omits potential side effects like whether the record is appended or overwritten, auth requirements, or behavior on manual invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences plus a formula. It front-loads the core purpose, mentions the trigger, and then gives the scoring rule. No unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 9 parameters, nested objects, and no output schema, the description provides essential scoring context and trigger. However, it does not mention return values, idempotency, or error scenarios, which would be expected given no annotations and no output schema. It is adequate but leaves gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds meaning by explaining the weighted-average formula for sentiment_score using emoji levels, which is not fully captured in the schema. It also ties the parameters to the digest workflow, providing context beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool records a daily sentiment snapshot for a stock, with a specific verb and resource. It also distinguishes itself from sibling tools like briefing_stock_history_get by mentioning it is automatically called after briefing_stock_digest. This makes the purpose 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states the tool is automatically invoked after briefing_stock_digest completes, providing a clear usage context. However, it does not explicitly say when not to use it or name alternatives, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the key behavioral trait that sources are appended and not overwritten, which is important side-effect information. It lacks details on authentication, duplicate handling, or return values, but the core behavior is clearly 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the main action and append behavior. It is concise with no filler, and every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 4 optional parameters fully described in the schema, and the description covers purpose, append behavior, and usage examples. Without an output schema, it sufficiently prepares the agent for invocation. A minor gap is not mentioning the hn_keywords parameter in examples or explicit alternative tool usage, but overall it is complete enough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description's examples map to rss and reddit parameters, but it does not add extra meaning beyond what the schema already explains. No additional parameter context is provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool adds custom news sources with a specific verb ('添加') and resource ('自定义新闻来源'). It also clarifies the append behavior ('追加，不会覆盖已有的'), which distinguishes it from sibling tools like briefing_set_sources that likely replace sources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Clear trigger examples are provided ('帮我加一个RSS', '我还想看XX的Reddit'), indicating when to call. However, it does not explicitly exclude scenarios or mention alternative tools like briefing_set_sources, relying on the append-vs-overwrite distinction to imply the appropriate context.
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 provided, the description bears full responsibility for behavioral disclosure. It reveals that the tool returns guidance questions, collects responses, and then invokes briefing_set_profile, making the multi-turn and delegation behavior transparent. It does not mention failure handling or cancellation, but covers the essential interaction pattern.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences that front-load the purpose and trigger conditions, followed by the behavioral outcome. Every sentence earns its place, with no redundant details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an interactive tool with no output schema, the description sufficiently explains the workflow: trigger phrases, the Q&A nature, returning questions, and the subsequent call to briefing_set_profile. It could include more details about the question format or fallback behavior, but the provided context is adequate for an agent to understand and invoke the tool appropriately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already has 100% description coverage for the single 'token' parameter, explaining it can be empty. The tool description adds no extra semantic context about this parameter. Per the rubric, when schema coverage is high, the baseline score is 3; no additional value is provided here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool gathers user interest preferences through interactive Q&A. It uses a specific verb+resource ('understand user's interest preferences') and distinguishes itself from the sibling briefing_set_profile by indicating that this tool handles the interactive collection phase before delegating submission to briefing_set_profile.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to invoke the tool, providing example user utterances ('帮我设置偏好', '重新设置我关注的内容'). It also implies the flow: collect answers then call briefing_set_profile. However, it does not explicitly mention when NOT to use this tool (e.g., if preferences are already known), so it lacks an exclusion clause.
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, description carries the burden. It discloses return content ('关注领域、当前项目、不想看的内容等') and implies read-only behavior via '获取' ('get') and '读取' ('read'). This adds context beyond schema, though it omits error handling or auth specifics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: first states the core purpose, second gives usage context. Every word earns its place, with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, but description summarizes the return types (focus areas, projects, disliked content). Combined with usage guidance, this is sufficient for a simple get tool with one optional parameter; it lacks only deeper details like pagination or error cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers the token parameter with 100% description coverage, setting baseline at 3. The tool description does not mention the token parameter, adding no additional semantic value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description states '获取用户的兴趣偏好' (get user's interest preferences) and lists example fields (关注领域、当前项目、不想看的内容), clearly identifying it as a profile retrieval tool. The '获取' verb and specific resource distinguish it from sibling set_profile/create_profile tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to read before analyzing news ('在分析新闻前应先读取，作为筛选依据'), providing clear timing and purpose. However, it does not mention when not to use or name alternative tools, so it lacks explicit exclusions.
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, so the description carries the full burden. It clearly states the core behavior (toggle daily auto-fetch) and the daily nature is disclosed. However, it does not mention side effects, persistence, or return value, which is a slight gap but not critical for a simple toggle.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized: the first sentence states the core purpose, and the second provides practical usage guidance. It is front-loaded and contains no wasted words, though the second paragraph is somewhat dense.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose and usage triggers well, but it does not mention the return value (no output schema) nor clarify whether the setting is per-user (given the token parameter). This leaves some gaps for a complete understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the schema already clearly describes both parameters (token and enabled). The description does not add any extra semantic context 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/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: enabling or disabling daily automatic stock news fetching. The verb+resource combination is specific and distinguishes it from sibling tools like manual fetch (briefing_stock_fetch) and alerts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit user utterance examples for when to invoke the tool and also describes a proactive scenario (when the user first adds stocks via watchlist_set). This is strong, concrete guidance with no ambiguity.
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 must carry the full burden. It discloses the three modes (add, remove, view) and the placeholder replacement behavior, but does not mention potential side effects (e.g., persistence), required permissions, or whether actions are reversible. This is adequate but lacks depth 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a compact, well-organized paragraph. It front-loads the core purpose, then explains parameter behavior and placeholder support without any redundant filler. Every sentence contributes useful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 4 parameters, 1 required, and no output schema, the description covers the main use cases and parameter interactions. It lacks an explicit note about the return value or output format, but for a simple management tool, the provided context is sufficient. Sibling tools are not referenced, but the trigger phrases help disambiguate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, giving a baseline of 3. The description adds value by explaining the semantics of omitting both add_urls and remove_urls (view mode) and the placeholder substitution for {ticker} and {company}, which is not obvious from the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool manages custom RSS sources for a specific stock, with a specific verb ('管理') and resource ('某只股票的自定义信源'). It distinguishes itself from sibling tools by focusing on per-stock custom sources and provides concrete example user utterances that trigger it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to call the tool with example user phrasings, and explains that omitting add_urls and remove_urls results in viewing the current list. However, it does not mention when not to use it or contrast with alternative tools like briefing_add_sources or briefing_get_sources, which slightly reduces clarity.
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 provided, the description carries the transparency burden. It discloses that add and remove operations can be combined and lists all valid focus-area IDs, which is valuable behavioral context. However, it does not explain side effects, whether the stock must already be on the watchlist, or what the response looks like, leaving some ambiguity 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: the first sentence states purpose, the second provides usage nuance, and the third lists valid values. Every sentence earns its place, with no fluff or repetition of schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple update tool with full schema parameter coverage and no output schema, the description is largely complete: it covers purpose, trigger scenarios, parameter behavior, and valid IDs. It could be improved by stating whether the stock must already exist in the watchlist or what the tool returns, but these are minor gaps 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/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description adds meaningful semantics beyond the schema: it clarifies that add_focus and remove_focus are ID lists that can be passed simultaneously, and it enumerates all valid IDs (executive_trades, earnings, etc.) that are not defined as enums in the schema. The trigger examples also map user intent to specific parameter usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('调整' / adjust) and resource ('某只股票的关注侧重面' / a stock's focus areas), and provides real user utterances ('AAPL 不看供应链了', 'CBA 加上分析师评级') that make the tool's purpose immediately identifiable. It clearly distinguishes this from sibling watchlist tools, which handle broader watchlist set/get/remove operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to call the tool: '用户说...等时调用' (call when user says...), giving concrete trigger examples. It also explains that add_focus and remove_focus can be passed together, but it does not explicitly state when not to use this tool or mention alternative tools.
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 provided, the description carries the burden of behavioral disclosure. It adds value by stating the 10-alert limit per stock, the generic-alert behavior when ticker is omitted, and the requirement to confirm with the user before creation. It does not detail potential side effects like overwriting existing alerts, but the primary creation behavior is transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is moderately sized but well-organized: the first paragraph states purpose and key constraints, the second describes the workflow, and the third gives presentation guidelines. Each sentence serves a purpose, though it could be slightly more compact.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a creation tool with no output schema and nested alert objects, the description provides sufficient context: when to call, how to handle analyst reports, constraints, and even phrasing guidance for user communication. It omits return-value details, which are not critical for a create operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage for all four parameters. The description adds the key decision rule that omitting ticker creates a generic alert and that scope is only used in that case, plus the 10-alert limit. This enhances the schema's parameter descriptions without being redundant.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with '批量创建预警' (batch create alerts), clearly stating the verb and resource. It further distinguishes this tool from siblings by noting it supports batch creation, manual creation, and generic alerts without a ticker, setting it apart from list/update/dismiss/trigger tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit when-to-use scenarios: after an analyst report is pasted, the agent extracts concerns and calls this tool; or manual creation. It also instructs to present extracted concerns to the user for confirmation before calling. While alternatives are not explicitly named, the workflow and constraints (max 10 alerts, generic alert when no ticker) provide clear usage context.
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?
No annotations are provided, so the description carries the full burden. It thoroughly discloses the tool's internal dedup logic (checks trigger_history for dates within ±3 days), the possible return states (near_date_found + near_entries vs new_trigger), and the expected follow-up actions. It even includes notification tone guidelines, providing rich behavioral context beyond a basic API description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but structured as a numbered list of steps, each sentence earning its place. It is front-loaded with the core purpose and then flows naturally into usage. No filler or redundant content; every detail supports the tool's complex dedup behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having no output schema, the description explicitly enumerates the possible return values (near_date_found + near_entries, new_trigger) and prescribes how to handle each. It also covers parameter semantics, workflow, and even stylistic guidance for notifications, making the description fully self-sufficient for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds meaningful workflow context: it explains that event_date is the date the event actually occurred (not the publication date), that event_signature is required on first call, and it interprets the action enum values. This goes beyond the schema's field-level descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a clear statement of the tool's function: '记录预警触发 + 事件级去重' (record alert trigger + event-level dedup). It also specifies the precise context for invocation: during briefing_stock_digest analysis when a news item matches an alert. This clearly distinguishes it from sibling tools like briefing_stock_alert_set or briefing_stock_alert_update.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage context ('在 briefing_stock_digest 分析过程中发现新闻命中 alert 时调用') and a detailed step-by-step workflow explaining how to react to different return values, including the decision to append_duplicate or confirm. However, it does not explicitly state when not to use the tool or mention alternative tools, so it stops short of a perfect 5.
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?
With no annotations provided, the description carries the full burden and covers data_status semantics, required follow-up actions for incomplete snapshots, and strict output tone constraints (no predictions, no judgement words). It makes the tool's non-obvious behavior explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but appropriately structured with a purpose-first opening, example triggers, a bulleted data-status contract, and a clear section on tone constraints. Every segment adds necessary operational detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description explains all key return values and behavior, including the raw_only/missing recovery workflow, so an agent can invoke the tool and handle incomplete data correctly. The only minor gap is the exact shape of the divergence detection result, but the workflow is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already defines ticker, days, and token. The description only maps '最近一周' to the days parameter and does not add materially new syntax or format details beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource phrase '查看某只股票的历史情绪趋势' and specifies the returned data (daily sentiment score, close price, change, divergence detection). It provides user trigger examples, which clearly differentiates this historical trend view from sibling tools like stock_digest or history_record.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly defines when to call (user asks 'AAPL 最近一周情况怎么样', etc.) and includes a conditional workflow for raw_only/missing data that names the exact alternative tools to invoke (briefing_stock_digest and briefing_stock_history_record). This is strong when-to-use guidance with concrete alternatives.
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:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/AmyYingTang/mcp-news-briefing'
If you have feedback or need assistance with the MCP directory API, please join our Discord server