gti-1c-mcp

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation4/5
Most tools have clearly distinct purposes, but there is overlap between keyword and semantic search, and between suggest_access_profile and suggest_profile_by_job. Descriptions help an agent differentiate them, though occasional ambiguity remains.
Naming Consistency3/5
Naming mixes verb_noun (list_instructions), verb_by_noun (search_by_role), and non-verb forms (onec_health). The inconsistency is readable but not predictable, making it harder to guess tool names.
Tool Count4/5
18 tools is on the heavier side but justified by the server's three subdomains: instructions, RBAC profiles, and live 1C queries. Each tool has a specific role, though the count slightly exceeds the ideal range.
Completeness4/5
The tool surface covers the full read-only workflow: listing, searching, retrieving, explaining, validating, and checking health. Minor gaps exist such as no write/update capabilities, but for the apparent advisory purpose, coverage is solid.
Average 4/5 across 18 of 18 tools scored. Lowest: 3.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 35 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
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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

Behavior2/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 disclosing behavioral traits. It does not mention pagination, result limits, filtering effects, or any potential side effects. The only contextual addition is that instructions are 'загруженных в базу знаний MCP сервера', but this does not convey behavior beyond the data source.
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 concise, consisting of exactly two sentences. The first sentence states the tool's purpose, and the second lists the output fields. It is front-loaded, free of unnecessary detail, and every word contributes value.
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 simple list tool with two optional filters, the description adequately conveys essential purpose and return structure. The schema covers parameter details, and the description confirms the fields in the response. However, it does not mention the availability of filters or contrast with search tools, which leaves some ambiguity, hence not a perfect score.
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 input schema provides complete descriptions for both parameters (filter_code and filter_keyword) with examples, achieving 100% coverage. The tool description adds no extra parameter semantics and does not even mention that filters exist, so the score matches the baseline for high schema coverage.
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 explicitly states 'Возвращает список инструкций пользователя 1С.БИТ' (Returns a list of 1C.BIT user instructions), clearly identifying the action and resource. It also specifies the output structure (id, code, name, source), which further clarifies the scope and differentiates it from search-oriented sibling tools.
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?
There is no guidance on when to use this tool versus sibling tools like search_instructions or semantic_search_instructions. The description simply states what the tool does without mentioning alternatives, prerequisites, or exclusion criteria, leaving the agent to infer usage from the tool name alone.
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 provided, so the description carries the full burden of behavioral disclosure. It states the tool returns a matrix, implying a read-only operation, but does not mention any potential side effects, authentication requirements, response size, or performance characteristics. The description is too high-level to fully inform the agent about the tool's 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?
The description is concise, with two sentences that front-load the primary purpose and a clear use case. It avoids extraneous words and is well-structured, though it could include a bit more detail without becoming verbose.
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 provides the core purpose and usage context, but given the absence of an output schema and annotations, it lacks details about the exact structure of the matrix, how filters affect the result, and any size or performance implications. It is adequate for a straightforward retrieval tool but not fully complete.
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 input schema covers 100% of the parameters with descriptions for search_keyword, filter_requires_transport, and filter_requires_accounting. The tool description does not add any parameter-specific meaning beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: 'Возвращает полную матрицу ролей RBAC для 1С:БИТ.ФИНАНС' (Returns the full RBAC roles matrix for 1C:BIT.FINANCE). It identifies the resource (RBAC roles matrix) and its scope (full matrix), which distinguishes it from sibling tools like search_by_role that focus on searching rather than returning the complete matrix.
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 gives explicit usage context: 'Используйте для изучения доступных бизнес-функций и их маппинга на роли 1С' (Use to study available business functions and their mapping to 1C roles). This tells the agent when to use the tool, but it does not mention alternatives or when not to use it, so it stops short of a full 5.
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 provided, so the description must disclose side effects, permissions, or failure modes. It does not explicitly state that the tool is read-only or what happens if a profile is not found, instead only describing the output content. This leaves the safety profile ambiguous.
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 concise and front-loaded, stating the purpose in the first clause. It avoids unnecessary details and includes only essential information about input and output scope.
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?
With no output schema and no annotations, the description should explain the return format and potential errors. It describes the content of the explanation but not its structure or limitations, leaving some gaps for a simple tool.
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 provides full coverage of the profile_id parameter, including the fuzzy search behavior and example format. The description merely repeats 'accepts id or name' without adding additional semantics, so it meets the baseline but offers no extra value.
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 clearly states that the tool explains a 1C access profile in business language, listing specific output aspects (employee capabilities, accessible sections, required approvals). It also notes it accepts profile id or name, distinguishing it from sibling tools that handle instructions or raw queries.
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 implies the tool is for explaining profiles in non-technical terms but does not explicitly state when to use it over alternatives like get_1c_access_groups or search_by_role. There is no mention of exclusions or preferred scenarios, though the business-language framing provides some context.
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. It discloses a prerequisite ('Требует настроенного подключения к 1С') but does not explicitly state it is a read-only operation or describe response format, error handling, or performance implications. The verb 'Получает' implies retrieval, but lacks explicit safety assurances.
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 concise sentences, front-loaded with the primary action and resource. The examples of document types and the prerequisite are both valuable additions without redundancy.
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 tool has 6 parameters and no output schema. The description covers purpose, filters, and prerequisites, but lacks any description of the returned document structure or pagination behavior beyond the limit parameter. This is adequate but leaves gaps for an agent needing to interpret results.
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 coverage is 100%, so baseline is 3. The tool description adds examples of document types and filter categories, but mostly restates what the schema already covers. The detailed parameter descriptions in the schema handle the semantics.
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 clearly states a specific verb and resource: 'Получает документы из рабочей базы 1С:БИТ.ФИНАНС' with concrete document examples (путевые листы, платёжные поручения). It distinguishes itself from siblings like get_1c_metadata or execute_1c_query by focusing on document retrieval with filtering.
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 implies usage through its stated filtering capabilities and prerequisite connection, but does not explicitly contrast with alternative tools like execute_1c_query or specify when not to use. It does hint at a workflow by referencing get_1c_metadata in the schema parameter description for document types.
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 must convey behavioral traits itself. It discloses a dependency (requires configured 1C connection) and implies a read-only operation through 'Получает'. However, it does not explicitly state the operation is non-mutating or provide details on error behavior or response characteristics.
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 two sentences, front-loaded with the main function, followed by usage scenarios and a necessary prerequisite. It contains no redundant or filler text, making it concise and well-structured.
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?
Without an output schema, the description reasonably sets expectations by stating it returns access groups, assigned users, and roles. It also mentions the connection prerequisite and two primary use cases. Some details about response format or error handling are absent, but for a simple lookup tool, the description is sufficiently complete.
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?
All three parameters are fully described in the schema (100% coverage), so the description adds minimal semantics beyond what is already structured. The phrases 'все группы' and 'конкретного сотрудника' loosely map to group_name and user_login, but the schema already provides comparable context.
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 clearly states that the tool retrieves access groups and assigned users from the 1C database, with specific use cases of finding a user's roles or listing all groups. This distinguishes it from sibling tools like execute_1c_query or list_instructions by focusing on access group data.
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 implies when to use the tool (to find out real roles of an employee or list all groups) and notes a prerequisite (configured connection to 1C). However, it does not explicitly mention alternatives or when not to use it, making the guidance implied rather than explicit.
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 provided, so the description must fully disclose behavior. It explains the role-to-level mapping but does not describe the output format, handling of unknown/conflicting roles, or empty input, leaving significant behavioral gaps.
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?
A single sentence with a compact enumeration of the possible levels. It is front-loaded with the verb and resource, and every word contributes meaning without 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?
For a deterministic mapping tool with one parameter and no output schema, the description covers the core behavior and enumerates all possible outcomes. It lacks explicit edge-case handling but is otherwise sufficient for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes the roles parameter as an array of 1C role names with 100% coverage. The description adds context about how these roles map to approval levels, but does not enrich the input parameter's format or constraints beyond the schema.
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 clearly states the tool determines the approval level for a set of roles, listing all possible levels (standard, accounting, transport, transport_accounting) with their meanings. This distinguishes it from sibling tools like validate_roles or get_roles_matrix.
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 implied usage is when you need to derive an approval level from a set of 1C role names. It doesn't explicitly mention alternatives or exclusions, but the context is unambiguous for a simple mapping function.
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?
No annotations are provided, so the description carries the burden. It discloses the required connection and lists returned fields, implying a read-only operation, but does not mention side effects, pagination, or error behavior. The requirements for .env variables add some behavioral context, but it's limited.
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 two sentences, front-loaded with the main purpose, and every sentence contributes useful information (purpose, return fields, prerequisites). No redundancy or filler.
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 tool's simplicity, the description covers the main purpose, return content, and a critical prerequisite. The lack of annotations is compensated by the clear read-only implication and explicit connection requirements. It doesn't explain all edge cases, but for a list tool with full schema coverage, it's largely sufficient.
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 baseline is 3. The description adds no additional parameter semantics beyond what the schema already documents. It mentions return fields that partially relate to filters, but doesn't explain parameter interactions, so it neither detracts nor adds value.
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 clearly states the tool obtains a list of 1C users from the working database, using the verb 'получает' and specifying the resource. It also lists the returned fields (ФИО, логин, должность, подразделение, группы доступа), distinguishing it from sibling tools like get_1c_access_groups or execute_1c_query.
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 provides a prerequisite (requires configured 1C connection via ONEC_* env vars) but does not explicitly state when to use this tool relative to alternatives like search_instructions or get_1c_documents. It implies usage for retrieving user lists but no exclusions or alternative mentions.
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 provided, so the description must carry the full burden of behavioral disclosure. It only states that the full text is returned, but does not disclose what happens when the id/code is not found, whether max_chars truncates the text, or any other potential side effects. This is a significant gap for a retrieval tool with no annotations.
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, well-structured sentence that front-loads the main action and includes essential input options. It contains zero wasted words and is immediately understandable.
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 simple retrieval tool with two parameters and no output schema, the description covers the core purpose and input formats. However, it omits important behavioral details such as the effect of max_chars (truncation?) and error/not-found behavior, which are not covered by any schema or annotation. This incompleteness makes it minimally viable but not fully comprehensive.
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 already provides 100% coverage with detailed descriptions for both 'id' and 'max_chars'. The description adds value by clarifying that the id can come from list_instructions/search_instructions, providing a direct link to the sibling workflow. This goes slightly beyond the schema, warranting a 4.
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 clearly states the tool returns the full text of a 1C.BIT user instruction, using a specific verb ('returns') and resource ('full text of instruction'). It distinguishes itself from sibling tools like list_instructions and search_instructions by specifying that input comes from those tools or by code, making its role as a fetch-by-id/code operation clear.
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 implies a clear workflow: first use list_instructions/search_instructions to get an id, then call this tool, or provide a known instruction code. It provides context on when to use the tool but does not explicitly state alternatives or exclusions (e.g., 'use semantic_search_instructions when...'), so it loses a point for not being fully explicit.
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?
No annotations are provided, so the description carries the full transparency burden. It discloses the underlying algorithm (TF-IDF + cosine similarity) and the semantic-matching behavior with an example. However, it does not explain score semantics, result ranking, or limitations (e.g., whether it searches full text or titles), leaving some behavioral aspects unspecified.
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 two sentences long, front-loads the verb and resource, and includes a concrete example. Every sentence contributes useful information with no 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 search tool with three parameters and no output schema, the description explains the search scope and algorithm but stops short of describing the return format or ranking. The example and parameter schema cover most essentials, but the absence of output details leaves a moderate gap.
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 input schema has 100% description coverage for all three parameters, so baseline is 3. The description adds a natural-language query example, but it does not provide additional meaning for limit or min_score that isn't already in the schema. Therefore, no added value beyond the structured fields.
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 clearly states the tool performs semantic search over 1C.BIT instructions using TF-IDF and cosine similarity, and explicitly contrasts it with keyword search ('лучше, чем keyword-поиск'). It provides a concrete example, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies preferred use for natural-language/semantic queries ('Понимает смысловые запросы лучше, чем keyword-поиск'), which distinguishes from the sibling search_instructions tool. However, it does not explicitly name the alternative tool or state when to avoid this tool, so the guidance is clear but not fully explicit.
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 provided, the description carries the full burden. It explicitly discloses the most critical behavior: 'запросы только на чтение (SELECT), изменение данных не поддерживается' and 'Требует настроенного подключения к 1С'. This goes beyond general descriptions and helps the agent avoid misuse. Not all edge cases are covered, but the key constraints are transparent.
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 three sentences long and front-loaded with the core verb ('Выполняет'). Each sentence adds value: the first states the action, the second gives scope and examples, and the third highlights essential warnings. There is no unnecessary fluff.
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?
The tool has no output schema and no annotations, yet the description effectively communicates what data can be accessed, the read-only restriction, and the connection prerequisite. It does not describe the return format, but for an arbitrary query tool this is less critical since the query itself determines the result. Overall, it provides enough context for an agent to decide when and how to use it.
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 coverage is 100% — every parameter has a description in the schema, including an example for query_text. The description text adds no additional parameter semantics beyond what the schema already provides, 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Выполняет произвольный запрос к данным 1С' which is a specific verb and resource. It further specifies the scope ('любого справочника, регистра или документа БИТ.ФИНАНС') and gives concrete examples (сотрудников, ТМЦ, договоры). This clearly distinguishes it from specific sibling tools like get_1c_documents, as it handles arbitrary queries.
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 implies usage for general data retrieval from 1C and states the read-only limitation, but it does not explicitly compare with alternatives or mention when to prefer specific tools like get_1c_documents. It would benefit from saying 'Use this for custom queries; for predefined data, use the specific getters'.
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?
No annotations are provided, so the description carries the full burden. It states that the tool returns a list of positions and supports substring filtering, which is transparent about its core behavior. However, it does not explicitly mention that it is read-only or describe the output format, making it only minimally adequate.
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 three concise sentences, front-loaded with the main purpose and followed by supporting details. Every sentence earns its place with no filler or redundant content.
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 simple list tool with two optional parameters and no output schema, the description covers the essential purpose and use case. It could mention what the returned items look like (e.g., titles only), but the explicit link to suggest_profile_by_job provides sufficient context for an agent.
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 input schema has 100% coverage with descriptions and examples for both limit and filter parameters, so the schema already handles parameter semantics. The description adds no extra parameter information, warranting the baseline score of 3.
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 clearly states the action: 'Возвращает список должностей из базы данных сотрудников' (Returns a list of positions from the employee database), including a count of 417 positions. It also distinguishes its purpose by noting it helps find the exact job title before calling suggest_profile_by_job, which is a sibling tool.
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 provides a specific use case: 'Помогает найти точное название должности перед вызовом suggest_profile_by_job' (Helps find the exact job title before calling suggest_profile_by_job), and mentions substring filtering as a feature. It does not explicitly state when not to use it, but the context is clear enough for an agent to decide.
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 disclosing behavior. It describes the tool's actions (checks roles, identifies missing ones, recommends mandatory roles), which gives some transparency about its read-only nature. However, it does not explicitly state whether the tool modifies data, requires permissions, or what happens on invalid input.
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 sentence that efficiently captures the tool's purpose and behavior without extraneous words. It is front-loaded with the main action ('Проверяет корректность...') and details the specific checks performed.
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?
The description adequately explains the tool's input (set of roles) and output (which roles exist, which missing, mandatory role recommendations) despite lacking an output schema. It is self-contained for a single-parameter validation tool, though it omits details about error handling or permission requirements.
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 provides 100% coverage for the single 'roles' parameter. The description adds context by specifying that roles are 1C roles and that they are checked against a matrix, which clarifies the parameter's purpose beyond the schema's generic 'array of role names'.
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 clearly states the tool validates a set of 1C roles against the role matrix, identifying missing roles and recommending mandatory ones. This specific verb+resource scope distinguishes it from sibling tools like get_roles_matrix and suggest_profile_by_job.
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 implies the tool is used when you need to check the correctness of roles, but it does not explicitly state when to use it versus alternatives, nor does it mention any exclusions. No explicit guidance on when not to use it or what alternative should be used in other cases.
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 transparency burden. It discloses the main prerequisite (configured connection), implies a read-only operation, and describes the return content (list of objects with attributes). It does not discuss potential large response sizes or pagination, but for this simple metadata tool it provides meaningful 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 two sentences, front-loaded with the core function and followed by usage guidance and a prerequisite. Every sentence adds value with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and lack of output schema, the description gives sufficient context about the returned data (list of objects and attributes) and the connection prerequisite. It could be more complete with a note on result limits or pagination, but overall it covers the essential context for an agent to invoke the tool effectively.
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 descriptions cover 100% of the parameters, including detailed enum meanings for object_type and the effect of include_attributes. The description adds only general purpose context and does not elaborate per-parameter semantics beyond the schema, so a baseline of 3 is appropriate.
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 clearly states the tool returns 1C configuration metadata, explicitly listing the kind of objects (directories, documents, registers) and mentioning 'their attributes'. It also distinguishes itself from sibling query tools by noting it should be used to learn correct table and field names before execute_1c_query.
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 gives explicit usage context: use before execute_1c_query to discover names, and it notes the prerequisite of a configured 1C connection. However, it does not mention when not to use it or reference alternatives for metadata retrieval.
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?
No annotations are provided, so the description carries the full burden. It discloses that it shows status, configuration, and tool list, but does not explicitly state whether it is read-only or if any side effects exist. For a health check, this is adequate but not deeply transparent.
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 two sentences, front-loaded with the primary action, and contains no unnecessary information. Every sentence adds value, making it highly concise and well-structured.
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 simple tool with no params and no output schema, the description covers the key aspects: what it checks, what it shows, and when to use it. It mentions the return content (status, config, tool list), so it's reasonably complete, though it could specify error behavior or prerequisites.
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 tool has zero parameters, so the schema coverage is effectively 100%. Baseline for 0 params is 4 per rubric, and the description does not need to add parameter details. It correctly focuses on behavior rather than parameters.
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 clearly states it checks the availability of the 1C database HTTP service and displays connection status, configuration, and tool list. This is a specific verb+resource that distinguishes it from sibling tools like get_1c_documents or execute_1c_query.
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?
Explicitly says 'Call it first when working with a live 1C database', giving a clear when-to-use directive. However, it does not mention when not to use it or name alternatives, so it lacks the full explicit exclusions of a 5.
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?
No annotations are provided, so the description carries the full burden. It indicates a read-only search action ('находит') but does not disclose potential limitations such as partial matching behavior, output format, or pagination. The description is adequate but not rich.
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 consists of two concise sentences, front-loaded with the action and resource. There is no redundant information, and every sentence adds value.
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 simple one-parameter search tool with no output schema, the description covers what it does and when to use it. It implies the return value (profiles and business functions) sufficiently, though it does not elaborate on matching behavior or output format.
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 already provides full coverage for role_name, including case-insensitivity and examples. The tool description adds the business context (understanding which profile a role belongs to) and a different example, which supplements the schema without repeating it verbatim.
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 clearly states the tool finds access profiles and 1C business functions by role name, with a concrete example ('бит_ИсполнительКазначейства'). The verb+resource combination is specific and distinguishes it from siblings such as search_instructions or validate_roles.
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 a clear use case for 1C administrators who see a role and want to discover its associated profile. However, it does not explicitly mention when not to use the tool or name alternative tools, so it falls short of a perfect score.
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 behavior burden. It discloses that this is a full-text keyword search over a knowledge base and that results include a relevance score, which is meaningful behavioral context for a search operation. It does not explicitly state read-only or edge-case behavior, but the search semantics are clear.
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 two sentences, front-loaded with the core action, and every clause adds value (resource, search type, relevance, usage context). There is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 2-parameter tool with no output schema, the description covers what the tool does, how it works (full-text keyword search), what it returns (relevant instructions with relevance score), and when to use it. The schema handles parameter details, so the description is sufficiently complete.
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 baseline is 3. The description does not add parameter-level details beyond the schema; it only echoes the idea of keyword search, while the query examples in the schema are already present. No additional semantic value is provided for 'limit' or 'query' beyond their existing descriptions.
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 uses a specific verb ('Ищет') and identifies the exact resource ('инструкции пользователя 1С.БИТ') along with the search mechanism ('по ключевым словам (полнотекстовый поиск по базе знаний)'). It clearly distinguishes itself from siblings like list_instructions and get_instruction by emphasizing keyword-based full-text search and relevance scoring.
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?
Provides explicit use cases ('как сформировать...', 'где найти...', 'как заполнить...') for answering user questions about 1C.BIT. While it does not mention when not to use it or name alternative tools like semantic_search_instructions, the context is clear enough for common scenarios.
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 of behavioral disclosure. It reveals key traits: keyword-based matching (no LLM), the NEED_CLARIFICATION response, the requirement to keep answer order, and a strong warning to never skip step 1. It doesn't cover failure modes or edge cases, but it goes well beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections for modes and protocol, a numbered two-step process, and a final imperative warning. Every sentence contributes necessary context; there is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having no output schema, the description thoroughly covers the entire interaction lifecycle: first call, server response (questions), user clarification, second call with answers, and the expected profile output. It explains the two-step flow enough for an agent to execute correctly.
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%, giving a baseline of 3. The description adds semantic value by explaining the two-step meaning of `answers` (omitted → questions, provided → profiles), the ordering constraint, and a concrete example for `request_text`. This exceeds schema descriptions.
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 ('Подбирает' - selects) and resource ('профиль(и) группы доступа 1С:БИТ.ФИНАНС') with a clear methodology (keyword-based, no LLM). It also explains the single/multi modes, distinguishing this tool from siblings like `suggest_profile_by_job` and `search_by_role`.
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?
Provides a clear two-step protocol with explicit instructions: first call without `answers`, second call with `answers`. It also gives an example of when multi mode is appropriate (storekeeper). However, it doesn't name alternative sibling tools or explicitly state when NOT to use this tool, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does an excellent job. It discloses the data source (real anonymized employee database, 417 positions), the algorithm (profiles occurring in >=40% of employees), the output details (% coverage and employee count), and the fuzzy search behavior. This gives the agent a solid understanding of what the tool will do.
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 two sentences, front-loaded with the core purpose and then succinctly adding key behavioral details. There is no fluff or repetition; every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description adequately explains what the tool returns (profiles with coverage % and employee counts). It also covers the matching logic and the threshold concept. For a suggestion tool of moderate complexity, this is complete enough for an agent to select and invoke it correctly.
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 baseline is 3. The description adds some context about the fuzzy search and data corpus, but these are already partially reflected in the schema's parameter description for job_title ('Поддерживается частичное совпадение'). It does not significantly augment the parameter meaning beyond what the schema provides.
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 clearly states a specific verb ('Подбирает' - selects) and a specific resource ('типовые профили доступа 1С' by job title). It further differentiates itself by mentioning the data source (417 job titles), the coverage threshold (>=40%), and fuzzy search, which distinguishes it from sibling tools like search_by_role or suggest_access_profile.
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 implies a clear usage context: when you have an employee's job title and need typical access profiles. It gives practical examples in the schema ('кладовщик', 'бухгалтер') and explains the fuzzy matching behavior. However, it does not explicitly state when not to use this tool or name alternatives like suggest_access_profile, so it misses the top score.
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:

[![gti-1c-mcp MCP server](https://glama.ai/mcp/servers/RomanSaranindev/gti-1c-mcp/badges/card.svg)](https://glama.ai/mcp/servers/RomanSaranindev/gti-1c-mcp)

Score Badge

Copy to your README.md:

[![gti-1c-mcp MCP server](https://glama.ai/mcp/servers/RomanSaranindev/gti-1c-mcp/badges/score.svg)](https://glama.ai/mcp/servers/RomanSaranindev/gti-1c-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/RomanSaranindev/gti-1c-mcp'

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