FinPortal.mk Financial Intelligence

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

Annotations already establish read-only, idempotent, non-destructive behavior. The description adds useful context by specifying that the response is limited to a short displayed excerpt and source link, and by warning against expecting full text.

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 tightly written sentences, with the core purpose front-loaded and the key limitation stated immediately afterward. No filler or redundant restatement of the title.

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 low-complexity, single-parameter read tool with annotations and no output schema, the description covers the essential purpose, return scope, and main exclusion. It could still say how to obtain a valid slug, but overall it is sufficient for correct 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?

The sole parameter is 'slug' with 0% schema description coverage. The description adds some meaning by indicating it identifies a published FinPortal story, but it does not explain slug format, where to obtain it, or what happens for invalid/unpublished slugs.

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?

States a specific verb and resource: retrieve the public summary for a published FinPortal story by slug. It also clarifies the output scope (short excerpt and source link), which distinguishes it from full-text or editorial article retrieval.

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 says not to use this tool for third-party full text, giving a clear usage boundary. However, it does not name the preferred alternative sibling (such as get_editorial_article or search_finportal) for obtaining full text or finding slugs.

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

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

Annotations already declare readOnly, idempotent, non-destructive, open-world, so the safety profile is covered. The description adds real value by disclosing that the package is bounded and source-attributed, grouped by source, and explicitly not a completeness guarantee. It still doesn't say what happens with no matching sources or how truncation is surfaced.

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 dense sentences with the purpose front-loaded before the resolver/filter details and the disclaimers last. "Bounded, source-attributed evidence package" is slightly jargony but each clause carries 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 no output schema, the description usefully states that results are grouped by source, which is the key return-shape fact. Combined with the scope limits and annotations, an agent has enough to invoke it correctly; only truncation and empty-result behavior are unaddressed.

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 0%, so the description must compensate. It does explain the company parameter (Cyrillic/Latin name or ticker resolution) and implies the date-range filter, but "limit" and the interplay between days and limit are never described beyond the vague word "bounded". Partial compensation only.

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?

A specific verb and resource: it builds a source-attributed evidence package for an MSE issuer, and it enumerates the source classes it aggregates (filings, news, FinPortal editorial, public stories, document metadata). That implicitly separates it from single-source siblings like get_company_news or get_seinet_filings, though it never names them.

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?

"Use for company research" gives clear context, and the negative clauses rule out live market data, investment advice, and completeness claims. What's missing is explicit routing: nothing says when to pick this over get_company_timeline or resolve_company.

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

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds genuinely new behavioral detail: the resolution logic for MSE issuers across exact ticker, Cyrillic, Latin transliteration and curated aliases, plus the instruction to cite source/date/URL, which hints at the shape of returned records. It says nothing about pagination or how results are ordered, which keeps it below a 5.

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, front-loaded with the use case, then the resolution and citation rules. Dense but every clause carries information; the second sentence is a long semicolon chain that could be split, but nothing is padded.

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 no output schema, the description must imply return content, and "cite each returned source/date/URL" does convey that results are sourced news items with dates and links. The only real omission is any guidance on the limit parameter or expected result volume for a tool that is open-world and could return unbounded matches.

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 0%, so the description carries the full burden. It does well on the two identifiers — explaining that ticker and company both resolve through multiple name forms — but the limit parameter (default 20, max 50) is never mentioned, leaving a third of the surface undocumented anywhere.

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 opening sentence gives a specific verb and resource — public news and editorial mentions scoped to a company — which cleanly separates it from the broadfeed siblings like get_latest_news or get_global_news. It never names a sibling explicitly, so the differentiation relies on the reader inferring scope rather than being told.

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?

"Use for public news and editorial mentions of a company" establishes the context of use, but there is no explicit when-not or named alternative (e.g. get_domestic_news for market-wide coverage). The agent must infer that this is the company-scoped variant from the name and phrasing alone.

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

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

