NewzAI News MCP server
Server Details
The only News based AI MCP your agents will ever need — custom categories, global regions, and time-scoped results in one tool. We use multi-vector & sparse-hybrid search to search through thousands of articles across the world to find the exact news you're looking for.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.1/5 across 10 of 10 tools scored. Lowest: 3.5/5.
Tools are mostly distinct with clear purposes. get_news_by_category and search_news both return full details but differ in input (predefined category vs free-form). get_news_headlines is explicitly for headlines only, and get_news_by_preference uses saved filters. Slight overlap but descriptions help differentiate.
All tools use snake_case and follow a consistent verb_noun pattern (get_*, set_*, update_*, search_). This makes the tool set predictable and easy for an agent to navigate.
10 tools is well-scoped for a news server: it covers news retrieval (headlines, category, search, full article, related) and user preferences management (CRUD-like). Not excessive or insufficient.
Covers main operations but has notable gaps: no delete_user_preferences (update only appends), no get_user_settings (only set is available). These omissions could lead to dead ends in user management workflows.
Available Tools
10 toolsget_full_articleARead-onlyInspect
Fetches the full article content for a given news item ID. Returns the complete text of the article along with metadata such as title, source, and publication date.
| Name | Required | Description | Default |
|---|---|---|---|
| news_id | Yes | ID of the news item to fetch the full article for | |
| language | No | Output language code for the article content (e.g., 'en' for English). It is not a filter — the article may be in its original language or translated. | en |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description does not add behavioral traits beyond the annotations (readOnlyHint=true, destructiveHint=false). It mentions the return of metadata like title, source, and publication date, which is mildly helpful but does not disclose error handling, rate limits, or side effects. Annotations already cover safety, so no contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no unnecessary words. It efficiently conveys the tool's purpose and output. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description adequately covers the return value. It does not discuss constraints like article existence or language translation behavior, but it is sufficient for a simple fetch tool with clear annotations. Slight deduction for missing usage guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides descriptions for both parameters (news_id and language), covering 100%. The description adds no additional semantic meaning beyond what the schema offers. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches the full article content for a given news item ID, specifying the verb 'Fetches' and the resource 'full article content'. It also mentions the return of metadata, which distinguishes it from sibling tools like get_news_headlines that likely return only summaries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention when not to use it or suggest sibling tools like get_news_headlines for shorter summaries. The description focuses solely on what the tool does without context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_news_by_categoryARead-onlyInspect
Fetches news for a predefined category with full details including title, source, summary, age, card_url, and source_url. Specify the predefined category for which you want the news, the required region of source of news and the OUTPUT language of news. If the user has not provided a country or region, ask them which region they want before calling this tool. Note: Language is not a filter.
| Name | Required | Description | Default |
|---|---|---|---|
| top_k | No | Number of news items to fetch | |
| region | Yes | Required region for the news. If missing from the user's request, ask the user which region/country they want. | |
| language | No | Language of the output of the news content. It is not a filter, news in other languages may also be included if output language is different | en |
| predefined_category | Yes | Predefined category to search (e.g., TECHNOLOGY, BUSINESS) |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so description adds value by clarifying that language is not a filter and that news in other languages may be included. Does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, no wasted words, front-loaded with purpose. Highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists (indicated by context signals), the description sufficiently covers the tool's behavior and parameters. No missing information for a simple fetch operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. Description adds meaningful context by explaining the roles of region and language, particularly that language is output-only and not a filter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it fetches news for a predefined category with full details, specifying the returned fields. Distinguishes from siblings like `get_news_headlines` by mentioning 'predefined category' and 'full details', but does not explicitly differentiate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides guidance on asking for region if missing and notes that language is not a filter, but does not compare to alternative tools like `search_news` or `get_related_news`.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_news_by_preferenceARead-onlyInspect
Fetches news for a specific saved user preference identified by its ID. The preference defines the category, region, and language of news to retrieve. Use get_user_preferences first to obtain valid preference IDs. Login is required to access this tool.
| Name | Required | Description | Default |
|---|---|---|---|
| preference_id | Yes | ID of the saved user preference to fetch news for |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and destructiveHint=false. The description adds that the preference defines category, region, and language, and that login is required. No contradictions. Additional behavioral details like rate limits or error handling are not needed given the simple read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three succinct sentences: purpose, definition of preference, and prerequisite. Front-loaded and every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with output schema, the description covers purpose, parameter semantics, prerequisite, and authentication requirements. It is complete given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with a clear description for preference_id. The description adds context that the preference encapsulates category, region, and language, enhancing understanding of how the parameter affects results.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches news for a specific saved user preference by ID. It distinguishes from siblings like get_news_by_category or get_news_headlines by specifying the use of a preference ID.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit prerequisite: 'Use get_user_preferences first to obtain valid preference IDs.' Also notes login requirement. This gives clear guidance on when and how to use the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_news_headlinesARead-onlyInspect
Fetches the latest headlines (title and source only, no summary) for a specified region. Use get_news_by_category or search_news when full article details like summary or source URL are needed.
| Name | Required | Description | Default |
|---|---|---|---|
| region | Yes | Region from where you request custom news | |
| language | No | Output language of the news content. Not a filter — news in other languages may be included. | en |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds that it returns only title and source (no summary) and implies language parameter behavior, but does not fully cover potential edge cases or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first states the action and output, second gives usage guidance. Front-loaded, no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with few parameters, output schema, and clear annotations, the description covers what the tool does, what it returns, and when to use alternatives.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% so baseline is 3. The description does not add meaning beyond the schema for the region parameter, and the language parameter is not mentioned in the description, so no additional value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it fetches the latest headlines with title and source only, for a specified region, and distinguishes from siblings that provide full article details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use this tool (for headlines only) and when to use get_news_by_category or search_news (for full details), providing clear decision guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_user_preferencesARead-onlyInspect
Returns all saved news preferences for the authenticated user. Each preference contains a news category, region, output language, last_n_hours, search_type, and enable_decay. Login is required to access this tool.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true and destructiveHint=false, so the description's behavioral addition is limited to stating 'Login is required.' This confirms the read-only nature but adds minimal extra behavioral context beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences that front-load the main purpose and immediately follow with a key requirement. Every word adds value, with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity (no parameters, no nested objects, and an existing output schema), the description covers the essential: what it returns, the fields, and the authentication requirement. It is complete enough for an agent to understand the tool's function without missing critical context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so per guidelines the baseline score is 4. The description correctly does not attempt to document nonexistent parameters, and the high schema description coverage (100%) makes further elaboration unnecessary.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns all saved news preferences for the authenticated user, with a specific verb and resource. It lists the fields included, distinguishing it from sibling tools like 'get_news_by_preference' by implying a broader scope. However, it could explicitly contrast with siblings for higher clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions that login is required, which is a prerequisite, but provides no guidance on when to use this tool versus alternatives like 'get_news_by_preference' or 'update_user_preferences'. No exclusions or context for selection are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_newsARead-onlyInspect
Searches news for a free-form topic or keyword and returns full details including summary, age, and source URL. To invoke multi-query search, put multiple topics in search_string separated by 'or', for example: 'abc or xyz or pqr'. The region is required. If the user has not provided a country or region, ask them which region they want before calling this tool. If search_type is not provided, it will be intelligently classified based on the search string. Specify the output language and top_k. Note: Language is the output language, not a filter — news in other languages may also be included. Choose the search_type based on the query intelligently.
| Name | Required | Description | Default |
|---|---|---|---|
| top_k | No | Number of news items to fetch | |
| region | Yes | Required region filter for the news search. If missing from the user's request, ask the user which region/country they want. | |
| language | No | Language code of the output news content, e.g., 'en' for English. It is not a filter — news in other languages may also be included. | en |
| search_type | No | - Use "vector" if the query is a free-form topic or question that would benefit from semantic understanding (e.g., "latest trends in AI", "impact of climate change on agriculture","entertainment"). - Use "sparse" if the query consists of specific keywords or phrases without much context (e.g., "Apple earnings report", "Olympics 2024 schedule"). - Use "exact" if the query is looking for a precise match, such as a specific news headline or article title (e.g., "Tesla Model 3 recall", "COVID-19 vaccine approval date"). - Use "hybrid" if the query contains a mix of free-form language and specific keywords, or if it's ambiguous and could benefit from both semantic and keyword search (e.g., "effects of inflation on housing market", "best smartphones 2024"). | |
| enable_decay | No | Whether to apply decay for increasing relevance of recent news | |
| last_n_hours | No | Time range in hours to fetch recent news, e.g., 24 for news from the last 24 hours | |
| search_string | Yes | Free form search string/topic to search for news (e.g., 'latest in AI', '2024 Olympics'). For multi-query search, separate topics with 'or', e.g. 'abc or xyz or pqr'. |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (readOnlyHint=true, destructiveHint=false) indicate safety. Description adds behavioral details: language not a filter, search_type auto-classification, decay for recent news. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is slightly long but well-structured with front-loaded purpose. Every sentence adds value; could trim slightly but effective overall.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 7 parameters, 2 required, and output schema present, description covers key usage, parameter nuances, and behavioral traits. Missing only explicit sibling differentiation, but output schema handles return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, baseline 3. Description enriches parameters: explains multi-query syntax for search_string, clarifies language behavior, gives search_type selection guidelines, and notes enable_decay purpose.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Searches news for a free-form topic or keyword and returns full details including summary, age, and source URL.' It specifies the verb (searches), resource (news), and output, distinguishing it from siblings like get_news_headlines or get_news_by_category.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance: asking for region if missing, multi-query syntax with 'or', and intelligent search_type classification. Lacks direct comparison to siblings for when to use alternatives, but context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
set_user_preferencesAInspect
Adds one or more news preferences for the authenticated user. Each preference is defined by news category(or search parameter), region, output language. Optional values include last_n_hours for recency filter, search_type, and enable_decay. Determine the best search type based on user categories. Use Hybrid search for semantic + similar word search. Select Sparse for keyword-prefered search and Vector for semantic-preferred search. Existing preferences are not removed — new ones are appended. Login is required to access this tool.
| Name | Required | Description | Default |
|---|---|---|---|
| preferences | Yes | List of preferences to add for the user |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations, the description reveals that preferences are appended, not overwritten, and that login is required. This adds value beyond what readOnlyHint and destructiveHint provide. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is front-loaded with the main action and is concise with 6 sentences. Some redundancy (e.g., repeating 'Optional' frames), but overall effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of the nested preference object and the presence of an output schema, the description covers purpose, behavior (append), login requirement, and parameter guidance. It could mention return values, but output schema handles that.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does 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 extra meaning by explaining how to choose search_type based on user categories, which is not in the schema. This enhances understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool adds news preferences for the authenticated user, with a specific verb and resource. It distinguishes from sibling tools like update_user_preferences by stating that existing preferences are appended, not removed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context (appending, login required) and guidance on selecting search_type, but does not explicitly mention when to avoid using this tool or name alternatives. The sibling tool names imply differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
set_user_settingsAInspect
Save the user's preferred news language and region. Call this after the user confirms their language and region preferences. Login is required to access this tool.
| Name | Required | Description | Default |
|---|---|---|---|
| region | Yes | Region slug, e.g. 'india', 'united-states', 'united-kingdom', 'japan' | |
| language | Yes | BCP-47 language code for news content, e.g. 'en', 'hi', 'ja' |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate a write operation (readOnlyHint=false) and non-destructive. Description adds login requirement, which is useful. It does not detail what happens after save (e.g., side effects on current session) but is consistent with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, no fluff, with purpose stated first. Every word contributes valuable information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present and low complexity, the description adequately covers purpose, usage timing, and login requirement. Could mention return value or error behavior for completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear examples for both parameters. Description mentions 'language and region' but does not add extra meaning beyond the schema, meeting the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool saves the user's preferred news language and region. It uses a specific verb 'Save' and resource 'preferred news language and region'. While this distinguishes it from general preference tools, it could explicitly differentiate from sibling set_user_preferences.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear usage context: call after user confirms preferences. It also notes login requirement. However, it lacks guidance on when not to use this tool or mention of alternatives like set_user_preferences.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
update_user_preferencesAInspect
Update news preferences for the authenticated user. Each preference is defined by news category(or search parameter), region, output language. Optional values include last_n_hours for recency filter, search_type, and enable_decay. Determine the best search type based on user categories. Use Hybrid search for semantic + similar word search. Select Sparse for keyword-prefered search and Vector for semantic-preferred search. Existing preferences are not removed — new ones are appended. Login is required to access this tool.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ID of the preference to update | |
| preference | Yes | Preference to update for the user |
Output Schema
| Name | Required | Description |
|---|---|---|
| id | Yes | |
| region | Yes | |
| category | Yes | |
| language | Yes | |
| search_type | Yes | |
| enable_decay | Yes | |
| last_n_hours | Yes | |
| similarity_threshold | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations, the description discloses that login is required, that existing preferences are appended rather than overwritten, and offers detailed advice on search_type selection. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively concise and front-loaded with the core purpose. It includes necessary behavioral details without excessive verbosity, though some guidance could be more targeted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is inconsistent: it says 'update news preferences' but also 'new ones are appended,' which is confusing regarding whether it modifies an existing preference or adds a new one. It does not explain what happens if the id does not exist, nor how the preference object is merged with existing data. Given the presence of an output schema, the description should compensate for these gaps but fails to do so.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% description coverage, so the description adds minimal new meaning beyond the schema. It reiterates optional fields and provides advice on search_type, but does not clarify the meaning of the 'id' parameter or the structure of the 'preference' object beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'update news preferences for the authenticated user' and explains the preference fields. It hints at appending behavior versus sibling tool set_user_preferences but does not explicitly differentiate, leaving some ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides guidance on selecting search_type based on user categories and mentions login requirement. However, it lacks explicit instructions on when to use this tool versus sibling tools like set_user_preferences, and does not specify prerequisites or conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!