lzt-dev-mcp is an MCP server for the lolzteam/lzt.market ecosystem, providing 29 tools across four groups:
API Testing (lzt_dev_mcp.testing) — Browse the pylzt API catalog (list_methods, describe_api), inspect method and model schemas (get_method_schema, get_model_schema), and send real requests against testnet (default) or production (gated: requires an explicit token, otherwise ProdBlocked).
Flow Orchestration (lzt_dev_mcp.flow) — Manage lzt-flow workflows: create, list, get, export, import, and compile flows. Discover node types and dynamic methods for flow building (list_catalog, list_dynamic_methods, get_dynamic_method). Start and monitor runs (create_run with idempotent run_key, list_runs, get_run, get_run_trace).
Event Subscriptions (lzt_dev_mcp.eventus) — Manage lzt-eventus subscriptions (webhook/websocket/sse/polling): list, create, poll pending events, and confirm reads. Register and list token accounts. Browse subscribable event types and check instance reachability. Admin-gated tools require LZT_DEV_MCP_LZT_EVENTUS_ADMIN_API_KEY.
Helpers (lzt_dev_mcp.helpers) — View rate limits per RateClass, browse typed pylzt error classes with HTTP statuses, and check testnet reachability.
Safety: Prod requests are blocked by default (token required). Testnet requests require LZT_DEV_MCP_TESTNET_BASE_URL; if unset, TestnetUnavailable is raised with no silent fallback to prod.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@lzt-dev-mcp list methods with search='lot'"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
MCP-сервер для экосистемы lolzteam/lzt.market: тестовые запросы к API (testnet по умолчанию,
прод заблокирован без явного токена), управление сценариями lzt-flow, управление
подписками/событиями lzt-eventus.
uv sync --extra dev
scripts/run.shДокументация для AI-агентов — карта модулей и инварианты, читать перед исходниками.
uv sync --extra devpylzt и lzt-testnet — git-зависимости (tool.uv.sources в pyproject.toml), обе тянутся с
ветки main репозиториев open-lzt/pylzt и open-lzt/lzt-testnet. Без --extra dev
lzt-testnet не ставится и pytest -m e2e не соберётся.
Related MCP server: amoCRM MCP Server
.mcp.json (или конфиг Claude Desktop) — cwd указывает на абсолютный путь до этого репозитория:
{
"mcpServers": {
"lzt-mcp": {
"command": "uv",
"args": ["run", "python", "-m", "lzt_dev_mcp"],
"cwd": "/absolute/path/to/lzt-mcp"
}
}
}По умолчанию сервер поднимается на транспорте stdio (scripts/run.sh делает то же самое).
Для streamable HTTP:
uv run python -m lzt_dev_mcp --http --host 127.0.0.1 --port 877029 инструментов, зарегистрированы в server.py из четырёх групп:
lzt_dev_mcp.testing)Инструмент | Что делает |
| Список методов API pylzt с фильтром по namespace/поиску |
| Поля запроса метода + имя модели ответа |
| JSON Schema модели ответа по имени |
| Реальный запрос: testnet по умолчанию, прод — под гвардом |
| Полнотекстовый поиск по каталогу методов |
lzt_dev_mcp.flow)Инструмент | Что делает |
| Список flow текущего тенанта |
| Полная спецификация flow по id |
| Создать flow из FlowSpec |
| Экспорт flow как версионированного конверта FlowSpec |
| Импорт flow из экспортированного конверта (гейт: компиляция + dry-run) |
| Компиляция flow в неизменяемый FlowIR |
| Каталог узлов lzt-flow (типы action/logic/trigger) |
| Методы фасада pylzt, доступные как динамические узлы flow |
| Параметры и форма возврата одного динамического метода |
| Запуск скомпилированного flow (идемпотентно по |
| Список ранов текущего тенанта |
| Текущий статус рана |
| Трейс выполнения рана по узлам |
lzt_dev_mcp.helpers)Инструмент | Что делает |
| Опубликованные лимиты запросов по |
| Типизированные классы ошибок pylzt с их аргументами |
| Доступен ли настроенный инстанс lzt-testnet |
lzt_dev_mcp.eventus)Инструмент | Что делает |
| Список подписок lzt-eventus (гейт админ-ключом) |
| Новая подписка (webhook/websocket/sse/polling) |
| Опрос ожидающих событий подписки на polling-транспорте |
| Зафиксировать прогресс чтения подписки до seq |
| Каталог типов событий, на которые можно подписаться |
| Регистрация токен-аккаунта lzt-eventus |
| Список токен-аккаунтов (гейт админ-ключом) |
| Доступен ли настроенный инстанс lzt-eventus |
CRUD в группах Flow и События неполный не случайно: lzt-flow и lzt-eventus сами не
предоставляют update/delete для flow и подписок — инструменты отражают их REST API один в один,
ничего сверху не достроено.
send_request(target="prod") без явного непустого token всегда бросает ProdBlocked
(errors.py) — фолбэка через переменные окружения нет и не будет: config.py намеренно не
содержит настройки allow_prod, чтобы не было второго, более слабого ответа на тот же вопрос.
Прод-клиент собирает client_factory.build_client:
if target == "prod":
if not token:
raise ProdBlocked()
return Client([token])target="testnet" (значение по умолчанию) без настроенного LZT_DEV_MCP_TESTNET_BASE_URL
бросает TestnetUnavailable, а не тихо уходит на прод.
Переменные окружения с префиксом LZT_DEV_MCP_ (config.py, Settings):
Переменная | Дефолт | Назначение |
| не задан | Куда бьёт |
|
| REST API |
| не задан |
|
|
| REST API |
| не задан | Админ-ключ для маршрутов |
.env.example в репозитории задаёт только первые три переменные — lzt-eventus работает с
дефолтным base_url без ключа, пока не нужны админ-маршруты.
uv run ruff check .
uv run ruff format --check .
uv run mypy src
uv run pytest -q # юнит-тесты, e2e пропускаются (маркер `e2e` в pyproject.toml)
uv run pytest -m e2e -q # нужен запущенный lzt-testnet + dev-инстанс lzt-flow.github/workflows/ci.yml гоняет тот же набор (ruff check, ruff format --check, mypy, pytest) на
каждый push в main и на каждый PR.
Compile a flow into an immutable FlowIR.
| Name | Required | Description | Default |
|---|---|---|---|
| flow_id | Yes |
| Name | Required | Description |
|---|---|---|
| flow_ir_id | Yes | |
| node_count | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description carries full burden. Mentions 'immutable' but doesn't explain side effects (e.g., flow becomes unmodifiable) or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no redundant words. However, could be slightly more informative without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having output schema, description lacks context on parameter semantics and usage. Incomplete for a compilation tool with no annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and description adds no meaning beyond parameter name 'flow_id'. No format, source, or example provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses specific verb 'compile' and resource 'flow', specifies result is 'immutable FlowIR', distinguishing it from sibling tools like create_flow or export_flow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to compile vs use other tools (e.g., create/export), no prerequisites, and no mention of when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Confirm read progress for a polling-transport subscription up to a seq.
| Name | Required | Description | Default |
|---|---|---|---|
| up_to_seq | Yes | ||
| subscription_id | Yes |
| Name | Required | Description |
|---|---|---|
| last_seq | Yes | |
| subscription_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states the action without disclosing side effects (e.g., state changes, authentication needs, rate limits). The description is too minimal to adequately inform the agent of behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no fluff. It efficiently conveys the core purpose, though slightly more detail would improve without sacrificing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite an output schema existing, the description lacks explanation of what 'confirm read progress' entails, the meaning of the sequence number, prerequisites, or typical usage flow. For a tool with two required parameters and no annotations, this is insufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. The description only loosely maps 'up_to_seq' via phrase 'up to a seq', omitting details for 'subscription_id'. No parameter descriptions are provided, and the description adds minimal meaning beyond parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Confirm read progress for a polling-transport subscription up to a seq' clearly states the action (confirm read progress), the resource (polling-transport subscription), and the scope (up to a sequence number). It distinguishes itself from sibling tools like poll_pending_events and create_subscription.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use after polling events to acknowledge receipt, but provides no explicit guidance on when to use this tool versus alternatives, nor any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new lzt-flow flow from a FlowSpec.
| Name | Required | Description | Default |
|---|---|---|---|
| spec | Yes |
| Name | Required | Description |
|---|---|---|
| flow_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It only states 'creates a new flow' without mentioning side effects, permissions, or what happens on success/failure. This is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
While the description is concise (one sentence), it is under-specified and fails to convey essential information. It prioritizes brevity over clarity and utility.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complex input schema, absence of annotations, and the presence of similar sibling tools, the description is inadequate. It does not cover necessary details for correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the description adds no meaning to the single required parameter 'spec'. The description does not explain that 'spec' must be a FlowSpec object or provide any context about its nested structure.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Create' and resource 'lzt-flow flow', clearly indicating the action and object. However, it does not distinguish from sibling tools like import_flow or compile_flow, which might also create flows.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as import_flow or compile_flow. The description lacks any context about prerequisites or use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Start a run of a compiled flow (idempotent on run_key).
| Name | Required | Description | Default |
|---|---|---|---|
| req | Yes |
| Name | Required | Description |
|---|---|---|
| run_id | Yes | |
| status | Yes |
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 mentions idempotency via 'run_key', which is good, but it does not disclose that this is a write/mutate operation, potential side effects (e.g., triggering execution), authorization requirements, or error conditions (e.g., if flow_id doesn't exist). This is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that immediately conveys the core action. It is concise with no extraneous words, and the idempotency detail is appropriately front-loaded. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (mutation with nested parameter) and availability of an output schema (though not described), the description provides a minimal but adequate outline. It lacks details on the return value, error handling, and usage context with respect to the flow lifecycle. For a tool with many siblings, more context would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds meaning for 'run_key' by explaining its role in idempotency, which goes beyond the schema's type-only definition. However, it does not describe 'flow_id' or the nested 'req' parameter, leaving half the schema undocumented. The baseline 3 is appropriate given partial added value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: starting a run of a compiled flow. It uses the specific verb 'Start' and the resource 'run', and the mention of 'idempotent on run_key' adds precision. This distinguishes it from siblings like 'get_run' (retrieval) and 'compile_flow' (compilation).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'get_run' or 'create_flow'. It does not mention prerequisites (e.g., flow must be compiled) or exclusions (e.g., not for un-compiled flows). The context is implied but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new lzt-eventus subscription (webhook/websocket/sse/polling).
| Name | Required | Description | Default |
|---|---|---|---|
| spec | Yes |
| Name | Required | Description |
|---|---|---|
| ctx | Yes | |
| scope | Yes | |
| active | Yes | |
| secret | No | |
| endpoint | Yes | |
| transport | Yes | |
| created_at | Yes | |
| event_types | Yes | |
| stream_token | No | |
| subscription_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only states 'create' (implying mutation) without disclosing behavioral traits like authentication requirements, rate limits, side effects, or response behavior. Minimal transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One short sentence with key information; no wasted words. However, could include a bit more detail (like spec requirements) without harming conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (nested spec parameter, low schema coverage), the description is insufficient. It omits details on parameter semantics, return value (output schema exists but not described), and behavioral context. Incomplete for a tool with nested objects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, but it only lists transport types, not explaining the spec parameter structure, required fields (e.g., endpoint, event_types), or semantics. Barely adds value beyond field names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Create' and the resource 'lzt-eventus subscription', and lists the supported transport types (webhook/websocket/sse/polling), distinguishing it from sibling tools like list_subscriptions or poll_pending_events.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs alternatives (e.g., not mentioning prerequisites or scenarios). The purpose is implied by the verb, but no exclusions or context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the method catalog by a free-text query.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only says 'search' without explaining query matching behavior, error handling, or that it is a read-only operation. The output schema exists but its structure is not described.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, but it lacks essential details for an agent to use the tool correctly. It is somewhat under-specification rather than efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of many sibling tools and an output schema, the description is incomplete. It does not explain what the output contains, when to search vs list methods, or any edge cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description should compensate. It merely labels the parameter as 'free-text query' but provides no format, constraints, or examples. The schema only defines it as a required string.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Search' and the resource 'method catalog', and specifies the mode 'by a free-text query'. This distinguishes it from listing tools like list_methods or list_catalog, though it doesn't explicitly differentiate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as list_methods or list_catalog. There is no mention of prerequisites or scenarios where this tool is preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Export a flow as a versioned FlowSpec envelope.
| Name | Required | Description | Default |
|---|---|---|---|
| flow_id | Yes |
| Name | Required | Description |
|---|---|---|
| flow | Yes | |
| schema_version | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. It does not disclose whether the operation is read-only, requires permissions, or has side effects. The term 'Export' implies retrieval but is not explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, front-loaded with key information. No unnecessary words, but could add more detail without losing brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the existence of an output schema, return values need not be described. However, the description lacks context on versioning, envelope format, or constraints, making it barely adequate for a simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description adds no meaning beyond the schema. The single parameter 'flow_id' is not explained, though its purpose is somewhat inferable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Export', the resource 'a flow', and the result type 'versioned FlowSpec envelope'. It distinguishes from siblings like get_flow (retrieval) and import_flow (import).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives such as get_flow, import_flow, or compile_flow. The description does not mention when not to use it or provide context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Describe one dynamic facade method's params and return shape.
| Name | Required | Description | Default |
|---|---|---|---|
| facade | Yes | ||
| method | Yes |
| Name | Required | Description |
|---|---|---|
| name | Yes | |
| params | Yes | |
| returns | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must disclose behavioral traits. It states the tool describes parameters and return shape, implying a read-only operation. However, it does not explicitly confirm non-destructiveness or mention any limitations (e.g., authentication, rate limits). The minimal disclosure is adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, concise and to the point. It contains no fluff. However, it is so brief that it sacrifices completeness. While it earns points for brevity, it could include more useful information without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity (2 params, output schema exists), the description should explain what 'facade' and 'method' refer to. It does not. The context from sibling tools (e.g., 'list_dynamic_methods') hints at the domain, but the description itself is insufficient for understanding the tool's full role without external knowledge.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, and the description adds no detail about the 'facade' and 'method' parameters. It merely restates the tool's purpose without explaining valid values, formats, or examples. The names are somewhat self-explanatory, but the description fails to compensate for the schema's lack of descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: to describe a single dynamic facade method's parameters and return shape. It uses a specific verb ('Describe') and identifies the resource ('one dynamic facade method') and scope ('params and return shape'). This distinguishes it from siblings like 'list_dynamic_methods' (which lists methods) and 'get_method_schema' (likely for static methods). However, it could be more explicit about the 'facade' parameter's meaning.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. For example, it does not contrast with 'list_dynamic_methods' (which enumerates methods) or 'get_method_schema' (static schema). The agent receives no context for decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List pylzt's typed error classes with their carried args.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but the description sufficiently discloses the behavior: listing error classes with args. Since it's a read-only operation with no parameters, no additional behavioral traits are needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, concise, and front-loaded with the verb 'List'. No extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, the description does not need to explain return values. It covers the purpose adequately for a list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist in the schema, so baseline 4 is appropriate. The description adds no parameter details, but none are required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it lists pylzt's typed error classes and their carried args. Specific verb 'list' and resource 'typed error classes' distinguish it from sibling tools like get_run or list_subscriptions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use vs alternatives. However, as a simple list tool with no parameters, its usage is implicitly clear, but it lacks context on when to choose it over other listing tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List lzt-eventus's subscribable event-type catalog.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 a read-only intent ('list') without specifying output behavior, pagination, or any side effects. For a simple catalog listing with no parameters, this is minimally 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that is concise and easy to parse. It could slightly expand on the output format without losing conciseness, but it is well-structured for its length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters, an output schema exists (though unseen), and sibling tools cover diverse operations, the description adequately covers the tool's purpose. It is complete enough for an agent to understand when to invoke this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema coverage is trivially 100%. Per guidelines, 0 parameters earns a baseline of 4. The description doesn't need to add parameter information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'list' and identifies the resource as 'subscribable event-type catalog', clearly distinguishing it from sibling tools like 'list_subscriptions' and 'create_subscription'. It unambiguously states what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives (e.g., when to call this vs. list_subscriptions or poll_pending_events). The description lacks any context for decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check whether the configured lzt-eventus instance is reachable.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| ok | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It states 'check reachability' but does not disclose side effects (none expected), authentication requirements, or error behavior. Adequate for a simple health check but lacks detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single concise sentence with no unnecessary words. Perfectly front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with no parameters, and output schema exists. However, the description does not mention what the output indicates (e.g., boolean or status object). Adequate but could be more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters, so description adds no param meaning beyond schema. Baseline 4 as per guidelines for 0 parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the verb 'check' and the resource 'lzt-eventus instance reachability'. Distinguishes from siblings like get_testnet_status, which checks a different component.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like get_testnet_status or other health checks. The description only states what it does, not when to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a flow's full spec by id.
| Name | Required | Description | Default |
|---|---|---|---|
| flow_id | Yes |
| Name | Required | Description |
|---|---|---|
| name | Yes | |
| spec | Yes | |
| flow_id | Yes |
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. The verb 'Get' implies a read-only operation, which is correct, but no additional traits (e.g., authentication requirements, rate limits, or side effect guarantees) are mentioned. The description is adequate but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single succinct sentence that front-loads the key action and resource. Every word is necessary; there is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a flow spec and the absence of annotations, the description is too brief. It does not hint at the scope of 'full spec' (e.g., steps, triggers, settings) or what to expect in the output. The presence of an output schema reduces the burden on the description, but the description still lacks sufficient context for an AI agent to understand when this tool is appropriate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, and the description only mentions 'by id' without elaborating on the parameter format, constraints, or examples. For a single parameter, this provides little added meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (get), the resource (flow's full spec), and the lookup method (by id). It effectively distinguishes from siblings like list_flows, which return summaries, and create_flow, which is a mutation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. For example, it does not contrast with list_flows (for listing flows) or with get_run (for run details). The description lacks context on prerequisites or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a method's declared request fields and response model name.
| Name | Required | Description | Default |
|---|---|---|---|
| method_name | Yes |
| Name | Required | Description |
|---|---|---|
| name | Yes | |
| fields | Yes | |
| returning | Yes | |
| required_fields | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as read-only nature, required authentication, or potential side effects. It only describes the return value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with no extraneous words. Efficiently conveys the tool's purpose without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with an output schema, the description covers the basic return. However, it lacks usage context, parameter detail, and any behavioral notes, making it adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The sole parameter 'method_name' is not described beyond its type in the schema. With 0% schema description coverage, the description should explain what values are valid (e.g., must be a declared method name), but it does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Get) and the resource (method's schema), specifying what is returned: declared request fields and response model name. This distinguishes it from sibling tools like 'get_model_schema' and 'list_methods'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. There is no mention of prerequisites, context of use, or conditions where this tool would be inappropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a response model's JSON Schema by name.
| Name | Required | Description | Default |
|---|---|---|---|
| model_name | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It implies a read-only operation but provides no details on authorization, side effects, or rate limits. It is adequate but not informative beyond basic purpose.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence. It is concise, front-loaded, and contains no extraneous information. Every word serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity and presence of an output schema, the description provides basic completeness. However, it omits context about when to prefer this over get_method_schema and lacks details on parameter meaning, leaving some gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions 'by name' implying model_name is the name, but does not specify allowed values, constraints, or examples. Minimal added value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get', the resource 'response model's JSON Schema', and the method 'by name'. It succinctly captures the tool's function and differentiates it from sibling tools like get_method_schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as get_method_schema. The description lacks any usage context or exclusion criteria, which is important given the list of sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List pylzt's published per-RateClass request ceilings.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description only states that the tool lists ceilings, which implies a read operation. However, it does not disclose any behavioral traits such as whether the tool is paginated, requires authentication, or has rate limits. Since no annotations are provided, the description carries the full burden but fails to add meaningful transparency beyond the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no extraneous words. It is front-loaded with the action and resource. Every word earns its place, making it highly concise and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and an output schema exists to describe return values, the description is adequate but not fully complete. It does not explain domain terms like 'RateClass' or 'ceilings', which may be necessary for an agent to correctly interpret the tool's output. The missing context reduces completeness slightly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters and schema description coverage is 100% (trivially). According to the rubric, zero parameters yields a baseline score of 4. The description does not need to explain parameters since none exist, and it does not add misleading information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List') and the resource ('pylzt's published per-RateClass request ceilings'). It is specific and distinguishes the tool's purpose from sibling tools, but the term 'pylzt' is not explained, which could cause minor ambiguity for agents unfamiliar with the system.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, context, or when not to use it. Sibling tools exist, but no comparison or exclusion criteria are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a run's current status.
| Name | Required | Description | Default |
|---|---|---|---|
| run_id | Yes |
| Name | Required | Description |
|---|---|---|
| run_id | Yes | |
| status | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description only says 'Get a run's current status' without disclosing any behavioral traits like idempotency, authentication needs, rate limits, or side effects. Since no annotations are provided, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that communicates the core purpose without filler. However, it is slightly under-specified for an agent, but still earns a 4 for efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the existence of an output schema, the description is minimal but missing key context like return value details, usage hints, and parameter help. It is not fully complete for an agent to use reliably.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no descriptions (0% coverage), and the description adds no meaning to the run_id parameter. The agent has no information on format, source, or constraints beyond the bare type 'string'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets a run's current status, with specific verb and resource. However, it does not differentiate from sibling tools like get_run_trace or list_runs, which could cause confusion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. There is no mention of prerequisites, context, or exclusions, leaving the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a run's per-node execution trace.
| Name | Required | Description | Default |
|---|---|---|---|
| run_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 only states what the tool does but omits side effects, authentication requirements, performance implications, or trace format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short but lacks necessary detail. While it is front-loaded, it is under-specified for the tool's complexity, making it minimally adequate.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the existence of an output schema and sibling tools, the description fails to provide sufficient context about what a 'per-node execution trace' entails or how it differs from similar tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no meaning beyond the schema for the single parameter 'run_id'. The agent receives no guidance on how to use or format the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('get') and the resource ('run's per-node execution trace'), distinguishing it from sibling tools like 'get_run' which likely provides run details rather than a trace.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as 'get_run' or 'get_flow'. The description only implies usage without explicit context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check whether the configured lzt-testnet instance is reachable.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| reachable | Yes | |
| latency_ms | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description implies a read-only, non-destructive check. No annotations are provided, so the description carries the full burden, and it adequately conveys the safe nature of the operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-formed sentence with no wasted words, directly stating the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters, an output schema exists (so return values needn't be described), and the description fully captures the tool's action, it is complete for the context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, so schema coverage is vacuous. Per guidelines, baseline is 4, and the description adds no unnecessary parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool checks reachability of a specific resource (lzt-testnet instance), with a specific verb 'check'. It distinguishes itself from sibling tools like get_eventus_status by naming a different resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives is provided. The description is self-explanatory for a simple health check, but does not mention prerequisites or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Import a flow from an exported envelope (compile+dry-run gated).
| Name | Required | Description | Default |
|---|---|---|---|
| envelope | Yes |
| Name | Required | Description |
|---|---|---|
| name | Yes | |
| flow_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description mentions 'compile+dry-run gated', implying a two-step validation before import, but it is vague about whether the tool performs those steps or requires prior completion. No annotations exist to clarify.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Very concise (one sentence), but it is front-loaded with the key action. However, it omits important details, making it under-informative for the complexity of the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description does not mention return values (though output schema exists, it's not shown), nor does it explain the import process or consequences. For a tool with nested schemas, this is insufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage and one required complex parameter 'envelope', the description does not explain its structure or how to construct it, failing to add value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Import' and the resource 'flow from an exported envelope'. It also adds 'compile+dry-run gated' to distinguish behavior from siblings like export_flow or create_flow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives. The phrase 'compile+dry-run gated' hints at prerequisites but does not explicitly state when-not or provide alternative tool names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List lzt-flow's node catalog (action/logic/trigger types).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behaviors like listing all or paginated results. It only says 'list' without details on scope, performance implications, or output format. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, succinct sentence with no extraneous words. It is front-loaded with the verb and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (known to exist), the description could be considered minimal but adequate. However, it lacks details on what the catalog includes beyond types (e.g., descriptions, icons) or how to use the output, leaving some gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so schema coverage is 100% by default. Baseline for 0 params is 4, and the description adds no extra semantics beyond the schema, which is acceptable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'list' and clearly identifies the resource as 'lzt-flow's node catalog', further specifying it covers action/logic/trigger types. This distinguishes it from siblings like list_runs or get_run.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus others or any prerequisites. There is no mention of exploring node types before creating flows, which would be helpful context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List pylzt facade methods usable as dynamic flow nodes.
| Name | Required | Description | Default |
|---|---|---|---|
| facade | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description lacks any behavioral traits (e.g., side effects, auth needs, pagination). Does not mention output schema despite its existence.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with key action. While minimal, every word contributes to purpose clarity. Could be expanded for context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with one param and output schema, description omits parameter explanation and output details. Incomplete compared to sibling richness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and description only implies 'facade' is the target to list methods for. No explanation of valid values, constraints, or relation to the resource.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly specifies verb (list), resource (pylzt facade methods), and context (usable as dynamic flow nodes). Distinguishes from siblings like list_methods and get_dynamic_method.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use vs alternatives (e.g., list_methods, get_dynamic_method). Agent must infer from sibling names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List lzt-flow flows for the current tenant.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It only states 'list' without describing return format, pagination, or what data is included. This is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words. It is front-loaded and immediately conveys the action and scope.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter list tool with many siblings, the description is minimally adequate. It lacks detail on what fields are returned or how to use it alongside other flow tools, but an output schema exists to fill some gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so the schema coverage is 100%. The description adds the context 'for the current tenant', which provides meaning beyond the empty schema, warranting a baseline 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states it lists 'lzt-flow flows' for the current tenant, using a clear verb+resource structure. It is distinct from sibling tools like get_flow, create_flow, etc., which target specific actions on flows.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as get_flow or list_catalog. There is no mention of prerequisites or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List pylzt API methods, optionally filtered by namespace/search.
| Name | Required | Description | Default |
|---|---|---|---|
| search | No | ||
| namespace | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It only states the basic function without mentioning side effects, safety (read-only), authentication requirements, rate limits, or output specifics. The existence of an output schema does not excuse the description from providing at least a high-level behavioral overview.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler words. It is front-loaded with the verb and resource, making the purpose immediately clear. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity and the presence of an output schema (which likely documents return values), the description is minimally adequate. However, it lacks details on default behavior, case sensitivity, or pagination. For a simple list with two optional filters, this is acceptable but not rich.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description only names the parameters ('search', 'namespace') without adding meaning. It says 'optionally filtered by namespace/search' but does not explain what values are acceptable, how filtering works (e.g., partial match), or defaults. This adds minimal value beyond the parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'List pylzt API methods, optionally filtered by namespace/search.' It clearly specifies the verb (list), resource (pylzt API methods), and the filtering options. This distinguishes it from sibling listing tools that target different resources (subscriptions, flows, etc.).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives. With many sibling 'list_*' tools, such as list_subscriptions or list_flows, the agent would benefit from contextual clues about selecting this specific tool for API methods. The description only implies usage without exclusions or comparisons.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List runs for the current tenant.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It adds tenant scoping but does not disclose pagination, result limits, or any side effects. For a simple list, more details on behavior would improve transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no unnecessary words. Every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple nature of the tool (0 parameters, output schema present), the description is complete. It conveys the essential purpose and scope without requiring elaboration on return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4 as per guidelines. The description does not need to add parameter info.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and the resource 'runs', and specifies scope 'for the current tenant'. However, it does not differentiate from sibling tools like list_subscriptions or list_flows, which also list resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use list_runs versus alternatives like get_run (single run) or get_run_trace. The description lacks context about when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List lzt-eventus subscriptions (admin-key gated).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses the admin-key requirement but omits other behaviors (e.g., authorization failure handling, output size limits, pagination).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with no wasted words. Action and resource are front-loaded, and the gating condition is appended concisely.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is minimal but adequate for a parameterless list operation. An output schema exists, so return format is covered. It lacks mention of result structure or pagination, but for a simple list this is acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters and schema coverage is 100%. The description adds no parameter info, but the baseline for no parameters is 4. The admin-key gating is a behavioral trait, not a parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List'), the specific resource ('lzt-eventus subscriptions'), and a key differentiator ('admin-key gated'), distinguishing it from sibling tools like list_runs or list_token_accounts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context via 'admin-key gated', indicating authorization required. However, it does not explicitly state when to use vs. alternatives, though no sibling directly overlaps.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List lzt-eventus token accounts (admin-key gated).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds one behavioral cue ('admin-key gated') beyond the tool name, indicating an access control restriction. However, it omits other potentially relevant behaviors such as read-only nature, pagination, or rate limits. Given no annotations are provided, the description carries the transparency burden and only partially fulfills it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence containing only essential information. It avoids redundancy or extraneous detail, making it easy for an agent to quickly parse the tool's core function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with no parameters and an existing output schema, the description is largely complete. It communicates the resource type and an access constraint, which suffices for basic usage. Minor improvements could include a note on default scope or result volume, but the current form is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the input schema is trivially covered at 100%. According to the calibration rule for 0 parameters, the baseline score is 4. The description does not need to add parameter semantics since none exist, and it does not detract from clarity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List lzt-eventus token accounts', using a specific verb ('List') and resource ('token accounts'), with a scope qualifier ('admin-key gated'). This succinctly distinguishes it from sibling tools like list_subscriptions or list_flows, which target different resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives. While 'admin-key gated' hints at an authentication requirement, it does not clarify scenarios such as when to use this over list_catalog or list_dynamic_methods, nor does it mention prerequisites or preferred contexts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Poll pending events for a polling-transport subscription.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| event_type | No | ||
| subscription_id | Yes |
| Name | Required | Description |
|---|---|---|
| items | Yes | |
| drained | Yes | |
| next_seq | Yes | |
| committed | Yes | |
| last_read_seq | Yes | |
| subscription_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It does not disclose behavioral traits such as blocking behavior, rate limits, or whether polling permanently removes events. The description is too brief to add meaningful 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one sentence, which is concise, but it lacks structure and does not front-load critical information. It is under-specified rather than optimally concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema and 3 parameters, the description fails to explain what 'poll' means in terms of side effects, whether events are consumed, or what the response contains. It is inadequate for an agent to fully understand the tool's behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description adds no information about parameters (subscription_id, limit, event_type). It does not explain their meaning or how they affect the tool's behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Poll') and the resource ('pending events') and specifies the context ('for a polling-transport subscription'). This distinguishes it from sibling tools like list_subscriptions or get_event_types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention conditions like required prior setup, or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Register a new lzt-eventus token account.
| Name | Required | Description | Default |
|---|---|---|---|
| spec | Yes |
| Name | Required | Description |
|---|---|---|
| token | No | |
| active | Yes | |
| metadata | Yes | |
| account_id | Yes | |
| categories | Yes | |
| created_at | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only says 'register', implying creation, but does not mention idempotency, authentication needs, or side effects. For a mutation tool, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no redundant words. It is front-loaded, but brevity sacrifices substance. Still, it earns its place as a minimal statement of purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a complex nested input and multiple sibling tools, but the description is too brief to provide sufficient context. Although an output schema exists, users lack understanding of parameters and the domain concept of 'token account'. The description is incomplete for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has a nested 'spec' object with fields 'token', 'alias', 'metadata', 'categories', but the description provides zero parameter information. With 0% schema description coverage, the description must compensate, yet it offers no explanations of what these fields represent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Register a new lzt-eventus token account', which identifies a specific verb and resource. However, it does not explain what a 'token account' is or how it differs from similar creation tools like create_subscription. The sibling tools include list_token_accounts, suggesting this is a creation counterpart, but no distinction is made.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives (e.g., create_subscription, create_flow). There are no prerequisites, recommendations, or exclusion criteria. The description merely states the action without context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send a real pylzt request; defaults to testnet, prod requires a token.
| Name | Required | Description | Default |
|---|---|---|---|
| token | No | ||
| params | Yes | ||
| target | No | testnet | |
| method_name | Yes |
| Name | Required | Description |
|---|---|---|
| body | Yes | |
| status | Yes | |
| elapsed_ms | Yes |
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 only mentions environment defaults and token requirements, but does not state whether the tool is idempotent, destructive, rate-limited, or any side effects. The term 'real pylzt request' is vague.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (one sentence), which is concise, but it sacrifices necessary details. For a tool with multiple parameters and no annotations, the description should be longer to compensate.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters (including a nested object), an output schema, and no annotations, the description is severely incomplete. It does not explain how to use the tool, what the parameters do, or what the output looks like. The agent would struggle to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 4 parameters and 0% description coverage. The description does not explain any parameter beyond implicit reference to 'token' and 'target'. It fails to clarify the structure of 'params' or the meaning of 'method_name'. The description adds no value over the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('send') and the resource ('real pylzt request'), and distinguishes between testnet and prod environments. However, it does not differentiate from sibling tools like 'get_run' or 'create_subscription', missing an opportunity to clarify that this is a low-level generic request sender.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a minor hint about environment selection ('defaults to testnet, prod requires a token'), but provides no guidance on when to use this tool versus alternatives. Sibling tools cover specific operations, and the description should clarify that this is for arbitrary requests not covered by other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0compile_flowconfirm_readcreate_flowcreate_runcreate_subscriptiondescribe_apiexport_flowget_dynamic_methodget_error_catalogget_event_typesget_eventus_statusget_flowget_method_schemaget_model_schemaget_rate_limitsget_runget_run_traceget_testnet_statusimport_flowlist_cataloglist_dynamic_methodslist_flowslist_methodslist_runslist_subscriptionslist_token_accountspoll_pending_eventsregister_token_accountsend_requestScored across 29 tools
Most tools cleanly target distinct resources (flows, runs, subscriptions, schemas), but a few pairs could confuse an agent: list_methods vs describe_api both surface API catalog information, and get_method_schema vs get_dynamic_method both describe method inputs/outputs. Overall, descriptions and naming help separate the main workflows.
All tools follow a consistent verb_noun pattern: list_*, get_*, create_*, import_*, export_*, send_*, poll_*, confirm_*, register_*. The naming is uniform across the pylzt, lzt-flow, and lzt-eventus subdomains, making the tool set predictable and easy to navigate.
At 29 tools, this is on the heavier side, but the server covers three distinct subsystems (pylzt, lzt-flow, lzt-eventus), each with a reasonable set of operations. The count feels justified for the stated purpose, though a few introspection helpers could potentially be consolidated.
The server provides strong lifecycle coverage: flows can be listed, created, imported, exported, compiled, and run; subscriptions can be created, listed, polled, and confirmed; API introspection covers methods, schemas, rate limits, and errors. Minor gaps like updating or deleting flows/subscriptions exist, but agents can likely work around them.
Free MCP server: 32 security & developer API tools -- WHOIS, DNS, CVE checks, IP reputation.
MCP server that delivers up-to-date Bitrix24 REST API documentation.
MCP server with quote and live cryptocurrency price tools, local and cloud-deployed transports.
MCP server for Hostinger API