Annotations already declare read-only, idempotent, open-world, and non-destructive behavior, so the safety profile is covered. The description adds useful behavioral context beyond annotations: results are newest-first, they are based on stored public mentions, and the tool is not a forecasting tool. It does not describe pagination or rate-limit behavior, which keeps it short of a 5.

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 efficient sentences with the core purpose front-loaded and the alternative-tool routing placed immediately after. Every sentence adds useful selection information with no repetition or filler.

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 read-only timeline tool with strong annotations, the description gives enough context to select it and route away from get_company_intelligence. However, with no output schema and no parameter descriptions in the schema, it leaves the limit behavior and the exact return shape under-specified.

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 0%, so the description must carry parameter meaning, but it only vaguely indicates that a company or ticker can be supplied. It says nothing about the limit parameter, its default, its maximum, or the fact that company is required while ticker is optional.

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: it builds a newest-first timeline of stored public mentions for a company or ticker. It also explicitly distinguishes itself from the sibling get_company_intelligence, so an agent can tell the two apart without opening both schemas.

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 names the alternative get_company_intelligence and the exact condition that selects it: bounded date range and records grouped by source category. It also states a clear exclusion, that this tool does not forecast price or performance, leaving little ambiguity about when to use it.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint, so the safety profile is covered. The description adds one genuinely new behavioral fact, that only public metadata already shown on FinPortal is returned, which bounds the output. It says nothing about ordering, pagination, or whether the feed is exhaustive versus sampled.

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, zero filler, with the triggering condition front-loaded ahead of the filtering detail. Nothing in it is redundant with the name or annotations.

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?

Placeholder

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 0%, so the description bears the burden and partially meets it: listing "MSE, SEI-Net, DZS, or DZR" together with "official statistics/audit releases" implicitly maps DZS to statistics and DZR to audit, giving the abbreviations real meaning. The limit parameter and its 1-50 range/default are entirely unaddressed, and the acronyms are never fully expanded.

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 names the resource precisely: Macedonian public-company announcements and official statistics/audit releases, which an agent can map to the tool's scope. However, it never says this is an aggregating feed versus the four dedicated per-source siblings (get_mse_announcements, get_seinet_filings, get_dzs_releases, get_dzr_reports) that cover the same sources, so the boundary between this tool and those is left implicit.

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?

"Use when the question concerns Macedonian public-company announcements or official statistics/audit releases" gives a usable trigger condition. But there are no exclusions and, more importantly, no routing advice against the four source-specific siblings or get_latest_news, which is the most likely selection confusion for this tool.

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

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

Annotations already declare readOnly, idempotent, open-world, non-destructive behavior, so the description only needs to add context. It does so by disclosing that only metadata is returned and that the underlying report text is unavailable — a substantive expectation-setting detail not present in the 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?

Two compact sentences, front-loaded with the resource and scope, followed by the use case and the key limitation. No filler 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?

With rich annotations and no output schema, the description adequately covers what is returned (metadata, date, source link) and what is not. It leaves a small gap around how to page or size results via the limit parameter.

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?

There is one parameter ('limit', default 20, max 50) with 0% schema description coverage, and the description says nothing about it — no mention of page size, default, or capping. With low coverage the description should compensate, and here it does not.

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?

States a specific verb ('List') and a specific resource ('stored State Audit Office report metadata'), plus the fields returned (date, source link). It is distinguishable from statistical releases (get_dzs_releases) only implicitly, since no sibling is named, so it falls short of a 5.

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?

'Use for public audit-report discovery' gives an implied use case, and the note that full third-party text is not returned acts as a soft exclusion. However, there is no explicit when-not guidance or pointer to an alternative sibling tool for other audit/statistics content.

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

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

Annotations already declare readOnly, idempotent, non-destructive and open-world, so safety is covered. The description adds genuinely new behavioral context: results are stored metadata containing a date and an original link, and full reports are not returned — useful given there is no output 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 tight sentences, front-loaded with the resource and followed immediately by the exclusion. No filler, though the second sentence could be slightly more specific about when the exclusion matters.

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?

