AI 어시스턴트에게 Celery에 대한 완전한 제어 권한을 부여하세요 — 워커 모니터링, 작업 관리, 큐 검사.
기능 · 빠른 시작 · 구성 · 도구 · 개발 · 기여
celery-flower-mcp는 Model Context Protocol 서버로, 전체 Celery Flower REST API를 MCP 도구로 노출합니다. Flower 인스턴스를 연결하면 AI 어시스턴트(Claude, Cursor, Windsurf 등)가 다음을 수행할 수 있습니다:
모니터링: 워커, 작업, 큐를 실시간으로 모니터링
제어: 워커 풀 제어 — 확장, 축소, 자동 확장, 재시작, 종료
작업 관리: 적용, 취소, 중단, 타임아웃 및 속도 제한 설정
큐 검사: 깊이 확인, 소비자 추가/제거
21개의 모든 Flower API 엔드포인트가 포함되어 있습니다.
Related MCP server: OpenAPI MCP Server
전체 API 커버리지 — 모든 Flower REST 엔드포인트가 MCP 도구로 노출됨
의존성 주입 — dishka를 통한 깔끔하고 테스트 가능한 아키텍처
Pydantic 설정 — .env 파일 지원을 포함한 타입 지정 구성
비동기 지원 — httpx + FastMCP 기반으로 구축
65개의 테스트 — 49개의 단위 테스트(99% 커버리지) + 실제 Flower 대상 16개의 통합 테스트
엄격한 타이핑 — mypy 엄격 모드, 전체 주석 처리
FLOWER_URL=http://localhost:5555 uvx celery-flower-mcpgit clone https://github.com/Darius1223/celery-flower-mcp
cd celery-flower-mcp
uv sync
uv run python -m source.main~/Library/Application Support/Claude/claude_desktop_config.json에 추가하세요:
{
"mcpServers": {
"celery-flower": {
"command": "uvx",
"args": ["celery-flower-mcp"],
"env": {
"FLOWER_URL": "http://localhost:5555"
}
}
}
}구성은 환경 변수나 프로젝트 루트의 .env 파일에서 읽어옵니다. 시작하려면 .env.example을 복사하세요:
cp .env.example .env변수 | 기본값 | 설명 |
|
| Flower 인스턴스의 기본 URL |
| — | 기본 인증 사용자 이름 |
| — | 기본 인증 비밀번호 |
| — | Bearer 토큰 (기본 인증보다 우선) |
도구 | 설명 |
| 모든 워커 나열 — 이름별 필터링, 실시간 통계 새로고침 또는 상태만 확인 가능 |
| 워커를 정상적으로 종료 |
| 워커의 프로세스 풀 재시작 |
| 워커 풀에 N개의 프로세스 추가 |
| 워커 풀에서 N개의 프로세스 제거 |
| 자동 확장 최소/최대 범위 구성 |
| 워커가 큐에서 소비를 시작하도록 설정 |
| 워커가 큐에서 소비를 중단하도록 설정 |
도구 | 설명 |
| 상태, 워커, 이름, 날짜 범위, 검색, 페이지네이션 필터를 사용하여 작업 나열 |
| 워커 전반에 등록된 모든 작업 유형 나열 |
| UUID로 작업의 전체 세부 정보 가져오기 |
| 작업 결과 검색 (선택적 타임아웃 포함) |
| 작업을 동기적으로 실행하고 결과 대기 |
| 작업을 비동기적으로 디스패치, 작업 UUID 반환 |
| 이름으로 작업 전송 — 워커 측 등록 불필요 |
| 실행 중인 작업 중단 |
| 작업 취소; 선택적으로 신호와 함께 종료 |
| 워커에서 작업에 대한 소프트/하드 시간 제한 설정 |
| 워커에서 작업에 대한 속도 제한 설정 (예: |
도구 | 설명 |
| 구성된 모든 큐의 현재 깊이 확인 |
| Flower 인스턴스에 연결 가능하고 정상인지 확인 |
source/
├── main.py # FastMCP server entry point + dishka container wiring
├── settings.py # Pydantic Settings — typed config from env / .env
├── client.py # Async HTTP client wrapping Flower REST API
├── providers.py # dishka Provider — manages FlowerClient lifecycle
└── tools/
├── workers.py # 8 worker management tools
├── tasks.py # 11 task management tools
└── queues.py # 2 queue / health toolsdishka가 FlowerClient 수명 주기를 관리합니다: 시작 시 한 번 생성되고, 비동기 생성기 제공자를 통해 종료 시 깔끔하게 닫힙니다.
make fmt # auto-format with ruff
make lint # lint with ruff
make typecheck # type-check with mypy (strict)
make test # run 49 unit tests
make cov # unit tests + coverage report
make all # fmt + lint + typecheck테스트 스위트는 두 개의 계층으로 나뉩니다:
단위 테스트 (tests/) — 빠르고 외부 의존성이 없으며, pytest-httpx를 사용하여 HTTP 호출을 모의(mock)합니다:
make test
# or
uv run pytest tests/ -m "not integration"통합 테스트 (tests/integration/) — Docker Compose로 관리되는 Redis 및 실제 Celery 워커가 지원하는 실제 Flower 인스턴스를 대상으로 실행됩니다:
make integration이 명령어는:
Docker Compose 스택(docker-compose.test.yml)을 빌드하고 시작합니다 — Redis → Celery 워커 → Flower
Flower의 /healthcheck 엔드포인트가 OK를 반환할 때까지 대기합니다
http://localhost:5555를 대상으로 16개의 통합 테스트를 실행합니다
완료되면 스택을 종료합니다
스택은 docker-compose.test.yml에 정의되어 있습니다. 워커 및 Flower 이미지는 tests/integration/Dockerfile.worker 및 tests/integration/Dockerfile.flower에서 빌드됩니다.
탐색적 테스트를 위해 스택을 수동으로 시작하려면:
docker compose -f docker-compose.test.yml up -d --build
# run tests, explore, etc.
make integration-down # stop + remove volumes통합 테스트는 pytest.mark.asyncio(loop_scope="session")를 사용하여 모든 테스트가 하나의 이벤트 루프를 공유하도록 합니다. 이는 Python 3.14에서 테스트 경계 전반에 걸쳐 httpx 전송이 정리될 때 RuntimeError: Event loop is closed가 발생하는 것을 방지합니다.
새 도구 추가 또는 PR 제출에 대한 자세한 내용은 CONTRIBUTING.md를 참조하세요.
CHANGELOG.md를 참조하세요.
Abort a running task.
| Name | Required | Description | Default |
|---|---|---|---|
| task_id | 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, but it only states the action. It does not mention side effects (e.g., partial execution, signal delivery, idempotency), safety, or authorization requirements, leaving the agent blind to consequences.
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?
At one sentence, the description is extremely concise, but it sacrifices necessary detail. It is not bloated, but it under-delivers on content that would fit in a short paragraph.
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 tool with one required parameter and no output schema, the description should still explain return values, errors, and behavior after abort. It fails to provide enough context for reliable 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 schema coverage is 0% and the description adds no detail about the 'task_id' parameter (e.g., format, source, validation). The agent must rely solely on the parameter name, which is insufficient for correct invocation.
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 'Abort a running task' uses a clear verb and resource, making the purpose unmistakable. However, it lacks specificity about what 'abort' entails (e.g., cancellation, rollback), and could be more distinct from sibling tools like 'revoke_task'.
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 'abort_task' versus sibling tools such as 'revoke_task', 'cancel_queue_consumer', or 'shutdown_worker'. The agent receives no context about prerequisites or scenarios where 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.
Make a worker start consuming from a queue.
| Name | Required | Description | Default |
|---|---|---|---|
| workername | Yes | ||
| queue | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description only says 'start consuming' with no details on side effects, idempotency, or what happens if already consuming. Output schema exists but is not clarified in description.
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 redundancy, but overly terse; could include brief param hints or usage context 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?
Given two required parameters and no annotations, description lacks essential context: worker existence requirements, queue state, output behavior. Incomplete for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Parameters 'workername' and 'queue' have no description in schema or tool description. 0% schema coverage means the description adds no meaning beyond raw 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?
Description clearly states verb 'make' and resources 'worker' and 'queue', indicating starting consumption. Differentiates from sibling 'cancel_queue_consumer' which is the reverse operation.
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, no prerequisites or context about worker state, and no warnings about preconditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute a task synchronously and wait for the result.
| Name | Required | Description | Default |
|---|---|---|---|
| taskname | Yes | ||
| args | No | ||
| kwargs | No | ||
| options | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description correctly discloses the blocking/synchronous behavior. However, it does not mention potential side effects, rate limits, or authentication requirements.
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 wasted words. It front-loads the core action.
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 with no schema descriptions and no annotations, the description is incomplete. It does not explain parameters nor guide on prerequisites, though the output schema existence mitigates the need for return value details.
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 description provides no information about any of the four parameters (taskname, args, kwargs, options). With 0% schema coverage, the description fails to add meaning 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 clearly states the action ('execute a task') and the specific nature ('synchronously and wait for the result'), which distinguishes it from the sibling async_apply_task. It is precise and informative.
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 when to use (when you need a synchronous result), but it does not explicitly contrast with alternative tools like async_apply_task or provide when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute a task asynchronously and return its task ID.
| Name | Required | Description | Default |
|---|---|---|---|
| taskname | Yes | ||
| args | No | ||
| kwargs | No | ||
| options | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior. It mentions 'asynchronously' implying non-blocking execution, but fails to disclose potential side effects, state changes, error handling, or that the task ID can be used with get_task_result to retrieve the outcome.
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 waste, but given the low schema coverage and lack of annotations, it is too brief. It should front-load essential behavioral and parameter 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?
The tool has four parameters, no input schema descriptions, and an output schema (presumably returning a task ID) which is not described. The description lacks sufficient detail to enable correct invocation, missing information about parameter formats, return value structure, and how to retrieve results later.
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 does not explain any of the four parameters (taskname, args, kwargs, options). The meaning of args, kwargs, and options is entirely undocumented, leaving the agent without necessary guidance.
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 'Execute a task asynchronously and return its task ID' clearly states the action (execute), the resource (task), and the async nature, distinguishing it from synchronous siblings like apply_task. However, it does not explicitly contrast with other async tools like send_task.
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 apply_task, send_task, or get_task_result. There are no usage prerequisites or context specified.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set autoscale bounds for a worker's pool.
| Name | Required | Description | Default |
|---|---|---|---|
| workername | Yes | ||
| min | Yes | ||
| max | Yes |
| 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 must disclose behavioral traits. It only states the action without explaining effects (e.g., whether setting bounds triggers immediate scaling, validation rules like min<=max, reversibility). This is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no unnecessary words. It is efficiently front-loaded and easy to read.
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 3 required parameters and no annotations, the description is extremely minimal. It does not mention prerequisites (e.g., worker pool must exist), error conditions, return value, or relationship to sibling tools. The output schema existence is not leveraged.
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 does not explain what 'min' and 'max' represent (e.g., minimum/maximum number of workers). The parameter names are self-explanatory but clarity could be improved, e.g., specifying units or constraints.
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 'Set autoscale bounds for a worker's pool' uses a specific verb ('set') and resource ('autoscale bounds for a worker's pool'), clearly distinguishing it from sibling tools like grow_worker_pool and shrink_worker_pool, which are for manual scaling.
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 does not explicitly state when to use this tool versus alternatives (e.g., for automated scaling vs. manual adjustments). The context of sibling tools implies the distinction, but no direct guidance or exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Make a worker stop consuming from a queue.
| Name | Required | Description | Default |
|---|---|---|---|
| workername | Yes | ||
| queue | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description only states the action but does not disclose behavioral traits like what happens to pending tasks, if the operation is reversible, or required permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence efficiently conveys the tool's purpose without any 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?
Despite having an output schema, the description lacks critical context such as error handling, prerequisites, or behavioral outcomes, making it insufficient for confident 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 schema has zero description coverage for parameters, and the description adds no meaning beyond their names, leaving the agent uncertain about formats or allowed values.
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 'stop consuming' and identifies the resource 'queue', clearly distinguishing it from sibling tools like 'add_queue_consumer' and 'shutdown_worker'.
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 when to use 'shutdown_worker' instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the current length of all Celery queues.
| 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 the full burden for behavioral disclosure. It states the basic function but omits any traits like read safety, expense, or freshness guarantees. The behavior is simple and expected, so it minimally meets the need.
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 that immediately conveys the purpose. There is no fluff or unnecessary detail, making it highly concise and effective.
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 complete enough for a simple read-only query with no parameters and an output schema. It lacks minor context like the nature of Celery queues but is still functional.
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 100%. The description does not need to add parameter details; the baseline is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and the resource ('current length of all Celery queues'), making it specific and distinct from sibling tools like 'list_tasks' or 'get_task_info'.
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 other queue-related tools or when the queue lengths might be stale. The description lacks any contextual cues for appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about a task by its ID.
| Name | Required | Description | Default |
|---|---|---|---|
| task_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description should disclose behavioral traits like idempotency, failure modes, or read-only nature. It only states 'Get detailed information', leaving the agent uninformed about side effects or constraints.
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 wasted words, but it is too brief and could be expanded to include necessary details.
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, the description does not indicate what 'detailed information' includes. For a simple tool with one parameter, it is marginally adequate but lacks depth to fully guide the 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?
The input schema has 0% description coverage, and the description only mentions 'by its ID', adding no meaning to the task_id parameter (format, example, or constraints). This is insufficient.
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 resource (detailed information about a task) with a specific identifier (by its ID). It is unambiguous but does not differentiate from similar sibling tools like get_task_result.
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_task_result or list_tasks. The agent has no context to decide which tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the result of a task.
| Name | Required | Description | Default |
|---|---|---|---|
| task_id | Yes | ||
| timeout | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, and the description does not disclose any behavioral traits such as whether the operation is read-only, has side effects, or requires authentication. The agent receives no safety or performance hints.
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 informational value. It earns its place but does not fully satisfy the needs of an AI agent.
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 an output schema and critical sibling tools, the description should explain what the result contains and how it differs from 'get_task_info'. The current description is incomplete for safe and effective tool selection.
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%, but the description fails to explain the purpose or format of the parameters ('task_id', 'timeout'). The agent must rely solely on the parameter names and types, which are insufficient for correct invocation.
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' and the resource 'the result of a task', making the main purpose obvious. However, it does not differentiate from the sibling 'get_task_info', which could be confused with result retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'get_task_info' or 'list_tasks'. The description lacks explicit context for optimal usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Grow a worker's process pool by n processes.
| Name | Required | Description | Default |
|---|---|---|---|
| workername | Yes | ||
| n | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full responsibility for behavioral transparency. It only states the operation but omits any side effects, safety implications, permissions required, or whether the change is immediate or queued.
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 sacrifices essential details for brevity. While not verbose, it under-delivers on necessary information given the absence of annotations and parameter descriptions.
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 insufficient for the tool's complexity. It lacks usage context, behavioral details, and parameter semantics, even though an output schema exists. The minimal information leaves agents with significant 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?
The input schema has 0% description coverage, and the description does not elaborate on the parameters ('workername' or 'n'). For example, valid values, constraints, or effects of 'n' are missing, leaving agents without critical context for parameter usage.
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 ('grow'), the resource ('worker's process pool'), and the amount ('by n processes'). It effectively distinguishes from sibling tools like 'shrink_worker_pool' and 'autoscale_worker_pool' by specifying manual growth.
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 like 'autoscale_worker_pool' or prerequisites. The description lacks context for appropriate usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check whether the Flower instance is healthy.
| 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 exist, so the description carries full burden. It states the purpose but doesn't disclose specifics like whether the call is cheap/expensive, what 'healthy' entails, or if authentication is needed. However, for a zero-parameter health check, this minimal description may suffice.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence with no filler. It front-loads the verb and resource. Every word is necessary and clear.
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 zero parameters, a simple purpose, and an existing output schema, the description is complete. The tool's complexity is low, and the description adequately covers the agent's needs.
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. The rubric sets a baseline of 4 for zero parameters, and the description does not need to add 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 verb 'Check' and the resource 'health' of the Flower instance. It is unambiguous and distinct from sibling tools which deal with tasks, workers, queues, 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?
No explicit when-to-use or when-not-to-use guidance is provided. However, the purpose is obvious: a health check is typically used for monitoring or as a precondition. No alternatives are mentioned among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List tasks with optional filters.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| offset | No | ||
| workername | No | ||
| taskname | No | ||
| state | No | ||
| received_start | No | ||
| received_end | No | ||
| sort_by | No | ||
| search | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose any behavioral traits such as pagination limits, sorting behavior, or performance implications. It only repeats the function signature without adding 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?
The description is a single sentence, which is concise but under-specifying. It front-loads the main action, but lacks necessary detail to be useful.
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 9 parameters and no parameter descriptions, no output schema description, and many sibling tools, the description is severely incomplete. It fails to mention pagination, filter semantics, sorting, or the structure of the returned list.
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 does not explain any of the 9 parameters (limit, offset, filters, sort_by, search). The agent must guess their semantics and usage.
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 resource 'tasks', and mentions 'optional filters', which distinguishes it from siblings like get_task_info or revoke_task that operate on single tasks. However, it does not explicitly differentiate from list_task_types, which lists task types, not tasks.
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_task_info or get_task_result. No context on pagination, filtering strategies, or when not to use it. Given 19 sibling tools, this is insufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all registered task 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?
No annotations are provided, and the description offers no behavioral details beyond the bare purpose. It does not mention pagination, filtering, or error handling, leaving the agent to guess the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, zero waste. Every word is necessary and front-loaded.
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 no parameters and the existence of an output schema, the description is sufficiently complete. It tells the agent exactly what the tool does, and the output schema can provide return value details.
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 100% coverage, so the description adds no parameter details. Per guidelines, no-param tools default to a baseline of 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 clearly states the tool lists 'all registered task types'. The verb 'list' and resource 'task types' are specific, and it distinguishes from siblings like 'list_tasks' which likely lists individual task instances.
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 'list_tasks' or 'get_task_info'. The agent must infer the difference based on the resource name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all Celery workers.
| Name | Required | Description | Default |
|---|---|---|---|
| refresh | No | ||
| workername | No | ||
| status | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose behavioral traits. It does not mention read-only nature, side effects, or parameter effects. 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?
Extremely concise (one short sentence), but too sparse to be informative. Lacks necessary detail for an agent.
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 3 parameters and no output schema details, description is severely incomplete. Does not explain parameters, return structure, or 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 description coverage is 0%, and description adds no information about parameters ('refresh', 'workername', 'status'). Fails to compensate for missing schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List all Celery workers' uses a specific verb and resource, clearly distinguishing it from sibling tools like 'list_tasks' and 'list_task_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 on when to use this tool versus alternatives such as 'grow_worker_pool' or 'restart_worker_pool'. Lacks context for appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Restart a worker's process pool.
| Name | Required | Description | Default |
|---|---|---|---|
| workername | Yes |
| 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 only states the action without disclosing behavioral traits such as impact on tasks, safety, or permissions.
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 wasted words. However, it may be too terse to be fully informative.
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 low complexity (1 parameter), the description omits output details, side effects, and behavioral context. It lacks completeness given the absence of 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?
The only parameter 'workername' has no schema description (0% coverage). The description adds no information about its format, constraints, or purpose, leaving the agent uninformed.
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 'Restart a worker's process pool' clearly states the action and resource. However, it does not differentiate from sibling tools like 'shutdown_worker' or 'autoscale_worker_pool', which could be confused.
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 usage guidance is provided. The description does not indicate when to use this tool versus alternatives, nor does it mention prerequisites or conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Revoke a task, optionally terminating it if running.
| Name | Required | Description | Default |
|---|---|---|---|
| task_id | Yes | ||
| terminate | No | ||
| signal | No | SIGTERM |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description reveals that revocation can optionally terminate a running task via a signal (default SIGTERM). However, it omits details like whether the task is removed from queues, what happens to results, or required permissions. With no annotations, this is basic but incomplete.
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 concise (11 words) and directly states the core function. While it could benefit from more structure, it is efficient for a simple 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?
Given the presence of an output schema and the complexity of revocation, the description lacks crucial context: what 'revoke' entails (e.g., removing from queue), how it differs from abort_task, and the meaning of the signal parameter. The agent likely misses key behavioral traits.
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 explain all parameters. It only hints at the 'terminate' boolean effect, but 'task_id' and 'signal' are left undefined. This is insufficient compensation for a 3-parameter tool.
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 (revoke a task) and the optional behavior (terminate if running). However, it does not distinguish from the sibling 'abort_task', so the agent may not know which to use.
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 revoke_task versus alternatives like abort_task, nor any prerequisites or context. The agent receives no help in deciding 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.
Send a task via send_task (does not require task to be registered on the worker).
| Name | Required | Description | Default |
|---|---|---|---|
| taskname | Yes | ||
| args | No | ||
| kwargs | No | ||
| options | 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 must disclose behavioral traits. It only mentions the registration requirement, but omits side effects, permissions, error handling, or return behavior. This is insufficient for a task-sending action.
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 compact sentence with no wasted words. It front-loads the action and key distinction. However, it is overly brief for the tool's complexity.
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 4 parameters, no annotations, and an output schema, the description lacks essential context: parameter usage, output format, error conditions, and behavioral guarantees (e.g., synchronous vs. asynchronous). It is not complete enough for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no meaning to the parameters (taskname, args, kwargs, options). The agent has no guidance on how to use these parameters beyond their 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 'Send' and the resource 'a task', and adds a critical differentiator: 'does not require task to be registered on the worker.' This distinguishes it from siblings like apply_task or async_apply_task that likely require prior registration.
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 explicitly mentions when to use this tool (when the task is not registered), but does not name specific alternatives or provide exclusions. However, the contrasting condition is clear and useful for decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Change the rate limit for a task on a worker.
| Name | Required | Description | Default |
|---|---|---|---|
| taskname | Yes | ||
| workername | Yes | ||
| ratelimit | Yes |
| 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 must carry full behavioral disclosure. It only indicates mutation ('Change') but does not mention reversibility, error conditions, or impacts on other tasks.
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 front-loaded. However, it omits important details, making it slightly under-specified for ideal 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 three string parameters with no descriptions or annotations, and an output schema not explained, the description is insufficient for an agent to use this tool correctly. It does not cover return values, validation, or 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?
The schema has 0% description coverage, and the tool description does not explain the parameters (taskname, workername, ratelimit). It adds no meaning beyond the parameter names, leaving format and constraints unclear.
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 'Change the rate limit for a task on a worker,' specifying the verb (change) and resource (rate limit). This distinguishes it from sibling tools like set_task_timeout or abort_task.
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, no prerequisites, and no context about necessary permissions or side effects.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Change soft and hard time limits for a task on a worker.
| Name | Required | Description | Default |
|---|---|---|---|
| taskname | Yes | ||
| workername | Yes | ||
| soft | No | ||
| hard | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must fully disclose behavior. It only says 'change' but does not explain if limits are set relative or absolute, if changes require restart, or if they are reversible. Lacks details on what happens to current timeout.
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?
Description is a single sentence, which is concise but omits necessary detail. It is minimally adequate for the purpose but too brief for a 4-parameter tool with 0% schema coverage.
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 no annotations, 0% schema coverage, and 4 parameters, the description is incomplete. It does not explain return values (though output schema exists) or side effects. A mutation tool needs more context for safe invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and description adds no meaning for parameters. The term 'soft' and 'hard' are ambiguous; description does not clarify their units, meaning, or defaults.
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 the tool changes soft and hard time limits for a task on a worker. It is specific about the verb and resource, and distinguishes from siblings like set_task_rate_limit, though it could be more explicit about soft vs hard definitions.
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 (e.g., set_task_rate_limit, abort_task). No mention of prerequisites, side effects, or scenarios where it is inappropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Shrink a worker's process pool by n processes.
| Name | Required | Description | Default |
|---|---|---|---|
| workername | Yes | ||
| n | No |
| 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 states the action without explaining effects on running tasks, whether the operation is reversible, or what happens if n exceeds current pool size. The existence of an output schema is not leveraged.
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 redundancy. Efficiently communicates the core action. Front-loaded with actionable information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with 2 parameters and an output schema, the description is minimally adequate. However, it omits edge cases and behavioral context (e.g., minimum pool size, impact on current tasks). Could be improved but not critically incomplete.
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 adds meaning for 'n' ('by n processes') but does not explain 'workername' (e.g., format, how to identify). No parameter enums or constraints are clarified.
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 the tool shrinks a worker's process pool by n processes, using a specific verb and resource. It distinguishes from siblings like 'grow_worker_pool' and 'autoscale_worker_pool' by indicating a reduction operation.
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 shrink versus grow or autoscale. No prerequisites, conditions, or exclusion criteria provided. The description assumes the agent knows when shrinking is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Shut down a Celery worker.
| Name | Required | Description | Default |
|---|---|---|---|
| workername | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description does not disclose behavioral traits such as whether shutdown is graceful, if permissions are required, or if tasks are affected. With no annotations, the full burden falls on the description, which 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, front-loaded sentence with no wasted words. It is appropriately sized for the tool's simplicity.
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 too minimal given the tool's complexity and the presence of many sibling tools. It fails to explain the effect, return value, or how it differs from similar operations like pool shutdowns.
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 description does not add meaning beyond the input schema: the parameter 'workername' is self-explanatory but the description offers no constraints, examples, or context. At 0% schema coverage, this is lacking.
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 'Shut down a Celery worker' uses a specific verb and resource, clearly distinguishing it from sibling tools like 'restart_worker_pool' and 'grow_worker_pool'. The action is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., pool-level operations). There is no mention of prerequisites or context, leaving the agent to infer usage.
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.1abort_taskadd_queue_consumerapply_taskasync_apply_taskautoscale_worker_poolcancel_queue_consumerget_queue_lengthsget_task_infoget_task_resultgrow_worker_poolhealthchecklist_task_typeslist_taskslist_workersrestart_worker_poolrevoke_tasksend_taskset_task_rate_limitset_task_timeoutshrink_worker_poolshutdown_workerScored across 21 tools
Most tools are distinct (e.g., list_workers vs. shutdown_worker), but some overlap exists: create_task vs. apply_task vs. async_apply_task could be confused, and get_task_result vs. get_task_info are similar. However, descriptions clarify the differences.
The majority follow a clear verb_noun pattern (list_*, get_*, set_*, create_, apply_*, etc.). There are minor deviations like 'healthcheck' (instead of check_health) and 'autoscale_worker_pool' (verb+noun with no underscore), but overall consistent.
21 tools is on the higher side but justified given the breadth of Celery/Flower management (workers, tasks, queues, health). The count is within the heavy range but not excessive for a complex domain.
The surface covers worker management (list, shutdown, restart, scale), task lifecycle (apply, send, revoke, abort, get results), and queue control (add/cancel consumer, get lengths). Missing: task retry or purge, but most essential operations are present.
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
MCP server for your apps' tools and custom tools, plus hosted AI agents and approval-gated workflows
MCP server for OpenAI API (chat completions, image generation, embeddings) via AceDataCloud
MCP server that lets AI assistants use all OneSchema features exposed via the public API.
