Provides web search capabilities using DuckDuckGo's search engine.
Enables delegation of subtasks to OpenAI's AI models for parallel execution and conditional branching.
Provides browser automation capabilities including page navigation, element interaction, screenshots, JavaScript execution, and multi-tab management using Selenium WebDriver.
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., "@oh-my-mcp search the web for latest AI breakthroughs"
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.
A powerful Model Context Protocol (MCP) server with 116 practical tools across 9 categories, built using FastMCP.
oh-my-mcp provides tools for:
๐ฆ Compression (5 tools): ZIP/TAR compression and extraction with security features
๐ Web & Network (18 tools): Web search, page fetching, HTML parsing, downloads, HTTP API client, DNS lookup
๐ File System (12 tools): Read, write, search files and directories, file comparison
๐ Data Processing (15 tools): JSON, CSV, XML, YAML, TOML parsing and manipulation
๐ Text Processing (9 tools): Regex, encoding, email/URL extraction, text similarity
๐ป System (8 tools): System info, CPU/memory monitoring, environment variables
๐ ๏ธ Utilities (10 tools): UUID, hashing, date/time operations, math, password generation
๐ค Subagent AI (6 tools): Delegate subtasks to external AI models (OpenAI/Anthropic), parallel execution, conditional branching, persistent config
๐ Browser Automation (33 tools): Selenium-based browser control, page navigation, element interaction, screenshots, JavaScript execution, multi-tab management
Note: Python Development, UV Package Manager, and Pylance/Pyright tools have been removed from the packaged version as they require external Python interpreters and package managers. All remaining tools work completely standalone.
Related MCP server: mcp-web-calc
๐ Documentation Index - Complete documentation hub (ไธญๆ)
๐๏ธ Project Structure - Detailed project organization
๐ฏ Setup Guide - Interactive configuration wizard guide
๐ฆ Build Guide - Package for Windows/Linux distribution
๐๏ธ Architecture Guide - System architecture and design
๐งช Subagent Guide - AI orchestration features
ๅฎ่ฃ ไพ่ตๅนถๅผๅๆจกๅผๅฎ่ฃ ๏ผ
pip install -e .่ฟ่กไบคไบๅผ้ ็ฝฎๅๅฏผ๏ผๆจ่๏ผ๏ผ
uv run configure.pyๆ็ดๆฅไธบClaude Desktop็ๆ้ ็ฝฎ๏ผ
python -m mcp_server.cli.config --claudeๆๅฏๅจHTTP้ ็ฝฎๆๅก๏ผ
python -m mcp_server.cli.config --http-server --port 8765่ฏฆ็ป้ ็ฝฎ่ฏดๆ่ง๏ผdocs/zh/SETUP_GUIDE.md
ๅฏๅจMCPๆๅก๏ผ
python -m mcp_server.mainๅฏๅจๅๅฏ้่ฟClaude DesktopๆMCPๅฎขๆท็ซฏ่ฟๆฅไฝฟ็จใ
Python 3.12 or higher
pip package manager
For the full list of tools, usage examples, and API details, see docs/en/TOOL_REFERENCE.md.
Logs are configured in mcp_server/utils.py. You can adjust:
Log level (INFO, DEBUG, WARNING, ERROR)
Output destinations (console, file)
Log format
File operations have safety limits:
read_file: 10MB max file size
safe_write_file: Creates parent directories automatically
Path validation: Prevents path traversal attacks
Safe evaluation: Math expressions only allow safe operations
Masked values: Sensitive environment variables are masked
Confirmation required: File deletion requires confirm=True
Retry logic: Network operations retry up to 3 times
All tools include comprehensive error handling:
ValidationError: Invalid input parameters
NetworkError: Network request failures
FileOperationError: File system errors
DataProcessingError: Data parsing/conversion errors
Errors are returned as JSON with descriptive messages.
oh-my-mcp/
โโโ pyproject.toml # Dependencies
โโโ configure.py # Interactive setup wizard
โโโ README.md # Documentation
โโโ src/
โโโ mcp_server/
โโโ __init__.py # Package init
โโโ main.py # Server entry point
โโโ utils.py # Infrastructure & utilities
โโโ command_executor.py # Secure command execution
โโโ cli/
โ โโโ config.py # Configuration generator
โโโ tools/ # Tool plugins (9 categories)
โโโ __init__.py # Plugin auto-discovery
โโโ registry.py # @tool_handler & ToolPlugin
โโโ search_engine.py # Web search backend
โโโ subagent_config.py # Subagent config manager
โโโ compression/ # Compression tools (5)
โโโ web/ # Web & Network tools (18)
โโโ file/ # File System tools (12)
โโโ data/ # Data Processing tools (15)
โโโ text/ # Text Processing tools (9)
โโโ system/ # System tools (8)
โโโ utility/ # Utility tools (10)
โโโ subagent/ # AI Orchestration tools (6)Create a new tool in the appropriate plugin's handlers.py:
from mcp_server.tools.registry import tool_handler
@tool_handler
def your_tool(param: str) -> str:
"""Tool description.
Args:
param: Parameter description
Returns:
Return value description
"""
try:
# Your implementation
return result
except Exception as e:
logger.error(f"Tool failed: {e}")
return f"Error: {str(e)}"Start the server and test tools using an MCP client or the FastMCP testing utilities.
Contributions are welcome! Areas for improvement:
Additional tool categories
Enhanced error handling
Performance optimizations
More comprehensive tests
Additional external API integrations
This project is provided as-is for educational and practical use.
๐ Documentation Hub - Complete documentation index (ไธญๆ)
๐๏ธ Project Structure - Project organization guide
๐๏ธ Architecture - System architecture and design
๐ Test Report - Test suite
โ๏ธ Configuration Guide (CN) - Complete configuration reference
๐ฏ Setup Guide - Step-by-step setup instructions
๐ฆ Build Guide - Package for Windows/Linux
๐ Installation Guide - Installation details
๐ค Subagent Configuration - AI task delegation setup
๐ง Subagent Guide - AI orchestration features
๐ Advanced Search - Search functionality details
๐๏ธ Architecture Guide - System architecture and design
๐ค Contributing Guide - How to contribute
๐ Changelog - Version history
The python -m mcp_server.cli.config command provides multiple ways to configure MCP clients:
# Quick install to Claude Desktop
python -m mcp_server.cli.config --claude
# Run HTTP server on custom port
python -m mcp_server.cli.config --http-server --port 9000
# Generate config file with custom server name
python -m mcp_server.cli.config --server-name my-tools --output config.json
# Show configuration in console
python -m mcp_server.cli.config --show-configWhen running with --http-server:
Endpoint | Description |
| Returns MCP configuration JSON |
| Returns server information and paths |
| Health check endpoint |
Example usage:
# Start server on port 8765
python -m mcp_server.cli.config --http-server
# Get configuration
curl http://localhost:8765/config
# Get server info
curl http://localhost:8765/infoEnjoy oh-my-mcp! ๐
Append content to a file.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Path to the file | |
| content | Yes | Content to append | |
| encoding | No | File encoding (default: utf-8) | utf-8 |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries full burden but only states 'Append content to a file.' It does not disclose what happens if the file does not exist, permission requirements, or whether the operation is atomic. Encoding is mentioned in schema but not in description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is straightforward and easy to parse. It is appropriately sized for a simple operation, though it could add more detail 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 simplicity of the tool and lack of annotations, the description is too thin. It does not explain the output format, error handling, or behavior for missing files. The presence of an output schema is not enough to compensate.
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 covers 100% of parameters with descriptions, so the description adds no additional meaning beyond the schema. The baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The verb 'append' and resource 'file' are specific, making the core action clear. However, it does not distinguish itself from the sibling tool 'write_file', which could cause confusion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'write_file' or 'read_file'. There is no mention of prerequisites or contexts where appending is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Navigate back in browser history.
| Name | Required | Description | Default |
|---|---|---|---|
| session_id | Yes | The session ID |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior, but it only says what it does without explaining side effects, behavior when history is empty, or per-tab scope. This leaves important behavioral traits unaddressed.
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, consisting of a single sentence with no repetition. However, it could be slightly expanded to include essential context without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the existence of an output schema and many sibling tools, the description is minimally complete. It lacks information about return values, error conditions, or integration with browser sessions, which would be helpful 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 input schema fully describes the session_id parameter (100% coverage), but the description adds no additional context or guidance on using the parameter. Baseline score of 3 is appropriate since the schema handles parameter 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 'Navigate back in browser history' clearly states the action (navigate) and the resource (browser history), effectively distinguishing it from sibling navigation tools like browser_forward or browser_navigate.
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 browser_forward or browser_navigate. Also missing prerequisites like requiring an active session or existing history.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Click an element on the page.
Waits for the element to be clickable before clicking.
| Name | Required | Description | Default |
|---|---|---|---|
| session_id | Yes | The session ID | |
| selector | Yes | Element selector | |
| by | No | Selector type (css, xpath, id, name, class, tag) | css |
| timeout | No | Maximum seconds to wait for element |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description takes on full disclosure responsibility. It mentions the key behavior 'Waits for the element to be clickable before clicking,' but does not disclose other behavioral traits like scrolling to element, error handling, or return value, limiting 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 at two sentences. The first sentence front-loads the main purpose, and the second adds a critical behavioral detail without redundant or superfluous 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?
Given the tool's simplicity and the presence of an output schema, the description sufficiently covers the core action and waiting behavior. However, it could briefly mention prerequisites (e.g., element must exist in DOM) or post-conditions, though not strictly necessary.
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?
Since input schema coverage is 100%, the description does not need to add meaning for each parameter. It does not elaborate on selector types or timeout semantics beyond the schema, so it meets the baseline without adding extra 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 'Click an element on the page' with a specific verb and resource, leaving no ambiguity about the tool's primary action. It effectively distinguishes itself from sibling browser interaction tools like browser_type or browser_select.
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 over alternatives or when not to use it. The usage context (clicking when element is clickable) is implicit but lacks comparison with other tools or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Close a browser session.
Closes the browser window and cleans up all associated resources.
| Name | Required | Description | Default |
|---|---|---|---|
| session_id | Yes | The session ID returned by browser_open |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description discloses that cleanup occurs but does not detail side effects like unsaved data loss or required permissions. Basic behavioral transparency is provided.
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?
Two sentences with no fluff. Purpose is front-loaded. Each word is necessary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and an output schema, the description covers purpose and behavior adequately. It could mention error cases but is mostly 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 100%. The description adds no additional meaning beyond the schema's parameter description 'The session ID returned by browser_open'. Baseline score applies.
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 closes a browser session and cleans up resources. It is distinct from sibling tools like browser_close_tab.
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 browser_close_tab or browser_list_sessions. The description does not mention prerequisites or avoid scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Close a browser tab.
| Name | Required | Description | Default |
|---|---|---|---|
| session_id | Yes | The session ID | |
| tab_index | No | Tab index to close (-1 for current tab) |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description does not disclose behavioral traits such as what happens if the tab index is invalid, whether the session is affected, or if the action is destructive. The schema's default for tab_index (-1 for current) is not mentioned.
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 short sentence, making it very concise. However, it lacks important detail about parameters and usage, so it is not optimally informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool and the existence of an output schema, the description is adequate but fails to mention error conditions or side effects. It does not provide enough context for an agent to fully understand the operation.
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 100%, so the input schema already explains both parameters. The tool description adds no additional meaning beyond the schema, meeting the baseline expectation.
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 'Close a browser tab' clearly states the action and resource, but does not specify which tab (e.g., by index or current). It distinguishes from siblings like 'browser_close' (probably whole browser) but could be more precise.
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 'browser_close', 'browser_switch_tab', or 'browser_new_tab'. The description lacks any context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
่ทๅๆต่งๅจ้ ็ฝฎ่ฎพ็ฝฎ
| Name | Required | Description | Default |
|---|---|---|---|
| key | No | ้ ็ฝฎ้ฎๅใ็็ฉบ่ทๅๆๆ้ ็ฝฎใ ๅฏ้ๅผ: chrome_driver_path, edge_driver_path, default_browser, default_headless, proxy, auto_fallback, screenshot_dir, all |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description indicates a read-only operation ('get'), but does not disclose behavior like error handling, return format, or potential side effects. The parameter description adds some transparency about empty key behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with clear purpose. No unnecessary words. Appropriate for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description and schema together cover the basic usage. Assumes an output schema exists (not shown) for return values. Lacks mention of errors or edge cases, but overall sufficient for a simple getter.
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 100% with a parameter description listing possible values. The tool description adds no extra semantic meaning beyond the schema. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb '่ทๅ' (get) and resource 'ๆต่งๅจ้ ็ฝฎ่ฎพ็ฝฎ' (browser config settings). It distinguishes from sibling tools like browser_config_set and browser_config_reset, which have different 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 on when to use this tool versus alternatives. The description only says 'get browser config', without mentioning when not to use or comparing to set/reset. Relies on agent inference from tool names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
้็ฝฎๆต่งๅจ้ ็ฝฎไธบ้ป่ฎคๅผ
Returns: JSONๆ ผๅผ็ๆไฝ็ปๆ
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. 'Reset to default values' implies a destructive action, but there is no mention of side effects, confirmation steps, or what exactly is reset. This lack of detail reduces transparency for an 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?
The description is exceptionally concise: one sentence stating the purpose and one line for return format. No wasted words, front-loaded, and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and an output schema exists, the description covers the basic action and return type. However, it omits context like whether a browser session is required or if the reset is persistent, leaving some gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the description does not add parameter-level meaning beyond the schema. With no parameters, baseline score is 4, and the description does not detract from this.
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 'reset' and the resource 'browser configuration' with the outcome 'to default values'. It is distinct from sibling tools like 'browser_config_get' and 'browser_config_set', which serve different purposes.
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 the tool (to revert configuration to defaults), but does not explicitly state when not to use it or mention alternatives. The context is clear enough given the list of sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
่ฎพ็ฝฎๆต่งๅจ้ ็ฝฎ๏ผไฟๅญๅฐ้ ็ฝฎๆไปถ๏ผ
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | ้ ็ฝฎ้ฎๅ (chrome_driver_path, edge_driver_path, default_browser, default_headless, proxy, auto_fallback, screenshot_dir) | |
| value | Yes | ้ ็ฝฎๅผ |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It mentions persistence (save to config file), but lacks details such as whether changes apply immediately, require a restart, or error handling for invalid keys. The schema lists valid keys but not behavior on failure.
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 conveys the essential purpose. There is no unnecessary information, and it is appropriately sized for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 parameters, no nested objects) and the presence of an output schema, the description covers the core functionality. It could hint at the return value, but is sufficient for a simple setter.
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 100%, so schema already documents both parameters. The description adds no extra meaning beyond what the schema provides, such as the format of value or interaction between parameters. According to guidelines, baseline is 3 when coverage is high.
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 sets browser configuration and persists to a config file. The verb 'set' and resource 'browser configuration' are specific. However, it does not differentiate from siblings like browser_config_get or browser_config_reset, which could cause confusion about when to use each.
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, nor any prerequisites or side effects. For a configuration setting tool, explicit instructions about when not to use (e.g., if config is read-only) would be helpful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete browser cookies.
| Name | Required | Description | Default |
|---|---|---|---|
| session_id | Yes | The session ID | |
| name | No | Cookie name to delete (optional, deletes all if empty) |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description only states 'Delete', implying a destructive operation, but fails to disclose that deleting all cookies occurs when the 'name' parameter is empty. No annotations are provided, so the description should carry the full behavioral burden but does not cover session requirements, side effects, or irreversibility.
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 (3 words) but lacks structure. It conveys the core purpose efficiently but omits important details that could be included without significant verbosity.
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 full parameter documentation, the description is still incomplete. It does not address behavioral aspects like what happens after deletion, whether the action is reversible, or the need for a valid session. More context would improve agent decision-making.
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 100% for both parameters, providing clear meanings for 'session_id' and 'name'. The description adds no extra semantic value beyond the schema, achieving the baseline 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 'Delete browser cookies' clearly states the verb (delete) and resource (browser cookies), distinguishing it from sibling tools like browser_get_cookies and browser_set_cookie. However, it does not explicitly mention the optional cookie name filtering, which is covered in the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as browser_set_cookie or browser_get_cookies. The description lacks context about prerequisites (e.g., an active browser session) or typical usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Enable network request logging.
After enabling, network requests will be captured and can be retrieved using browser_get_network_logs.
| Name | Required | Description | Default |
|---|---|---|---|
| session_id | Yes | The session ID |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since annotations are absent, the description bears full transparency burden. It clearly communicates that enabling captures network requests and that logs are retrievable, but lacks details on persistence, performance impact, or disabling capabilities.
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?
Two short, focused sentences with no wasted words. The purpose and follow-up action are 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?
For a simple enable tool with one parameter and an output schema (assumed present), the description is largely complete. It covers the primary action and retrieval path, though it omits any mention of disabling or resetting the log.
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 100% (session_id has a clear description). The tool description adds no additional parameter meaning beyond what the schema already provides, meeting the baseline expectation.
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 enables network request logging and specifies that captured logs can be retrieved via browser_get_network_logs. This distinguishes it from its sibling tool browser_get_network_logs.
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 by linking to browser_get_network_logs, but does not explicitly state when to use this tool versus alternatives or provide exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute JavaScript code in the page context.
| Name | Required | Description | Default |
|---|---|---|---|
| session_id | Yes | The session ID | |
| script | Yes | JavaScript code to execute | |
| args | No | JSON array of arguments to pass to the script (accessible via arguments[]) | [] |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description fails to disclose that executing arbitrary JS can modify page state, trigger network requests, or cause other side effects. It lacks any behavioral warnings.
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 fluff. While short, it is to the point. Could benefit from a brief note on return value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema in the description, the tool's behavior (e.g., return value, error handling) is not covered. Insufficient for safe agent 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?
Input schema covers all 3 parameters with descriptions, so description adds no extra meaning. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool executes JavaScript in the page context. However, it does not distinguish this tool from sibling browser interaction tools like browser_click or browser_type.
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 similar tools (e.g., for custom JS vs. browser_click for clicks). 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.
Fill multiple form fields at once.
| Name | Required | Description | Default |
|---|---|---|---|
| session_id | Yes | The session ID | |
| form_data | Yes | JSON object mapping selectors to values, e.g.: '{"#username": "john", "#password": "secret", "#country": "US"}' | |
| by | No | Selector type for all fields (css, xpath, id, name, class, tag) | css |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description gives minimal behavioral insight beyond 'fill form fields'. It does not disclose whether existing fields are cleared, if the form is submitted, or any side effects. With no annotations, the description fails to convey safety or operation details.
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 gets straight to the point without any fluff. It is properly front-loaded and easy to parse.
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 (3 parameters, needs a browser session), the description fails to mention required context like session existence, form state, or output behavior. An output schema exists but is not utilized in the description.
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 already provides full descriptions for all three parameters (100% coverage), including an example for form_data. The description adds no additional semantic value beyond what the schema offers.
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 fills multiple form fields at once, distinguishing it from single-field tools like browser_type. However, it does not specify the use of CSS selectors or the ability to handle various selector types, which is covered in the schema but could be highlighted.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like browser_type or browser_click. The description does not mention prerequisites (e.g., form must be loaded) 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.
Find multiple elements matching a selector.
| Name | Required | Description | Default |
|---|---|---|---|
| session_id | Yes | The session ID | |
| selector | Yes | Element selector | |
| by | No | Selector type (css, xpath, id, name, class, tag) | css |
| limit | No | Maximum number of elements to return |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden of behavioral disclosure. It only says 'Find multiple elements matching a selector' but omits critical details like whether it returns an empty list vs throws on no match, if it waits for elements, or any side effects on browser 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 a single, front-loaded sentence with no wasted words. However, the brevity sacrifices important context, making it less effective despite being concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema (not provided to the evaluator), the description fails to mention the return format (list of elements). Without annotations, the tool's safety profile and interaction with browser state are missing, leaving significant gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the description adds no additional meaning beyond what the parameter descriptions already provide. For example, it does not clarify when to use 'by' types like 'xpath' vs 'css', or the effect of 'limit'. Baseline of 3 applies as schema does the heavy lifting.
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 finds multiple elements by a selector, using a specific verb 'find' and resource 'elements'. It naturally distinguishes itself from sibling tools like browser_click (single element action) and browser_get_text (single element text extraction).
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 browser_get_element_attribute or browser_fill_form. The description does not mention prerequisites or typical use cases, leaving the agent to infer usage 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.
Navigate forward in browser history.
| Name | Required | Description | Default |
|---|---|---|---|
| session_id | Yes | The session ID |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description lacks details on behavior when no forward history exists, potential side effects, or required state. No annotations are provided to compensate.
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, front-loaded sentence with no extraneous words. Efficient and directly communicates 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?
While the tool is simple and has an output schema (so return values are not required in description), the description omits preconditions (e.g., forward history exists) and error scenarios. Adequate but not comprehensive.
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, session_id, is documented in the schema with the description 'The session ID'. With 100% schema coverage, baseline is 3; the tool description adds no further meaning.
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 ('Navigate forward') and the resource ('in browser history'). It distinguishes from sibling tools like browser_back (backward) and browser_navigate (direct URL navigation).
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 browser_navigate or browser_refresh. Does not mention prerequisites like the existence of forward history.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get browser console logs.
Captures console.log, console.error, console.warn, etc. from the page.
| Name | Required | Description | Default |
|---|---|---|---|
| session_id | Yes | The session ID | |
| level | No | Filter by log level (all, error, warning, info, debug) | all |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only states that it captures logs without detailing side effects (e.g., does it clear logs?), read-only nature, or any limitations. For a tool retrieving logs, more behavioral context would be beneficial.
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?
Two sentences, front-loaded with the core purpose, no extraneous words. Efficient and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity and the presence of an output schema (not detailed here), the description is sufficient for most use cases. Could mention when logs might be empty, but not critical.
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 covers 100% of parameters with descriptions. The description does not add additional meaning beyond the schema; it merely restates the function. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get browser console logs' and specifies 'console.log, console.error, console.warn, etc. from the page.' This uniquely identifies the tool's purpose and distinguishes it from sibling tools like browser_get_network_logs.
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 when console logs are needed, but provides no guidance on prerequisites (e.g., active browser session) or when not to use it. No alternatives 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.
Get browser cookies.
| Name | Required | Description | Default |
|---|---|---|---|
| session_id | Yes | The session ID | |
| name | No | Filter by cookie name (optional, returns all if empty) |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries full responsibility for behavioral disclosure. It indicates a read operation but provides no details on side effects, authentication needs, or rate limits. The minimal description is insufficient for informed 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?
At three words, the description is very concise but under-specified. It lacks essential context that would make it appropriately sized for the tool's purpose, striking a balance between brevity and 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 presence of an output schema and full parameter coverage, the description should still provide usage context and behavioral insights. It fails to address these, leaving the tool's context incomplete for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with descriptions for both parameters (session_id and name). The description adds no additional meaning beyond what the schema already provides, meeting the baseline expectation.
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 'Get browser cookies' clearly states the action and resource, distinguishing it from sibling tools like 'browser_delete_cookies' and 'browser_set_cookie'. However, it lacks specificity about the scope (e.g., per session), which would make it a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like browser_delete_cookies or browser_set_cookie. The absence of any usage context leaves the agent to infer the appropriate scenario.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get an attribute value from an element.
| Name | Required | Description | Default |
|---|---|---|---|
| session_id | Yes | The session ID | |
| selector | Yes | Element selector | |
| attribute | Yes | Attribute name to get | |
| by | No | Selector type (css, xpath, id, name, class, tag) | css |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as whether an error is thrown for a missing attribute or if null is returned. The simple action of 'getting' is stated without caveats 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, front-loaded sentence with no unnecessary words. It is appropriately concise for a simple getter tool, though slightly more context could be added without harming conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description does not mention the return value format, but an output schema exists (not shown). Given the tool's simplicity and the presence of an output schema, the description is moderately complete but could benefit from noting whether the attribute value is returned as a string or null.
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 covers all 4 parameters with descriptions, achieving 100% coverage. The description adds no extra meaning beyond the schema, which already defines parameters like 'attribute' as 'Attribute name to get'. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and the resource ('an attribute value from an element'), making it unambiguous. It distinguishes itself from sibling tools like browser_get_text, which retrieves text 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?
No guidance on when to use this tool versus alternatives (e.g., browser_get_text for text content, browser_find_elements for element existence). The description does not provide conditions or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get captured network request logs.
Requires browser_enable_network_log to be called first.
| Name | Required | Description | Default |
|---|---|---|---|
| session_id | Yes | The session ID | |
| filter_url | No | Filter by URL substring (optional) | |
| filter_method | No | Filter by HTTP method (GET, POST, etc.) | |
| limit | No | Maximum number of entries to return |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must bear full responsibility for behavioral disclosure. It only says 'Get captured network request logs,' which implies a read operation, but it does not clarify whether retrieving logs clears them, whether logs are cumulative over multiple calls, or any other behavioral traits. For a tool with zero annotation coverage, this is insufficient 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 two sentences, front-loaded with the main purpose, and every sentence adds value. No extra fluff.
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, the presence of an output schema (covering return values), and the clear prerequisite, the description is fairly complete. It could mention that the parameters help filter the logs, but the schema already covers that, so this is a minor gap.
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 100%, so the schema already documents all four parameters. The description adds no additional detail about the parameters beyond the prerequisite. According to guidelines, baseline is 3 with high coverage, which is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get captured network request logs' using a specific verb and resource. It distinguishes itself from the sibling tool 'browser_enable_network_log' which enables logging. However, it could be slightly more explicit about the fact that it retrieves logs, so it's not a perfect 5.
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?
Explicitly states the prerequisite: 'Requires browser_enable_network_log to be called first.' This tells the agent when to use this tool (after enabling) and implies that if logging isn't enabled, the agent should call 'browser_enable_network_log' first. No additional exclusions are needed for this simple tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the HTML source code of the current page.
| Name | Required | Description | Default |
|---|---|---|---|
| session_id | Yes | The session ID | |
| max_length | No | Maximum length of source to return (truncated if exceeded) |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must carry the full burden. It does not disclose important behaviors like whether the source includes dynamically loaded content, if it is post-render, or if truncation occurs (though max_length hints at it). No mention of 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 a single clear sentence with no wasted words. It is appropriately concise but could benefit from brief additional context 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?
The description is minimally adequate for a simple fetch tool. An output schema exists (not shown) so return values need not be described. However, the lack of usage guidance and behavioral details limits completeness given the two parameters and no annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% description coverage for both parameters (session_id, max_length). The description adds no additional meaning beyond the schema; baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Get) and the resource (HTML source code of the current page), distinguishing it from sibling tools like browser_get_text (visible text) or browser_get_url (URL).
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 browser_get_text or browser_screenshot. The description lacks context for selecting this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the text content of an element.
| Name | Required | Description | Default |
|---|---|---|---|
| session_id | Yes | The session ID | |
| selector | No | Element selector (CSS selector by default) | body |
| by | No | Selector type (css, xpath, id, name, class, tag) | css |
| max_length | No | Maximum text length to return |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must fully disclose behavior. It only states the basic function without mentioning edge cases (e.g., element not found, hidden text, multiple matches) or returning plain vs rendered text. The agent lacks information about failure modes or output format beyond what the output schema provides.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single concise sentence with no redundant information. Every word is necessary.
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 get-text tool with a likely output schema, the description is acceptable but could be more complete. It doesn't clarify behavior for multiple matches or non-existent elements, but given the tools's simplicity and the presence of an output schema, it meets minimum adequacy.
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 100% with each parameter already described (session_id, selector, by, max_length). The description adds no additional semantic value beyond what the schema provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the action ('Get the text content') and the resource ('an element'). It effectively distinguishes this tool from sibling browser tools like browser_get_url, browser_get_page_source, and browser_get_element_attribute, which have distinct purposes.
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 retrieving text from a specific element but provides no guidance on when to choose this over alternatives like browser_get_page_source (for full page text) or browser_get_element_attribute (for specific attributes). No explicit when-to-use or when-not-to-use context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the current page URL and title.
| Name | Required | Description | Default |
|---|---|---|---|
| session_id | Yes | The session ID |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries burden. It states a read operation with no side effects, which is clear, but does not mention any requirements (like active session) or limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no redundancy, front-loaded with the action. Perfectly concise for a simple getter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity, the description covers purpose and return. Output schema exists, so return format is documented. Could mention that session must be active, but session_id parameter implies that.
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 100% with one parameter (session_id) fully described. Description adds no additional meaning beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses specific verb 'Get' and resource 'current page URL and title'. It clearly distinguishes from sibling tools like browser_get_page_source, browser_get_text, and especially get_page_title which only returns the title.
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 when not to use. For example, if only the title is needed, get_page_title might be more efficient, but this is not mentioned. The usage is implied but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all active browser sessions.
Returns information about all currently active browser sessions including their URLs, titles, and configuration.
Returns: JSON string with list of active sessions
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the tool is read-only and returns session details, which is transparent. However, it does not disclose potential side effects or performance implications.
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 short and front-loaded. The second sentence slightly repeats 'active browser sessions' but overall is efficient with minimal waste.
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 listing tool with no parameters and an output schema, the description is sufficient. It explains purpose and return format, though it could clarify what constitutes a 'session' versus a tab.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, and schema coverage is 100%. The description adds no parameter information, but baseline is 3 per rubric for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List all active browser sessions' with a specific verb and resource. It distinguishes from sibling tools like browser_list_tabs, though it does not explicitly differentiate itself.
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 when session-level information is needed but offers no explicit guidance on when to use it versus alternatives like browser_list_tabs. No exclusions or context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all open tabs in the browser session.
| Name | Required | Description | Default |
|---|---|---|---|
| session_id | Yes | The session ID |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It implies a read-only operation but does not detail return format, session scoping, or side effects. The presence of an output schema somewhat mitigates this, but the description adds 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, efficient sentence that conveys the essential purpose without extraneous words. It is front-loaded and earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, one parameter, and the existence of an output schema to define return values, the description is complete enough for an agent to understand the tool's purpose and use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the baseline is 3. The description does not add extra meaning for the session_id parameter beyond what the schema provides. No format, source, or example is given.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List all open tabs') and the resource ('in the browser session'), distinguishing it from sibling tools like browser_switch_tab or browser_close_tab, which are about individual tabs.
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. It lacks context such as prerequisites, typical use cases, or when not to use it, leaving the agent to infer 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.
Open a new browser tab.
| Name | Required | Description | Default |
|---|---|---|---|
| session_id | Yes | The session ID | |
| url | No | URL to navigate to in new tab (optional) |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It does not disclose whether the new tab becomes active, remains in background, or if the session must already exist (though implied by schema). No return value or side effects are mentioned, leaving significant gaps in behavioral understanding.
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 at five words, which is appropriate for a simple tool. However, it could incorporate more context without becoming verbose, such as mentioning session_id or optional URL. It is not overly terse but misses opportunities.
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 availability of an output schema and many sibling browser tools, the description is incomplete. It fails to explain core behaviors (e.g., does the tool switch to the new tab?) or how it differs from browser_open and browser_switch_tab. The output schema is present but not described, so the agent relies solely on the minimal text.
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 100%, so the baseline is 3. The description adds no extra meaning beyond the schema; it neither clarifies parameter usage nor provides examples. It is adequate but not contributing additional semantic 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 'Open a new browser tab' clearly specifies the action (open) and resource (browser tab), distinguishing it from siblings like browser_open (new window) and browser_switch_tab. However, it does not explicitly differentiate from similar operations, such as opening a tab versus switching, which could be clarified.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description lacks context about when to use this tool versus alternatives like browser_open, browser_switch_tab, or browser_navigate. An agent would need to infer based on names alone, which is insufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Open a new browser session and navigate to a URL.
Creates a new browser instance (Chrome or Edge) and navigates to the specified URL. Returns a unique session ID for subsequent operations.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | URL to navigate to after opening the browser | |
| browser | No | Browser type to use ("chrome" or "edge") | chrome |
| headless | No | Run in headless mode without visible window | |
| window_size | No | Initial window size in WxH format (e.g., "1920x1080") | 1920x1080 |
| user_agent | No | Custom user agent string (optional) | |
| proxy | No | Proxy server URL (optional) |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It mentions creating a new browser instance and returning a session ID, but fails to disclose potential resource usage, the need to close sessions, or implications of headless mode.
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?
Two short sentences that convey the essential purpose and return value without unnecessary words. 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?
For a tool with 6 parameters and an output schema, the description covers the key behavior and return. It could mention error handling or session management, but it's largely 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?
Schema coverage is 100%, so baseline is 3. The description adds minimal parameter detail beyond what the schema already provides, only reiterating the creation and navigation aspects.
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 opens a new browser session and navigates to a URL. It distinguishes from sibling tools like browser_navigate (which reuses an existing session) by emphasizing the creation of a new instance.
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 explains the tool's function and return value but does not provide explicit guidance on when to use it versus alternatives (e.g., browser_navigate for existing sessions) 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.
Refresh the current page.
| Name | Required | Description | Default |
|---|---|---|---|
| session_id | Yes | The session ID |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description does not disclose potential side effects (e.g., losing unsaved form data, triggering reload prompts) or the behavior when the page is not loaded. With no annotations, the description must cover these, but 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 concise sentence that communicates the core action. It is not overly verbose, though it could include a brief note about the session context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with an output schema, the description is adequate but lacks context about state changes (e.g., page reload behavior) or error conditions (e.g., invalid session). It is minimally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully describes the single parameter (session_id) with a clear description. The tool description adds no extra semantic detail, so it meets the baseline for high schema coverage.
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 ('Refresh') and the resource ('current page'), making the purpose evident. However, among siblings like browser_back and browser_forward, it does not differentiate further, so it lacks explicit differentiation.
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 reloading a page versus navigating to a URL. It does not mention prerequisites like an active session or page.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Take a screenshot of the page or a specific element.
| Name | Required | Description | Default |
|---|---|---|---|
| session_id | Yes | The session ID | |
| save_path | No | File path to save screenshot (optional) | |
| selector | No | Element selector for element screenshot (optional) | |
| by | No | Selector type if selector is provided | css |
| full_page | No | Capture full scrollable page (Chrome only) | |
| filename | No | Custom filename (used with configured screenshot_dir) |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It does not mention behavioral traits such as non-destructiveness, whether it modifies page state, or any permissions required. The description is too minimal to convey these aspects.
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 front-loads the core purpose. While very concise, it lacks some details, but the structure is efficient and not 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 and many sibling tools, the description is somewhat complete. However, it omits where the screenshot is saved (relying on parameters) and does not mention return format. It is adequate but not fully comprehensive.
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 100% with well-described parameters. The description adds little beyond the schema (e.g., 'page or a specific element' hints at the selector parameter). Baseline of 3 is appropriate as the description provides marginal extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool takes a screenshot of a page or element. It distinguishes from siblings like browser_get_page_source (returns HTML) and browser_navigate (navigation). However, it could explicitly differentiate from other capture 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 (e.g., when to use screenshot vs get_page_source) or prerequisites like an active session. The description does not mention any 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.
Scroll the page or scroll an element into view.
| Name | Required | Description | Default |
|---|---|---|---|
| session_id | Yes | The session ID | |
| direction | No | Scroll direction (up, down, left, right, top, bottom) | down |
| amount | No | Pixels to scroll (for up/down/left/right) | |
| selector | No | Element to scroll into view (optional, overrides direction) | |
| by | No | Selector type if selector is provided | css |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 fails to mention scrolling behavior (e.g., smooth vs instant), side effects, or whether it scrolls the main viewport or a specific element.
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 covering both main use cases. However, it could be slightly expanded to include key behavioral or return info 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?
The description omits return value information, which is not covered by the output schema (if present). It does not explain what 'scroll into view' entails or any prerequisites, leaving 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 coverage is 100% with detailed parameter descriptions. The description adds minimal value by hinting at the selector's role ('scroll an element into view'), but does not provide additional semantics 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 scrolls the page or an element into view, using a specific verb and resource, which distinguishes it from sibling browser tools like navigation or clicks.
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 or when not to use it. No explicit context for usage selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Select an option from a dropdown/select element.
| Name | Required | Description | Default |
|---|---|---|---|
| session_id | Yes | The session ID | |
| selector | Yes | Select element selector | |
| value | Yes | Value to select | |
| by | No | Selector type for finding the select element | css |
| select_by | No | How to match the option ("value", "text", or "index") | value |
| timeout | No | Maximum seconds to wait for element |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description does not disclose behavioral traits such as whether it waits for the element, what happens on timeout, or post-selection events. The timeout parameter is mentioned in the schema but not in the description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no redundancy, making it very concise and 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 an output schema (not shown but indicated) and full schema coverage for parameters, the description is mostly complete. However, it could briefly mention the supported option matching methods (value, text, index) for better 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 100%, so the schema already documents all parameters. The description adds no additional meaning beyond the tool's purpose, which is already clear from the 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 ('select') and the UI element ('dropdown/select element'), making it distinct from sibling tools like browser_click or browser_type.
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., browser_click for non-select elements), and no mention of prerequisites or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set a browser cookie.
| Name | Required | Description | Default |
|---|---|---|---|
| session_id | Yes | The session ID | |
| name | Yes | Cookie name | |
| value | Yes | Cookie value | |
| domain | No | Cookie domain (optional, uses current domain if empty) | |
| path | No | Cookie path | / |
| secure | No | Secure flag | |
| http_only | No | HttpOnly flag | |
| expiry | No | Expiry timestamp (0 for session cookie) |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It only states the basic action without mentioning side effects (e.g., overwriting existing cookies), security implications, or whether the session must be valid. This is insufficient for an agent to understand the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (one short sentence), but lacks any structure such as bullet points, examples, or notes. While brevity is valued, it sacrifices clarity and completeness. It earns a middle 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?
The tool is simple, but the description omits important context: it does not mention that a valid session_id is required, what happens on success/failure, or relationships with other cookie tools. An output schema exists but is not referenced. The description is 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?
Input schema coverage is 100%, so the schema already documents all 8 parameters with descriptions. The description adds no extra meaning beyond the schema. Baseline 3 is appropriate given the high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Set a browser cookie' clearly states the action and resource. It distinguishes from sibling tools like browser_get_cookies and browser_delete_cookies by specifying 'set'. However, it lacks additional context that could further clarify the tool's role.
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 a cookie already exists (it will be overwritten) or prerequisites like having an active browser session. The description offers no usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Switch to a different browser tab by index.
| Name | Required | Description | Default |
|---|---|---|---|
| session_id | Yes | The session ID | |
| tab_index | Yes | Tab index (0-based) |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description carries full burden. It states core behavior but does not disclose side effects, error handling, or return values. 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, no redundancy. Front-loaded with verb and resource. Efficient use of 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?
Given a simple action and presence of output schema, description is acceptable but lacks details on failure cases and return values. Sufficient for basic understanding.
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 covers 100% of parameters with descriptions. The description adds 'by index' which reinforces tab_index but does not provide additional semantics beyond 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?
Description clearly states the action ('Switch') and resource ('browser tab'), with a specific mechanism ('by index'). It distinguishes from siblings like browser_list_tabs, browser_new_tab, and browser_close_tab.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs alternatives. Does not mention prerequisites (e.g., session must exist) or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Type text into an input element.
| Name | Required | Description | Default |
|---|---|---|---|
| session_id | Yes | The session ID | |
| selector | Yes | Element selector | |
| text | Yes | Text to type | |
| by | No | Selector type (css, xpath, id, name, class, tag) | css |
| clear | No | Whether to clear existing text first | |
| timeout | No | Maximum seconds to wait for element |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It does not mention that existing text may be cleared (clear param) or that it waits for element (timeout), nor any side effects. This is insufficient for a browser automation 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 extremely concise with one short sentence, which is good for brevity but lacks structure and additional relevant details. It is not overly verbose, but could include more key information without becoming long.
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 (6 parameters, browser automation context), the description is incomplete. It does not cover behavioral nuances like element waiting, clearing, or selector types. Although an output schema exists, the description still needs to address usage 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 100%, so baseline is 3. The description adds no meaning beyond the schema; it merely states the overall action. No parameter details are elaborated.
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 'Type text into an input element' clearly states the action and target, using a specific verb and resource. It is unambiguous but does not explicitly distinguish from sibling tools like browser_fill_form, which could be used for multiple fields.
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, nor any prerequisites or exclusions. The description lacks context for when this tool is appropriate, such as element visibility or page load state.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Wait for an element to satisfy a condition.
| Name | Required | Description | Default |
|---|---|---|---|
| session_id | Yes | The session ID | |
| selector | Yes | Element selector | |
| by | No | Selector type (css, xpath, id, name, class, tag) | css |
| timeout | No | Maximum seconds to wait | |
| condition | No | Condition to wait for: - "present": Element exists in DOM - "visible": Element is visible - "clickable": Element is clickable - "gone": Element no longer exists | present |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description fails to disclose key behaviors like blocking nature, timeout behavior, or error handling, leaving the agent unaware of important operational details.
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, front-loaded with the core action, and contains no superfluous text.
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 moderate complexity (5 parameters, multiple conditions) and the existence of an output schema, the description is minimal but sufficient for basic understanding, though it could elaborate on waiting behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% description coverage, so the description adds no new meaning; baseline 3 is appropriate as the schema already documents parameters adequately.
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 (wait) and the target (element) with a condition, which is specific and distinguishes it from other browser actions like clicking or navigating.
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 browser_click or browser_find_elements, nor any scenarios to avoid.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calculate difference between two dates.
| Name | Required | Description | Default |
|---|---|---|---|
| date1 | Yes | First date string | |
| date2 | Yes | Second date string | |
| unit | No | Unit for difference - 'days', 'hours', 'minutes', 'seconds' (default: days) | days |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must fully disclose behavior. It only says 'calculate difference' without specifying date format expectations, return type, 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?
Extremely concise (5 words) but lacks critical details; conciseness should not compromise 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 3 parameters and presence of output schema, description fails to explain return values or date format requirements, leaving significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with parameter descriptions covering date strings and unit options; description adds no additional semantic value, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool calculates date difference, but could be more specific about units and differentiate from siblings like date_to_timestamp or format_date.
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 alternative date calculations or conversions; description lacks context for agent decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Safely evaluate a mathematical expression.
| Name | Required | Description | Default |
|---|---|---|---|
| expression | Yes | Mathematical expression to evaluate (supports +, -, *, /, **, (), basic math functions) |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only says 'safely evaluate' without disclosing specific behavioral traits (e.g., memory limits, function restrictions, 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, concise sentence. It is front-loaded with the core purpose. However, it could benefit from slight expansion for usage context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has a single parameter and an output schema (not shown), the description is largely sufficient. It covers the essential behavior, though it omits any constraints like recursion limits.
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 covers 100% of parameters, but the description adds value by listing supported operators and functions ('+', '-', '*', '/', '**', '()', basic math functions). This provides 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 evaluates a mathematical expression, with a specific verb 'evaluate' and resource 'mathematical expression'. It distinguishes itself from sibling tools like calculate_date_diff and calculate_text_similarity.
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, nor any exclusions or prerequisites. The word 'safely' hints at context but lacks specificity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calculate similarity between two text strings.
| Name | Required | Description | Default |
|---|---|---|---|
| text1 | Yes | First text string | |
| text2 | Yes | Second text string | |
| method | No | Algorithm - "levenshtein" or "jaccard" (default: levenshtein) | levenshtein |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states 'Calculate similarity' without explaining the behavior (e.g., algorithms, output format, that it is a pure computation with no side effects). The schema covers method choices, but the description adds nothing 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?
A single, clear sentence that is front-loaded with purpose. No redundant words or structure issues.
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 simplicity, presence of an output schema, and full parameter descriptions in the schema, the description is mostly complete. However, it could briefly mention that the result is a similarity score and mention the default algorithm.
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 100%, so the schema already documents all parameters. The description does not add extra meaning or context beyond what is in the schema. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (calculate) and the resource (similarity between two text strings). It is specific and distinct from sibling tools like diff_text or count_words.
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 diff_text or other text comparison tools. The description lacks context about appropriate scenarios or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check password strength and provide recommendations.
| Name | Required | Description | Default |
|---|---|---|---|
| password | Yes | Password to check |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must cover behavioral traits. It does not disclose whether the password is stored, logged, or transmitted, nor any security implications. The strength criteria and recommendation format are also unspecified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is a single, clear sentence with no wasted words. It efficiently conveys the tool's purpose and outcome.
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 good schema coverage and an output schema, the description fails to explain what constitutes strength or provide context on recommendations. Missing important details for a security-sensitive tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a clear description ('Password to check'). The tool description adds no additional meaning beyond the schema, so baseline 3 applies.
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 specific action ('check'), the resource ('password strength'), and the outcome ('provide recommendations'). 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 explicit guidance on when or when not to use, but the tool's purpose is self-evident. No sibling tool competes, so lack of alternative mention is acceptable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check the HTTP status of a URL.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | URL to check | |
| timeout | No | Request timeout in seconds (default: 10) |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only states the action; it does not disclose details like redirect handling, error responses, or timeout behavior, beyond what can be inferred from 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 very concise (one line) and front-loaded, but it could include additional useful context 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 output schema exists, return values are covered. However, the description lacks usage guidelines and behavioral context, making it less complete for a tool amidst many similar 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?
Schema description coverage is 100% (both url and timeout documented), so the description adds no extra meaning beyond what the schema provides, baseline is 3.
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 'Check the HTTP status of a URL' uses a specific verb and resource, clearly distinguishing it from sibling tools like fetch_webpage or http_request.
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 fetch_webpage or get_headers, leaving the agent to infer context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Clear the search cache.
This will remove all cached search results, forcing fresh searches.
Returns: JSON string with operation result
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description discloses the destructive behavior ('remove all cached search results') and the return type, providing sufficient 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 two sentences plus return info, with no unnecessary words. 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 no parameters and an output schema, the description fully explains the tool's effect and return, making it complete for its 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?
With zero parameters, the description adds value by explaining the return format (JSON string with operation result), going beyond the schema's minimal information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (clear) and the resource (search cache), making it distinct from sibling tools like get_search_stats or web_search.
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 force fresh searches) but does not explicitly exclude scenarios or mention alternatives, which is acceptable for a simple maintenance tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a TAR archive from files.
| Name | Required | Description | Default |
|---|---|---|---|
| files | Yes | List of file paths to compress | |
| output_path | Yes | Path for output TAR file | |
| compression | No | Compression type - "none", "gz", or "bz2" (default: "gz") | gz |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the action, without mentioning file overwrite behavior, error handling, or support for directories.
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 is easy to read and front-loads the core purpose. It could benefit from a bit more structure but is effective for its length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and 100% parameter coverage, the description is minimally adequate. However, it lacks context about supported compression types (though in schema) and typical use cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the parameters are already described. The description adds no additional meaning beyond the schema, meeting the baseline of 3.
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 'Create a TAR archive from files,' specifying both the verb (create) and resource (TAR archive). It distinguishes from sibling tools like compress_zip and extract_tar.
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 compress_zip or extract_tar. It does not mention which scenarios are appropriate 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.
Create a ZIP archive from files.
| Name | Required | Description | Default |
|---|---|---|---|
| files | Yes | List of file paths to compress | |
| output_path | Yes | Path for output ZIP file | |
| compression_level | No | Compression level 0-9 (default: 6) |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral traits. It only states the action without disclosing permissions, overwrite behavior, error handling, or other 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 single-sentence description is concise but omits critical information. It is appropriately front-loaded but insufficient for a complete 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 a simple input schema and available output schema, the description lacks details about return values, error conditions, and usage context, leaving gaps for a file operation 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 100% with clear descriptions for all parameters. The tool description adds no additional meaning beyond the schema, so baseline 3 applies.
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 'Create a ZIP archive from files' uses a specific verb and resource, clearly stating the tool's action and distinguishing it from siblings like compress_tar and extract_zip.
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 vs alternatives such as compress_tar. There are no when-to-use, when-not-to-use, or prerequisite details.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Copy a file from source to destination.
| Name | Required | Description | Default |
|---|---|---|---|
| source | Yes | Source file path | |
| destination | Yes | Destination file path | |
| overwrite | No | Whether to overwrite if destination exists (default: False) |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description should disclose behavior like error handling, whether directories are created, and what happens on conflict. The overwrite parameter is in schema but description doesn't clarify behavior 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 concise sentence. It is front-loaded and efficient, though could benefit from a slightly more structured 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?
For a simple file copy with a complete schema and output schema, the description is adequate but lacks mention of common error cases (e.g., source not found) and behavioral nuance.
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 100%, so baseline is 3. The description does not add any additional meaning beyond the schema's parameter 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 action (copy) and resource (file), with explicit source and destination. It distinguishes itself from sibling tools like delete_file, write_file, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this vs alternatives (e.g., when to use copy vs move vs duplicate). No context about prerequisites like file existence or permissions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Count words and provide text statistics.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | Text to analyze | |
| detailed | No | Include detailed statistics (default: True) |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It vaguely mentions 'text statistics' without details on what statistics are included, return format, or side effects. Critical information is 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 concise (one sentence) but overly vague, trading informativeness for brevity. It could be restructured to include key details 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?
Despite low complexity and an output schema, the description fails to explain what statistics are returned or how the output is structured. The word 'statistics' is insufficient for an agent to infer 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?
Schema description coverage is 100%, so the baseline is 3. The description adds no extra meaning beyond the schema; it does not clarify the 'detailed' parameter's effect or data types.
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 counts words and provides text statistics with a specific verb and resource, but lacks differentiation from sibling tools like 'text_summary' or 'calculate_text_similarity'.
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 exclusions or prerequisites. The agent has no 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.
Create a directory.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Path to the directory to create | |
| parents | No | Create parent directories if needed (default: True) |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It only states 'Create a directory', omitting any effects, side conditions, permissions, or return behavior. This is severely lacking for a write 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 sentence, which is concise but too minimal. It essentially repeats the tool name and does not provide value beyond that. It is front-loaded but under-specified for the tool's context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no annotations and an output schema (unknown content), yet the description fails to mention any return value or behavioral context. For a simple tool, it is incomplete and does not compensate for missing structured metadata.
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 100% parameter description coverage, so the baseline is 3. The description adds no additional meaning beyond the schema, but does not detract either.
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 'Create a directory.' clearly states the action and resource, but does not differentiate from sibling tools like 'list_directory' or 'delete_file'. It is essentially a tautology of the tool name, though distinct enough for 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?
No guidance is provided on when to use this tool versus alternatives. The description lacks any context or prerequisites, leaving the agent without direction on appropriate scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Convert CSV data to JSON.
| Name | Required | Description | Default |
|---|---|---|---|
| csv_string | Yes | CSV string to convert | |
| delimiter | No | CSV delimiter (default: ,) | , |
| has_header | No | Whether first row is header (default: True) |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral traits. It fails to disclose default behaviors (e.g., has_header=True, delimiter=','), error handling, or output structure. The description is too brief to inform the agent of important behavioral nuances.
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 gets straight to the point. It is front-loaded and wastes no words, though it could potentially include 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?
Given the tool's low complexity (3 parameters, no nested objects) and the presence of an output schema, the description is somewhat complete but lacks details about default behaviors and output format. It is 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 coverage is 100%, and the description adds no additional meaning beyond what is already in the schema. The baseline score of 3 is appropriate as the schema fully documents the parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb ('Convert') and resource ('CSV data') and output ('JSON'). It distinguishes itself from sibling tools like 'parse_csv' and 'json_to_csv' by its explicit name and action.
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 'parse_csv' or other conversion utilities. No context or exclusion criteria are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Convert date string to Unix timestamp.
| Name | Required | Description | Default |
|---|---|---|---|
| date_string | Yes | Date string to convert (various formats supported) | |
| timezone | No | 'local' or 'utc' (default: local) | local |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only states the basic function, omitting supported date formats, error handling, 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, straightforward sentence with no unnecessary words, achieving conciseness but lacking supportive 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 output schema exists and the tool is simple, the description minimally covers the conversion task but does not specify supported date formats or edge cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters; the description adds no extra meaning beyond what is in 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 converts a date string to a Unix timestamp, using a specific verb and resource, and distinguishes it from the sibling 'timestamp_to_date'.
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, nor any prerequisites or context for the timezone parameter.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Decode Base64 to text.
| Name | Required | Description | Default |
|---|---|---|---|
| encoded | Yes | Base64 encoded string | |
| encoding | No | Text encoding for decoded output (default: utf-8) | utf-8 |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full responsibility. It explains the core transformation but omits details like error handling for invalid input or behavior with non-text outputs. Minimal but adequate for a simple utility.
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 extraneous words. Every word contributes to conveying the purpose 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's simplicity, the description paired with full schema and output schema covers the essential information. However, it could be slightly more helpful by mentioning the output format explicitly.
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 100%, so the baseline is 3. The description adds no extra parameter information beyond what the schema already provides (encoded string, optional encoding).
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 'Decode Base64 to text' clearly specifies the action (decode), object (Base64), and output (text). It is distinct from sibling tools like 'encode_base64' which performs the reverse operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidelines are provided on when to use this tool versus alternatives. There is no mention of context, prerequisites, or exclusions, leaving the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a file (requires confirmation).
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Path to the file to delete | |
| confirm | No | Must be True to actually delete (safety feature) |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It correctly identifies the tool as destructive and mentions the safety confirmation feature. However, it omits critical details such as whether the deletion is permanent, if files can be recovered, or required permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (seven words) and front-loaded. Every word is meaningful and earns its place, with no redundancy or fluff.
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 (two parameters, obvious deletion action) and the existence of an output schema documenting return values, the description is fairly complete. However, it could improve by explicitly stating that deletion is permanent and irreversible.
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 100% coverage (both parameters have descriptions). The description adds minimal meaning beyond the schemaโ'requires confirmation' reinforces the confirm parameter's role. The schema already documents that confirm 'Must be True to actually delete (safety feature)', so the description does not significantly enhance parameter understanding.
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 'Delete a file (requires confirmation)' clearly states the action and resource, distinguishing it from siblings like copy_file, read_file, and write_file. The verb and resource are specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description hints at a usage guideline by mentioning 'requires confirmation', indicating that the confirm parameter must be set to True to perform deletion. However, it does not provide guidance on when to use this tool versus alternative deletion methods (e.g., moving to trash) or any prerequisite conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compare two files and show differences.
| Name | Required | Description | Default |
|---|---|---|---|
| file1 | Yes | Path to first file | |
| file2 | Yes | Path to second file | |
| context_lines | No | Number of context lines (default: 3) | |
| format | No | Output format - "unified", "context", or "ndiff" (default: "unified") | unified |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 merely states the action without addressing read-only nature, file size limits, error handling, or output format details. The description fails to convey behavioral traits beyond the basic function.
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 and front-loaded, but it is overly brief. It could include a bit more detail (e.g., supported formats) without losing conciseness. It is adequate but not exemplary.
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 four parameters, an output schema, and no annotations, the description is too sparse. It omits important context such as the ability to customize output format and context lines, which are specified in the schema but not mentioned in the description. The description feels incomplete for a file comparison tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides descriptions for all four parameters, covering 100% of them. The description adds no additional meaning beyond what the schema offers, so it meets the baseline but does not exceed it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('compare') and resource ('two files'), and the output ('differences'). It effectively distinguishes itself from the sibling tool 'diff_text' by specifying files rather than text strings.
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 'diff_text' or other file manipulation tools. There is no mention of 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.
Compare two text strings and show differences.
| Name | Required | Description | Default |
|---|---|---|---|
| text1 | Yes | First text string | |
| text2 | Yes | Second text string | |
| format | No | Output format - "unified", "context", or "ndiff" (default: "unified") | unified |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description lacks behavioral details such as output format specifics, case sensitivity, encoding handling, or line-level behavior. The format parameter is in the schema, but the description does not clarify its effect.
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 without unnecessary detail or repetition. Every word contributes meaning.
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, and the existence of an output schema, the description is largely complete. It could benefit from mentioning the output format options, but the schema and output schema likely suffice for agent 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 100%, so the schema already documents all parameters fully. The description adds no additional meaning or context beyond the schema, achieving the baseline 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 verb 'compare' and the resource 'two text strings', effectively distinguishing it from sibling tools like diff_files (compares files) and calculate_text_similarity (provides similarity scores).
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 its siblings (e.g., diff_files for file comparison) or alternatives. Usage context is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Perform DNS lookup.
| Name | Required | Description | Default |
|---|---|---|---|
| hostname | Yes | Hostname or domain name | |
| record_type | No | DNS record type - A, AAAA, MX, NS, TXT (default: A) | A |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must bear the full burden of disclosing behavioral traits. The description only says 'Perform DNS lookup.' It does not mention that it performs network I/O, may be slow, or may fail without network, which are important for an agent to anticipate.
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 (5 words) and front-loaded. No wasted information. It is appropriate for a simple utility tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (not shown), the description is minimally adequate. It does not explain what the output represents (e.g., resolved IP addresses), which might confuse agents. For a 2-parameter tool with common functionality, it is acceptable but could be more informative.
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 100% with descriptions for both parameters. The description adds no additional meaning beyond what the schema provides. Baseline score of 3 applies.
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 ('Perform') and resource ('DNS lookup'). It is specific and distinct from siblings, as no other tool in the server deals with DNS. However, it could be more descriptive (e.g., 'resolve domain names to IP addresses').
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidelines are provided. The description does not specify when to use this tool, any prerequisites, or alternatives. For a simple tool this is acceptable but lacks context for the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Download a file from URL and save to disk.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | URL of the file to download | |
| save_path | Yes | Local path where file should be saved | |
| timeout | No | Request timeout in seconds (default: 30) |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behaviors. It only states the action without mentioning overwrite behavior, permission requirements, error handling, or resource constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with one sentence that is front-loaded. Every word is necessary, and there is no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a file download tool, important context is missing: overwrite behavior, directory creation, supported protocols, and output format. The existence of an output schema partially mitigates, but the description remains 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 coverage is 100%, so baseline is 3. The description adds no additional meaning beyond what the input schema already provides for the three parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: downloading a file from a URL and saving to disk. It uses specific verbs and resources, and distinguishes from siblings like read_file and fetch_webpage.
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 http_request or fetch_webpage. It does not mention prerequisites, when not to use, or edge cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Encode text to Base64.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | Text to encode | |
| encoding | No | Text encoding (default: utf-8) | utf-8 |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden. It does not disclose any behavioral traits beyond the basic operation, but for a simple encoding tool, the behavior is inherent. Lacks details on output format or potential errors.
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 single sentence that immediately conveys the tool's purpose. 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?
For a simple tool with full schema coverage and an output schema (though not provided), the description is nearly complete. Could mention that it returns a Base64-encoded string, but not strictly necessary given the output schema.
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 100%, so baseline is 3. The description does not add any additional meaning to the parameters beyond what the schema already provides.
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 says 'Encode text to Base64', which clearly states the action and resource. It distinguishes from sibling 'decode_base64' but is somewhat tautological with the tool name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidelines are provided. There is no indication of when to use this tool versus alternatives like 'decode_base64' or other encoding methods.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Extract all email addresses from text.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | Text to search for emails |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description only states the basic function without disclosing behavioral details like handling multiple emails, validation, or duplicates.
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 at one sentence, front-loaded with key action. Could benefit from additional context but avoids verbosity.
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?
Adequate for a simple extraction tool with output schema present, but lacks usage guidance and behavioral transparency, leaving gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a clear parameter description. The tool description adds no significant 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?
Description clearly states the action 'extract' and resource 'email addresses from text'. It is specific and distinct from sibling tools like extract_urls.
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 extract_urls or regex_match. Usage is implied but no explicit context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Extract a TAR archive.
| Name | Required | Description | Default |
|---|---|---|---|
| tar_path | Yes | Path to TAR file | |
| extract_to | No | Directory to extract to (default: current directory) | . |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavioral traits. It only says 'Extract a TAR archive' with no mention of overwrite behavior, error handling, or security considerations. This 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 with no wasted words. While very concise, it lacks structure such as sections or bullet points, but given the simplicity of the tool, it is acceptable.
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 mention supported compression types (gzip, bzip2?), error conditions, or side effects (e.g., overwriting files). For a tool with no annotations, this is insufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers both parameters with descriptions, achieving 100% coverage. The description adds no new parameter meaning beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the action 'Extract' and resource 'TAR archive', but it does not differentiate from sibling tools like list_archive_contents or compress_tar. It lacks specifics on scope or supported formats.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives (e.g., list_archive_contents for listing, compress_tar for creating). There is no mention of preconditions 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.
Extract all URLs from text.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | Text to search for URLs |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It only states it extracts URLs but does not specify the format (e.g., full URLs, relative, protocol-relative), whether it deduplicates, or limits such as not extracting URLs from certain contexts. This is minimal disclosure.
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 the core action. It is appropriately sized for a simple tool, though some might argue it is too brief. Still, it meets conciseness well.
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, has output schema), the description adequately covers the core functionality. The presence of an output schema informs the agent about return values, so the description does not need to elaborate further. It is complete for the task.
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 100% coverage with parameter 'text' described as 'Text to search for URLs'. The description adds no additional semantic value beyond what the schema already provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Extract all URLs from text' uses a specific verb and resource clearly indicating the tool's function. It differentiates from sibling tools like extract_emails, parse_url_components, and check_url_status that deal with URLs differently.
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. Siblings such as parse_url_components (for parsing URL components) or check_url_status (for validating URL status) are not mentioned. The description lacks exclusions or context for appropriate use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Extract a ZIP archive.
| Name | Required | Description | Default |
|---|---|---|---|
| zip_path | Yes | Path to ZIP file | |
| extract_to | No | Directory to extract to (default: current directory) | . |
| password | No | Optional password for encrypted ZIP |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description is minimal ('Extract a ZIP archive'), revealing no behavioral details such as whether the original archive remains, error handling, or permission requirements. With no annotations, the description carries the full burden but fails to provide meaningful 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 with a single sentence, making it front-loaded and easy to parse. However, it may be overly terse, sacrificing 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 the tool has three parameters, no annotations, and an output schema, the description is notably incomplete. It fails to mention handling of encrypted archives (password parameter), default extraction directory, or the nature of the result, leaving an agent with insufficient 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 100%, so the parameters are already documented. The description adds no additional meaning beyond the schema, meeting the baseline expectation.
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 'Extract' and the resource 'ZIP archive', making the purpose unambiguous. However, it does not differentiate from sibling tools like 'extract_tar' or 'list_archive_contents'.
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, nor any prerequisites or limitations. The description simply states the action without contextual direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch the HTML content of a webpage.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | URL of the webpage to fetch | |
| timeout | No | Request timeout in seconds (default: 10) |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior like redirect handling, cookie support, user-agent, or truncation. It only states it fetches HTML, leaving critical traits unknown.
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 is concise and front-loaded, with no wasted words. However, it is slightly under-specified for a tool with no 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?
An output schema exists (context signal), so the description can be lighter, but it still fails to mention return format, error handling, or limitations (e.g., timeout behavior). 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 100%, so the baseline is 3. The description adds no extra meaning beyond the parameter names and defaults already in 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 fetches HTML content of a webpage, which is a specific verb+resource. However, it does not distinguish itself from siblings like `fetch_webpage_text` or `http_request`, missing differentiation.
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 over alternatives (e.g., `fetch_webpage_text` for text extraction, `browser_navigate` for JavaScript rendering, or `http_request` for custom requests). The agent receives no criteria for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch and extract clean text content from a webpage.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | URL of the webpage to fetch | |
| timeout | No | Request timeout in seconds (default: 10) |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 only states what the tool does (fetch and extract), but omits details such as how it handles redirects, timeouts, JavaScript, or non-text content. The 'timeout' parameter is not elaborated.
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 succinct and front-loaded, conveying the core purpose without 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?
The presence of an output schema reduces the need to explain return values. Given the tool's simplicity, the description is adequate but lacks behavioral context and usage guidance, leaving some gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. However, the description adds no meaning beyond the schema's parameter names and types. It does not explain the significance of 'clean text' or how the timeout affects behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies a verb ('Fetch and extract') and a resource ('clean text content from a webpage'). It effectively distinguishes this tool from its sibling 'fetch_webpage', which likely retrieves raw HTML, by specifying 'clean text'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'fetch_webpage' or other extraction methods. There are no exclusions or context for when it is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check if a file or directory exists.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Path to check |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Does not disclose what happens if path does not exist (e.g., returns false vs error), permissions needed, or side effects. Minimal behavioral info.
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 unnecessary words. 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?
With no annotations and a single parameter, the description is too minimal. Lacks details on return value (likely boolean), error handling, and practical usage context. Incomplete for an AI agent to use reliably.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, schema already describes 'path' as 'Path to check'. Description adds no additional meaning beyond schema. Baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb 'check' and resource 'file or directory existence'. Distinguishes from many sibling file tools (e.g., read_file, get_file_info) that do more than just existence.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use vs alternatives. No mention of using this before read_file or other operations that require existence. Could benefit from clarifying context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Flatten nested JSON object into single-level object.
| Name | Required | Description | Default |
|---|---|---|---|
| json_string | Yes | JSON string to flatten | |
| separator | No | Separator for nested keys (default: .) | . |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description only states the basic behavior. It does not disclose edge cases, handling of arrays, errors, or idempotency. However, the behavior is simple and predictable.
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, efficiently conveying the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity and presence of an output schema, the description covers the core functionality adequately. It could mention limitations like not handling arrays, but overall it is sufficient.
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 100%, so the description does not add value beyond the parameter descriptions in the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the verb 'flatten' and specifies the resource as 'nested JSON object', clearly indicating the transformation to a single-level object. It is distinct from sibling JSON tools like json_query or parse_json.
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 flatten_json versus other JSON tools or similar operations. The description does not mention alternatives or appropriate contexts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Format a date string using custom format.
| Name | Required | Description | Default |
|---|---|---|---|
| date_string | Yes | Date string to format | |
| format | No | strftime format string (default: %Y-%m-%d %H:%M:%S) | %Y-%m-%d %H:%M:%S |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, and the description lacks details about input format expectations, error handling, or behavior for invalid dates.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, concise and front-loaded. However, it is slightly too brief for a full 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?
Output schema exists, so return value explanation is unnecessary. However, details about input date string parsing expectations are missing, making it slightly 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 coverage is 100% with clear parameter descriptions. The description adds minimal value beyond the schema, repeating the concept of custom 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 (format) and resource (date string), and specifies the use of a custom format. It distinguishes itself from sibling date tools like date_to_timestamp and timestamp_to_date.
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, nor are prerequisites or limitations mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Format JSON with pretty printing.
| Name | Required | Description | Default |
|---|---|---|---|
| json_string | Yes | JSON string to format | |
| indent | No | Number of spaces for indentation (default: 2) | |
| sort_keys | No | Whether to sort object keys (default: False) |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, and the description only says 'pretty printing' without disclosing error handling, output format, or whether the input is validated. It does not specify that the output is a formatted string.
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 to the point, but it lacks structure and additional necessary details. It is concise but not optimally informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool, the description is too minimal. It does not cover potential errors, return type, or formatting behavior. The presence of an output schema partially mitigates the lack of return value explanation, but behavioral context 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 coverage is 100% with descriptions for all parameters. The description adds no additional semantic value beyond the schema, earning the baseline score of 3.
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 'Format' and resource 'JSON', indicating pretty-printing. It is distinct from sibling tools like json_query or parse_json, though it does not explicitly differentiate itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. For example, it does not mention that parse_json or flatten_json may be more appropriate for other JSON tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate hash of text using specified algorithm.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | Text to hash | |
| algorithm | No | Hash algorithm - md5, sha1, sha256, sha512 (default: sha256) | sha256 |
| encoding | No | Text encoding (default: utf-8) | utf-8 |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden. It correctly implies a pure computation without side effects but does not explicitly state non-destructive behavior or any limitations. The schema provides algorithm options, which the description acknowledges.
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 contains no unnecessary words. Every word serves a purpose, making it concise and easy to parse.
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 full parameter descriptions, the description adequately covers the tool's purpose. There is no need to explain return values or additional behavioral 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 coverage is 100%, so baseline is 3. The description adds minimal extra meaning beyond what the input schema already provides (text, algorithm, encoding). It does not elaborate on parameter constraints or usage tips.
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 (generate hash) and the resource (text) with a specified algorithm. It distinguishes itself from sibling tools like encode_base64 and generate_random_string by focusing on cryptographic hashing.
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. With many sibling tools, explicit usage context would help the agent choose correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a strong password.
| Name | Required | Description | Default |
|---|---|---|---|
| length | No | Password length (8-128, default: 16) | |
| include_symbols | No | Include special characters (default: True) | |
| include_numbers | No | Include numbers (default: True) | |
| exclude_ambiguous | No | Exclude ambiguous characters like 0/O, 1/l/I (default: True) |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral traits (e.g., randomness source, side effects). It only says 'strong password' without explaining what strong means or security implications.
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. While minimal, it is front-loaded with purpose, though it could benefit from slightly more detail 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 full schema and output schema, the description covers the basics but lacks completeness in usage context and behavioral details for a simple 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 100%, so the description does not need to add parameter details. Baseline 3 is appropriate as the description adds no extra 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 generates a strong password, with a specific verb and resource. However, it does not distinguish from siblings like `generate_random_string`, which could also be used for password generation.
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., `generate_random_string`, `generate_hash`). Lacks context on use cases or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a random string.
| Name | Required | Description | Default |
|---|---|---|---|
| length | No | Length of string to generate (default: 16) | |
| charset | No | Character set - 'alphanumeric', 'letters', 'digits', 'hex', 'ascii' (default: alphanumeric) | alphanumeric |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only says 'Generate a random string' without detailing randomness quality (e.g., cryptographic security), charset constraints, or edge cases. The parameter schema covers some semantics, but the description adds no 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 short sentence, which is concise and front-loaded. However, it may be too minimal, sacrificing completeness for brevity. Every word earns its place, but lacks informative value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and the existence of a complete input schema (with output schema likely defined), the description is barely adequate. It does not explain random generation properties or handle edge cases, but for a straightforward string generator, it might suffice.
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 100%, and the parameter descriptions in the schema are clear. The tool description does not add any extra meaning beyond what the schema already provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 'random string'. It is specific enough for a simple utility, but does not differentiate from similar sibling tools like generate_password or generate_uuid, which could lead to confusion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description does not mention any context, prerequisites, or exclude conditions, leaving the agent to infer usage 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.
Generate a UUID.
| Name | Required | Description | Default |
|---|---|---|---|
| version | No | UUID version (1 or 4, default: 4) | |
| uppercase | No | Return uppercase UUID (default: False) |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description is extremely minimal and does not disclose behavioral traits beyond the basic action. With no annotations provided, the description fails to mention that the tool is stateless and non-destructive, or that it generates a random UUID (v4) by default. The agent must infer behavior from 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 sentence with no wasted words. It is front-loaded with the key verb and resource. While extremely short, it is concise for a simple tool, though slightly more contextual information could be added 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 tool's simplicity (2 optional params, output schema exists), the description is minimally sufficient but lacks completeness. It does not explain the output format (e.g., a string) or mention that the default version is 4 and uppercase false. With an output schema present, the description could be slightly richer.
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 100%, so the schema already documents both parameters (version and uppercase) with defaults and descriptions. The description adds no additional semantic value beyond what is in the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Generate') and the resource ('UUID'). It distinguishes from sibling tools like generate_password or generate_hash by specifying the exact output format. However, it could be improved by mentioning the default version or typical use cases.
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 the purpose is clear, there is no mention of context, such as when to choose UUID v1 vs v4, or how it differs from other generation tools like generate_random_string.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get CPU information and current usage.
Returns: JSON string containing CPU details and usage
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description carries full burden. It states it returns a JSON string, which implies a read operation, but does not disclose any permissions, side effects, or rate limits. Minimum acceptable for a trivial 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?
Two sentences, very concise. Front-loaded with purpose. 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?
Tool is simple (no parameters, has output schema). Description covers purpose and return type. No missing context for this complexity level.
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?
Zero parameters. Per rules, baseline is 4 when no parameters exist. Description does not need to add parameter info.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (get) and resource (CPU information, current usage). The name itself distinguishes it from siblings like get_memory_info or get_system_info. 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 vs alternatives. For a simple read tool, usage is obvious, but the dimension requires explicit context or exclusions, which are missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get current date and time.
| Name | Required | Description | Default |
|---|---|---|---|
| timezone | No | Timezone (default: local) - use 'utc' for UTC | local |
| format | No | Output format - 'iso', 'timestamp', or 'readable' (default: iso) | iso |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as that it is a read-only operation or any side effects. For a tool with no annotations, the description should explicitly mention safety or idempotency.
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 5 words, but it is overly terse and lacks structure. It does not front-load key information beyond the basic 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?
Despite having an output schema and only two optional parameters, the description is incomplete. It does not explain the output or how timezone and format affect it, leaving the agent to infer from the schema.
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 100% and the parameter descriptions are clear. The overall description adds no additional meaning beyond what the schema provides, leading to a baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets current date and time, but it does not distinguish it from sibling tools like format_date or date_to_timestamp. The purpose is clear but lacks differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidelines provided. The description does not indicate when to use this tool or mention alternatives, which is critical given the many sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get disk space information for a path.
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | Path to check disk space (default: root/current drive) | / |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears the full burden. It does not disclose error behavior, permission requirements, or output format beyond the schema. The phrase 'disk space information' is vague.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single, front-loaded sentence with no unnecessary words. Efficiently conveys 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 simplicity and presence of an output schema, the description is somewhat adequate but lacks behavioral context (e.g., error handling, permissions). For a tool with no annotations, more detail would be beneficial.
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 100% and the param 'path' has a clear description including default. The description adds little beyond what the schema provides, earning a baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets disk space information for a given path. It uses a specific verb ('Get') and resource ('disk space information'), and distinguishes itself from other get_* tools by being path-specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs alternatives. The description is minimal and does not mention prerequisites, limitations, or alternative tools for similar queries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get an environment variable value.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Name of the environment variable | |
| default | No | Default value if variable not found (default: empty string) |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only states 'Get an environment variable value.' It does not disclose potential side effects, error handling, security implications (e.g., exposing secrets), or any behavioral traits beyond the basic read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is appropriately sized and front-loaded. Every word is necessary, and there is 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?
Given the simplicity of the tool (2 parameters, high schema coverage, and an output schema), the description captures the core purpose. However, it could mention the return type or behavior when the variable is not found, though the default parameter partially addresses that.
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 100% description coverage for both parameters ('name' and 'default'). The description adds no additional meaning beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get an environment variable value.' uses a specific verb ('Get') and resource ('environment variable value'), clearly indicating what the tool does. It naturally distinguishes itself from sibling tools like 'list_env_variables' which lists all variables.
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 the name implies reading a single variable, there is no explicit context for usage or exclusion of other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about a file or directory.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Path to file or directory |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only says 'detailed information' without specifying what fields are returned (e.g., size, permissions, timestamps) or whether the operation is purely 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 with no wasted words. However, it is too brief to fully convey the tool's purpose and behavior.
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, the description does not need to detail return values, but it lacks context about what 'detailed information' entails, which is important for differentiating from other file tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the schema already describes the `path` parameter. The description adds no further meaning beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Get detailed information) and the resource (file or directory), distinguishing it from sibling tools like read_file (which reads content) and list_directory (which lists contents).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no explicit guidance on when to use this tool versus alternatives like read_file or search_files. Usage is implied but not clarified.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get HTTP headers from a URL.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | URL to get headers from | |
| timeout | No | Request timeout in seconds (default: 10) |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description does not disclose behavioral traits like redirect handling, error behavior, or read-only nature. With a simple statement, the agent cannot infer important operational details.
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. However, it could incorporate more behavioral context without being verbose. Still, it is concise and to the point.
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 presence of an output schema, the description is minimally adequate. However, in the context of many sibling tools, additional guidance would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the description adds no additional meaning beyond the schema's definitions for 'url' and 'timeout'. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get HTTP headers from a URL' clearly identifies the action and resource. While it doesn't explicitly differentiate from siblings like fetch_webpage or http_request, the name and description make its purpose evident.
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 fetch_webpage, check_url_status, or http_request. The description lacks any context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get memory (RAM) usage statistics.
Returns: JSON string containing memory usage details
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It states it returns a JSON string, which is adequate for a simple read-only tool. However, it could disclose that it requires no input or permissions, but the description is sufficient.
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?
Two sentences, zero filler. Every word adds value: states purpose and return format. Perfectly concise and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and presence of an output schema, the description is fairly complete. It explains the tool's purpose and return format. Could add detail about what memory statistics are included (e.g., free, used, total), but not 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?
No parameters exist in the input schema, so the description does not need to add parameter information. Baseline score of 4 applies as no further explanation is required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it gets memory (RAM) usage statistics and returns a JSON string. It is specific (verb 'get' + resource 'memory usage statistics') and distinguishes itself from sibling tools like get_cpu_info (CPU) or get_disk_info (disk).
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 (e.g., get_system_info for broader info). Usage is implied by the name and description, but explicit when/when-not instructions are missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get network interface information.
Returns: JSON string with network interfaces, IP addresses, and MAC addresses
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden. It discloses what is returned (JSON string with specific data) but does not mention safety, permissions, or potential side effects. Adequate for a simple read operation but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief with no unnecessary words, though the 'Returns:' format could be more integrated. Still 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?
With no parameters and an output schema present, the description adequately explains the return value. It is sufficient for 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?
There are zero parameters, so the schema already covers all inputs. Baseline 4 applies as the description does not need to add extra meaning.
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 'Get network interface information' and enumerates the returned data (network interfaces, IP addresses, MAC addresses). It is a specific verb+resource and distinct from sibling system info 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 is provided on when to use this tool versus alternatives like get_cpu_info or get_disk_info, nor any conditions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Extract all links from a webpage.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | URL of the webpage | |
| timeout | No | Request timeout in seconds (default: 10) | |
| absolute | No | Convert relative URLs to absolute (default: True) |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, and the description does not disclose any behavioral traits such as handling of large pages, failure modes, or network requirements. It is completely opaque beyond the basic purpose.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that is not wasteful. However, it could be slightly more structured with additional context without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema, the description does not need to explain return values, but it still lacks completeness regarding limitations, edge cases, and behavioral details. It is too minimal for a tool with multiple parameters and a specific task.
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 100% parameter description coverage, so the baseline is 3. The tool description adds no additional meaning beyond what the schema already provides.
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 extracts all links from a webpage, using a specific verb and resource. It distinguishes from general URL extraction but does not explicitly differentiate from sibling tools like extract_urls.
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 fetch_webpage or parse_html. There is no mention of exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Extract the title from a webpage.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | URL of the webpage | |
| timeout | No | Request timeout in seconds (default: 10) |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description does not disclose behavioral traits like timeout handling, error behavior on missing titles, or reliance on network requests. Annotations are absent, so the description fails to compensate.
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 too brief for a tool with two parameters and no annotations. It lacks necessary detail without being 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 does not cover edge cases (e.g., non-HTML pages, missing titles, redirects) or explain the extraction logic. It is not comprehensive 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 coverage is 100% with descriptions for both 'url' and 'timeout', so the description adds no additional meaning. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Extract the title from a webpage' uses a clear verb and resource, distinguishing it from sibling tools like 'get_page_source' or 'fetch_webpage_text'.
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 'fetch_webpage' or browser navigation tools. No usage context or exclusions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get information about the current process.
Returns: JSON string with process details
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries full burden. It states the tool returns a JSON string with process details, but does not disclose what details are included, whether it is safe, or what 'current process' refers to. Adequate but basic.
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 two short sentences with no unnecessary words. It front-loads the purpose and briefly explains the return value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters), the description is minimal but incomplete. It does not specify what process details are included, leaving ambiguity given sibling tools like get_cpu_info and get_memory_info. The agent may need more detail to decide between tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters and 100% coverage, so the description adds no parameter information beyond the schema. Baseline score applies.
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 retrieves information about the current process, using a specific verb and resource. However, it does not differentiate from sibling tools like get_cpu_info or get_memory_info, which may overlap.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives (e.g., get_system_info, get_cpu_info). The description lacks context about its specific role among sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get search cache and rate limiter statistics.
Returns: JSON string with cache stats, hit rate, and rate limiter info
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It does not disclose that the tool is read-only or any potential side effects. Although the name implies a read operation, the description lacks explicit 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 extremely concise: two sentences with no wasted words. The first sentence states the action, and the second details the return value. 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?
For a parameter-less stat tool, the description is fairly complete. It explains what the tool does and what it returns. However, it could mention when such stats are useful or if there are any dependencies, but given simplicity, it is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, and schema coverage is 100%. The description adds value by detailing the return type (JSON string with cache stats, hit rate, rate limiter info), which goes beyond the empty 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 'Get search cache and rate limiter statistics,' specifying the verb 'get' and the resource 'search cache and rate limiter statistics'. This distinguishes it from sibling tools like 'clear_search_cache'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, such as other stat tools like 'get_system_info'. There is no mention of context, prerequisites, or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get comprehensive system information.
Returns: JSON string containing system details
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states 'Returns: JSON string containing system details' without disclosing behavioral traits like performance impact, permission requirements, or what constitutes 'system information'. This is minimal transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences, no redundant information, and the key action is front-loaded. Every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and the existence of an output schema, the description provides complete context. The only missing detail (what 'system information' specifically includes) is covered by the output schema, so no additional explanation 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 tool has zero parameters, so schema coverage is trivially 100%. The description adds 'JSON string containing system details', which provides some context about the return format beyond the schema, but since an output schema exists, this is incremental. Baseline of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The name 'get_system_info' and description 'Get comprehensive system information' clearly state the tool's purpose with a specific verb and resource. It is distinct from sibling tools like get_cpu_info, get_disk_info, etc., which are more specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use guidance is provided. While the tool's broad purpose is implied, the description does not mention alternatives (e.g., specific info tools) or context, leaving the agent to infer usage without direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Make HTTP request with custom headers and body.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Target URL | |
| method | No | HTTP method (GET, POST, PUT, DELETE, PATCH) | GET |
| headers | No | JSON string of headers | {} |
| body | No | Request body (for POST/PUT/PATCH) | |
| timeout | No | Request timeout in seconds (default: 10) |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must disclose behavioral traits. It doesn't mention error handling, idempotency, data size limits, or authentication needs. The description only covers basic functionality.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, concise, no fluff. 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?
Despite having an output schema (not shown), the description doesn't mention return values or behavior on errors. For a tool with 5 parameters, it lacks completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents all parameters. The description adds 'custom headers and body,' which is repetitive. With high coverage, baseline is 3.
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 makes HTTP requests with custom headers and body. It uses a specific verb and resource, distinct from sibling tools like fetch_webpage. However, it doesn't mention return values like status code or response body.
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., fetch_webpage, check_url_status). It doesn't specify prerequisites, limitations, 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.
Extract value from JSON using dot notation path.
| Name | Required | Description | Default |
|---|---|---|---|
| json_string | Yes | JSON string to query | |
| path | Yes | Dot-separated path (e.g., "user.name" or "items.0.title") |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description does not disclose error handling (e.g., invalid JSON, missing path), return format, or side effects. With no annotations, the description carries full burden but provides minimal insight into tool behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. However, it could be slightly expanded to cover basic usage constraints without harming conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description does not mention return values, error cases, or path resolution behavior. For a simple tool, this level of completeness is insufficient for reliable 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?
Schema description coverage is 100%, so the schema already fully documents both parameters. The description adds no additional meaning beyond restating 'dot notation 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 action (extract value), the resource (JSON), and the method (dot notation path). It effectively distinguishes from sibling tools like parse_json or flatten_json.
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 parse_json (which returns the entire parsed object) or other JSON manipulation tools. The description lacks context for choosing between them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Convert JSON array to CSV format.
| Name | Required | Description | Default |
|---|---|---|---|
| json_string | Yes | JSON string (must be array of objects) |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description provides no behavioral details beyond the verb 'convert'. With no annotations, it fails to disclose what happens with invalid input, nested objects, or key mismatches. The input schema partially covers input validation, but the description adds no safety or side-effect 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 sentence with no waste. However, it could be slightly expanded to include input constraints or output details 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 existence of an output schema, the description might rely on that for return format. Still, it lacks contextual details like error handling, supported CSV dialect, or behavior with huge arrays. The description is too minimal for a complete understanding.
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 100% for the single parameter. The description 'Convert JSON array to CSV format' does not add extra meaning beyond the schema's 'JSON string (must be array of objects)'. Baseline score of 3 applies.
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), the input (JSON array), and the output (CSV format). It effectively distinguishes from sibling tools like csv_to_json or json_to_yaml.
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. For instance, it does not mention that the input must be a JSON array of objects, nor does it suggest other tools for different JSON structures.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Convert JSON to YAML format.
| Name | Required | Description | Default |
|---|---|---|---|
| json_string | Yes | JSON string to convert |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but the description does not disclose behavior on invalid input, output format, or error handling. It merely states the conversion action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Very concise single sentence, front-loaded with essential info. Slightly too terse, but 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?
For a simple one-param conversion tool with an output schema, the description suffices minimally, but lacks details on edge cases or output structure.
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 100% (one parameter well-described), so baseline 3 is appropriate. The description does not add additional semantics beyond the schema's 'JSON string to convert'.
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 'Convert' and the resource 'JSON to YAML format', making it specific and distinguishable from siblings like yaml_to_json or csv_to_json.
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., for other format conversions), nor any conditions or prerequisites like input validity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List contents of an archive file without extracting.
| Name | Required | Description | Default |
|---|---|---|---|
| archive_path | Yes | Path to archive file (ZIP, TAR, TAR.GZ, TAR.BZ2) |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It states 'without extracting,' indicating no destructive side effects. However, no details on output format or potential limitations (e.g., large archives, password-protected files) are given. Adequate for a simple read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (9 words) and front-loaded. Every word serves a purpose, with no fluff. It efficiently conveys the core functionality.
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, and the presence of an output schema, the description is complete. It covers the essential behavior and parameter details. No additional context is necessary.
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 single parameter 'archive_path' is fully described in the input schema with supported formats. The description adds no extra semantic value beyond the schema. With 100% schema coverage, a score of 3 is appropriate as per guidelines.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists archive contents without extracting. The verb 'List' and resource 'contents of an archive file' are specific, and it distinguishes from sibling extract tools like extract_zip and extract_tar.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for viewing contents without extraction, but lacks explicit guidance on when to use vs alternatives like extract_zip. It does not mention exclusions or prerequisites, so guidance is merely implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List contents of a directory.
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | Directory path (default: current directory) | . |
| pattern | No | Glob pattern to filter files (default: * for all files) | * |
| recursive | No | Search recursively in subdirectories (default: False) |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only restates the tool's name. No disclosure of whether hidden files are listed, sorting order, or other behavioral details. The description adds minimal value beyond the title.
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 fluff. Efficient but could be slightly more informative. It earns its place but lacks context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that the tool has three parameters (path, pattern, recursive) and an output schema exists, the description is too sparse. It does not explain return format, filtering behavior, or edge cases. Users may not know basic behaviors like pattern matching or recursive listing.
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 100%, so baseline is 3. The description adds no new meaning beyond what is already in the parameter descriptions. It is adequate but does not enhance understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List contents of a directory' clearly states the action (list) and the resource (directory contents). It is specific and not a tautology. However, it does not explicitly differentiate from sibling tools like search_files or read_file, but the action is distinct enough.
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 search_files or read_file. No mention of when not to use it or any prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all environment variables.
| Name | Required | Description | Default |
|---|---|---|---|
| filter_pattern | No | Optional substring to filter variable names (case-insensitive) |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral burden. It states the tool lists all environment variables but does not disclose any side effects, limitations, or details about the output format. The read-only nature is implied but not explicitly stated.
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. It is concise but could benefit from a brief mention of the filter parameter or output format 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 and a single optional parameter, the description is minimally adequate. However, it lacks contextual information such as performance implications or that it returns all variables, which would be helpful for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single parameter filter_pattern, which is already described as an optional substring filter. The tool description adds no additional semantic 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 "List all environment variables" clearly states the action (list) and the resource (environment variables). It effectively distinguishes the tool from siblings like get_env_variable, which retrieves a single variable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like get_env_variable. The description does not mention the optional filter parameter or scenarios where filtering might be useful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Merge two JSON objects.
| Name | Required | Description | Default |
|---|---|---|---|
| json_string1 | Yes | First JSON string | |
| json_string2 | Yes | Second JSON string (takes precedence) | |
| deep | No | Deep merge nested objects (default: True) |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should fully disclose behavior. It only says 'Merge' without specifying merge strategy (shallow vs deep) or that the second object takes precedence. The input schema partially fills this gap, but the description does not convey these details.
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. It efficiently conveys the core action, earning its place 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 availability of an output schema and full parameter descriptions in the input schema, the description is partially complete. However, it omits critical details like the precedence of the second JSON object and the default deep merge behavior, which are important 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 100%, so the baseline is 3. The description adds no extra meaning beyond what the schema already provides for parameters like 'deep' and 'json_string2'.
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 'Merge' and resource 'JSON objects', making the tool's purpose immediately understandable. However, it does not differentiate from sibling tools like 'flatten_json' or 'json_query', though the name itself is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, such as 'json_query' for JSON manipulation or 'validate_json_schema' for validation. The description lacks context about appropriate use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Parse CSV data and return as JSON.
| Name | Required | Description | Default |
|---|---|---|---|
| csv_string | Yes | CSV string to parse | |
| delimiter | No | CSV delimiter (default: ,) | , |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only states parsing and JSON output, omitting details like header handling, error behavior, or output structure. The presence of an output schema is not leveraged in the description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence, concise and without redundancy. It earns its place but could be slightly more structured with additional context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity (2 parameters, output schema exists), the description is minimally adequate. However, it lacks information on output format, error handling, and encoding, which would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the input schema already documents both parameters. The description adds no extra meaning, examples, or constraints beyond what is in 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 'Parse CSV data and return as JSON' clearly states the verb, resource, and output format. However, it does not distinguish itself from the sibling tool 'csv_to_json', which likely has an identical 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?
No guidance is provided on when to use this tool vs alternatives like 'csv_to_json'. There is no mention of prerequisites, restrictions, or usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Parse HTML and extract elements using CSS selector.
| Name | Required | Description | Default |
|---|---|---|---|
| html | Yes | HTML content to parse | |
| selector | Yes | CSS selector to find elements |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden for behavioral disclosure. It does not mention error behavior (e.g., invalid CSS, malformed HTML), output format, or any side effects. Minimal context is given.
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, a single sentence that front-loads the purpose. It wastes no words, though it could be slightly more informative without losing brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with an output schema, the description is minimally adequate. It does not explain the return structure or edge cases, but given low complexity, it meets basic needs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents both parameters. The description adds no extra meaning beyond restating the parameter purpose; baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (parse/extract), resource (HTML), and method (CSS selector). It distinguishes from sibling tools like parse_csv or parse_json, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied: use when you need to extract elements from HTML via CSS selectors. However, no explicit guidance on when not to use it or alternatives (e.g., fetch_webpage for fetching, browser_get_text for visible text) is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Parse and validate a JSON string.
| Name | Required | Description | Default |
|---|---|---|---|
| json_string | Yes | JSON string to parse |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It states the tool parses and validates, but doesn't disclose what happens on invalid JSON (e.g., error thrown), return format, or side effects. This is insufficient for safe 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 5-word sentence, highly concise. While it lacks some detail, it is efficient and to the point. A score of 4 reflects that it is well-structured but could include a bit more 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 one-parameter schema and the existence of an output schema (not shown), the description is minimally adequate. However, it does not explain the return value, validation behavior, or distinguish from similar siblings, making it somewhat incomplete for complex scenarios.
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 100% description coverage, fully documenting the single parameter 'json_string'. The tool description adds no additional semantic value beyond what the schema provides, resulting in a baseline score of 3.
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 'Parse and validate a JSON string' clearly states the verb (parse/validate) and the resource (JSON string). It effectively distinguishes this tool from siblings like format_json, json_query, and validate_json_schema, which have different purposes.
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 json_query or validate_json_schema. It lacks explicit context for selection, leaving the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Parse TOML configuration file to JSON.
| Name | Required | Description | Default |
|---|---|---|---|
| toml_string | Yes | TOML string to parse |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral traits, but it only states the conversion. It does not describe error handling, edge cases, or whether the tool modifies any state (it likely does not, 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?
The description is a single, front-loaded sentence that conveys the essential purpose without any wasted words. It is appropriately concise for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, the description provides the core purpose. However, it lacks context on expected input format, output structure (despite an output schema existing), and error scenarios. It is minimally complete but could be more informative.
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 100% description coverage, so the schema already documents the 'toml_string' parameter. The description adds no additional meaning beyond what the schema provides, fitting the baseline of 3.
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 parses TOML to JSON, using a specific verb and resource. However, it does not distinguish itself from the sibling 'toml_to_json' tool, which likely has similar functionality.
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 over alternatives like 'toml_to_json' or other parsing tools. There are no usage conditions or exclusions mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Parse a URL and extract its components.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | URL to parse |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; the description fails to disclose what components are extracted, how invalid URLs are handled, or the output format. Although an output schema exists, the description does not mention behavior beyond 'parse'.
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 efficient sentence with no wasted words. Clearly front-loaded with the action and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Minimally adequate for a simple parse tool with an output schema. Lacks usage guidance and behavioral details but covers the core purpose.
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 100% with a clear 'url' description. The description adds minimal extra meaning beyond the schema, achieving baseline score for a single-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Parse a URL and extract its components' clearly states the verb (parse) and resource (URL). It distinguishes itself from sibling parse tools (parse_csv, parse_html, etc.) by being URL-specific.
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 like validate_url_format or check_url_status. The description lacks context about when parsing is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Parse YAML string to JSON.
| Name | Required | Description | Default |
|---|---|---|---|
| yaml_string | Yes | YAML string to parse |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It does not disclose error handling, supported YAML features, or output format details beyond the name. This is acceptable for a simple transformation but lacks depth.
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 core purpose. However, it could include a bit more context without becoming verbose, such as error behavior or output format note.
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 low complexity and an existing output schema, so the description does not need to explain return values. The brief description is sufficient for basic understanding, though it could benefit from noting supported YAML versions.
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 single parameter 'yaml_string' is described in the schema as 'YAML string to parse'. Since schema coverage is 100%, the description adds no additional meaning beyond what the schema already provides, meeting the baseline.
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: parsing YAML strings to JSON. It uses a specific verb and resource, distinguishing it from sibling parse tools like parse_csv, parse_html, and parse_json.
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 over alternatives. While the purpose is clear, there is no mention of prerequisites, limitations, or when not to use it. The context is implied but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read the contents of a file.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Path to the file to read | |
| encoding | No | File encoding (default: utf-8) | utf-8 |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must fully disclose behavior. Only states 'Read the contents', missing details like file existence handling, encoding effects, return format, or file size 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 very concise, but lacks structured information like parameter explanations or usage notes. Could use slight expansion while remaining 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?
Despite an output schema existing (per context), the description fails to explain what the tool returns or how encoding parameters affect output. Incomplete for a simple read operation.
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 100%, so baseline is 3. Description adds no extra meaning beyond the schema descriptions for 'path' and 'encoding'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Read the contents of a file' with a specific verb and resource. This distinctively separates it from sibling tools like write_file, delete_file, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., for reading vs. searching files, reading text vs. binary). The description provides no context for appropriate use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find all matches of a regular expression in text.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | Text to search | |
| pattern | Yes | Regular expression pattern | |
| flags | No | Regex flags (i=ignorecase, m=multiline, s=dotall) |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description does not disclose what 'all matches' returns (e.g., array of strings, objects with indices). With no annotations, the description carries full burden but only states the action, not the output format or edge-case behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The single sentence is very concise and front-loaded. However, it may be too sparse, lacking additional details that could help without harming conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (as per context signals), the description might be sufficient if the schema documents the return format. However, the description itself does not mention what a 'match' consists of, leaving some ambiguity.
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 100%, with clear descriptions for each parameter (e.g., 'pattern' is self-explanatory). The description adds no extra meaning beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: finding all matches of a regular expression in text. It uses a specific verb 'Find' and resource 'all matches of a regular expression in text', distinguishing it from siblings like regex_replace.
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 vs alternatives such as regex_replace or extract_emails. The description lacks context on prerequisites or suitable scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Replace text matching a regular expression.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | Text to process | |
| pattern | Yes | Regular expression pattern to match | |
| replacement | Yes | Replacement string | |
| flags | No | Regex flags (i=ignorecase, m=multiline, s=dotall) |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as whether the operation is destructive, any side effects, or input/output limitations. It only states what it does without additional context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short sentence, which is extremely concise. However, it could benefit from a bit more detail without becoming verbose. Still, it is efficient and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there is an output schema (context indicates 'Has output schema: true'), the description does not need to explain return values. The tool is simple and the description covers the core functionality sufficiently.
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 100% description coverage, so the schema already documents each parameter. The description adds no extra meaning beyond the schema, which is adequate but not improved upon.
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 replaces text using a regular expression. It specifies a specific verb ('Replace') and resource ('text matching a regular expression'), and it distinguishes itself from similar siblings like 'regex_match' which likely only matches without replacing.
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 'regex_match' or other text manipulation tools. The context siblings include 'regex_match', but the description does not mention when to choose this one over others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for files in a directory.
| Name | Required | Description | Default |
|---|---|---|---|
| directory | No | Directory to search in (default: current directory) | . |
| pattern | No | Glob pattern (default: *) | * |
| name_contains | No | Optional string that filename must contain |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It only mentions searching without details on read-only nature, caching (implied by sibling 'clear_search_cache'), error handling, or return format. This is insufficient for a mutation-ambiguous 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, complete sentence with no wasted words. It is front-loaded and efficiently states 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?
Given the existence of an output schema and many sibling tools, the description lacks crucial context such as what the search returns (e.g., file paths, metadata) and how it relates to other file operations. It is incomplete for an agent to fully understand the tool's role.
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 100% description coverage, so the baseline is 3. The tool description adds no extra meaning beyond the schema; it merely restates the action.
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 searches for files in a directory, which is a specific verb and resource. However, it does not differentiate from sibling tools like 'list_directory' that also list files, though 'search_files' implies pattern matching.
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 vs alternatives. For instance, it doesn't explain why one would use 'search_files' over 'list_directory' or when to choose different patterns.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Call an external AI model to handle a subtask.
Supports OpenAI and Anthropic APIs with custom endpoint configuration. Returns response with token usage statistics.
| Name | Required | Description | Default |
|---|---|---|---|
| provider | Yes | AI provider - "openai" or "anthropic" | |
| model | Yes | Model name (e.g., "gpt-4", "claude-3-5-sonnet-20241022", or any custom model) | |
| messages | Yes | JSON string of message list [{"role": "user", "content": "..."}] | |
| max_tokens | No | Maximum tokens to generate (optional, max 32000) | |
| temperature | No | Temperature parameter 0.0-2.0 (default: 0.7) |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description lacks details on side effects (e.g., API calls, latency, costs, error handling) that are critical for a tool making external network calls.
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?
Two sentences with efficient front-loading: core purpose first, then supported APIs and return value. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex tool making external API calls, the description is incomplete. It omits details on authentication, endpoints, error handling, rate limits, and cost implications, which are essential for safe and correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds minimal extra meaning (e.g., supported providers, token usage return) but also introduces an inconsistency by mentioning 'custom endpoint configuration' without a corresponding parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Call'), the resource ('external AI model'), and the context ('handle a subtask'), distinguishing it from sibling tools like subagent_config_set or subagent_conditional.
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., subagent_parallel, subagent_conditional). It only states the basic purpose, leaving the agent without decision-making support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute conditional branching based on AI decision.
First calls AI to evaluate a condition, then executes either true_task or false_task based on the decision. Useful for dynamic workflow control.
| Name | Required | Description | Default |
|---|---|---|---|
| condition_task | Yes | JSON string of task to evaluate condition {provider, model, messages} AI should return "true" or "false" in response | |
| true_task | Yes | JSON string of task to execute if condition is true | |
| false_task | Yes | JSON string of task to execute if condition is false |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description outlines the basic behavior: calling AI to evaluate a condition and branching accordingly. It lacks details on error handling, what happens if the AI response is not 'true'/'false', or any side effects. With no annotations, the description carries the burden but provides only minimal behavioral disclosure.
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, consisting of only two sentences plus a short usage note. No extraneous information. Every sentence serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a conditional branching tool, the description is somewhat complete but misses details like error scenarios, what happens if the AI fails to respond, or the structure of the output. An output schema exists but is not described, so the description could be more helpful.
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 100%, so the baseline is 3. The tool description does not significantly add meaning beyond what the parameter descriptions already provide (e.g., it repeats the JSON task format). The description adds no new semantic context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Execute conditional branching based on AI decision' and explains the process of evaluating a condition and executing one of two tasks. The name 'subagent_conditional' and the explanation distinguish it from sibling tools like subagent_call and subagent_parallel.
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 mentions 'Useful for dynamic workflow control,' which gives general context. However, it does not explicitly state when to use this tool over alternatives, nor does it provide when-not-to-use guidance. Usage is implied but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
่ทๅๆๅฎๆไพๅ็ API ้ ็ฝฎไฟกๆฏ
| Name | Required | Description | Default |
|---|---|---|---|
| provider | Yes | ๆไพๅๅ็งฐ๏ผๆฏๆ: "openai", "anthropic" |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It only states the basic purpose without disclosing behavioral traits such as read-only nature, authentication requirements, 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?
Single short sentence with clear, front-loaded information; no extraneous 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 simplicity, the description along with output schema provides sufficient context for a one-parameter tool. Missing some usage context but adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already covers the parameter with 100% coverage, and the description does not add new meaning beyond what is in the schema description.
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 action (่ทๅ/get) and resource (API้ ็ฝฎไฟกๆฏ/API configuration info) for a specified provider, effectively distinguishing from siblings like subagent_config_list and subagent_config_set.
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 retrieving a specific provider's API configuration, and the sibling context provides clarity, but no explicit when-not-to-use or alternative guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ๅๅบๆๆๅทฒ้ ็ฝฎ็ AI ๆไพๅ
่ฟๅๆๆ้ ็ฝฎ็ๆไพๅๅๅ ถ็ถๆ๏ผๅ ๆฌๅฏ้ฅ้ข่งๅ้ ็ฝฎๆฅๆบใ
Returns: JSON ๆ ผๅผ็ๆไพๅๅ่กจ
Example: providers = subagent_config_list()
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It clearly states that the tool returns a list of providers with status, key preview, and source. It does not mention side effects or permissions, but for a read-only listing, this is adequate.
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, with only essential information: purpose, return format, and an example. It is well-structured with a clear separation between description, returns, and example.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and an output schema exists, the description provides sufficient context. It explains what the tool does and what it returns, making it complete for a simple listing operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, and the input schema has 100% description coverage. Per the guidelines, the baseline score is 4, as the description does not need to add parameter semantics when none exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: listing all configured AI providers. It also specifies the return details (status, key preview, source), which distinguishes it from sibling tools like subagent_config_get (which retrieves a specific provider) and subagent_config_set (which modifies 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 does not explicitly provide usage guidelines, such as when to use this tool versus alternatives or when not to use it. However, the purpose is implied by the name and description, so an agent might infer that it's for getting a complete list, but explicit guidance is absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
่ฎพ็ฝฎ Subagent ๆไพๅ็ API ้ ็ฝฎ๏ผๆไน ๅไฟๅญ๏ผ
ๆญคๅทฅๅ ทๅฐ API ๅฏ้ฅๅๅบ็ก URL ไฟๅญๅฐ้ ็ฝฎๆไปถไธญ๏ผไธๆฌกๅฏๅจๆถ่ชๅจๅ ่ฝฝใ ้ ็ฝฎๆไปถไฝ็ฝฎ๏ผ~/.subagent_config.json
| Name | Required | Description | Default |
|---|---|---|---|
| provider | Yes | ๆไพๅๅ็งฐ๏ผๆฏๆ: "openai", "anthropic" | |
| api_key | Yes | API ๅฏ้ฅ | |
| api_base | No | API ๅบ็ก URL๏ผๅฏ้๏ผ |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that configuration is saved persistently to a specific file (~/.subagent_config.json) and auto-loaded on restart. This is sufficient behavioral information for a config-set tool, given no annotations are provided. However, it does not mention overwrite behavior or security implications.
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?
Two short sentences in Chinese concisely convey purpose, persistence, and file location. Every word earns its place; 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 the tool's simplicity (3 params, no complex behavior) and the existence of an output schema, the description adequately explains the core action and persistence aspect. It could mention return values or error cases, but these are likely covered by the output schema.
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 already provides full descriptions for all three parameters (100% coverage). The description confirms that api_key and api_base are saved but adds no new semantic details beyond the schema. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sets Subagent provider API configuration and saves it persistently. The verb 'set' and resource 'Subagent provider API configuration' are specific. However, it does not explicitly differentiate from sibling tools like subagent_config_get or subagent_config_list, relying on the name alone.
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 is no mention of prerequisites, when to avoid using it, or comparison to related tools such as subagent_config_get.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute multiple AI subtasks in parallel with result aggregation.
Coordinates concurrent calls to different AI models and aggregates results. Useful for breaking complex problems into independent subtasks.
| Name | Required | Description | Default |
|---|---|---|---|
| tasks | Yes | JSON string of task list. Each task: {provider, model, messages, max_tokens?, temperature?, name?} | |
| max_workers | No | Maximum concurrent tasks (default: 3, max: 10) |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses coordination of concurrent calls and result aggregation, which are key behaviors. However, it does not mention error handling, rate limits, or task independence beyond paras. The minimal disclosure earns a 3.
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?
Two concise sentences, front-loaded with the core action. Every sentence adds value without redundancy. Ideal structure for quick comprehension.
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 (reducing return-value explanation burden) and schema coverage, the description covers parallelism and aggregation adequately. It lacks details on ordering or task independence, but for a coordination tool, it is sufficient. Score 4.
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 100%, so baseline is 3. The description adds minimal extra meaning: it mentions 'different AI models' which aligns with the provider/model in tasks. No further semantic detail beyond schema, so score 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: executing multiple AI subtasks in parallel and aggregating results. It uses a specific verb ('Execute') and resource ('multiple AI subtasks'), and distinguishes itself from sibling tools like subagent_call (single call) and subagent_conditional (conditional) by emphasizing parallelism and aggregation.
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 usage context: 'useful for breaking complex problems into independent subtasks.' This implies when to use it, but does not explicitly state when not to use it or compare it to alternatives like subagent_call. Since siblings exist, it would benefit from direct differentiation, but the given context is adequate for a 4.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Summarize or truncate text to a maximum length.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | Text to summarize | |
| max_length | No | Maximum length (default: 500) | |
| method | No | Method to use - 'truncate' or 'sentences' (default: truncate) | truncate |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for behavioral disclosure. It merely states the tool can summarize or truncate, without explaining how summarization works (e.g., extractive vs. abstractive) or what 'truncate' means in terms of character cutoff. The schema's method parameter adds some detail, but the description adds little transparency 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 sentence, very concise and front-loaded with the core purpose. It avoids unnecessary words. While it could include more detail without harming conciseness, it is efficient for a simple tool and scores well on 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 tool has an output schema (which need not be described) and 3 parameters with clear schema descriptions, the description is minimally adequate. However, it lacks details about how the 'sentences' method selects sentences (e.g., based on importance, length limits) and whether summarization is context-aware. The schema covers param syntax, but the description does not fill behavioral gaps, making it moderately 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 100%, so the baseline is 3. The description adds that the tool works on text to a maximum length, which reinforces the schema's parameter descriptions but does not add significant new meaning. The description does not explain the difference between 'truncate' and 'sentences' methods beyond what the schema already provides.
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 does 'summarize or truncate text to a maximum length.' It specifies the verb (summarize/truncate) and the resource (text), and it distinguishes from sibling tools like count_words or calculate_text_similarity, which perform different text 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?
The description does not provide any guidance on when to use this tool versus alternatives. It does not mention scenarios where summarization is preferred over truncation, nor does it refer to other tools that could be used instead. The agent receives no context for selecting this tool appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Convert Unix timestamp to readable date.
| Name | Required | Description | Default |
|---|---|---|---|
| timestamp | Yes | Unix timestamp (seconds since epoch) | |
| format | No | Output format - 'iso', 'readable', or custom strftime format (default: iso) | iso |
| timezone | No | 'local' or 'utc' (default: local) | local |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It lacks disclosure of timezone behavior (defaults to local), format handling (default iso, custom strftime), or behavior on invalid input. The output schema exists but the description omits any 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, front-loaded sentence with no wasted words. It is efficient but could benefit from a bit more detail on 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?
For a simple conversion tool with good schema and output schema, the description is minimally complete. However, it lacks guidance on timezone and format behavior, and does not explicitly state that the output is a date string.
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 100% with each parameter having a description. The description adds no additional meaning beyond what the schema already provides. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Convert Unix timestamp') and the result ('readable date'). It distinguishes from sibling tools like 'date_to_timestamp' and 'format_date'.
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 (e.g., format_date, get_current_time). The description does not mention use cases or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Convert TOML to formatted JSON.
| Name | Required | Description | Default |
|---|---|---|---|
| toml_string | Yes | TOML string to convert | |
| indent | No | JSON indentation level (default: 2) |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavior like error handling on invalid TOML, output format (JSON string vs object), or size constraints. It only says 'formatted JSON' without specifying the output structure or behavior on malformed input.
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 immediately conveys the tool's purpose. It is front-loaded and contains no unnecessary words, though it could be slightly expanded for clarity on 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?
Given the presence of an output schema (context indicates it exists), the description does not need to detail return values. However, it lacks any behavioral context such as error handling or performance considerations, making it minimally complete for a conversion tool with no annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds no extra meaning beyond the parameter descriptions already in the schema. The parameter names and descriptions in the schema are self-explanatory, but the tool description does not elaborate on constraints or usage tips.
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 'Convert TOML to formatted JSON' clearly states the action (convert) and the resource (TOML to JSON). It differentiates the tool from siblings like csv_to_json or yaml_to_json by specifying the exact format conversion.
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 parse_toml or other conversion tools. There is no mention of prerequisites, limitations, or scenarios where this tool is preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Validate JSON syntax and structure.
| Name | Required | Description | Default |
|---|---|---|---|
| json_string | Yes | JSON string to validate |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations present, so description carries full burden. It doesn't clarify what 'structure' means or that it likely only checks JSON validity, not against a schema. Ambiguous about what 'validate' entails.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One short sentence with no wasted words. However, it is too brief and could benefit from additional context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lacks any information about the output (e.g., boolean, error details) despite having an output schema. It doesn't address the tool's behavior on success/failure or clarify the scope of 'structure validation'.
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 100% for the single parameter. The description adds 'JSON string to validate', which is adequate but not insightful beyond the schema. Baseline 3 applies.
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 'Validate JSON syntax and structure' clearly indicates the tool validates JSON, but the name suggests schema validation without a schema parameter, causing 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 like parse_json or json_query. No when-not-to-use or context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Validate if a string is a properly formatted URL.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | URL string to validate |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must carry behavioral info. It states validation of URL formatting but lacks details on what constitutes proper formatting or output type (though output schema likely covers return).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no redundancy, 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?
Given a single parameter and existence of output schema, description adequately captures core functionality. Minor omission of explanation for valid URL criteria, but overall sufficient.
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 100% with parameter description 'URL string to validate'. Description adds no extra meaning beyond schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verb 'Validate' and resource 'URL format'. It clearly distinguishes from siblings like check_url_status (checks reachability) and parse_url_components (parses URL parts).
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. Usage is implied: for checking URL format validity. No mention of alternatives, which is acceptable given simplicity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the web using multiple search engines withๆบ่ฝ fallback.
Features:
Automatic fallback between search engines (DuckDuckGo -> Bing)
Intelligent caching to reduce API calls
Rate limiting protection
Result deduplication
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query string | |
| max_results | No | Maximum number of results to return (default: 10, max: 20) |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Given no annotations, the description discloses key behaviors: automatic fallback (DuckDuckGo -> Bing), caching, rate limiting, deduplication. This adds meaningful context for an agent, though error handling or pagination is not mentioned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise: one sentence with a verb and resource, followed by a bullet list of features. Every sentence adds value, and the key information is 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?
For a simple tool with output schema present, the description covers core behaviors (fallback, caching, rate limits). It lacks guidance on use cases or output format, but overall is fairly 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 coverage is 100%, so baseline is 3. The description does not add meaning beyond the schema; it does not elaborate on query format or max_results 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?
Description clearly states 'Search the web' as the action and resource, and lists features like fallback and caching. It does not explicitly differentiate from sibling tools like web_search_advanced or web_search_news, but the purpose is clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives such as web_search_advanced (for advanced options) or web_search_news (for news). The description lists features but does not provide when/when-not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Advanced web search with multi-engine support and parallel searching.
Features:
Support for multiple search engines: DuckDuckGo, Bing, Google, Baidu
Parallel searching across multiple engines
Intelligent result merging and deduplication
Smart caching mechanism
Rate limiting protection
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query string | |
| max_results | No | Maximum number of results (default: 10, max: 50) | |
| engines | No | Comma-separated list of engines (default: "duckduckgo,bing") Available: duckduckgo, bing, google, baidu | duckduckgo,bing |
| parallel | No | Search engines in parallel (default: False) | |
| use_cache | No | Use cached results if available (default: True) |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Mentions caching and rate limiting but does not detail error handling, fallback behavior, or result structure beyond features list.
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?
Brief, front-loaded with a clear header and bullet list. Every sentence adds 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 tool's complexity and presence of output schema, description covers core features adequately. Missing some behavioral details but overall sufficient for understanding.
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 100%, so parameters are well-documented in schema. Description does not add significant extra semantics beyond naming the parameters in context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it is an advanced web search with multi-engine support and parallel searching. Distinguishes from sibling tools like 'web_search' by emphasizing advanced features.
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 like 'web_search' or 'web_search_news'. The description implies usage through feature listing but lacks direct context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for news articles using multiple search engines with fallback.
Features:
Automatic fallback between news search engines
Intelligent caching
Rate limiting protection
Result deduplication
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query string | |
| max_results | No | Maximum number of results to return (default: 10, max: 20) |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description effectively discloses key behaviors: automatic fallback between engines, intelligent caching, rate limiting protection, and result deduplication. These are important for the agent's decision-making, though it doesn't confirm read-only nature.
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: a single sentence followed by a bullet list. It front-loads the main action and presents features efficiently without extraneous text.
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 (2 params, output schema exists), the description covers purpose and key features. It could mention something about return format or limitations, but the output schema likely handles that, making it reasonably 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 covers both parameters (query and max_results) fully (100% description coverage). The description adds no additional meaning beyond what's in the schema, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Search for news articles' which is a specific verb and resource. It distinguishes from sibling tools like 'web_search' and 'web_search_advanced' by focusing on news articles, making its purpose clear.
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 news searches and lists beneficial features like fallback and caching, but does not explicitly state when to use versus alternatives or exclude certain scenarios. The agent can infer it's for news, but lacks explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Write content to a file.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Path to the file to write | |
| content | Yes | Content to write to the file | |
| encoding | No | File encoding (default: utf-8) | utf-8 |
| overwrite | No | Whether to overwrite if file exists (default: True) |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It fails to disclose critical behaviors such as the default overwrite behavior (overwrite=true, which is destructive) or encoding handling, leaving safety implications unclear.
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 (5 words) and efficiently conveys the core function without extraneous information. It is concise but not excessively under-specified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema and full parameter documentation, the description lacks context about overwrite behavior, encoding defaults, and the tool's distinction from append_file. It is insufficient for safe use without additional knowledge.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% coverage, so baseline is 3. The description adds no additional meaning beyond the schema; it does not mention path, content, encoding, or overwrite parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Write content to a file' clearly states the tool's function with a verb and resource. However, it does not differentiate from sibling tools like 'append_file', which also writes content but appends instead of overwriting.
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 'append_file' or 'copy_file'. There is no mention of prerequisites, exclusions, or preferred usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Convert XML to JSON format.
| Name | Required | Description | Default |
|---|---|---|---|
| xml_string | Yes | XML string to convert |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description does not disclose any behavioral traits such as error handling, namespace handling, encoding, or potential side effects. With no annotations, the description should carry this burden.
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 wasted words. But may be too terse for a conversion tool. Still concise and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool and existence of output schema, the description minimally suffices. However, it lacks context on return format, error cases, or any special behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the single parameter xml_string is described in the schema. The description adds no additional meaning beyond the schema, so baseline score of 3 applies.
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 converts XML to JSON format. However, it does not differentiate from sibling conversion tools like csv_to_json or yaml_to_json, leaving the agent to infer based on the name alone.
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 csv_to_json or json_to_yaml. There is no mention of prerequisites, limitations, 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.
Convert YAML to formatted JSON.
| Name | Required | Description | Default |
|---|---|---|---|
| yaml_string | Yes | YAML string to convert | |
| indent | No | JSON indentation level (default: 2) |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states 'convert' without disclosing any error handling, validation behavior, or side effects. For a pure conversion tool, this is minimal but lacks depth.
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 at five words, front-loaded with the action. Every word earns its place, though it could benefit from slightly more context for a 1-5 scale.
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 low complexity, the presence of an output schema (not shown), and complete parameter documentation, the description is adequate but lacks details on error handling or return format specifics.
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 100% with descriptions for both parameters (yaml_string and indent). The description adds no extra meaning beyond what the schema already provides, earning the baseline score of 3.
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 'Convert YAML to formatted JSON' uses a specific verb (Convert) and resource (YAML to JSON), clearly differentiating it from siblings like json_to_yaml or csv_to_json.
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 as a direct conversion tool but provides no explicit guidance on when to use it versus alternatives, leaving the agent to infer from the tool name and sibling context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0append_filebrowser_backbrowser_clickbrowser_closebrowser_close_tabbrowser_config_getbrowser_config_resetbrowser_config_setbrowser_delete_cookiesbrowser_enable_network_logbrowser_execute_jsbrowser_fill_formbrowser_find_elementsbrowser_forwardbrowser_get_console_logsbrowser_get_cookiesbrowser_get_element_attributebrowser_get_network_logsbrowser_get_page_sourcebrowser_get_textbrowser_get_urlbrowser_list_sessionsbrowser_list_tabsbrowser_navigatebrowser_new_tabbrowser_openbrowser_refreshbrowser_screenshotbrowser_scrollbrowser_selectbrowser_set_cookiebrowser_switch_tabbrowser_typebrowser_wait_forcalculate_date_diffcalculate_expressioncalculate_text_similaritycheck_password_strengthcheck_url_statusclear_search_cachecompress_tarcompress_zipcopy_filecount_wordscreate_directorycsv_to_jsondate_to_timestampdecode_base64delete_filediff_filesdiff_textdns_lookupdownload_fileencode_base64extract_emailsextract_tarextract_urlsextract_zipfetch_webpagefetch_webpage_textfile_existsflatten_jsonformat_dateformat_jsongenerate_hashgenerate_passwordgenerate_random_stringgenerate_uuidget_cpu_infoget_current_timeget_disk_infoget_env_variableget_file_infoget_headersget_memory_infoget_network_infoget_page_linksget_page_titleget_process_infoget_search_statsget_system_infohttp_requestjson_queryjson_to_csvjson_to_yamllist_archive_contentslist_directorylist_env_variablesmerge_jsonparse_csvparse_htmlparse_jsonparse_tomlparse_url_componentsparse_yamlread_fileregex_matchregex_replacesearch_filessubagent_callsubagent_conditionalsubagent_config_getsubagent_config_listsubagent_config_setsubagent_paralleltext_summarytimestamp_to_datetoml_to_jsonvalidate_json_schemavalidate_url_formatweb_searchweb_search_advancedweb_search_newswrite_filexml_to_jsonyaml_to_jsonMost tools have distinct purposes, especially in the browser and subagent groups. However, there is some overlap between similar tools like fetch_webpage/fetch_webpage_text, parse_csv/csv_to_json, and multiple search tools (web_search, web_search_advanced, web_search_news). Descriptions help but some boundaries are blurry.
All tool names follow a consistent verb_noun pattern in snake_case (e.g., browser_navigate, parse_csv, get_system_info). No mixed conventions or irregular naming, making the set predictable for an agent.
With 116 tools, the server is extremely large for an MCP server. While it aims to be a comprehensive toolkit, the sheer number likely overwhelms agents and increases selection errors. A more focused scope or modularization would improve coherence.
The tool set covers a wide range of domains (browser, file, text, system, web search, subagent) with good depth. Minor gaps exist, such as lack of in-place file editing or image processing, but overall the surface is quite complete for its stated purpose.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
8 MCP servers, 104+ tools: memory, social, PDF, email, images, calendar, scheduler, files.
Nifty's MCP server โ exposes tasks, projects, messages, and files as tools for AI agents.
MCP server for progressive tool usage at any scale (see https://klavis.ai)
A registry of AI agent tools โ MCP servers, APIs, CLIs, SDKs โ kept current by automated ingestion.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/quyansiyuanwang/oh-my-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