It compensates for the missing output schema by describing the returned fields (date, original link), which is good. But with a completely undocumented parameter and no guidance on result volume or pagination, an agent still lacks enough to call it confidently beyond defaults.

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 0% and the single 'limit' parameter (default 20, max 50) is never mentioned in the description, so its meaning, bounds, and pagination role must be inferred from the raw schema alone. The description does not compensate for the coverage gap.

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?

States a specific verb ('List') and a precise resource ('stored State Statistical Office of Macedonia release metadata'), which clearly separates it from siblings like get_dzr_reports or get_mse_announcements. It stops short of explicit sibling routing but the resource is 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?

The negative scope ('does not expose full reports or calculate new statistics') implies this is a metadata-lookup tool, which helps an agent avoid it for full text. However, it never states when to prefer it over the related sibling get_dzr_reports or other release/news tools.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is covered structurally. The description adds the useful content-scope constraint (no drafts, no third-party), but says nothing about return body format (Markdown vs HTML) or not-found behavior, which matters for an openWorld retrieval tool.

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 with no filler, front-loading the core action and following with the exclusion clause. Nothing needs trimming or reordering.

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?

No output schema exists, but the description states that the full article body is returned, which is the essential return-value fact for this tool. Missing only secondary details (body serialization format, error behavior for unknown slugs) that an agent could discover at call time.

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 0%, so the single parameter carries no documentation of its own. The description compensates partially by clarifying that either an ID or a slug is accepted, but the parameter name already implies that, and constraints like the 255-character maximum go unmentioned.

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?

States a specific verb and resource ('Retrieve the full body of one published, FinPortal-authored editorial article') plus the lookup key ('by ID or slug'). The scope qualifiers ('published', 'FinPortal-authored', 'one') differentiate it cleanly from the plural sibling get_editorial_articles and from third-party 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 exclusions ('does not expose third-party articles or unpublished drafts') tell the agent when this tool will fail and therefore implicitly when to route elsewhere. It stops short of naming get_editorial_articles as the list alternative, leaving that inference to the agent.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is fully covered. The description adds the meaningful filter that only currently published articles are returned, implying drafts or unpublished content are excluded. It says nothing about ordering, pagination beyond the limit parameter, or result shape, so with the low annotation bar a 3 is right.

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 short sentences, zero filler, and the core purpose is front-loaded before the disambiguation hint. Every clause 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?

For a read-only single-parameter list tool with full annotation coverage and no output schema, the definition covers purpose, scope and the main alternative. The remaining gap is ordering and pagination behavior (whether limit truncates silently and in what order results arrive), which matters for a listing tool but is a minor omission.

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?

There is one parameter (limit) with 0% schema description coverage: the schema supplies only default 20, minimum 1 and maximum 50, with no prose. The description says nothing about limit, so an agent must infer that it caps the number of returned articles. The parameter's intent is largely self-evident from its name and bounds, keeping this at the baseline-3 level rather than penalizing harder.

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 ('List') plus the resource and scope ('original FinPortal editorial articles that are currently published'), and the second sentence names the sibling get_editorial_article as the single-item counterpart. An agent can distinguish collection listing from single-article retrieval without opening either schema.

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 second sentence explicitly routes the agent to get_editorial_article by ID or slug 'only when the full FinPortal-owned article is needed', which gives a clear alternative and condition. It does not address other siblings such as search_finportal or explain when a different listing tool would apply instead, leaving some routing inference to the agent.

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

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

Annotations already declare readOnly/idempotent/openWorld, so the safety profile is covered. The description adds genuinely useful behavioral context: output content is FinPortal's translation, and the original publisher's full text is never returned — an important expectation-setter that no annotation conveys.

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 dense sentences with zero filler; the usage cue leads and the return contract follows immediately. Nothing repeats the name or title.

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 no output schema, the description does the work of describing the return shape (title, summary, publisher, date, URL) and its licensing limit. What remains unstated is result ordering, coverage window of the stored news, and how `limit` interacts with total results — minor but relevant for a news-retrieval 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 single parameter is `limit`, and schema description coverage is 0% — the property has no description at all. The description never mentions it, so an agent gets only the property name plus a default of 20 and a max of 50 to infer that it caps result count; nothing explains ordering, truncation, or total available 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?

