Trend News Agency: search and read 2.6M articles on Azerbaijan, the Caspian and Central Asia.
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.
Average 4.6/5 across 12 of 12 tools scored.
Most tools have clearly distinct purposes: article_get, author_get, coverage_get, front_page, news_list, news_search, page_get, research, subscription_plans, taxonomy_search, trending, and whoami each serve a unique function. Some overlap exists (e.g., news_search vs. research, news_list vs. trending), but descriptions clarify the differences.
Naming patterns are inconsistent. Some tools follow noun_get (article_get, author_get), others use noun_search (news_search, taxonomy_search), while some are bare nouns (front_page, trending, whoami) or verbs (research). This mixed style makes the API less predictable.
With 12 tools, the count is reasonable for a news agency data server. Each tool addresses a specific need, though a few could be combined (e.g., research could subsume news_search and article_get). The count is slightly above the ideal range but still well-scoped.
The tool set covers the full read-only surface for this domain: retrieving articles, authors, coverage info, front page, list, search, static pages, subscription plans, taxonomy, trending, and account status. There are no obvious missing operations for a news data server.
trendaz_article_getRead a Trend articleAFetch one Trend News Agency article in full: headline, byline, dateline, publication date, section, tags and the body as markdown. Pass the article URL if you have one — that is the reliable way — or an id together with its language edition. Subscriber-only articles published within the last year return their metadata and excerpt with the body withheld; everything older than a year, and everything free, returns in full. Always cite the returned url.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | Numeric article id. Requires lang. Use url instead when you have one. | |
| url | No | Full article URL, e.g. https://www.trend.az/business/4216277.html. Preferred over id+lang. | |
| lang | No | Language edition of the id. Defaults to en. Ignored when url is given. |
| Name | Required | Description |
|---|---|---|
| note | No | |
| found | Yes | |
| article | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the readOnlyHint annotation by disclosing subscriber-only behavior: articles within the last year return metadata/excerpt with body withheld, while older or free articles return in full. Also instructs the agent to cite the returned url, a practical behavioral requirement.
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?
Packed but not bloated: purpose, return values, parameter selection, access restrictions, and citation requirement all earn their place. Front-loaded with the main action.
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?
Despite having an output schema, the description covers all important nuances: article contents, restrictions for subscriber-only articles, URL/id+lang behavior, and the citation instruction. Nothing important is left to inference for a 3-parameter tool.
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 already documents all three parameters at 100% coverage, so the baseline is 3. The description adds meaningful usage semantics: url is the 'reliable way,' id requires lang, and lang defaults to en/ignored with url. This elevates the parameter guidance.
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 states a specific action ('Fetch one Trend News Agency article in full') and enumerates the returned content (headline, byline, dateline, tags, body). The URL-vs-id+lang distinction and access restrictions separate it from sibling list/search/page tools.
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 clear guidance on selecting URL vs id+lang and notes that lang is ignored when url is given. It does not explicitly mention alternative sibling tools for cases like listing or searching, but the single-article scope is strongly implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
trendaz_author_getLook up a Trend journalistALook up a Trend News Agency journalist by name, id or profile alias, and get what the agency publishes about them: role, the beats they cover, biography, stated expertise, declared conflicts of interest and whether they are staff. Use it when a citation needs to establish who reported something and what standing they have on the subject. Combine with trendaz_news_list using the returned id to see what else they have written.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | Numeric author id, as returned by trendaz_article_get. | |
| lang | No | Language edition whose directory to search. Defaults to en. | |
| name | No | Byline as printed, in whole or part, e.g. "Maryana". Matched case-insensitively. | |
| alias | No | Profile slug from an author URL, e.g. "peter_tase". |
| Name | Required | Description |
|---|---|---|
| note | No | |
| found | Yes | |
| author | No | |
| matches | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the read-only nature is covered. The description adds behavioral context by listing the specific data fields (role, beats, bio, etc.) and indicating that it returns an id for further use. It does not contradict annotations and adds useful detail about the tool's output semantics.
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 sentences, each purposeful. The first defines the action and outputs, the second states the use case, and the third suggests a follow-up action. No redundant wording, front-loaded with the core purpose. It is concise yet complete.
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, the description doesn't need to explain return format. It covers the essential aspects: what the tool does, what info it returns, when to use it, and how to chain it with another tool. Given its read-only nature and clear schema, no gaps are evident.
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% — all four parameters have descriptions in the input schema. The description adds context beyond the schema by clarifying that the id is returned by trendaz_article_get, and by giving examples of name and alias formats. This slightly elevates it above the baseline of 3 for full schema coverage.
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 starts with a specific verb+resource ('Look up a Trend News Agency journalist') and enumerates the exact data returned (role, beats, biography, expertise, conflicts of interest, staff status). It clearly distinguishes itself from siblings like trendaz_news_list (which lists articles) and trendaz_article_get (which fetches a single article) by focusing on the author profile.
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 states when to use: 'when a citation needs to establish who reported something and what standing they have on the subject.' It also gives a concrete workflow recommendation: 'Combine with trendaz_news_list using the returned id to see what else they have written.' This provides clear context and directs the agent to a complementary tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
trendaz_coverage_getWhat Trend coversADescribe what the Trend News Agency archive covers: which language editions exist and their canonical hosts, which regions and beats the agency reports on, and the terms under which its text may be used. Call this before a first search to find out whether Trend is a useful source for a question, and which language edition to search.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| beats | No | |
| license | Yes | |
| regions | Yes | |
| editions | Yes | |
| publisher | Yes | |
| not_yet_available | No | |
| editions_not_available | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already include readOnlyHint: true, and the description adds context about the type of information returned (coverage details, languages, regions, usage terms). It mentions usage terms, which is extra behavioral context beyond annotations. No contradiction with annotations, and it uses the annotation coverage appropriately.
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, front-loaded with the purpose and followed by usage guidance. Every sentence adds value, with no redundancy or filler. It is 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 low complexity (no parameters) and the presence of an output schema, the description fully covers the tool's scope: what it does, what it covers, and when to call it. It provides all necessary context for an agent to decide whether to invoke it, without needing to describe return values since the output schema exists.
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 the baseline score of 4 applies per the rubric. The description does not need to explain parameters, and it correctly focuses on the tool's purpose and output content.
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 states a specific verb and resource: 'Describe what the Trend News Agency archive covers.' It enumerates the exact content areas (language editions, canonical hosts, regions, beats, usage terms), which clearly differentiates it from sibling tools that fetch articles or search. This is a distinct, well-defined purpose.
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 explicitly says 'Call this before a first search to find out whether Trend is a useful source for a question, and which language edition to search.' This gives clear context on when to use it, but it does not explicitly mention alternatives or when not to use it, so it falls slightly short of the highest rating.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
trendaz_front_pageTrend front page right nowAWhat Trend News Agency is leading with at this moment, grouped the way the newsroom groups it: the main story block, the editor's picks, and the regional sections. This is editorial judgement rather than recency — use it for "what is the news from Azerbaijan today" or "what is Trend leading with", where the answer should be what editors chose rather than whatever was filed last. Metadata only; follow up with trendaz_article_get.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | Language edition. Defaults to en. Each edition has its own front page chosen by its own desk. | |
| blocks | No | How many blocks to return, in front-page order. Defaults to 5. | |
| per_block | No | Maximum articles per block. Defaults to 4. |
| Name | Required | Description |
|---|---|---|
| lang | Yes | |
| note | No | |
| blocks | Yes | |
| total_articles | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, and the description builds on that by explaining that the result is editorial judgement rather than a recency feed, and that each language edition has its own front page. It also indicates metadata-only output, leaving the output schema to detail the structure. It adds behavioral context beyond annotations, though it doesn't discuss pagination or full block details, which are covered by parameters.
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 brief and front-loaded with actionable purpose, then usage, then metadata note, all in two sentences. Every sentence adds value, no fluff or redundancy.
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 tool's simple purpose, full parameter documentation in the schema, and an output schema present, the description fully covers the context. It explains the editorial filtering, language editions, and follow-up action, leaving no gaps for the agent.
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 schema description coverage is 100%, and the description makes no additional parameter explanations beyond what is in the schema. The baseline for high schema coverage is 3, and the description's focus is on purpose rather than parameter syntax, which is acceptable.
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 the current front page grouped by editorial blocks, distinguishing it from recency-based tools. It specifies the resource (Trend News Agency front page) and the verb (get/report).
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 explicitly states when to use it (e.g., 'what is the news from Azerbaijan today') and what it is not (not recency-based), and even points to an alternative follow-up tool (trendaz_article_get). This provides clear usage guidance and differentiation from siblings like trendaz_news_list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
trendaz_news_listBrowse Trend headlinesAList Trend News Agency headlines newest first, optionally narrowed by section, tag, author or a date range. Returns metadata only — headline, date, section, byline, excerpt and the canonical URL — never article text; follow up with trendaz_article_get for the ones worth reading. Use this to answer "what has Trend published about X" or "what did Trend report that week".
| Name | Required | Description | Default |
|---|---|---|---|
| tag | No | Tag slug or title to filter by. | |
| lang | No | Language edition. Defaults to en. The three newsrooms publish independently, so coverage differs between them. | |
| limit | No | How many headlines to return. Defaults to 20. | |
| date_to | No | Latest publication date, YYYY-MM-DD. | |
| section | No | Section slug as it appears in article URLs, e.g. "business", "politics", "uzbekistan". | |
| author_id | No | Numeric author id, as returned by trendaz_article_get. | |
| date_from | No | Earliest publication date, YYYY-MM-DD. |
| Name | Required | Description |
|---|---|---|
| note | No | |
| count | Yes | |
| filters | No | |
| articles | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description adds valuable behavioral detail: headlines are sorted newest first, results are metadata-only (headline, date, section, byline, excerpt, canonical URL), and article text is never returned. This gives the agent concrete expectations about response content without contradicting 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 three sentences with no wasted words: it states the core action, defines the return scope and limitations, and gives concrete use cases. It is front-loaded with the most important information and each sentence earns its place.
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, full parameter descriptions, and readOnlyHint annotation, the description adds the remaining necessary context: ordering, metadata-only behavior, the follow-up tool, and example queries. It is complete for an agent to select and invoke the tool correctly.
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 parameters are already well-documented. The description adds useful semantic grouping by naming the filter dimensions (section, tag, author, date range) that map to the schema properties, reinforcing how the optional filters are intended to be combined.
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 opens with a specific verb and resource: 'List Trend News Agency headlines newest first' and enumerates the optional filters (section, tag, author, date range). It clearly differentiates from trendaz_article_get by stating it returns metadata only and never article text, and it also frames the use case for the list tool.
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 explicitly says when to use the tool: to answer 'what has Trend published about X' or 'what did Trend report that week.' It further directs follow-up to trendaz_article_get for full articles, effectively guiding the agent to choose this list tool for headlines and metadata rather than article retrieval.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
trendaz_news_searchSearch the Trend archiveASearch Trend News Agency's archive by keyword and get matching headlines ranked by relevance, with date, section, byline and canonical URL. The archive runs back to 2003 and holds over 2.6 million articles across the English, Azerbaijani and Russian editions. Wrap words in double quotes for an exact phrase — "Trans Anatolian Pipeline" is far narrower than the same three words loose. Returns metadata only; use trendaz_research when you want the text of what was reported, or trendaz_article_get for one article.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | Language edition to search. Defaults to en. The three newsrooms report independently, so a story covered in one may be absent from another. | |
| sort | No | Defaults to relevance. Use date when recency matters more than fit. | |
| limit | No | How many results. Defaults to 10. | |
| query | Yes | Keywords. Double quotes mark an exact phrase. | |
| date_to | No | Latest publication date, YYYY-MM-DD. | |
| section | No | Restrict to a section slug, e.g. "business" or "casia". A parent section includes everything under it. | |
| date_from | No | Earliest publication date, YYYY-MM-DD. |
| Name | Required | Description |
|---|---|---|
| note | No | |
| count | Yes | |
| query | No | |
| articles | Yes | |
| total_is_floor | No | |
| total_matching | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With readOnlyHint=true already provided in annotations, the description adds valuable context: the archive spans back to 2003 with 2.6 million articles across three editions, and it returns metadata only. It also explains exact phrase behavior with a concrete example, contributing behavioral insight beyond the schema and 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 three sentences, front-loaded with the core action and output, and each sentence earns its place. It provides useful context about archive coverage, searching behavior, and alternative tools without verbose or redundant text.
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 tool has 7 parameters and an output schema, and the description covers the essential use case, return type, collection scope, language editions, phrase searching, and related tools. Given the rich schema and output schema, the description sufficiently contextualizes the tool for an agent to invoke it correctly.
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%, so the description doesn't need to explain every parameter. It adds value by illustrating the exact-phrase use case with a real-world example and reinforcing the language edition independence. The baseline is high because the schema is thorough; the description neatly complements it.
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 searches the Trend News Agency archive by keyword and returns matching headlines with ranking, date, section, byline, and URL. It explicitly differentiates itself by noting it returns metadata only, which separates it from siblings like trendaz_research and trendaz_article_get.
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 gives explicit guidance: use trendaz_research for full reported text and trendaz_article_get for a single article. It also implies when the search tool is appropriate (keyword-based headline retrieval) versus alternatives, making the use case clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
trendaz_page_getRead a Trend policy pageAFetch one of Trend News Agency's own standing documents in full: its corrections policy, editorial standards, masthead, ownership and contact details, terms of service, privacy and cookie policies, copyright terms, and the published auditor reports. Use it to answer questions about the publisher rather than about the news — how the agency handles errors, who runs it, what its editorial process is.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | Language edition. Defaults to en. | |
| slug | Yes | Which document. Common ones: corrections, editorial-standards, masthead, about, contacts, terms-of-service, privacy-policy, copyright. |
| Name | Required | Description |
|---|---|---|
| note | No | |
| page | No | |
| found | Yes | |
| available | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, and the description adds complementary context by noting it fetches the full standing documents and catalogs their categories. It also indicates safe, non-destructive behavior consistent with the annotations, providing value beyond the structured metadata.
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 fully convey purpose, content scope, and usage guidance. The document list is compact yet comprehensive, and the use-case instruction is efficiently placed in the second sentence. No wasted words or redundant references to schema details.
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 2-parameter tool with a full output schema and readOnly/openWorld annotations, the description fully covers what the tool does, what document types it returns, and when to use it. The presence of an output schema removes the need for return-value details, and the description's scope is complete for selection and invocation.
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?
With 100% schema coverage, the schema already documents 'slug' and 'lang' with descriptions. The description enhances parameter understanding by clarifying what the slug values represent (standing policy documents) and ties the document list to the publisher-vs-news use case, adding meaningful context 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 begins with a specific verb+resource ('Fetch one of Trend News Agency's own standing documents in full') and enumerates the exact document types covered. It also explicitly distinguishes the tool from news-focused siblings by directing use toward publisher questions, making its purpose unambiguous.
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?
It clearly states when to use the tool: 'Use it to answer questions about the publisher rather than about the news.' While it does not name alternative sibling tools, the 'rather than the news' clause serves as an explicit when-not and effectively separates it from news-oriented tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
trendaz_researchResearch a topic in the Trend archiveASearch Trend News Agency's archive and read the relevant part of each result in one call. Returns several articles with the passage that actually addresses the query — not just the opening paragraph — plus byline, date, section and the canonical URL to cite. This is the tool to reach for on any question about Azerbaijan, the South Caucasus, the Caspian, Central Asia, Turkey or Iran that needs what was actually reported: energy and pipelines, regional politics, trade corridors, economics. Prefer it over calling search and then reading articles one by one. Wrap words in double quotes for an exact phrase. Subscriber-only articles from the past year contribute their summary rather than their text, and say so.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | Language edition. Defaults to en. | |
| depth | No | quick = 3 articles briefly, standard = 6, deep = 8 with longer passages. Defaults to standard. | |
| query | Yes | What you want to know. Keywords, or a phrase in double quotes. | |
| date_to | No | Latest publication date, YYYY-MM-DD. | |
| section | No | Restrict to a section slug, e.g. "business". A parent section includes everything under it. | |
| date_from | No | Earliest publication date, YYYY-MM-DD. |
| Name | Required | Description |
|---|---|---|
| note | No | |
| count | Yes | |
| query | No | |
| results | Yes | |
| total_is_floor | No | |
| total_matching | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses behavioral details beyond annotations: it reads relevant parts of articles, returns passages, and mentions that subscriber-only articles from the past year provide summaries instead of full text. This transparency aligns with the readOnlyHint annotation and adds useful context.
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 moderately long but every sentence serves a purpose: it states the action, the output, the scenarios, and a query tip. It is well-structured and avoids fluff, making it appropriately sized for the information conveyed.
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 tool's complexity, the description covers all essential aspects: what it does, when to use it (specific regions/topics), how it differs from alternatives, and a special caveat about subscriber-only content. Combined with the schema's parameter details, it is comprehensive.
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?
While the schema already documents each parameter, the description adds a valuable instruction: 'Wrap words in double quotes for an exact phrase.' This enriches the query parameter meaning without redundancy. Since schema coverage is 100%, the baseline is high, and the added tip elevates it.
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's function: searching the Trend archive and reading relevant parts of results. It also distinguishes it from sibling tools by explicitly saying to prefer it over a two-step search-and-read approach.
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 on when to use this tool: for any question about specific regions/topics (Azerbaijan, South Caucasus, etc.) and mentions to prefer it over calling search then reading articles individually. This makes the use case clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
trendaz_subscription_plansTrend subscription: price and what it unlocksAWhat a Trend News Agency subscription costs and what it gives access to: the monthly and annual price in manat, dollars and euro, any introductory offer, and the link to subscribe. Call this when a reader asks what a subscriber-only article would cost them, or asks about subscribing. Reading it does not subscribe anyone — sign-up happens on trend.az, where the reader sees the terms and confirms it themselves.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | Which edition's subscribe link to return. Defaults to en. The price is the same in every edition. |
| Name | Required | Description |
|---|---|---|
| note | No | |
| plans | No | |
| includes | No | |
| available | Yes | |
| currency_note | No | |
| subscribe_url | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, and the description reinforces and extends this by stating 'Reading it does not subscribe anyone' and explaining that sign-up happens on trend.az with the reader confirming terms themselves. This adds useful side-effect context beyond the annotation.
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 sentences: the first defines output, the second gives an explicit call trigger, the third clarifies the non-transactional nature. No redundant words; each sentence adds necessary guidance.
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 read-only tool with one optional parameter and an output schema, the description covers what the tool returns, when to invoke it, and the crucial safety caveat. It is complete without needing to restate schema details.
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 single 'lang' parameter is fully described in the schema (which edition's link to return, default 'en', price identical across editions), and the description adds no new parameter-specific meaning. With schema coverage at 100%, 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: returning subscription costs ('monthly and annual price in manat, dollars and euro'), what it unlocks, and the subscribe link. This distinguishes it sharply from sibling tools that focus on article content, authors, or news listings.
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 the agent when to call: 'Call this when a reader asks what a subscriber-only article would cost them, or asks about subscribing.' It also provides a key exclusion, clarifying that the tool does not actually sign anyone up and that sign-up happens externally on trend.az.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
trendaz_taxonomy_searchFind a Trend sectionAFind the section slug for a subject or a country, so the other tools can be narrowed correctly. Matches on title and slug — "Kazakhstan", "energy", "casia" — and returns the slug to pass as the section argument, along with the public URL of that section. Call it with no query to see the whole section tree of an edition.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | Language edition. Defaults to en. Section names are translated; slugs are usually, but not always, the same across editions. | |
| limit | No | Maximum sections to return. Defaults to 20. | |
| query | No | Part of a section name or slug. Omit to list every section. |
| Name | Required | Description |
|---|---|---|
| note | No | |
| count | Yes | |
| total | No | |
| sections | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses additional behavior beyond the read-only annotation, such as matching on title and slug and returning the public URL. It does not contradict the annotations and gives a clear picture that the tool is a read-only search.
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 concise, consisting of three sentences that front-load the primary purpose. It is well-structured, with no redundant or vague wording, and every sentence contributes to understanding the tool.
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 tool's simplicity, the description adequately covers its main use cases, including the optional query behavior. While it does not specify the full output schema, it mentions returning the slug and URL, which is sufficient for this type of tool.
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 detailed descriptions for all parameters (lang, limit, query), achieving 100% coverage. The tool description adds little new information about the parameters themselves, only restating the behavior when query is omitted.
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's function: finding a section slug for a subject or country. It distinguishes itself from sibling tools by explaining its role in narrowing other tools correctly.
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 usage context: it should be used before other tools to obtain section slugs, and calling with no query lists the entire section tree. However, it does not explicitly contrast with alternative tools, though the implication is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
trendaz_trendingMost-read Trend articlesAList the most-read Trend News Agency articles of the last day, week or month, ordered by readership rather than by date. Use it for "what is Trend's audience paying attention to" — a different question from "what is the latest news", which is trendaz_news_list.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | Language edition. Defaults to en. | |
| limit | No | How many to return. Defaults to 10. | |
| period | No | Window to rank over. Defaults to week. |
| Name | Required | Description |
|---|---|---|
| note | No | |
| count | Yes | |
| period | Yes | |
| articles | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the read-only nature is covered. The description adds behavioral context by stating the ordering is by readership rather than date, and that results are ranked over a specified window. It does not contradict annotations and provides useful non-obvious behavior beyond the schema.
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, both information-dense. The first states the core function and scope; the second provides usage context and sibling differentiation. No filler or redundant detail.
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 read-only list tool with full schema coverage, an output schema, and helpful annotations, the description covers purpose, ordering, time window, and usage boundaries. All essential context is present, and the output schema handles return-value details.
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%; all parameters (lang, limit, period) already have clear descriptions including defaults and enum values. The description contributes only minimal interpretive value by connecting 'last day, week or month' to the period parameter and clarifying the sort intent, but it does not need to do more since the schema is comprehensive.
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 specifies the action ('List'), the resource ('most-read Trend News Agency articles'), the time window ('last day, week or month'), and the ordering ('by readership rather than by date'). It also explicitly distinguishes itself from the sibling tool trendaz_news_list, making its purpose unambiguous.
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?
It provides an explicit use case ('what is Trend's audience paying attention to') and contrasts it with a different question ('what is the latest news') that belongs to trendaz_news_list. This gives concrete when-to-use and when-not-to-use guidance with a named alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
trendaz_whoamiCheck access levelAReport which Trend News Agency access tier this connection has, which tools it may call, and what its request budget is. Call this first when a Trend tool is refused or returns less than expected — it distinguishes "not permitted at your tier" from "no such data".
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| tier | Yes | |
| notes | No | |
| quota | No | |
| scopes | Yes | |
| server | No | |
| protocol | Yes | |
| tier_title | Yes | |
| tool_names | No | |
| quota_enforced | No | |
| tools_available | Yes | |
| article_body_rights | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=true, and the description reinforces this by stating it reports information without modifying data. It adds useful context about what it diagnoses (permission vs. data absence), complementing the annotations without contradicting them.
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 concise and informative, using two sentences to convey purpose and usage guidance without unnecessary verbosity. It is well-structured and immediately relevant.
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 tool's simplicity (no parameters) and the presence of an output schema, the description sufficiently covers its purpose, usage, and diagnostic value. It is complete enough for an agent to invoke it appropriately.
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?
Since there are no parameters, the schema coverage is 100%, and the baseline is 4. The description effectively explains what the output indicates, adding value beyond the empty 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 the tool's purpose: reporting the access tier, available tools, and request budget. It distinguishes itself by explaining it helps differentiate between permission issues and data availability, which is distinct from sibling tools that fetch content.
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 advises using this tool first when a Trend tool is refused or returns unexpected results. It implies a diagnostic role but does not explicitly state when not to use it or mention specific alternatives, hence a slight deduction.
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.
No comments yet. Be the first to start the discussion!