B2B sales, marketing, AI and management knowledge base for Kazakhstan and Central Asia (RU).
Scored across 6 tools
The three search tools overlap significantly: search_knowledge covers the entire public knowledge base, while search_cases and search_playbook target subsets (cases, playbooks) that search_knowledge also includes. The descriptions do clarify scope, but an agent may still default to the broad search, causing misselection.
All tool names follow a consistent snake_case verb_noun pattern: get_article, get_related_content, list_categories, search_cases, search_knowledge, search_playbook. The convention is predictable and easy to parse.
Six tools is well-scoped for a knowledge base: retrieval, related content, category listing, and three search variants. Each tool has a plausible purpose and the count avoids both thinness and bloat.
Core read-only retrieval is covered: fetching articles by slug/URL, related content, category overview, and multiple search modes. A minor gap is the lack of direct browsing or listing of all articles, but search and category tools largely compensate.
Актуальное содержимое материала KZSalesHub в Markdown с метаданными и URL для цитирования. Принимает slug или полный URL.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | slug (например nfr-licenziya-chto-mozhno) или URL страницы | |
| format | No | markdown |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint and non-destructive behavior, so the safety profile is covered. The description adds that the content is 'current/up-to-date' and includes metadata plus a citation URL, which is useful but not rich behavioral context (no pagination, no error behavior for bad slugs).
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, front-loaded with the returned value and followed by the accepted input form. No filler, no repetition.
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, so the description carries the return-value burden and does so: Markdown body plus metadata and a citation URL. It is nearly complete for a single-resource reader; only missing guidance about invalid/missing slugs or how format=text differs.
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 50%: 'slug' is documented with an example, but 'format' has no description at all. The description compensates partly by clarifying that the input accepts either a slug or a full page URL, adding meaning beyond the schema; the format parameter's markdown/text distinction is left entirely to the enum.
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: returns the current full content of a KZSalesHub article ('Актуальное содержимое материала') in Markdown with metadata and a citation URL. This clearly distinguishes a full-document fetch from the search_* siblings, though it never names 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?
No when-to-use or when-not-to-use guidance. It does not tell the agent to prefer this over search_knowledge/search_cases when it already has a slug, nor does it explain what to do when only a query is available. Usage is only inferable from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Темы, типы контента с количеством, системы, роли, технологии и отрасли. Полезно вызвать первым, чтобы понять устройство базы.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 adds nothing beyond that – no hint about output shape, whether counts are ever stale, or how many categories come back. It doesn't contradict annotations, but it doesn't enrich them either.
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?
One dense clause enumerating resources followed by a single orienting sentence. No filler, front-loaded with what the agent gets.
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-arg, read-only lister this is largely adequate, but with no output schema and no annotation-independent detail on return shape, the agent still can't predict the response format. One extra clause on what the entries look like would close the gap.
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?
Zero parameters, so the schema cannot carry meaning and the description correctly spends no words on parameters. Baseline 4 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 Russian description names concrete resources returned (themes, content types with counts, systems, roles, technologies, industries), which distinguishes it from siblings like search_knowledge or get_article. However, it never states the verb – it's ambiguous whether it lists, enumerates, or returns these taxonomies.
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 'useful to call first to understand the structure of the base' – a clear when-to-use cue that no sibling offers. No when-not-to-use or exclusion, but the entry-point framing is strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Поиск по разборам вендоров, продуктов, стартапов и практическим кейсам внутри материалов KZSalesHub.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes | Запрос на русском или английском, свободной формой |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety and idempotency profile is covered structurally. The description adds only the content scope (what is searched) and says nothing about ranking, result shape, or pagination behavior, so it clears the lowered bar but adds limited behavioral value.
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?
A single sentence that front-loads the verb and enumerates the covered content types without waste. It is appropriately sized for the tool's simplicity, with no filler or repetition.
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 two-parameter read-only search the description is functionally adequate, and no output schema exists so return values need not be explained. However, in a family containing three separate search tools, the absence of any routing guidance leaves the agent under-informed about which search to invoke.
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 50%: 'query' is described as free-form Russian/English, while 'limit' has no textual description (though its default=8, min=1, max=20 make its role as a page size fairly inferable). The description adds no parameter detail whatsoever, so the schema does the work and this lands at the borderline baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('Поиск') and a concrete resource scope: vendor/product/startup breakdowns and practical cases inside KZSalesHub. An agent knows what content is indexed, but nothing distinguishes this from siblings search_knowledge and search_playbook, which is required for 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?
There is no when-to-use guidance, no exclusions, and no mention of the alternative search tools (search_knowledge, search_playbook) that an agent must choose between. Usage must be inferred entirely from the content-scope phrase.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Поиск по всей публичной базе KZSalesHub (B2B и IT-продажи, маркетинг, операции, стартапы, ИИ; Казахстан и Центральная Азия): материалы, системы (playbook), фреймворки, термины, книги, программы. Учитывает морфологию и синонимы RU/EN. Возвращает заголовок, URL оригинала, тип, категорию, дату, релевантность и выдержку.
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | Необязательный фильтр по типу | |
| limit | No | ||
| query | Yes | Запрос на русском или английском, свободной формой |
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 adds genuinely new behavioral context: it handles morphology and RU/EN synonyms, and it will return title, original URL, type, category, date, relevance, and an excerpt — useful for an agent deciding what to expect.
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?
A single dense sentence that front-loads the core action and scope, followed by a compact list of matching behavior and return fields. No wasted preamble, though the middle enumeration is somewhat list-heavy.
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 search tool with no output schema, the description covers scope, language/morphology handling, and the return field set, and the annotations cover safety. An agent has everything needed 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 coverage is 67%, and the description's enumeration of content kinds (playbook, фреймворки, термины, книги, программы) roughly mirrors the `type` enum values, adding a little semantic anchoring. It says nothing about `limit` or the free-form nature of `query` beyond what the schema already states, so baseline 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 names a specific verb (поиск) and resource (вся публичная база KZSalesHub) and enumerates the content domains it spans (B2B/IT, marketing, playbooks, frameworks, etc.). The phrase 'по всей публичной базе' implicitly separates it from narrower siblings like search_cases and search_playbook, though no sibling is named 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?
Scope ('вся публичная база') implies this is the broad, catch-all search, which is usable context. However, there is no explicit when-to-use/when-not guidance and no pointer to alternative tools such as search_cases or get_article, so the agent must infer routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Поиск по Sales OS и другим системам (playbook), программам обучения и фреймворкам — пошаговые методики, а не отдельные статьи.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes | Запрос на русском или английском, свободной формой |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered structurally. The description adds no behavioral context beyond that - nothing about result ranking, pagination, what the 'limit' truncation does, or query behavior. Beyond the annotations the description carries no extra behavioral signal.
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?
A single front-loaded sentence that immediately states the search domain and then the content-type caveat. There is no filler, though the parenthetical '(playbook)' and the dash clause make it slightly dense for one line.
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?
There is no output schema, so the description should carry more of the load, and the tool sits among four sibling search tools with no routing guidance to any of them. Return shape, result ordering and how 'limit' behaves are all unspecified, leaving an agent able to call the tool but not to reason about its results or when to prefer it.
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 50%: 'query' is documented in the schema as free-form RU/EN, but 'limit' has no description (only default 8, min 1, max 20). The description adds no parameter meaning at all - it never mentions the query form or the result cap - so it does not compensate for the coverage gap as the rubric requires below 80%.
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 verb (поиск) and a concrete resource class: Sales OS systems/playbooks, training programs and frameworks. It also draws a content-type boundary (пошаговые методики, а не отдельные статьи), which separates it from article retrieval. It stops short of naming the sibling search tools (search_knowledge, search_cases), so differentiation is semantic 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?
Usage is implied through the negative qualifier 'не отдельные статьи', which tells the agent this is for methodologies rather than single articles. However, no alternative tool is named and no condition for choosing search_playbook over search_knowledge/search_cases/get_article is stated. The agent must infer routing from the content-type hint alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
get_articleget_related_contentlist_categoriessearch_casessearch_knowledgesearch_playbookIndependent weekly on AI in B2B revenue teams: articles, frameworks, skills, playbooks, datasets.
Expert knowledge base for sales, negotiation, strategy, operations, and risk.
Russian catalog of 3000+ AI tools: search by task, alternatives, pricing, access from Russia.
AI sales — prospect discovery, ICP scoring, outreach generation.
Add one secure layer between your agents and this server.