States a specific verb+resource: retrieves stored international financial news, and the return description (translated title, short summary, publisher, date, original URL) makes the output concrete. It does not name which sibling to use instead (get_domestic_news, get_latest_news, get_company_news), so the differentiation is implied rather than explicit.

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?

"Use for stored international financial news" implies the usage context (international, stored/archived), which edges out pure silence. But there are no exclusions, no prerequisites, and no named alternative for domestic, company-specific, or breaking-news queries, all of which exist as siblings.

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

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

Annotations already declare readOnly, idempotent, non-destructive behavior, so the bar is lower, and the description still adds real context the annotations don't: results are stored snapshots rather than a live feed, and they preserve attribution and original links. That snapshot-vs-live distinction materially affects how an agent should interpret recency.

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 economical sentences with the usage directive front-loaded and every clause carrying information (scope, snapshot nature, attribution). Nothing is redundant with the title or schema.

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 no output schema, the description correctly characterizes the return payload (concise feed of stored snapshots with links and attribution), which is the essential missing piece. The only gap is the undocumented limit parameter, so it falls just short of complete.

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 sole parameter 'limit' has 0% schema description coverage, so the description needed to compensate and entirely fails to mention it. The agent must infer that limit caps feed size from the name and its 1-50 bounds alone.

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 names a specific resource ('most recent stored Macedonian business and international news') and frames it as a concise feed, so the agent knows exactly what comes back. It does not explicitly contrast with close siblings like get_domestic_news or get_global_news, leaving overlap to inference.

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?

'Use for a concise feed' implies a use case, but with siblings get_domestic_news, get_global_news, and get_company_news in the list, there is no stated condition for choosing this combined feed over the narrower ones, and no when-not guidance.

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

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

Annotations already cover read-only, idempotent, non-destructive, and open-world behavior, so the bar is lower. The description still adds real value by disclosing the content boundary: only the short description FinPortal already displays is returned, never the full third-party announcement — telling the agent not to expect full-text content.

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 tight sentences, front-loaded with what is listed and what fields come back, followed by the content limitation. No filler and nothing redundant.

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 no output schema, the description adequately conveys the return shape and content limit. However, the sole parameter is left unexplained and there is no statement about result ordering or how many announcements typically exist.

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?

There is one parameter (limit) with 0% schema description coverage, and the description never mentions it, its default of 20, or the 50 cap. Pagination/result-size behavior is entirely undocumented, so the description fails to compensate for the coverage gap.

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?

States a specific verb and resource — listing stored Macedonian Stock Exchange announcement metadata — and names the returned fields (publication date, original link). It is clear what the tool does, though it doesn't explicitly contrast itself with siblings like get_seinet_filings or get_company_news.

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 implies the tool is for MSE announcements but gives no explicit when-to-use guidance, no prerequisites, and no named alternatives among the many filing/news siblings. An agent must infer routing from the name alone.

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

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

Annotations already declare read-only, idempotent, non-destructive, and open-world behavior. The description adds meaningful context beyond the annotations: it returns stored metadata, includes a date and original link, and the excerpt is not a complete filing.

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 efficient sentences, with the core purpose stated first and the usage caveat immediately after. Every sentence carries useful 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?

