Allows scheduling meetings via the Calendly API.
Pushes Docker images to a container registry.
Enables self-updating the MCP server by pulling from a remote Git repository.
Allows caching and downloading base models from the Hugging Face Hub.
Sends notifications to Slack channels via an incoming webhook.
Click on "Install 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., "@fine-tuning-os Prepare my training data for fine-tuning"
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.
The Zero-Data Model Context Protocol control plane for LLM fine-tuning — 64 tools across 10 dimensions to prepare, build, train in the client enclave, evaluate, secure, package, and deliver a fine-tuned model — without ever seeing the client's data.
Quickstart · Architecture · The 10 dimensions · Zero-Data · Testing · Security
Related MCP server: MCP Presidio
fine-tuning-os is a zero-dependency-on-secrets MCP server that exposes 64 domain tools (+ 1 health tool) for the entire LLM fine-tuning delivery workflow. It integrates into any MCP-compatible host — Claude Desktop, Claude Code, or a custom orchestrator — with no mandatory secrets at boot.
Tools that require external services (SSH, HuggingFace, SFTP, SMTP, Slack, registries) advertise their requirements via a dry_run response rather than failing silently or faking execution. This means you get a fully operational server and actionable CLI commands from day one, and can progressively enable live execution by setting environment variables.
64 tools / 10 dimensions. prep · synthetic · pipeline · execution · evaluation · security · packaging · docs · client · maintenance — the full fine-tuning delivery lifecycle, callable from any MCP host.
Zero-Data by construction. C1/C3 tools cannot open a socket; C2 tools dry-run (the exact command, with env-name placeholders) until you set the env var — never a faked success. Enforced by tests/test_zero_data.py on every CI run.
Trains where the data lives. The server embeds no torch/unsloth; heavy GPU work runs in the client enclave (or a routed engine) — only sanitized metrics/logs come back.
Real artifacts you own. AES-256-GCM encrypted deliverables + SHA256, French-law contract / NDA / data-destruction-certificate templates, performance & security reports — generated, not black-boxed.
Companion skill. A fine-tuning-os Claude skill (SKILL.md + 16 references) maps every phase to the exact tool, with go/no-go gates and a Zero-Data playbook.
657 tests, ≥95% coverage, ruff + black + mypy clean, Hypothesis property tests + mutation config, CI on Python 3.10–3.13 across Linux / macOS / Windows.
Every tool belongs to one of three classes:
Class | Behaviour | Network | Secrets required |
C1 — Pure/Offline | Generates text, configs, or analysis from local state only | Never | None |
C2 — Emit/Dry-run | Builds and returns an actionable command or payload; if the required env var is absent returns | Only when env is configured | Optional (enables live mode) |
C3 — Static Audit | Reads local files/config and returns a structured report | Never | None |
Guarantees enforced by tests/test_zero_data.py on every CI run:
C1 and C3 tools cannot open sockets (socket patched to raise on any attempt).
C2 tools with no env configured return executed=False, dry_run=True and open no sockets.
65 tools registered at server boot with zero env vars set.
No file written outside the configured workspace root (FTOS_WORKSPACE).
flowchart TB
subgraph Host["MCP Host (Claude Code / Claude Desktop)"]
CC["Claude Code"]
end
subgraph Server["fine-tuning-os MCP Server (stdio)"]
S["server.py<br/>FastMCP + 65 tools"]
subgraph Socle["Socle / Infrastructure"]
ST["store.py<br/>Filesystem abstraction"]
TG["targets.py<br/>gate() — env-based C2 activation"]
MD["models.py<br/>Response dataclasses"]
CR["crypto.py<br/>AES-256-GCM encryption"]
SN["sanitize.py<br/>Secret / PII stripping"]
RE["render.py<br/>Markdown to PDF"]
end
subgraph Tools["10 Tool Modules"]
T1["prep<br/>9 tools"]
T2["synthetic<br/>1 tool"]
T3["pipeline<br/>7 tools"]
T4["execution<br/>8 tools"]
T5["evaluation<br/>7 tools"]
T6["security<br/>6 tools · C3"]
T7["packaging<br/>8 tools"]
T8["docs<br/>8 tools"]
T9["client<br/>6 tools"]
T10["maintenance<br/>4 tools"]
end
end
subgraph Boundary["Zero-Data Boundary"]
direction LR
ZD["C1/C3: socket = BLOCKED<br/>C2: dry_run when no env<br/>All writes: FTOS_WORKSPACE only"]
end
subgraph Enclave["Client Enclave (optional)"]
HF["HuggingFace API"]
SSH["Remote GPU server<br/>SSH"]
REG["Container Registry"]
SFTP["SFTP / SMTP / Slack"]
end
CC <-->|"MCP stdio protocol"| S
S --> Socle
S --> Tools
Tools --> Boundary
Boundary -.->|"C2 live mode<br/>only when env set"| EnclaveThe server registers all 65 tools at startup. C2 tools call gate() from targets.py to check whether the required environment variable is set; if not, they return the dry-run command without touching the network.
# Clone
git clone https://github.com/Casius999/fine-tuning-os.git
cd fine-tuning-os
# Create virtual environment (Python 3.10+)
python -m venv .venv
.venv\Scripts\activate # Windows
# source .venv/bin/activate # Linux / macOS
# Install (dev mode with test dependencies)
pip install -e ".[dev]"Optional PDF export support (requires system libraries):
pip install -e ".[pdf]"python -m fine_tuning_os
# or: fine-tuning-osclaude_desktop_config.json){
"mcpServers": {
"fine-tuning-os": {
"command": "python",
"args": ["-m", "fine_tuning_os"],
"env": {
"FTOS_WORKSPACE": "/path/to/your/workspace"
}
}
}
}All configuration is through environment variables. Setting none of them is valid — the server starts and all tools respond (C2 tools return dry-run commands).
Variable | Class | Description | Default |
| All | Root directory for all project files |
|
| C2 | Path to Python interpreter for local training/merge/quantize | — |
| C2 | Hugging Face token for | — |
| C2 | Remote training server hostname | — |
| C2 | Path to SSH private key for remote operations | — |
| C2 | Container registry URL for | — |
| C2 | Registry authentication token | — |
| C2 | SFTP host for | — |
| C2 | SFTP username | — |
| C2 | Path to SFTP private key | — |
| C2 | SMTP host for | — |
| C2 | SMTP username | — |
| C2 | SMTP password | — |
| C2 | Slack incoming webhook URL for notifications | — |
| C2 | Calendly API token for | — |
| C2 | Git remote URL for | — |
Tool | Class | Description |
| C1 | Generate a full training configuration (LoRA, hyperparams, scheduler) |
| C2 | Emit |
| C1 | Produce |
| C1 | Scaffold a project directory tree under workspace |
| C1 | Load and render a named project template |
| C1 | Return schema documentation for a task type |
| C1 | Validate a dataset sample against the expected schema |
| C1 | Mask PII in a dataset sample for safe preview |
| C1 | Generate train/eval/test split configuration |
Tool | Class | Description |
| C1 | Generate a synthetic instruction-tuning dataset from a schema |
Tool | Class | Description |
| C2 | Emit |
| C2 | Emit |
| C2 | Emit local training command via |
| C1 | Parse and return metrics from a local training log file |
| C1 | Validate remote training config without connecting |
| C1 | Suggest hyperparameter adjustments based on metrics |
| C1 | Generate pytest unit tests for a training script |
Tool | Class | Description |
| C2 | Emit |
| C1 | Build deployment command string for a given engine and host |
| C2 | SSH-trigger training job or emit command if SSH not configured |
| C2 | SSH-tail training logs or emit SSH command |
| C2 | SSH-poll metrics endpoint or emit monitoring command |
| C1 | Analyse a metrics series and flag anomalies |
| C2 | SSH-send pause/resume signal or emit command |
| C1 | Evaluate early-stopping criteria from a metrics snapshot |
Tool | Class | Description |
| C2 | Fetch checkpoint metadata from remote or emit command |
| C1 | Run evaluation loop on synthetic dataset locally |
| C2 | Run evaluation on remote validation set or emit command |
| C1 | Compute BLEU, ROUGE, and task-specific metrics |
| C1 | Generate a sample of model predictions for review |
| C1 | Compare current metrics to a stored baseline |
| C1 | Run bias and fairness checks on evaluation outputs |
Tool | Class | Description |
| C3 | Static security scan of training code (no network) |
| C3 | Audit a Dockerfile for security misconfigurations |
| C3 | Scan dataset for PII and data-leakage patterns |
| C3 | Verify model license compatibility for commercial use |
| C3 | Aggregate audit results into a structured security report |
| C3 | Strip secrets and PII from logs before sharing with Claude |
Tool | Class | Description |
| C2 | Emit merge command or execute via |
| C2 | Emit quantization command (GGUF/GPTQ/AWQ) or execute |
| C2 | Write Dockerfile to workspace and emit |
| C1 | Generate vLLM/SGLang/TGI inference configuration |
| C2 | Emit curl test command or execute against live endpoint |
| C1 | Encrypt a deliverable file with AES-256 and return key hex |
| C2 | Emit SFTP upload command or execute if SFTP configured |
| C1 | Generate a signed delivery note document |
Tool | Class | Description |
| C1 | Generate a service contract from project metadata |
| C1 | Generate a non-disclosure agreement |
| C1 | Generate a full training performance report |
| C1 | Generate end-user guide for a fine-tuned model |
| C1 | Generate deployment and operations guide |
| C1 | Generate data destruction certificate (RGPD) |
| C1 | Render a markdown document to PDF locally |
| C1 | Hash-sign a document and return verification metadata |
Tool | Class | Description |
| C1 | Create client project record and onboarding checklist |
| C2 | Send status email/Slack or emit message if not configured |
| C2 | Create Calendly event or emit scheduling command |
| C1 | Append a timestamped event to the project log |
| C1 | Generate an approval request document |
| C1 | Generate a project invoice from billing metadata |
Tool | Class | Description |
| C1 | Analyse metric drift to detect model rot |
| C1 | Recommend retraining schedule based on drift analysis |
| C1 | Generate update plan for a new base model version |
| C2 | Emit |
Tool | Class | Description |
| C1 | Return server version, tool count, and workspace status |
# Full suite with coverage
pytest --cov=src/fine_tuning_os --cov-report=term-missing --cov-fail-under=95
# Zero-Data invariant tests only
pytest tests/test_zero_data.py -v
# Tool registration check (65 tools)
pytest tests/test_registration.py -v
# Run the synthetic demo bundle (no network, no secrets needed)
python scripts/demo_bundle.pyCoverage gate: ≥95% (CI enforced).
Test structure (tests/):
tests/
├── conftest.py # workspace / store / project_id fixtures
├── test_registration.py # 65-tool registration check
├── test_zero_data.py # Zero-Data invariants (C1/C2/C3 × network × filesystem)
├── test_prep.py
├── test_synthetic.py
├── test_pipeline.py
├── test_execution.py
├── test_evaluation.py
├── test_security.py
├── test_packaging.py # TDD + confinement regression
├── test_docs.py
├── test_client.py
├── test_maintenance.py
├── test_error_paths.py # error-path coverage (OSError, TemplateError, missing-project, bad-crypto)
└── test_property.py # Hypothesis property-based tests (sanitize, crypto, metrics, Store)No secret on disk. All credentials are read from environment variables at call time via targets.py:gate(). No secret is ever written to files or returned in tool output values.
Filesystem confinement. Every tool that writes files resolves the destination through Store.project_dir(project_id), anchored under FTOS_WORKSPACE. Writing outside is rejected with an explicit error.
Sanitize before returning. Use sanitize_logs_for_claude to strip secrets and PII from logs before passing output to any LLM.
C2 dry_run is safe. The returned command string contains only env var name references (e.g., $HF_TOKEN), never literal secret values.
No network for C1/C3. Verified by the test suite on every CI run.
Found a vulnerability? See SECURITY.md — report privately, do not open a public issue.
Contributions are welcome! Please read CONTRIBUTING.md and our Code of Conduct. Commits follow Conventional Commits.
Ce logiciel est fourni à titre d'outil d'assistance technique. Il ne constitue pas un conseil juridique, fiscal, ou professionnel. Les documents générés (contrats, NDA, factures) sont des modèles à soumettre à un professionnel qualifié avant tout usage. L'utilisateur reste seul responsable de l'usage qu'il fait des outils et des sorties produites.
Licensed under the Apache-2.0 license. © 2026 Casius999.
Static AST analysis of Python source — flag network imports/calls without executing code.
| Name | Required | Description | Default |
|---|---|---|---|
| source | No | ||
| allowlist | No | ||
| code_path | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses the critical behavioral trait of 'without executing code', indicating safety and static analysis. However, it lacks details on limitations, required permissions, or side effects beyond that.
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 conveys the core purpose efficiently. Every word is meaningful with no wasted content.
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 (which reduces the need to explain returns), the tool has three optional parameters with no descriptions either in schema or description. The description fails to specify how to use the tool (what source or path to provide), leaving the agent uninformed.
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 mention any of the three parameters (source, allowlist, code_path). The description adds no meaning beyond the schema, which itself lacks descriptions. The agent has no guidance on what to input.
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 performs static AST analysis of Python source to flag network imports/calls without execution. It uses specific verbs ('analyze', 'flag') and resource ('Python source'), distinguishing it from sibling tools like audit_dockerfile_security and bias_fairness_scan.
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 provide explicit guidance on when to use this tool vs alternatives, nor does it mention when not to use it or any prerequisites. The purpose is clear but usage context is absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Parse a Dockerfile and flag: root user, unpinned images, secrets in ENV/ARG, network fetches.
| Name | Required | Description | Default |
|---|---|---|---|
| dockerfile_path | No | ||
| dockerfile_text | No |
| 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 the full burden of behavioral disclosure. It lists the types of issues flagged, which gives some insight into what the tool checks, but it does not mention side effects, permissions required, or whether the tool is read-only. It 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 that gets straight to the point, listing key security checks. It is front-loaded and concise, though it could be slightly expanded to include parameter usage without losing 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 presence of an output schema (not shown), the description omits details about the return format. More critically, the complete lack of parameter explanations leaves a significant gap for a tool with two optional parameters that require explanation for proper 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?
The description does not mention the two parameters (dockerfile_path, dockerfile_text) at all, and the input schema has no descriptions. The agent is left without guidance on how to provide the Dockerfile content, whether one parameter is preferred, or how they interact.
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 parses a Dockerfile and flags specific security issues (root user, unpinned images, secrets in ENV/ARG, network fetches). The action is specific and distinct from sibling tools like audit_code_no_network or bias_fairness_scan.
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 provide any guidance on when to use this tool versus alternatives, nor does it mention prerequisites or exclusions. The usage context is implied by the tool name but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Heuristic bias/fairness scan over template prompts across given categories — deterministic, offline.
| Name | Required | Description | Default |
|---|---|---|---|
| categories | Yes | ||
| test_prompts | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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 mentions 'heuristic', 'deterministic', and 'offline', but does not explain side effects, required permissions, or output behavior. The description is insufficient for a safe understanding of the tool's 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 extremely concise, consisting of a single sentence that conveys the core purpose. However, it sacrifices necessary detail for brevity, making it slightly too short to be fully 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?
Given the tool has an output schema but no return value description, and two required parameters with no documentation, the description is incomplete. It does not explain what the scan produces, how to interpret results, or any constraints on inputs.
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?
Input schema has 0% description coverage, and the tool description adds no meaning beyond the property names ('test_prompts', 'categories'). The description does not explain what these parameters are or how they should be formatted, failing to compensate for the missing schema 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 it performs a heuristic bias/fairness scan over template prompts across given categories, and specifies it is deterministic and offline. While it distinguishes itself from other tools by its focus on bias/fairness, it does not explicitly differentiate from siblings like evaluate_on_synthetic or scan_data_leakage_risk.
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 lacks context about prerequisites, appropriate scenarios, or situations where another tool would be preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Emit the huggingface-cli download command for a base model (dry_run — no network).
| Name | Required | Description | Default |
|---|---|---|---|
| dest | Yes | ||
| repo_id | Yes | ||
| revision | No | main |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and adequately discloses that the tool is a dry run (no network) that emits a command. This prevents misinterpretation as a harmful operation. However, it could mention that no files are modified or that the command is printed to output.
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 is concise and front-loaded with the core purpose. It efficiently communicates the tool's function without unnecessary words, earning a place for its 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?
Given the tool's simplicity and the presence of an output schema, the description covers the main intent and behavioral constraint (dry run). However, it lacks parameter guidance and does not detail the output format beyond being a command. This is adequate but leaves gaps for an agent unfamiliar with huggingface-cli.
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 any parameter (dest, repo_id, revision). An agent must rely on parameter names alone, which may be ambiguous (e.g., 'dest' could be local or remote). The description would benefit from brief parameter clarifications.
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 'emits the huggingface-cli download command for a base model' and specifies it's a dry run with no network activity. This verb+resource combination is specific and distinguishes it from sibling tools like _mcp_update_base_model which likely performs actual downloads.
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 for previewing commands via 'dry_run — no network', but it does not explicitly state when to use this tool versus alternatives, nor does it mention when not to use it. No sibling tools are referenced for comparison.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compute per-metric deltas between fine-tuned and baseline and render a Markdown comparison table.
| Name | Required | Description | Default |
|---|---|---|---|
| metrics_ft | Yes | ||
| metrics_base | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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 states the tool computes and renders a table, implying a non-destructive read operation, but does not explicitly confirm no side effects, required permissions, or details on return format (though output schema may cover that). This 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?
Single sentence, front-loaded with the core action, no redundant words. Every part contributes to the 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 description explains what the tool does and the meaning of inputs. Given an output schema exists, return value details are likely covered. However, it lacks usage context (when to call) and does not mention that this is a read-only operation, which would help 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?
With 0% schema description coverage, the description compensates by labeling 'metrics_ft' as fine-tuned and 'metrics_base' as baseline, adding meaning beyond the parameter names. It clarifies the relationship between the two parameters, which is essential 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 action: 'Compute per-metric deltas between fine-tuned and baseline and render a Markdown comparison table.' It specifies both the computation and output format, and the verb 'compute' and 'render' with specific resources (deltas, table) leave no ambiguity.
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. With over 60 sibling tools, including 'compute_metrics' and 'evaluate_on_validation_set', the lack of context or exclusion conditions forces the agent to rely on heuristic matching.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compute BLEU, ROUGE-1/2/L, perplexity, accuracy, macro-F1 from preds and refs — pure, offline.
| Name | Required | Description | Default |
|---|---|---|---|
| nll | No | ||
| loss | No | ||
| refs | Yes | ||
| task | Yes | ||
| preds | Yes | ||
| logprobs | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden. It states 'pure, offline' implying no side effects or network access, which adds some context. However, it does not disclose required permissions, data handling, or edge cases. With no annotations, a baseline score of 3 is appropriate.
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 that front-loads key information (metrics list, offline nature). It is concise, though some might argue it sacrifices completeness for 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 that the tool has six parameters with no descriptions, no annotations, but has an output schema, the description should compensate by explaining parameters, expected task values, and return format. It only mentions preds and refs, leaving significant gaps. The presence of an output schema reduces some burden, but the description is still 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%, yet the description does not explain any parameter beyond mentioning 'preds and refs' in the tool's purpose. The schema shows six parameters including nll, loss, logprobs, and task, but none are described. The description adds no value for parameter semantics.
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 the tool computes specific metrics (BLEU, ROUGE-1/2/L, perplexity, accuracy, macro-F1) from preds and refs, and characterizes it as 'pure, offline', which clearly distinguishes it from sibling evaluation and reporting tools.
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 evaluate_on_validation_set or compare_to_baseline. It only mentions 'offline' but does not set conditions or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Detect divergence, NaN, plateau, and data-leak signs from sanitized logs/metrics.
| Name | Required | Description | Default |
|---|---|---|---|
| logs | Yes | ||
| metrics | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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 basic function; it does not mention what the output format is, whether the operation is destructive, any rate limits, or side effects. It implies inputs should be sanitized but doesn't enforce 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 concise sentence, but it lacks any structure (e.g., sections for parameters, usage). It efficiently states purpose but sacrifices completeness.
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 (not shown), the description is insufficient for a tool with nested objects and required parameters. It omits parameter guidance, usage context, and validation criteria, making it incomplete for an AI 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%, and the description adds no meaning to the parameters 'logs' and 'metrics'. It does not explain expected format (e.g., what keys in the metrics object) or constraints, leaving the agent to guess.
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 detects specific anomaly types (divergence, NaN, plateau, data-leak signs) from logs/metrics, providing a specific verb and resource that distinguishes it from siblings.
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, nor any prerequisites or exclusions. The context signals show many sibling tools, but no differentiation is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch checkpoint metadata (step, loss…) without downloading weights (dry-run unless FTOS_SSH_* configured).
| Name | Required | Description | Default |
|---|---|---|---|
| target | Yes | ||
| checkpoint | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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 key behavioral trait of being a dry-run unless SSH is configured. But it lacks details on authentication needs, error states, or whether it is read-only, which are important for safe usage.
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 efficiently conveys the purpose and a critical condition. No wasted words.
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 only two parameters, so complexity is low. The description explains the main behavior, but the missing parameter explanations create a significant gap. Given the output schema exists, return values are covered, but parameter documentation is essential.
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 no parameter descriptions exist in the schema. The description does not explain what 'target' or 'checkpoint' refer to, leaving the agent without guidance on how to provide valid inputs.
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 it fetches checkpoint metadata (step, loss) without downloading weights, using a specific verb 'fetch' and resource 'checkpoint metadata'. This distinguishes it from any tool that downloads weights.
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 includes a condition for dry-run versus actual download based on FTOS_SSH_* configuration, providing clear context. However, it does not explicitly mention when to use this tool versus alternatives 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.
Check which deployment env vars are present/missing (names only — never secret values).
| Name | Required | Description | Default |
|---|---|---|---|
| deployment_spec | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It explicitly states that only names are checked, never secret values, which is a key behavioral trait. However, it does not explicitly state whether the tool is read-only or has side effects, though the name 'dry_run' hints at no modifications.
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 efficiently communicates the core purpose and a key constraint (no secret values). 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 0% schema description coverage and no annotations, the description is the primary source of information. It adequately explains the tool's purpose but lacks details on parameter structure and return value format (though an output schema exists). For a simple one-parameter tool, it is minimally sufficient 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?
Schema description coverage is 0%, so the description must compensate. The description implies that 'deployment_spec' is a specification of env vars, but does not describe its structure (e.g., format, required fields). For a free-form object parameter, 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 verb 'Check' and the resource 'deployment env vars', and specifies it checks presence/missing only. It also clarifies it never shows secret values, distinguishing it from potential similar tools that might expose secrets. Sibling tools do not seem similar.
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 for verifying deployment environment variables before deployment, but does not explicitly state when to use it versus alternatives, nor does it provide when-not-to-use guidance or mention excluded scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Evaluate early-stop (patience + min_delta) over a loss history.
| Name | Required | Description | Default |
|---|---|---|---|
| metrics | Yes | ||
| patience | No | ||
| min_delta | No |
| 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 the full burden. It does not disclose side effects, required state (e.g., a pre-existing loss history), or what the tool returns (output schema exists but is unmentioned). The behavior is only hinted at.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that is very concise and front-loads the core purpose. However, it omits necessary details, making it slightly too terse for full 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 tool has three parameters (one a complex object) and an output schema, the description is insufficient. It does not explain the metrics format, interpretation of patience and min_delta, or the output structure, leaving significant gaps for correct 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%, so the description must compensate. It mentions 'patience + min_delta' but provides no details on the 'metrics' parameter (an object with additionalProperties) or how min_delta is applied. 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 clearly states the tool evaluates early-stop using patience and min_delta over a loss history, distinguishing it from sibling tools like monitor_training_metrics or compute_metrics by focusing on the specific early stopping logic.
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 or under what circumstances to trigger early stopping. The description only states what it does, not when it should be applied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run a deterministic eval over synthetic data to verify the pipeline — no real data required.
| Name | Required | Description | Default |
|---|---|---|---|
| project_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It mentions 'deterministic' but does not state read-only status, side effects, permissions, or failure modes. The tool could be a read operation, but this is not confirmed.
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 that front-loads the core purpose and a key constraint (no real data). Every word contributes value; no wasted space.
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 a simple input schema (1 parameter) and an output schema (implied by context), the description adequately conveys purpose and usage context. It could add behavioral details, but the presence of an output schema excuses the need to explain 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 input schema has 0% description coverage, and the description does not explain the sole parameter 'project_id' beyond its name. The agent cannot infer what the project ID represents or how it affects the evaluation.
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 runs a deterministic eval over synthetic data to verify the pipeline, distinguishing it from real-data evaluations. The verb 'run' and resource 'eval over synthetic data' are specific and actionable.
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 phrase 'no real data required' implies use when real data is unavailable or inappropriate, providing clear context. However, it does not explicitly mention alternatives like evaluate_on_validation_set or when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run eval on the client validation set via SSH (dry-run unless FTOS_SSH_* configured).
| Name | Required | Description | Default |
|---|---|---|---|
| target | Yes | ||
| eval_spec | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the burden. It discloses the SSH execution method and dry-run default behavior, which adds transparency. However, it does not mention side effects, safety profile, or what happens when SSH is fully configured.
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 front-loads the main action. Every word adds value, but it could be slightly expanded 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 the complexity (SSH, dry-run, nested eval_spec object), the description is too minimal. It does not explain output, configuration requirements, or how to set up the SSH context. Critical information for correct invocation is missing.
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 either parameter ('target' or 'eval_spec'). The description adds no meaning beyond the schema, which is insufficient given the coverage gap.
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 'Run eval' and the resource 'client validation set', with a specific context 'via SSH'. However, it does not differentiate from sibling tools like 'evaluate_on_synthetic' or 'compute_metrics', so purpose is clear but not uniquely distinguished.
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 versus alternatives. The dry-run note implies a condition, but no 'when to use' or 'when not to use' context is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Report Fine-Tuning OS server health: version, workspace path, and which external targets are configured (booleans only — never secrets).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that it returns booleans only and never secrets, which is valuable. However, lacks details on side effects, authentication needs, or potential network dependencies. Without annotations, the description carries the burden and is mostly transparent.
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, clear sentence with no wasted words. Front-loaded with the core action and return values. Highly 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?
For a zero-parameter health report with an output schema, the description adequately summarizes return values. No gaps given the tool's simplicity.
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 input schema fully covers them. Baseline 4 per guidelines as there's nothing additional to describe.
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 reports server health including version, workspace path, and configured external targets as booleans. It uniquely distinguishes itself from siblings as a health check tool.
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 or not use this tool versus alternatives. The description implies it's for health checks but doesn't provide context like prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Produce docker run / compose command using env NAME references only — never secret values.
| Name | Required | Description | Default |
|---|---|---|---|
| gpus | Yes | ||
| image | Yes | ||
| mounts | Yes | ||
| env_names | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses one behavioral trait: it never uses secret values. However, it does not mention other important aspects such as input validation, side effects, or authentication requirements. Since annotations are absent, the description carries the full burden but 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 of 13 words, concise and front-loaded with the key action. Every word contributes value 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?
Given the absence of annotations and schema descriptions for 4 parameters, the description is too sparse. It does not cover parameter formats or usage context, making it incomplete for an agent to use confidently.
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 add meaning. It explains that env_names are references to environment variable names and not secret values, but it provides no detail on gpus, image, or mounts, leaving their semantics 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 the tool's function: to produce a docker run or compose command. It also specifies a key constraint (using env NAME references, never secret values), which distinguishes it from other tools that might handle secrets or generate different commands.
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 or compare it to alternatives like `_mcp_build_docker_image` or `push_docker_to_registry`. No guidance on prerequisites or exclusions is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Emit a Python harness to generate sample predictions on synthetic prompts — pure, offline.
| Name | Required | Description | Default |
|---|---|---|---|
| prompts | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must fully convey behavioral traits. It states the tool is 'pure, offline' but omits details such as whether it requires a model, writes files, or has side effects. The description is insufficient for safe agent invocation.
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 is front-loaded and efficient. However, it is too terse and could benefit from additional context 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 presence of an output schema (unseen), the description need not detail return values, but it fails to mention prerequisites, whether a model is needed, or if the tool is standalone. For a tool generating predictions, this is 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?
The schema has 0% description coverage for the single required parameter 'prompts'. The description does not explain what prompts are expected, their format, or how they are used. No value is added beyond the schema name.
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 emits a Python harness for generating sample predictions on synthetic prompts, which is specific and distinguishes it from evaluation or deployment tools among siblings. However, it could be more precise about what the harness includes.
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 like evaluate_on_synthetic or generate_synthetic_dataset. The phrase 'pure, offline' implies local use but does not exclude other scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Sanitize a dataset file via pattern-based masking and write an .anon copy.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It suggests a write operation but does not confirm whether the original file is preserved, what patterns are used, or any side effects like file locking or access 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?
Single sentence with no redundant words. However, it omits critical details that could be included without breaking 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 an output schema, the description lacks details on patterns, supported file types, or how this tool fits into a workflow with siblings like scan_data_leakage_risk or generate_synthetic_dataset.
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 only parameter, file_path, is not described at all in the tool description. The description mentions 'dataset file' but gives no format, validation, or usage 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 states a specific verb ('sanitize') and resource ('dataset file'), and clearly distinguishes the output ('.anon copy'). It is unique among siblings, as no other tool explicitly handles dataset anonymization.
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., sanitize_logs_for_claude), nor any prerequisites or exclusions. The agent must infer context from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Render Dockerfile.train and emit/execute docker build command (dry-run unless local_python+docker configured).
| Name | Required | Description | Default |
|---|---|---|---|
| tag | Yes | ||
| base_image | Yes | ||
| project_id | Yes | ||
| cache_models | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses the two modes of operation (dry-run vs actual build) and that it both renders and builds. However, it lacks details on side effects (e.g., overwriting files, need for Docker daemon) which could be expected for a build 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, front-loaded sentence with no unnecessary words. It immediately communicates the core action and the key behavioral nuance.
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 tool with 4 parameters and a complex build process, the description is minimal. It does not explain prerequisites (e.g., existence of Dockerfile.train), output details, or how the dry-run mode works. While an output schema exists, the agent still lacks guidance on parameter semantics and configuration.
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 4 parameters with 0% description coverage, and the description adds no information about any parameter (tag, base_image, project_id, cache_models). The agent must rely solely on parameter names, which may be insufficient for correct 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 tool renders a Dockerfile and executes a docker build command, using specific verbs 'Render' and 'emit/execute'. It distinguishes from sibling tools like '_mcp_build_inference_container' and 'test_docker_build' by focusing on building the training image.
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 a key usage condition: 'dry-run unless local_python+docker configured'. This tells the agent when the tool will actually execute versus just emitting the command. However, it does not explicitly compare to alternatives or state 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.
Render Dockerfile.infer and emit docker build command — dry_run unless local docker configured.
| Name | Required | Description | Default |
|---|---|---|---|
| engine | No | vllm | |
| model_path | Yes | ||
| project_id | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the dry-run behavior unless local Docker is configured, which is a key behavioral trait. However, it omits other details like error handling, required permissions, or side effects (e.g., generating files). With no annotations, the description bears the full 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, compact sentence that conveys the core functionality and key behavioral note without any extraneous information. It is well-structured 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?
Despite having a simple signature, the tool has three parameters with no schema descriptions and no parameter details in the description. The output schema exists but its content is unknown. The description fails to fully orient the agent on required inputs and expected outputs.
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%, yet the description provides no explanations for the three parameters (engine, model_path, project_id). The agent is left with only names and types, 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 clearly states the tool renders a Dockerfile and emits a docker build command, with a dry-run fallback. It distinguishes itself from sibling tools like _mcp_build_docker_image and test_docker_build by focusing on the inference container build, but does not explicitly contrast them.
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 _mcp_build_docker_image or test_docker_build. The description does not specify prerequisites (e.g., having a Dockerfile.infer) or conditions for actual execution beyond local Docker configuration.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Detect performance drift in a time-ordered metric history — pure, deterministic.
| Name | Required | Description | Default |
|---|---|---|---|
| threshold | No | ||
| metric_key | Yes | ||
| metric_history | Yes | ||
| lower_is_better | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must bear the full burden of behavioral disclosure. It only adds 'pure, deterministic', which addresses algorithm behavior but not side effects, permissions, or data mutation. Critical behaviors like read-only or auth requirements are omitted.
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 extremely concise—a single sentence with no wasted words. However, it could benefit from slightly more structure to cover key aspects.
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, no schema descriptions, no annotations, and an output schema that is not described, the description is insufficient. It does not explain the meaning of threshold, how drift is detected, or what the tool returns.
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 (no descriptions for any parameter). The description does not mention any parameter or add meaning beyond the parameter names. Since no compensation is provided, the score is minimal.
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 'detect' and the resource 'performance drift in a time-ordered metric history'. It is specific and informative, but does not differentiate from sibling tools like detect_anomalies.
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. The description does not mention prerequisites, contexts, 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.
Initialise the project directory tree and project.json in the workspace.
| Name | Required | Description | Default |
|---|---|---|---|
| project_id | Yes | ||
| client_name | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states it initializes a directory tree and project.json, implying file creation. However, without annotations, it does not disclose whether it overwrites existing files, requires specific permissions, or has side effects. The transparency 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 a single, concise sentence. It contains no extraneous information and communicates the core action efficiently.
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 (not shown) and is relatively simple, the description covers the basic action. However, it lacks parameter explanations and usage context, making it less complete for an agent that needs to know how to use parameters 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 input schema has two required parameters (project_id, client_name) with no descriptions in the schema (0% coverage). The tool description does not explain what these parameters represent or their expected format (e.g., project ID format, client name restrictions). Thus, the description adds no 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 tool initializes a project directory tree and project.json. The verb 'initialise' and specific resources 'project directory tree' and 'project.json' make the purpose unambiguous. It also distinguishes from sibling tools like _mcp_onboard_client or _mcp_load_project_template which handle different aspects of project setup.
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. There is no mention of prerequisites, such as whether a workspace must be empty, or when it should be run relative to other tools. The description provides no context for proper usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Render a LoRA training config YAML and write it to the project config/ directory.
| Name | Required | Description | Default |
|---|---|---|---|
| lr | No | ||
| epochs | No | ||
| framework | No | unsloth | |
| lora_rank | No | ||
| scheduler | No | cosine | |
| base_model | Yes | ||
| batch_size | No | ||
| project_id | Yes | ||
| max_seq_len | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that it writes to the config/ directory, but lacks details on whether it overwrites existing files, required project existence, or permissions. No annotations are provided, so the description carries the full burden, but it is only partially transparent.
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 clear sentence that efficiently conveys the core action. It is front-loaded and avoids unnecessary words, though it could benefit from parameter bullet points.
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, 0% schema coverage, and no annotations, the description is far from complete. It does not explain return values, prerequisites, or side effects beyond writing to config/, making it insufficient for correct tool 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%, meaning no parameter descriptions exist. The description adds no information about any of the 9 parameters, leaving the agent to infer meaning from names and defaults alone.
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 ('Render...and write'), the resource ('LoRA training config YAML'), and the destination ('project config/ directory'), distinguishing it from sibling tools that create other configs or perform other MCP operations.
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 or not use this tool versus alternatives. The description implies it's for creating a training config, but does not compare to siblings like _mcp_generate_inference_config or _mcp_run_local_synthetic_train.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Validate and persist an abstract data schema (no real content).
| Name | Required | Description | Default |
|---|---|---|---|
| columns | Yes | ||
| task_type | Yes | ||
| project_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must fully disclose behavior. It mentions 'validate and persist' but gives no details on side effects, authentication needs, or whether the operation is destructive.
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 captures the core purpose. However, it is slightly terse given the complexity of the parameters.
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, the description lacks parameter explanations, usage context, and behavioral details, making it incomplete for a tool that persists data.
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 information about the three parameters (project_id, columns, task_type). It does not explain what columns should contain or valid task_type 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 clearly states the tool validates and persists an abstract data schema, distinguishing it from siblings like _mcp_validate_data_schema which likely only validates. The phrase 'no real content' clarifies it deals with metadata.
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 conditions, prerequisites, or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
AES-256-GCM encrypt deliverable file(s); key returned ONCE in data, never persisted.
| Name | Required | Description | Default |
|---|---|---|---|
| paths | Yes | ||
| output_dir | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses that the key is returned only once and never persisted, which is critical security-related behavior. However, it does not mention whether files are modified in place, or if the operation is reversible, leaving gaps.
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 it omits necessary detail about parameters and usage. It is front-loaded with key info, but at the expense of completeness.
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 2 parameters, no schema coverage, and an output schema exists, the description should provide enough context for correct invocation. It fails to explain the parameters or the structure of the output, making it 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%, so the description must explain parameters. It does not mention 'paths' or 'output_dir' at all, forcing the agent to guess their meaning. This is a significant failure.
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 the tool encrypts deliverable file(s) with AES-256-GCM, which is a specific verb and resource. It distinguishes from sibling tools like _mcp_sign_document or _mcp_upload_deliverable by focusing on encryption.
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 versus alternatives. It does not mention conditions, prerequisites, or scenarios to avoid. The description is solely about what it does, not context of use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Convert a Markdown document to PDF — skips gracefully if weasyprint absent.
| Name | Required | Description | Default |
|---|---|---|---|
| md_path | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description partially discloses behavior: it mentions graceful skipping if weasyprint absent, which is useful. However, it does not indicate whether the PDF is saved to disk, returned as a stream, or any side effects. More transparency is needed for a conversion 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 sentence with no redundant words. It conveys the core action and an important exception 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?
Given the tool's simplicity (one parameter, output schema present), the description provides minimal but adequate context. However, it lacks details on the output format or how the PDF is delivered, which an agent would need to use the tool effectively.
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 the single parameter 'md_path'. The agent must infer its meaning from the name alone, which may be insufficient for precise invocation (e.g., file path format).
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 ('convert') and the resource ('Markdown document to PDF'). It is specific and distinguishes this tool from siblings that perform other document or export tasks, though it does not explicitly differentiate from similar tools.
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 description does not provide prerequisites, context for usage, or mention any conditions under which it should be preferred or avoided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Render a French-law service contract (Code civil, CPI, RGPD art. 28) as Markdown + optional PDF.
| Name | Required | Description | Default |
|---|---|---|---|
| clauses | No | ||
| montant | Yes | ||
| client_nom | No | [CLIENT] | |
| project_id | Yes | ||
| prestataire_nom | No | [PRESTATAIRE] |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey all behavioral traits. It only discloses output format (Markdown + optional PDF) but does not state whether the tool is read-only, whether it modifies any data, requires authentication, or has side effects. This is insufficient for an agent assessing invocation safety.
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 efficiently conveys the core purpose and output formats. Every word is functional, with no redundancy or unnecessary 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?
Given the tool has an output schema (not shown but indicated) and operates in a legal document generation context, the description provides enough to understand the high-level function. However, it omits parameter semantics and behavioral traits, leaving gaps for an agent making a precise invocation decision.
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 5 parameters with 0% description coverage, meaning no parameter descriptions are provided in the schema. The tool description adds no information about any parameter, leaving their semantics entirely to the schema field names (e.g., 'clauses', 'montant'). Since schema coverage is 0%, the description should compensate but fails to do so.
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 renders a French-law service contract with specific legal references (Code civil, CPI, RGPD art. 28) and output formats (Markdown + optional PDF). This verb-resource combination and legal specificity distinguish it from sibling tools like _mcp_generate_nda or _mcp_generate_invoice.
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 for French-law service contracts by naming legal references, but it does not explicitly state when to use this tool over alternatives. No exclusion criteria or prerequisites are provided, relying solely on the tool name and context to guide selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Render delivery note with file list + SHA256 each + decryption procedure.
| Name | Required | Description | Default |
|---|---|---|---|
| files | Yes | ||
| client_nom | No | [CLIENT] | |
| project_id | Yes | ||
| prestataire_nom | No | [PRESTATAIRE] |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavior. It mentions 'decryption procedure' and the content of the note, giving some insight into output. However, it does not clarify whether the tool is read-only, has side effects, or requires specific permissions. The description adds value beyond the name but lacks depth on safety or side effects.
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 of 9 words that immediately conveys the core functionality. There is no extraneous information, and it is front-loaded with the key action and content.
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?
While the description covers the main deliverable components, it does not explain the output schema (which exists but is not shown), nor does it detail how to use the four parameters effectively. Given the complexity of a document generation tool with multiple parameters and siblings, the description is somewhat 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?
The input schema has 0% description coverage, meaning no parameter descriptions are provided. The tool description vaguely references 'file list', 'SHA256', and 'decryption procedure' but does not map these to parameters like 'files', 'client_nom', or 'prestataire_nom'. It offers insufficient detail to understand parameter roles, failing to compensate for the lack of schema 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 verb 'Render' and the resource 'delivery note', and specifies the included components: file list, SHA256 hashes, and decryption procedure. This distinguishes it from sibling tools like _mcp_generate_contract or _mcp_generate_invoice which have different content.
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, such as _mcp_encrypt_deliverable or _mcp_upload_deliverable. There is no mention of prerequisites, ordering, or conditions that would help an agent decide when to invoke this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Render an IT deployment guide for the inference container.
| Name | Required | Description | Default |
|---|---|---|---|
| port | No | ||
| gpu_device | No | all | |
| project_id | Yes | ||
| api_hostname | No | api.example.com |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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 fails to mention whether the tool is read-only, requires authentication, has side effects (e.g., writing to disk), or performance considerations. Only the output format is not discussed, despite an output schema existing.
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 only one sentence, achieving high conciseness but at the cost of omitting critical information. It is front-loaded with the core purpose but lacks structure to support further details. Every sentence earns its place, but the description is too sparse to be fully 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?
Given the tool has 4 parameters, no schema descriptions, and no annotations, the description is insufficient for an agent to correctly invoke it. It does not explain the output format (even though an output schema exists, the description should outline what a 'deployment guide' entails), prerequisites, or typical use cases alongside siblings.
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 4 parameters with 0% description coverage, meaning the schema provides no explanations for 'port', 'gpu_device', 'project_id', or 'api_hostname'. The description adds no parameter information whatsoever, leaving the agent to guess the meaning and defaults. This is especially problematic for 'gpu_device' and 'api_hostname'.
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 'Render' and identifies the resource as 'IT deployment guide for the inference container'. It distinguishes from siblings like '_mcp_generate_user_guide' which targets a different document type. However, 'Render' is somewhat vague (could mean generate, format, or present), slightly reducing clarity.
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 such as '_mcp_generate_user_guide' or '_mcp_generate_security_report'. There is no mention of prerequisites, context, or exclusions, leaving the agent without comparative context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Render an irreversible data destruction certificate (RGPD art. 17, 5-1-c, 32).
| Name | Required | Description | Default |
|---|---|---|---|
| date | Yes | ||
| lieu | No | Paris | |
| methode | Yes | ||
| client_nom | No | [CLIENT] | |
| project_id | Yes | ||
| signataire | No | [SIGNATAIRE] | |
| prestataire_nom | No | [PRESTATAIRE] | |
| description_donnees | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explicitly labels the action as 'irreversible', which is critical behavioral context not covered by annotations (none provided). It also references legal basis, adding useful 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, front-loaded sentence that efficiently states the core purpose. It could be expanded slightly to include parameter hints, but it is 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 an output schema existing, the description does not describe the return value (e.g., PDF, certificate format). Combined with zero parameter documentation, the agent lacks sufficient context to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not explain any of the 8 parameters (e.g., date, methode, client_nom). The agent has no guidance on what values to provide.
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 defines the tool's purpose: to render an irreversible data destruction certificate, citing specific GDPR articles. This is precise and distinguishes it from other generation tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use or when-not-to-use guidance is provided. Among siblings like _mcp_generate_contract, there is no differentiation or context for choosing this tool over alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Produce inference server config (port, api key NAME ref, context, limits) — no secrets embedded.
| Name | Required | Description | Default |
|---|---|---|---|
| port | No | ||
| engine | No | vllm | |
| project_id | No | ||
| extra_params | No | ||
| context_length | No | ||
| max_concurrent | No | ||
| api_key_env_name | No | API_KEY |
| 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. It does disclose one behavioral trait: 'no secrets embedded', which is valuable for security awareness. However, it does not mention other aspects like whether the config is written to disk, returned, or if it requires network access. Given the lack of annotation support, a 3 is appropriate—minimal but not completely absent.
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 with the core verb. However, it could be slightly more structured (e.g., listing parameters explicitly) without adding much length. Still, it is well within acceptable conciseness, earning a 4.
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 (7 parameters, no schema descriptions, no annotations), the description is too sparse. It does not explain the purpose of engine, project_id, extra_params, or how the output is returned. While an output schema exists, the input side is under-documented for an agent to make informed decisions about parameter overrides. The tool's simplicity doesn't fully excuse the lack of detail.
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 'port, api key NAME ref, context, limits', mapping partially to parameters (port, api_key_env_name, context_length, max_concurrent). But it omits engine, project_id, and extra_params. It adds some meaning beyond the schema (e.g., 'api key NAME ref' clarifies that the parameter is an environment variable name, not the key itself), but coverage is incomplete, resulting in a mid-range score.
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 function: 'Produce inference server config' with specific elements (port, api key NAME ref, context, limits). It also adds a safety note about no secrets embedded, which distinguishes it from potentially similar tools that might handle secrets. This is a specific verb+resource with added context, earning a top score.
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. While many siblings exist (e.g., _mcp_generate_deployment_guide), the description does not indicate any conditions, prerequisites, or exclusions. The agent is left to infer context from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Render an invoice from prestation lines as Markdown + optional PDF.
| Name | Required | Description | Default |
|---|---|---|---|
| lines | Yes | ||
| client_nom | No | [CLIENT] | |
| project_id | Yes | ||
| invoice_ref | No | ||
| prestataire_nom | No | [PRESTATAIRE] | |
| conditions_paiement | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must carry the full burden. It describes the action as 'render' but does not disclose whether this is read-only, destructive, or requires specific permissions. Minimal behavioral insight beyond the output 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?
Extremely concise (one sentence), but at the cost of omitting essential details. It is not overly verbose but lacks completeness for effective use.
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 6 parameters (2 required) and no annotations or parameter descriptions, the description is insufficient for an agent to correctly invoke it. It does not explain the input structure, defaults, or expected 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?
Description mentions 'prestation lines' corresponding to the lines parameter, but provides no information about the other five parameters (client_nom, project_id, invoice_ref, prestataire_nom, conditions_paiement). With 0% schema description coverage, the description fails to compensate.
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 renders an invoice from prestation lines, distinguishing it from sibling tools that generate other documents like contracts or delivery notes. However, 'prestation lines' may be domain-specific and not immediately clear to all agents.
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. Does not specify prerequisites, limitations, or when to avoid using it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Render a bilateral NDA (secret des affaires — Code de commerce L151-1 s.) as Markdown.
| Name | Required | Description | Default |
|---|---|---|---|
| duree | No | 3 ans | |
| objet | No | ||
| partie_a | Yes | ||
| partie_b | Yes | ||
| project_id | Yes | ||
| juridiction | No | Tribunal de commerce de Paris |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must reveal behavior. It states output is Markdown, but does not disclose side effects (e.g., file creation, database storage), error handling, or input validation. Some legal context is given but significant gaps remain.
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 directly conveys the tool's function with no extraneous words. It is well-structured for quick understanding.
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 the presence of an output schema (markdown), the description omits details about return value structure, parameter requirements, and usage context. For a legal document generator, more completeness is expected.
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 tool description adds no information about the parameters (duree, objet, etc.). Beyond the names, no semantics are provided, failing to help agents understand parameter meanings.
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 it renders a bilateral NDA as Markdown, with specific legal reference (Code de commerce L151-1 s.). This distinguishes it from sibling _mcp_generate_contract, providing a specific verb and 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 explicit guidance on when to use or not use this tool versus alternatives. The context implies it's for NDA generation, but without specifying when to prefer it over _mcp_generate_contract, clarity is limited.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Render a performance report with metrics, baseline comparison, and curves description.
| Name | Required | Description | Default |
|---|---|---|---|
| notes | No | ||
| metrics | Yes | ||
| baseline | No | ||
| project_id | Yes | ||
| eval_dataset | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral traits like side effects or read-only nature. It only states 'render' which implies output but no details on whether data is modified, auth needs, or rate limits.
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 is efficient but lacks structure for 5 parameters. Could front-load purpose and then list key behaviors or parameter roles.
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 5 parameters (2 required) and an output schema, the description is incomplete. It doesn't explain required project_id, metrics object, optional baseline, eval_dataset, or notes. Output schema exists but not referenced.
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 parameter explanations. It mentions 'metrics, baseline comparison, and curves' but does not clarify which parameters correspond or their formats.
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 renders a performance report with metrics, baseline comparison, and curves. It distinguishes from siblings like compare_to_baseline and compute_metrics by focusing on rendering rather than computation.
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., compute_metrics, compare_to_baseline). No prerequisites or context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a pinned requirements.txt for the given fine-tuning framework.
| Name | Required | Description | Default |
|---|---|---|---|
| cuda | No | ||
| extras | No | ||
| framework | No | unsloth | |
| project_id | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must bear the full burden of behavioral disclosure. It does not mention side effects (e.g., whether it writes to disk or returns content), permissions needed, or any constraints. The description is too minimal for a tool with no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise, but it omits necessary information. It does not waste words, but it is under-specified for the number of parameters and lack of annotations.
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 that the tool has four parameters and no annotations, the description is insufficient. While an output schema exists, the description does not integrate with it or provide enough context for an agent to use the tool correctly. Sibling tools are numerous, and no differentiation is made.
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%, meaning no parameter descriptions exist in the schema. The description fails to explain any of the four parameters: cuda, extras, framework, project_id. It only implies the framework parameter via context, but does not specify allowed values or formats.
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 'Generate' and the resource 'pinned requirements.txt' with context 'for the given fine-tuning framework'. It distinguishes itself from siblings by specifying a specific output file, unlike other generate tools like _mcp_generate_inference_config.
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 _mcp_create_training_config which might also involve requirements. The description lacks context for 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.
Aggregate security audit results into a Markdown (+ optional PDF) report for a project.
| Name | Required | Description | Default |
|---|---|---|---|
| findings | No | ||
| project_id | 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. It mentions output format but not side effects, required data state, or whether it modifies anything. No disclosure about file creation, access rights, or how optional PDF is triggered.
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 verb and resource, no superfluous words. Perfectly concise for stating the core 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?
Lacks context: no explanation of the 'findings' parameter, no description of report content sections, and no mention of how optional PDF is controlled. With many sibling tools, more context is needed for correct 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 coverage is 0% and the description does not explain any parameters. The 'findings' parameter is ambiguous (anyOf object or null) with no guidance on structure. 'project_id' is required but not described.
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 it aggregates security audit results into a Markdown report with optional PDF. It distinguishes from similar generate_* tools by specifying 'security audit results', but does not explicitly differentiate from sibling audit tools like audit_code_no_network.
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., _mcp_generate_performance_report or running individual audit tools). The description implies usage after security audits, but does not state prerequisites or exclude inappropriate scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate n deterministic synthetic rows (10-50) matching the project data schema and write as JSONL.
| Name | Required | Description | Default |
|---|---|---|---|
| n | Yes | ||
| seed | Yes | ||
| schema | No | ||
| project_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description mentions 'deterministic' and 'write as JSONL', which provides basic behavioral info. However, no annotations exist, so the description should disclose side effects like file creation location, overwrite behavior, or permissions required. These are missing.
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 with the verb and output. It contains no unnecessary words. However, could be slightly more structured (e.g., listing key parameters) 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 the presence of an output schema and 4 parameters, the description is adequate for purpose but lacks details on parameter formats (e.g., seed role), side effects, and return value specifics. It's not fully complete, but sufficient for a straightforward generation 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 description coverage is 0%, so the description must clarify parameters. It explains 'n' (number of rows) and loosely implies 'project_id' and 'schema' (matching data schema), but does not explain the 'seed' parameter (which relates to determinism) or the optional 'schema' parameter (default null, possibly for overriding). The description does not compensate adequately for the 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 clearly states 'Generate n deterministic synthetic rows (10-50) matching the project data schema and write as JSONL.' It specifies the action (generate), resource (synthetic rows), constraints (deterministic, 10-50 rows, matching schema), and output format (JSONL). Among sibling tools, this one is uniquely about synthetic data generation for the project 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?
Usage is implied: use when you need synthetic rows matching the project schema. However, no explicit guidance on when not to use it or alternatives (e.g., for different sizes or non-deterministic generation). It lacks context about prerequisites or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate pytest unit-test stubs for critical training-script functions.
| Name | Required | Description | Default |
|---|---|---|---|
| targets | Yes | ||
| project_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only states it generates stubs but does not disclose potential side effects, file system changes, or required permissions. 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 concise sentence, but it is too brief and could be expanded to include more helpful information without becoming verbose. It is appropriately front-loaded but lacks substance.
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 with only two required string parameters and an output schema, the description fails to specify what the output contains, any prerequisites, or how to use the parameters. 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?
Schema coverage is 0%, and the description adds no explanation for the two parameters ('project_id' and 'targets'). The agent cannot infer their meaning or expected format from the description alone.
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 generates pytest unit-test stubs for critical training-script functions, providing a specific verb and resource. However, it does not differentiate from sibling tools, but the name and context are sufficiently distinct.
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 or when not to use it. The description lacks any context about prerequisites or typical scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Render an inference API user guide (endpoints, code examples, parameters).
| Name | Required | Description | Default |
|---|---|---|---|
| port | No | ||
| engine | No | vllm | |
| base_url | No | http://localhost:8000 | |
| max_tokens | No | ||
| model_name | No | ftos-model | |
| project_id | Yes | ||
| temperature | No | ||
| context_length | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description only mentions rendering a guide, not side effects, permissions, or whether it is read-only. Does not disclose any 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?
One sentence, no waste. However, it is too concise for the complexity, leaving out crucial 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 is too brief: 8 parameters with no schema descriptions and no annotation support. The agent cannot determine how to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description does not explain any of the 8 parameters (port, engine, base_url, etc.). The agent has no guidance on how to set them.
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 the tool renders an inference API user guide including endpoints, code examples, and parameters. It is clear what it produces but does not differentiate from siblings like _mcp_generate_deployment_guide.
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. Siblings include many _mcp_generate_* tools but the description offers no context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Parse metrics from the last synthetic run (outputs/metrics.json).
| Name | Required | Description | Default |
|---|---|---|---|
| project_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It mentions parsing from the last synthetic run but does not disclose what happens if the file is missing, authorization needs, or side effects. It is 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 sentence that includes the file path, which is helpful. No unnecessary words.
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 cover error conditions, prerequisites, or output interpretation. For a tool with one parameter and no annotations, more context is needed.
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 the project_id parameter at all. It adds no meaning beyond the schema's type and required status.
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 it parses metrics from the last synthetic run and specifies the file path (outputs/metrics.json). It uses specific verb and resource, distinguishing it from siblings like compute_metrics or evaluate_on_synthetic.
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. Among siblings, there are similar tools like compute_metrics and evaluate_on_synthetic, but the description does not differentiate when to use this one.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Apply a named template preset (config + requirements) to a project.
| Name | Required | Description | Default |
|---|---|---|---|
| project_id | Yes | ||
| template_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 but only states 'apply', implying mutation without detailing side effects, authorization needs, or failure modes. Lacks transparency for a potentially impactful 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, front-loaded sentence without fluff. However, it sacrifices completeness for brevity, which slightly reduces the score.
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, full return detail is not needed. However, the description lacks operational context (e.g., what 'apply' entails, whether it modifies existing configurations, dependencies). Adequate but not 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?
Schema description coverage is 0%, so description must compensate. It adds the context that template_name is a 'named template preset' but does not explain valid values, format, or the relationship between parameters. Insufficient detail.
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 'apply' and the resource 'named template preset (config + requirements)' to a project. It distinguishes from sibling tools like _mcp_create_project_structure, though it could be more specific about the nature of the template.
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 conditions for use, and no mention of when not to use it. Given many sibling tools, this is a significant gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Append a timestamped event to the project events.jsonl log.
| Name | Required | Description | Default |
|---|---|---|---|
| payload | Yes | ||
| event_type | Yes | ||
| project_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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 basic append action, omitting side effects (e.g., whether it creates the file if missing), permissions, or return value. 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, direct sentence with no superfluous words. The description is efficiently front-loaded with 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 presence of 3 parameters (all required, one nested), no annotations, and an output schema, the description is insufficient. It does not cover parameter constraints, return format, or edge cases, leaving the agent without critical invocation 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?
Schema description coverage is 0%, yet the description adds no explanation for any of the three parameters. 'payload', 'event_type', and 'project_id' remain opaque despite being required, and the nested object nature of payload is not 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?
The description clearly states the action (append) and the resource (project events.jsonl log), with the detail 'timestamped' implying automatic timestamping. It distinguishes itself from siblings as a dedicated logging tool.
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, nor when not to use it. The description is purely declarative without any usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Emit the LoRA merge command (base + adapter → merged 16-bit) — dry_run unless FTOS_LOCAL_PYTHON configured.
| Name | Required | Description | Default |
|---|---|---|---|
| base_model | Yes | ||
| output_path | Yes | ||
| adapter_path | Yes | ||
| local_python | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description reveals the dry-run behavior and configuration dependency, which adds transparency. However, it does not explain what 'emit' means (e.g., prints command, runs it, side effects) or mention auth, rate limits, or resource usage.
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, focused sentence that immediately states the tool's purpose and key behavior. Every word serves a purpose, with 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 tool has 4 parameters and performs a potentially destructive merge, the description is insufficient. It fails to explain what 'emit' means, prerequisites (e.g., model format), the output format, or the role of the FTOS_LOCAL_PYTHON configuration. The presence of an output schema (not seen) may partially compensate, but overall completeness is low.
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 must compensate. It adds the phrase 'base + adapter → merged 16-bit' which explains the overall transformation but does not describe individual parameters or provide format details beyond their names, which are already clear.
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 emits a LoRA merge command, specifying the transformation (base + adapter to merged 16-bit). It distinguishes from siblings by mentioning dry-run behavior and configuration dependency, avoiding tautology.
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 a condition for when the tool actually executes (dry_run unless FTOS_LOCAL_PYTHON configured) but offers no guidance on when to use this tool versus alternatives, such as _mcp_quantize_model or other merge-related siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Onboard a new client: collect company info and create the project workspace.
| Name | Required | Description | Default |
|---|---|---|---|
| needs | Yes | ||
| company | Yes | ||
| base_model | No | ||
| contact_email | No |
| 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 responsibility for behavioral disclosure. It only implies creation ('onboard', 'create workspace') but does not specify any behavioral traits such as destructiveness, required permissions, or side effects.
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) and front-loaded, but lacks structured detail such as parameter roles or usage context. It is concise but at the cost of completeness.
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 (2 required) and an output schema, the description provides minimal context. It does not explain required vs. optional parameters, expected input format, or return value, making it incomplete for the complexity of onboarding a client.
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%, yet the description only mentions 'company info' vaguely corresponding to the 'company' parameter. The 'needs' parameter remains unexplained, and 'base_model' and 'contact_email' are omitted entirely, failing to add 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 states 'Onboard a new client: collect company info and create the project workspace,' which clearly indicates the verb (onboard) and resource (client). However, it does not differentiate from sibling tools like _mcp_create_project_structure, which may also create a workspace, so it lacks sibling distinction.
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. There are no scenarios, exclusions, or prerequisites mentioned, leaving the agent without context for appropriate invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Emit the quantization command for GGUF/GPTQ/AWQ — dry_run unless FTOS_LOCAL_PYTHON configured.
| Name | Required | Description | Default |
|---|---|---|---|
| bits | No | ||
| format | No | gguf | |
| model_path | Yes | ||
| output_path | No | ||
| local_python | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears full responsibility for behavioral disclosure. It mentions dry-run behavior and the conditional execution, but it does not describe side effects (e.g., file creation, model changes), required permissions, or error conditions. Significant gaps remain.
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 (single sentence) and front-loaded with the purpose. However, its brevity sacrifices important details, such as parameter explanations and output description. It is adequately concise but incomplete.
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 five parameters and a complex domain (model quantization), the description is insufficiently complete. It does not explain parameter roles, expected input format, or return value (despite an output schema existing). The agent would likely need additional information to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning no parameters are documented in the schema. The description adds no information about any of the five parameters (bits, format, model_path, output_path, local_python). Thus, it fails to add 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 tool emits a quantization command for specific formats (GGUF/GPTQ/AWQ), using a specific verb ('emit') and resource ('quantization command'). It is distinct from all sibling tools, none of which deal with quantization.
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 a condition for when the tool actually runs versus dry-run ('unless FTOS_LOCAL_PYTHON configured'), offering some usage guidance. However, it does not explicitly state when to use this tool over alternatives, and no alternatives are mentioned, so guidance is limited.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a formal approval request (status='pending') persisted in project state.
| Name | Required | Description | Default |
|---|---|---|---|
| question | Yes | ||
| artifacts | Yes | ||
| project_id | 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 must fully disclose behavior. It states creation and persistence but omits side effects (e.g., notifications, concurrency, idempotency) and does not mention what the tool returns despite an output schema existing.
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 concise at one sentence, but it sacrifices necessary detail. It is front-loaded with purpose but could be restructured to include parameter explanations 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 tool has 3 required parameters, no annotations, and an output schema, the description is too brief. It fails to explain the output format or any error conditions, leaving significant gaps for an AI 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%, and the description adds no information about the parameters `project_id`, `question`, or `artifacts`. The agent must guess their meanings from names alone, which 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?
Description clearly states the verb 'Create' and resource 'formal approval request' with initial status 'pending' and persistence, distinguishing it from sibling tools like _mcp_generate_contract or _mcp_sign_document.
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 vs alternatives, such as _mcp_send_status_update or _mcp_generate_delivery_note. The context of 'approval request' suggests its use, but lack of when-not-to instructions or prerequisites reduces clarity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Render train.py and optionally run a micro-train loop (dry-run unless FTOS_LOCAL_PYTHON set).
| Name | Required | Description | Default |
|---|---|---|---|
| steps | No | ||
| project_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries full burden. It reveals a key behavioral trait (dry-run unless environment variable set) but omits side effects, resource usage, or required permissions. Adequate but not thorough.
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 wasted words. Front-loads the core action (render and run) and adds key behavioral note. Highly 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?
For a tool with 2 parameters and no annotations but having an output schema, the description covers the main purpose and a critical behavior, but lacks details on return values, error handling, or prerequisites. Adequate but 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%, and the description adds no meaning to the parameters beyond their names and types. No explanation of 'steps' or 'project_id' purpose or format.
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 renders train.py and optionally runs a micro-train loop, with a specific verb and resource. It distinguishes itself from sibling tools like trigger_remote_training by focusing on local synthetic training.
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., remote training). The description does not specify prerequisites, exclusions, or context for choosing this over sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Propose meeting slots via Calendly API (dry-run if FTOS_CALENDLY_TOKEN not configured).
| Name | Required | Description | Default |
|---|---|---|---|
| window | Yes | ||
| duration | 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 bears full burden. It discloses two key behaviors: uses Calendly API and performs a dry-run if the token is missing. This is sufficient for basic behavior, though additional details like rate limits or side effects are absent.
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 is well front-loaded and contains no unnecessary words. Every element contributes to understanding 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?
Given the tool has an output schema and only two parameters, the description should at least outline the expected inputs and output. It lacks parameter explanations and what the tool returns, making it incomplete for an agent to use effectively.
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%, yet the description provides no explanation of the 'window' or 'duration' parameters. It adds zero semantic value beyond the schema, leaving the agent to guess their meaning and format.
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 proposes meeting slots via the Calendly API. It is specific about the action and resource, and the tool name aligns with this purpose. However, 'propose' could be interpreted as suggesting available times versus creating meetings, which introduces slight ambiguity.
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 by mentioning 'dry-run if FTOS_CALENDLY_TOKEN not configured', which hints at when the tool actually schedules versus tests. No explicit guidance on when to use versus alternatives is given, but the tool appears unique among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update the MCP server from a secure Git remote via git pull (dry-run if FTOS_GIT_REMOTE not set).
| Name | Required | Description | Default |
|---|---|---|---|
| ref | No | main |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description discloses the core behavior (git pull) and the dry-run condition. However, it omits details about permissions, conflict resolution, or whether local changes are preserved, leaving significant ambiguity.
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 is concise but lacks structure. It front-loads the main action but sacrifices clarity by not separating the dry-run note or parameter 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?
The tool has an output schema and a single parameter, but the description does not explain the output, error cases, or the effect of the parameter. An agent needs more context to use this tool safely and effectively.
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 'ref' is not mentioned in the description. Schema coverage is 0%, so the description must explain parameter meaning but fails to do so. The agent cannot infer that 'ref' selects a branch or tag.
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 the tool updates the MCP server via git pull, and adds a specific condition (dry-run if FTOS_GIT_REMOTE not set). This clearly distinguishes it from sibling tools like _mcp_build_docker_image or _mcp_quantize_model.
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. It does not mention prerequisites (e.g., network access, repository setup) or scenarios where a dry-run is insufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Render a status update and deliver via SMTP or Slack webhook (dry-run if neither configured).
| Name | Required | Description | Default |
|---|---|---|---|
| body | Yes | ||
| subject | Yes | ||
| recipient | No | ||
| project_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the fallback to dry-run, but omits details on side effects (e.g., whether state is modified), authentication needs, rate limits, or error handling. It adds basic behavioral context beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, front-loading the core action and delivery methods. It contains no redundant information, but could be slightly longer to include parameter guidance without losing 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?
Despite having an output schema, the description fails to document parameter semantics, which is critical given the lack of schema descriptions. The tool has four parameters (three required), and missing parameter guidance makes it incomplete for correct 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?
Schema description coverage is 0%, yet the description does not explain any of the four parameters (body, subject, recipient, project_id). The agent must infer meaning solely from parameter names, 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 clearly states the tool renders and delivers a status update via SMTP or Slack, with a dry-run fallback. This distinguishes it from sibling tools that focus on other operations like audit, generation, or training.
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 for sending status updates, and mentions dry-run behavior when channels are unconfigured. However, it does not explicitly state when to use this tool versus alternatives, nor does it provide prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Apply a local detached signature (SHA-256 + timestamp) as a .sig sidecar file.
| Name | Required | Description | Default |
|---|---|---|---|
| signer | No | ||
| doc_path | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It explicitly states the operation type (signing), algorithm (SHA-256), and output format (.sig sidecar), giving reasonable transparency. However, it omits details like whether existing files are overwritten or network access is 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 clearly conveys the core function with no extraneous words. Front-loaded with key action and output format.
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 fails to explain input parameters or provide sufficient context for a signing operation. For a tool with 2 parameters and 0% schema coverage, the description should compensate but does not.
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% (no description in schema) and the tool description provides no explanation for 'doc_path' or 'signer'. Without these, an agent cannot determine the correct path format or what the signer parameter does.
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 action: apply a local detached signature with SHA-256 and timestamp, outputting a .sig sidecar file. It distinguishes itself from sibling tools by specifying a unique cryptographic signing function.
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, prerequisites, or context. The description lacks information about required environment (e.g., local filesystem) or dependencies (e.g., OpenSSL).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Render a seeded train/val/test split Python script from template.
| Name | Required | Description | Default |
|---|---|---|---|
| seed | No | ||
| ratios | No | ||
| stratify | No | ||
| project_id | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It states it renders a script from a template but omits critical details like whether it writes to disk, requires network, or has side effects. The output schema exists but 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 that directly states the tool's purpose with no superfluous words, earning a high score for efficiency despite lacking detail.
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 4 parameters with no schema descriptions, no annotations, and many siblings, the description is severely incomplete. It does not explain how the script is rendered, what the output is, or how to interpret parameters, making it inadequate for an agent to use 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 description provides no explanation for any of the 4 parameters (seed, ratios, stratify, project_id), despite 0% schema description coverage. The description must compensate but does not, leaving the agent to guess parameter meanings.
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 'render' and the resource 'a seeded train/val/test split Python script from template', making the purpose specific and distinct from sibling tools which cover different functions like generating synthetic data or creating project structures.
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 when to split a dataset vs. generating a synthetic dataset. It does not mention prerequisites, limitations, or preferred scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recommend retraining from production signals (drift, new data volume, staleness) — pure.
| Name | Required | Description | Default |
|---|---|---|---|
| new_data_size | Yes | ||
| drift_magnitude | Yes | ||
| days_since_last_train | 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 recommendation via 'recommend' and 'pure', but does not explicitly state side effects, required permissions, or whether the tool modifies state.
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 at 10 words, but the '— pure' adds little value and could be removed. It lacks structure for complex parameters. Still, it is front-loaded with the core 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 3 undocumented required parameters and an output schema (not shown). The description fails to map parameters clearly or explain how the recommendation is derived. It is incomplete for effective use without further 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?
Schema description coverage is 0%, and the description does not elaborate on parameter semantics beyond listing the signal names. There is no explanation of units, ranges, or examples. The description uses slightly different terms ('drift' vs 'drift_magnitude', 'new data volume' vs 'new_data_size', 'staleness' vs 'days_since_last_train'), potentially causing confusion.
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 recommends retraining based on production signals, listing the three signals (drift, new data volume, staleness). It distinguishes from sibling tools like 'trigger_remote_training' which actually executes training. However, the meaning of '— pure' is ambiguous.
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 (e.g., 'trigger_remote_training'). It does not mention prerequisites, context, or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send test requests to a running inference container — dry_run curl unless base_url provided.
| Name | Required | Description | Default |
|---|---|---|---|
| model | No | ftos-model | |
| prompts | Yes | ||
| base_url | No | ||
| max_tokens | No | ||
| api_key_env | No | API_KEY |
| 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 the full burden. It reveals the dry-run behavior (curl constructed unless base_url is given), which is key. However, it does not disclose authentication requirements, potential side effects on the container, rate limits, or error handling.
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 short and front-loaded with purpose. However, it is underspecified and could be expanded to cover more aspects without becoming verbose. The conciseness is acceptable but not optimal.
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 5 parameters, no schema descriptions, and no annotations, the description is woefully incomplete. It does not explain input requirements, output (despite output schema existing), or configuration details, leaving the agent underinformed.
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 only hints at base_url's role ('dry_run curl unless base_url provided') but fails to explain the purpose and usage of other parameters like prompts (required), model, max_tokens, and api_key_env.
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 function: sending test requests to a running inference container. It also distinguishes the behavior with 'dry_run curl unless base_url provided', which adds specificity and separates it from sibling tools like _mcp_build_inference_container.
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 (e.g., _mcp_run_local_synthetic_train). It only implies testing after building an inference container, but lacks 'when not to use' or context for different scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update the base model repo/revision in the project config and produce a diff — pure, no network.
| Name | Required | Description | Default |
|---|---|---|---|
| new_repo | Yes | ||
| project_id | Yes | ||
| new_revision | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden for behavioral disclosure. It does add key insight: 'pure, no network' indicates no network calls and a local operation. However, it fails to mention whether the operation is destructive, reversible, or requires any state. For a tool that modifies project configuration, more behavioral context (e.g., does it overwrite files?) 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 extremely concise—one sentence—and front-loaded with the core action. While it could benefit from more structure (e.g., separate sections), it delivers the essential message without verbosity. Every word contributes to the 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 complexity (three required parameters, modifies config, produces a diff) and the existence of an output schema, the description provides adequate top-level context: it updates the config and outputs a diff, with no network. However, it omits details about error conditions, safety (e.g., does it validate inputs?), and the nature of the diff. It is minimally complete for a simple tool but leaves several 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 schema has 0% description coverage, so the description must compensate. The description mentions 'repo/revision', implying that 'new_repo' and 'new_revision' are the target fields, but it does not explain their format, constraints, or valid values. 'project_id' is not mentioned at all. This provides minimal semantic 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 clearly states the tool's function: 'Update the base model repo/revision in the project config and produce a diff'. It uses a specific verb ('Update') and resource ('base model repo/revision'), and distinguishes itself from sibling tools by mentioning the output ('diff') and the local nature ('pure, no network'). This leaves little ambiguity about 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?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, context, or situations where it would be inappropriate. Sibling tools like '_mcp_quantize_model' or '_mcp_merge_lora_weights' are not contrasted. The agent has no information about when to prefer this tool over others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Upload encrypted deliverable over SFTP — dry_run unless FTOS_SFTP_* configured.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | ||
| destination | No | . |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the burden of disclosing behavior. It accurately states the dry-run default and the condition for actual upload (FTOS_SFTP_* configured). This is critical for an agent to understand the tool's behavior. Missing details like error handling or idempotency are acceptable for a simple upload 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 sentence that front-loads the core action and includes a key condition. Every word earns its place; no filler or unnecessary detail. Perfectly 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?
The tool has two parameters and an output schema (not shown but present). The description does not explain the input file format, remote path behavior, or success/error outputs. While the output schema may compensate, the description itself leaves some gaps about what constitutes a valid upload. Adequate but not thorough.
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 input schema has no descriptions for its two parameters ('path' and 'destination'). The tool description adds zero information about these parameters—it does not explain what 'path' refers to (local file?), or what 'destination' means (remote directory?). Thus minimal 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 action: 'Upload encrypted deliverable over SFTP'. The verb 'upload' and resource 'encrypted deliverable' are specific, and the protocol is specified. The conditional 'dry_run unless FTOS_SFTP_* configured' adds helpful nuance, distinguishing it from sibling tools like _mcp_encrypt_deliverable.
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: to upload a deliverable, but it warns that it will dry-run unless environment variables are set. This gives clear context about prerequisites. However, it does not explicitly mention when not to use or list alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check a JSONL file against a schema — returns keys/types/lengths only, never values.
| Name | Required | Description | Default |
|---|---|---|---|
| schema | No | ||
| file_path | Yes | ||
| project_id | No |
| 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 the full burden. It discloses a key behavioral trait (returns only keys/types/lengths, never values), which is helpful. However, it does not mention whether the tool modifies files, error behavior, or any side effects.
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 zero wasted words. It immediately conveys the action and the key limitation on output.
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 simplicity (3 parameters, output schema present), the description provides the core purpose but lacks details on output structure (though output schema covers this) and parameter semantics. It is minimally adequate but leaves room for improvement, especially in parameter documentation.
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 should compensate. It only mentions 'JSONL file' and 'schema' implicitly through the description, but does not explain the format of the schema parameter, the role of project_id, or how file_path is used. The parameter names themselves are somewhat descriptive but 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 tool checks a JSONL file against a schema, specifying what it returns (keys/types/lengths only, never values). This distinguishes it from sibling tools that might return values or perform other operations.
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 _mcp_describe_expected_data_format or _mcp_generate_synthetic_dataset. There is no mention of constraints, 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.
Aggregate loss/lr/gpu time-series from sanitized remote logs via SSH.
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | Yes | ||
| source | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations present, so description carries full burden. Mentions aggregation via SSH (read operation) but lacks details on side effects, auth requirements, or error handling.
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, 9 words, front-loads key action. No wasted words.
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?
Description is too brief for a 2-param tool with output schema. Misses time range, failure behavior, and output interpretation beyond what schema might provide.
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 has 0% description coverage for both required parameters (job_id, source). Description adds no parameter-level meaning, leaving agents to guess their 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?
Description clearly states the verb 'aggregate' and the specific resources 'loss/lr/gpu time-series' from 'sanitized remote logs via SSH', distinguishing it from sibling tools like stream_remote_logs or compute_metrics.
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. Does not differentiate from streaming alternatives or note prerequisites like SSH access.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Suggest hyperparameter adjustments from local training metrics.
| Name | Required | Description | Default |
|---|---|---|---|
| metrics | 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 must disclose behavioral traits. It does not state whether the tool is read-only or modifies state, required permissions, rate limits, or side effects. The inference that it only suggests adjustments is implicit.
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 single-sentence description is concise but under-specified. It could include additional useful information (e.g., output format, typical input shape) without becoming overly 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?
Despite having an output schema (not shown), the description omits details about the return value, adjustable hyperparameters, and algorithm used. For a tool with one parameter and no annotation guidance, this level of detail is insufficient for correct agent 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?
The description adds minimal meaning to the 'metrics' parameter: 'from local training metrics' implies the input should contain training metrics, but does not specify expected keys, format, or structure. Schema coverage is 0%, so the description should compensate more.
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 function: 'Suggest hyperparameter adjustments from local training metrics.' It distinguishes from siblings like 'compute_metrics' by focusing on adjustments rather than just calculation, but lacks specificity on the nature of suggestions.
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 evaluate_on_validation_set or early_stopping_check. The description does not mention prerequisites, context, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Pause or resume a remote training job via SSH (dry-run unless FTOS_SSH_* configured).
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | ||
| job_id | 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 discloses that the tool may perform a dry-run instead of the actual action if SSH configuration is missing, which is a key behavioral trait. However, it does not detail error handling, side effects, or authentication requirements beyond SSH.
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 of 13 words, front-loading the core purpose and key condition. Every word earns its place with no 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?
Given an output schema exists, return format is covered. However, with 0% parameter schema coverage, the description should have clarified allowed values for 'action' and 'job_id' format. It is minimally adequate but missing critical param 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?
Schema description coverage is 0%, and the description adds no meaning to the parameters 'action' or 'job_id'. It does not specify expected values for 'action' (e.g., 'pause', 'resume') or format for 'job_id', leaving the schema's minimal info uncompensated.
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 pauses or resumes a remote training job via SSH, providing a specific verb, resource, and mechanism. It distinguishes from purely dry-run tools like dry_run_remote_config by indicating real execution is contingent on configuration.
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: it's a dry-run unless FTOS_SSH_* environment variables are set, guiding the agent on when actual execution occurs. However, it does not explicitly mention when to use this tool over siblings like dry_run_remote_config or provide exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Push a Docker image to the configured registry (dry-run unless FTOS_REGISTRY configured).
| Name | Required | Description | Default |
|---|---|---|---|
| tag | 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 bears full responsibility. It discloses the dry-run default behavior, which is a key behavioral trait. However, it omits details about required authentication, network access, or potential side effects (e.g., overwriting existing tags).
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, highly concise with no extraneous words. However, the brevity sacrifices essential parameter guidance, slightly reducing effectiveness. Overall, it earns its place but could be restructured to include parameter 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?
Given the tool's complexity (push with conditional behavior), the description is incomplete. It lacks explanation of the 'tag' parameter, return values (though output schema exists but not described), and error conditions. For a mutation tool without annotations, more context is needed.
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%, so the description must explain the sole required parameter 'tag'. It fails to do so entirely—no format, purpose, or examples are provided. The agent cannot infer what value the 'tag' should hold (e.g., image name, version, or full URL).
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 'Push' and the resource 'Docker image to the configured registry'. It also distinguishes from sibling tools like '_mcp_build_docker_image' by focusing on the push step. The dry-run conditional adds specificity.
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 a clear conditional: it performs a dry-run unless the FTOS_REGISTRY environment variable is configured. This guides when the tool actually pushes vs just simulates. However, it does not explicitly state when to use over alternatives like building or testing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Sanitize text or a log file via pattern masking — returns the sanitized body and masked count.
| Name | Required | Description | Default |
|---|---|---|---|
| text | No | ||
| log_path | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility. It mentions 'pattern masking' but does not disclose what patterns are used, whether masking is reversible, or any permissions or side effects. The behavioral disclosure is 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 concise sentence that front-loads the key information. While efficient, it could benefit from slightly more detail 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?
The tool has two optional parameters and an output schema (though not visible here). The description covers the return values but lacks details on error handling, parameter combinations, or constraints. For a simple tool, it is 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?
Schema description coverage is 0%, so the description must compensate. It hints at two parameters ('text' and 'log_path') by referencing 'text or a log file', but does not explain their relationship, requirements (e.g., at least one must be provided), or format constraints. This leaves ambiguity for the agent.
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 'sanitize', the resource 'text or a log file', and the method 'pattern masking'. It also specifies the return values. This distinguishes it from sibling tools, none of which appear to have a similar purpose.
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 the tool is for sanitizing text or log files, but it does not provide explicit guidance on when to use it versus alternatives, or when not to use it. No exclusions or alternative tools are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Scan logs/artifacts for sensitive data leakage — reports counts by category, never raw values.
| Name | Required | Description | Default |
|---|---|---|---|
| text | No | ||
| logs_path | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description discloses key behavior: reports counts by category and never returns raw values, which is critical for privacy. However, it omits other traits like destructive potential or rate limits.
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 action and output characteristics with no redundant words.
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 two-parameter tool with an output schema, the description adequately covers purpose and output behavior but lacks guidance on parameter usage or execution 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?
With 0% schema description coverage, the description adds no meaning to the two parameters (text, logs_path). The hint 'scan logs/artifacts' suggests logs_path but leaves text 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 the tool scans logs/artifacts for sensitive data leakage and reports aggregated counts, distinguishing it from sibling tools like audit_code_no_network or sanitize_logs_for_claude.
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 for detecting sensitive data leakage but does not explicitly state when to use versus alternatives or provide any exclusions or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch and sanitize remote training logs via SSH (dry-run unless FTOS_SSH_* configured).
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | Yes | ||
| target | Yes | ||
| n_lines | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. It discloses the dry-run behavior but lacks details on what 'sanitize' entails, what happens when SSH is not configured, and whether the operation is destructive or read-only.
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 it omits crucial details that would improve readability and utility without being 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 tool's complexity (SSH, dry-run, sanitization, three parameters with zero descriptions), the single sentence is insufficient for an agent to use the tool correctly, even with an output schema present.
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%, yet the description adds no meaning to the three parameters. It only mentions 'via SSH' but does not clarify job_id, target, or n_lines, leaving the agent to infer from parameter names alone.
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 specific actions 'Fetch and sanitize' and clearly identifies the resource 'remote training logs' via SSH, distinguishing it from sibling tools like 'sanitize_logs_for_claude' or 'dry_run_remote_config'.
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 mention of 'dry-run unless FTOS_SSH_* configured' implies when the tool actually fetches logs, but it does not explicitly state when to use this tool over alternatives or provide exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run docker build + internal pytest tests for an image (dry-run unless local_python+docker configured).
| Name | Required | Description | Default |
|---|---|---|---|
| image_tag | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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 dry-run behavior and the condition for real execution, but does not mention side effects (e.g., image creation), network access, permissions needed, or output format. This is adequate but leaves gaps for an AI agent.
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 conveys the primary purpose and a key conditional (dry-run). Every word adds value, and the information is front-loaded. No 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?
Given one parameter, no annotations, and an existing output schema (not shown), the description covers the essential action and the dry-run nuance. It could mention that the tool returns test results, but with output schema present, the agent can infer that. Almost complete 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?
With 0% schema description coverage, the description should compensate, but it does not explain the single parameter 'image_tag'. The name is somewhat self-explanatory, but the agent would benefit from knowing the expected format (e.g., 'tag' vs full URL) or its role in the command.
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 specifies the action ('Run docker build + internal pytest tests') and the target ('an image'). It also adds context about dry-run behavior, which differentiates it from sibling tools like push_docker_to_registry that only push without testing.
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 clear context for when a real execution occurs vs dry-run ('dry-run unless local_python+docker configured'), but does not explicitly state when to use this tool over alternatives. However, the sibling list suggests distinct purposes, and the description implies use for testing rather than deployment.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Launch remote training via SSH (dry-run unless FTOS_SSH_* configured).
| Name | Required | Description | Default |
|---|---|---|---|
| target | Yes | ||
| command | 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. It reveals the dry-run behavior but does not disclose potential destructiveness (e.g., overwriting running jobs), authentication requirements, or what happens on error. Insufficient for an SSH-based training launch.
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 sacrifices informativeness for brevity; a slightly longer description could add value 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 an output schema (assumed), the description lacks essential context: parameter semantics, safety warnings, prerequisites (SSH keys?), and what constitutes a successful launch. Incomplete for a potentially destructive 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?
Description provides no explanation of the two required parameters (target, command). Schema coverage is 0%, so the agent has zero guidance on what values to provide for target (e.g., hostname, IP) or command (e.g., script path).
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 launches remote training via SSH, with a specific condition (dry-run unless FTOS_SSH_* configured). It distinguishes from sibling tools like 'dry_run_remote_config' which is for configs, not training.
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 versus alternatives. The dry-run condition is mentioned but does not help the agent choose between this and other training-related tools like 'dry_run_remote_config' or 'ssh_remote_execute' (if existed).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up base-model license and commercial-use compatibility from the in-module registry.
| Name | Required | Description | Default |
|---|---|---|---|
| repo_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description implies a read operation but does not disclose any behavioral traits beyond that. With no annotations provided, it fails to mention authentication needs, error handling, or side effects. The minimal description leaves significant gaps.
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 13-word sentence, extremely concise and front-loaded with the action. 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?
For a simple one-parameter tool, the description covers the essential action. An output schema likely exists (not shown), but the description could still benefit from mentioning the kind of information returned (e.g., license name, compatibility status). It is minimally 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?
With 0% schema coverage, the description should compensate by explaining the parameter. It only mentions 'repo_id' without specifying format, examples, or constraints, adding little value over the schema field name.
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 ('look up') and the resource ('base-model license and commercial-use compatibility from the in-module registry'). It distinguishes itself from sibling tools by focusing on license information, though it does not explicitly differentiate from other model-related tools like 'cache_base_model'.
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 'cache_base_model' or 'download_checkpoint_metadata'. There is no mention of prerequisites or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Most tools have distinct purposes, but the large number and similar verb patterns (e.g., generate_deployment_command vs generate_deployment_guide) could cause minor confusion. The underscore prefix for internal tools helps separate scopes.
Naming mixes underscore_case without prefix, _mcp_ prefixed tools, and inconsistent verb forms (e.g., audit_ vs _mcp_generate_). While there is an overall verb_noun pattern, the mix of conventions reduces consistency.
With 65 tools, the set is very large, far exceeding typical scopes (3-15). While the domain of fine-tuning is broad, the count feels excessive and may overwhelm agents, leading to misselection.
The tool surface covers a wide range: auditing, security, training, evaluation, deployment, monitoring, and project management. Minor gaps like model rollback or dataset versioning exist, but core workflows are well-supported.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
MCP server for building and testing AI agents with multi-model experimentation and insights.
MCP server providing access to the Scorecard API to evaluate and optimize LLM systems.
The CustomGPT.ai MCP server is a fully managed, RAG-powered endpoint that connects large language models with private knowledge bases and external data sources. It provides tools for retrieval-augmented generation queries (send_message), data ingestion (upload_file), and source listing, enabling AI agents to query private documents like PDFs with high accuracy and real-time citations.
The Remote MCP server acts as a standardized bridge between LLM applications (like Claude, ChatGPT, and Cursor) and external services, enabling AI agents to access external tools and resources. Its primary capability is providing a centralized search tool to discover other MCP servers and their respective tools. Unlike local implementations, it runs remotely with OAuth authentication and permission controls for security.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Casius999/fine-tuning-os'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
