v8help-mcp

by sergeyfedyakov

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.10.0
Disambiguation4/5
The tools are largely distinct: search, page retrieval, related pages, hierarchy, index build/status, and config access have clear boundaries. The only mild overlap is discover vs config_get, which both surface configuration/state, but their focus on autodiscovery vs effective settings is enough to separate them.
Naming Consistency3/5
Names are readable and mostly snake_case, but the conventions are mixed: bare verbs (search, build, discover), nouns (related, hierarchy), verb_noun (get_page), and the inverted noun_verb pattern (config_get, config_set). This is inconsistent but not chaotic.
Tool Count5/5
Nine tools form a well-scoped set for a documentation/help-server: four read/retrieval operations, two index lifecycle operations, and three config/discovery operations. Each tool has a distinct job and none feel redundant.
Completeness5/5
The surface covers the full help-documentation workflow: search, page content, related links, table of contents, index rebuild with async status, and configuration discovery/update. I see no critical dead ends for agents using this server.
Average 3.7/5 across 9 of 9 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 5 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden, and it usefully discloses that the result includes both outgoing and incoming links, implying a read-only lookup. However, it does not describe the output format, pagination, error behavior, or how the two link directions are represented.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single compact sentence with no filler. The core resource 'related pages' is front-loaded and the parenthetical detail about outgoing and incoming links adds meaningful scope without waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, but with no output schema and no annotations, the description leaves the return structure and behavior largely to inference. An agent still does not know whether the result is a list of page IDs, page objects, or a structured link map, and there is no disambiguation from hierarchy.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents the single id parameter with 100% coverage. The description's 'по id' merely confirms the parameter usage and adds no format, interpretation, or value constraints beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource: related pages, and specifies the scope: outgoing and incoming links, keyed by id. This distinguishes it from siblings like search and get_page, though it lacks an explicit verb and does not explicitly contrast with hierarchy.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided: there is no mention of when to use this tool instead of search, get_page, or hierarchy, and no exclusions or prerequisites are given. The intended use can be inferred from the noun phrase, but the tool does not state it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It usefully reveals that this is an FTS5 search (implying query syntax semantics) and that results include relevance scores and snippets. However, it does not disclose filtering defaults (e.g., behavior when kind/section are omitted), limit defaults, or pagination behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences, no fluff. The core function is front-loaded and the return format gets a dedicated sentence. Every part earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description plus schema covers the essentials: parameters are documented and the return format is stated despite the lack of an output schema. However, with no annotations and no usage guidance, an agent still lacks context on default filtering semantics, result limits, and when to choose this tool over nearby siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all four parameters. The description adds no parameter-specific meaning beyond the schema, which is acceptable given the high coverage — baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific function — full-text search over the 1C help (FTS5) — and describes the return format (pages with relevance score and snippets). It is clear what the tool does, and the FTS5 scope differentiates it from siblings like related, get_page, and discover, though it does not explicitly name an alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. The description is purely definitional; it does not mention when to prefer search over related, discover, or hierarchy, nor does it state any exclusions or prerequisites. The intended usage is only implied by the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden of behavioral disclosure. It reveals that the tool exposes effective configuration values, but it does not state that the operation is read-only, describe the response format, or mention error or side-effect behavior. This is only minimal behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence with no filler. The key idea ('current settings / effective config') is front-loaded, and the listed examples add substance without unnecessary length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter config retrieval tool, the description is adequate: it states the purpose and sample contents. But with no output schema and no annotations, it leaves the response format and full key set unspecified, and 'and so on' is vague. It is minimally viable but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters and schema coverage is 100%, so the baseline is already 4. The description adds useful context by naming the config categories the result will contain, helping an agent anticipate the returned data beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies a specific resource ('current settings / effective config') and lists concrete content areas such as embedder, search.backend, bin_dir, and books. It is clear this tool returns configuration, though it relies on the tool name to imply the read action and does not explicitly differentiate from config_set.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'current settings' implies this is the read-oriented counterpart to config_set, so an agent can infer when to use it. However, there is no explicit guidance about when to use this tool versus alternatives, no exclusions, and no mention of config_set as the write path.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Аннотаций нет, поэтому описание несет полную нагрузку. Оно раскрывает, что инструмент обращается к реестру Uninstall/ФС и сканирует localhost-порты, что полезно, но не заявляет явно об отсутствии побочных эффектов и не описывает поведение при недоступности компонентов.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Одно предложение с двоеточием, перечисляющее все ключевые элементы вывода без лишних слов. Главная идея вынесена в начало, каждый элемент списка информативен.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Для инструмента без параметров и без выходной схемы описание достаточно полно: перечислены каталог bin, эмбеддеры и состояние индекса. Не хватает формата возвращаемых данных и четких критериев выбора среди siblings, но для вызова discover этого достаточно.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
У инструмента 0 параметров, схема пуста и покрытие схемы 100%. Описанию не нужно пояснять аргументы; по правилам для нулевого числа параметров ставится базовая оценка 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Описание содержит конкретный глаг 'Показать' и точно перечисляет состав результата: каталог bin, эмбеддеры на localhost-портах, состояние индекса. Это отличиеет discover от sibling-инструментов, хотя явного противопоставления config_get/search нет.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Нет указаний, когда использовать discover вместо конкурирующих инструментов: не названы альтернативы, условия выбора или сценарии, где discover неуместен. Агент должен сам догадываться о месте этого инструмента среди config_get, search и related.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It reveals that the build is asynchronous, that the status can be running/done/error, and that progress information is included. It does not explicitly state that the operation is read-only or describe error payload details, but the core behavior is meaningfully disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The entire description is one compact sentence that front-loads the tool's purpose and packs in the async nature, possible statuses, and progress. There is no filler or redundant wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter status tool, the description covers the key context: it queries by job_id, is asynchronous, returns status values, and includes progress. A small gap remains because there is no output schema and no annotation, so the exact response shape and any polling/repeated-call semantics are left unspecified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already fully documents job_id as 'Идентификатор job из build', and the description only repeats that the status is queried by job_id. With 100% schema description coverage, the description adds no new parameter meaning beyond the schema, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies this as a status lookup for an asynchronous build keyed by job_id, and enumerates expected states (running/done/error) plus progress. It is specific enough to be distinguished from the sibling tool 'build', but it does not explicitly name or contrast that alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no explicit guidance on when to use this tool versus siblings such as 'build'. The mention of job_id implies it should be used after an asynchronous build, but the description does not state this prerequisite, polling behavior, or when an alternative would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does add useful context: the atomic save behavior to v8help.toml and the set of valid keys with value domains. But for a mutation tool it fails to disclose whether unspecified settings are preserved or reset, whether a rebuild is required for changes to take effect, or what validation/error behavior occurs on invalid keys.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single dense sentence with the action front-loaded ('Изменить настройки и сохранить в v8help.toml (атомарно)') followed by the key enumeration. The key list is long but earns its place since the schema does not enumerate valid keys. It could be better organized, but there is no wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations and no output schema, the description covers the what and where well but omits post-invocation behavior: return value, whether a rebuild is needed after configuration changes, and whether values are merged into or replace the existing config. The nested embedder.index/query structure also hints at depth the flat-keys contract does not clarify. Adequate for basic invocation, with clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only says 'Плоские ключи -> значения' (flat keys -> values) with 100% coverage, so the description adds real value by enumerating the valid keys and their value types — search.backend options, embedder.index/query sub-keys, bin_dir, lang, books. This exceeds the schema baseline of 3, though it stops short of specifying exact types for every key.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Изменить' — change), a precise resource (settings), and the persistence target (v8help.toml) with atomic-write semantics. The enumeration of valid keys and value domains (fts|hybrid|vectors) defines the exact scope, making it clearly distinguishable from the sibling config_get (its read counterpart).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The verb 'Изменить' implies this is the write tool and config_get is the read tool, and the key list tells the agent what can be modified. However, the description never explicitly says when to use this tool versus alternatives — no mention that reading settings should route to config_get, and no exclusions or conditions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the disclosure burden. It reveals the behavior change based on the section parameter and describes the output shape for both cases. It does not explicitly state read-only/no side effects, but the semantics strongly imply a read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One compact sentence with a clear conditional structure. It front-loads the tool purpose and wastes no words on filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-optional-parameter tool with no output schema, the description gives an adequate high-level shape of the response in both modes. It still leaves the exact structure of the section summary and 'top-level objects' underspecified, so it is not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only says section is a 'Раздел для детализации', while the description adds practical meaning: providing section changes the result to grouped top-level pages with counts. That is meaningful value beyond the parameter description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies the resource (оглавление/hierarchy) and defines two distinct output modes depending on the optional section parameter. It is clear about what is returned, though it does not explicitly reference sibling tools to sharpen differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear conditional guidance: omit section for a summary, provide section for page groups with counts. However, it does not state when to use this tool over siblings such as related, search, or discover, so tool-selection guidance is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and discloses the non-obvious behavior that articles over 4000 characters are not returned in full, but rather as a chunk list plus first chunk, with chunk=N to fetch further chunks. This is substantial transparency, though it omits error/not-found behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three front-loaded sentences with no redundancy. The first sentence states the core operation, the second defines id cardinality, and the third explains important long-article behavior. Dense but every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of an output schema, the description explains the key return behavior: normal pages return full text, while long articles return a chunk list and first chunk. It also covers multi-page limits. A full response envelope or error behavior is missing, but for correct invocation the description is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the schema documents types, but the description adds meaningful semantics: id can be a filename without .md or a numeric id, arrays must contain 2-10 items, and max_chars bounds the aggregate response. This goes beyond the bare property descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the operation: fetching the full text of a help page by identifier, with concrete identifier forms (filename without .md or numeric id). It distinguishes itself from siblings like search or related by framing the lookup as identifier-based, though it does not explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear invocation context: use a string for one page, an array for 2-10 pages bounded by max_chars, and chunk=N for long articles. It does not explicitly mention when not to use it or name sibling alternatives, but the conditions for using this tool are evident.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries the full burden and does well: it discloses asynchronous behavior (returns job_id immediately), potential runtime ('Может занять минуты'), and points to build_status for progress. It does not explicitly mention side effects like overwriting an existing index, but 'пересобрать' strongly implies it. This is meaningful behavioral context beyond a bare summary.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact: three sentences that front-load the purpose and pipeline, then add async behavior, timing, and parameter clarification. There is no fluff or repetition; every sentence contributes essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema and annotations, the description covers a reasonable amount: async job lifecycle, job_id return, progress via build_status, expected duration, and chunking semantics. It does not detail default values or side effects for force/cleanup, but the schema handles parameter-level details, leaving only minor gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds extra meaning for chunk_size/chunk_overlap by explaining they are in characters and used when splitting long articles, which complements the schema's brief descriptions. This additional context justifies a slightly higher score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description leads with a specific verb and resource: 'Пересобрать индекс' (rebuild the index), and outlines the exact pipeline: unpack .hbk, consolidate md corpus, FTS indexing + chunking. It also distinguishes itself from the sibling tool build_status by stating that build returns a job_id and that result/progress are obtained via build_status. This is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly indicates when to use this tool: when an index rebuild is needed. It also specifies the asynchronous nature and directs the agent to build_status for progress and results. However, it does not explicitly state when not to use it or mention alternatives such as search or discover, though the core use case is fairly obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![v8help-mcp MCP server](https://glama.ai/mcp/servers/sergeyfedyakov/v8help-mcp/badges/card.svg)](https://glama.ai/mcp/servers/sergeyfedyakov/v8help-mcp)

Score Badge

Copy to your README.md:

[![v8help-mcp MCP server](https://glama.ai/mcp/servers/sergeyfedyakov/v8help-mcp/badges/score.svg)](https://glama.ai/mcp/servers/sergeyfedyakov/v8help-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/sergeyfedyakov/v8help-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server