For a simple read-only listing tool with one optional parameter and no output schema, the description covers the main content and an important caveat. However, it omits limit/pagination behavior and does not describe the returned metadata beyond date and original link.

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 only parameter is limit, and schema description coverage is 0%. The description never mentions the limit, default value, maximum, or pagination behavior, so it does not compensate for the missing parameter documentation.

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 gives a specific verb and resource: list stored SEI-Net public filing metadata, including date and original link. It also scopes the tool to issuer disclosure discovery, which helps distinguish it from news and report siblings, though it does not name those alternatives explicitly.

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 says to use this for issuer disclosure discovery and warns not to treat the excerpt as a complete filing. This gives useful usage context and one important caveat, but it does not contrast the tool with specific sibling tools or state when not to use it beyond that caveat.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so safety behavior is covered. The description adds useful scope detail by enumerating what the returned policy includes and by warning against unsupported capability claims, though it does not describe response format or freshness.

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 front-loaded and purposeful. The first defines the return contents; the second states the operational check. No unnecessary repetition or filler.

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 zero-parameter metadata tool with no output schema, the description is complete enough: it explains what the authoritative policy list contains and when an agent should consult it before making capability claims.

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 takes zero parameters, so there are no parameter semantics to explain. The empty schema is fully consistent with the description, and the baseline for a no-parameter tool applies.

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 uses a specific verb ('Return') and clearly identifies the resource: an authoritative list of enabled data sources, exposed fields, attribution, reuse restrictions, and disabled categories. This is distinct from every sibling tool, which retrieves news, filings, reports, or company data rather than source-policy metadata.

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 gives a clear usage directive: check this before claiming that MCP provides quotes, indices, currency rates, or full third-party text. It does not name alternative tools, but none of the siblings serve this policy-introspection purpose, so the context is sufficient.

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

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

Annotations already cover read-only/idempotent safety, so the credit here goes to genuine extras: ambiguity yields multiple candidates, the tool 'never guesses', and it deliberately excludes price data. What is missing is any note on result ordering or how an agent should disambiguate among returned candidates.

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, zero filler, with the accepted input forms front-loaded and the fallback behavior plus exclusions following. Every clause adds information an agent needs.

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 resolver with no output schema, the description covers inputs, ambiguity handling, and scope exclusions. The remaining gap is the shape of a successful response (single object vs. candidate list, and what fields identify a candidate), which the agent must discover at runtime.

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 0%, so the description must carry the load, and it does: it tells the agent that 'query' accepts an exact ticker, a Cyrillic name, a Latin transliteration, or a curated alias. It stops short of showing concrete syntax or stating whether matching is exact versus fuzzy for each form.

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?

States a specific verb and resource ('Resolve a Macedonian Stock Exchange issuer') and immediately enumerates the accepted identifier forms. It is clearly distinguishable from siblings like get_company_intelligence or get_company_news, which return content rather than identity resolution.

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 makes the intended input space explicit (ticker, Cyrillic name, Latin transliteration, alias) and rules out one adjacent use case ('does not return prices'). It does not explicitly say to call this before the company content tools, so the sequencing guidance is implied rather than stated.

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

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

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description usefully adds that results carry source, date, URL and only permitted excerpts, and that third-party full text and live market data are excluded, but says nothing about pagination, ranking, or empty-result behavior for a search tool.

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 tight sentences with no filler; the search purpose and scope choice come first, the result-content caveat second. Every clause carries 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?

No output schema exists, and the description compensates by enumerating returned fields (source, date, URL, excerpts). Only the limit/pagination behavior is unaddressed, a minor gap for a search endpoint.

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 0%, so the description should compensate, and it does partially by explaining the meaning of the scope enum (all/domestic/global/editorial). It leaves query semantics (min 2, max 120 chars) and the limit parameter (max 50) entirely to 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?

States a specific verb+resource ('Search FinPortal's already-stored public records') and a use case (evidence for a topic, event, or company). It implicitly separates itself from live-data siblings by saying 'already-stored' and 'not live market data', but never names which sibling to use for specific news/filings, so differentiation is only partial.

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?

Gives a clear trigger ('when an agent needs evidence for a topic, event, or company') and indicates the four scope modes to choose from. It lacks explicit when-not guidance or routing to specific siblings like get_company_news or get_editorial_article.

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