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 this is a read/informational operation but doesn't disclose what specific information the tool returns (dimensions, title, etc.), whether the pane is guaranteed to exist, or what happens if the server isn't in a pane. The lack of an output schema means the description should clarify what 'information' means here.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single sentence that is perfectly sized for a zero-parameter tool. Every word earns its place, and the specificity about 'where the MCP server is running' is valuable context in compact form.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter informational tool, this is mostly complete. The main gap is not specifying what 'information' is returned—the description neither lists example output nor references an output schema (which doesn't exist). This leaves the agent guessing about whether it gets dimensions, title, session name, or other attributes. A brief note on return content 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?

With 0 parameters, the schema coverage is trivially 100%. The description correctly explains what the tool refers to ('the current iTerm2 pane where the MCP server is running'), disambiguating which pane is meant. No parameter documentation is needed since there are none.

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 information about the current iTerm2 pane where the MCP server is running. The verb 'Get' with the specific resource 'current iTerm2 pane' is clear and specific. It distinguishes from siblings like iterm2_side_pane and iterm2_list_panes since it specifically targets the 'current' pane where the server runs.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies the use case (querying the current pane's info) but doesn't explicitly contrast with alternatives like iterm2_list_panes for enumerating all panes. It relies on sibling names being self-explanatory rather than explicitly stating when to use this tool versus others.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It discloses that a restart is required after enabling, which is useful behavioral context. However, it doesn't disclose whether this changes preferences persistently, whether it requires the tool to be idempotent, or what happens if already enabled. For a configuration/mutation tool with zero annotations, more disclosure would be valuable, but the restart note does add meaningful behavioral context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, both earning their place: the first states the purpose, the second adds a critical behavioral caveat. No filler or redundancy. Very efficient for what it communicates.

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 zero-parameter configuration tool with no output schema, the description covers the core action and a key side effect (restart required). However, it could be more complete regarding what 'enabling the API' unlocks, why a user would want this, whether it's reversible, or what error conditions might arise. Given zero siblings conceptually overlap, the completeness is adequate but not rich.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has 0 parameters, and schema coverage is 100% (trivially, since there are no params). With no parameters, there is nothing for the description to add semantically. The baseline for 0 params is 4, and the description correctly adds no param noise. This 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 states the action clearly: 'Enable the iTerm2 Python API in preferences.' It has a specific verb (enable) + resource (iTerm2 Python API) + location (in preferences). It doesn't explicitly distinguish from the sibling tools, but the siblings are all about pane control or status, so the purpose is reasonably distinct in context.

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 setup context by noting 'Note: iTerm2 must be restarted after enabling.' However, it doesn't state when to use this tool versus alternatives or any prerequisites like whether iTerm2 is already running or whether this is a one-time setup step. The restart note gives some context for expected behavior after invocation but no explicit when/when-not guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the burden. It describes the informational/read-only nature implicitly by stating it 'lists' and 'shows' content, but doesn't explicitly state it's non-destructive or describe any limitations (e.g., requires iTerm2 running, requires API enabled). The read-only trait is implied rather than disclosed.

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 compact at two sentences and front-loads the primary purpose. The second sentence about 'shows which pane you are in' and 'use with other tools' adds practical value without padding. Minor inefficiency: the second sentence's two clauses could be slightly more structured, but overall it's tight.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter, informational listing tool, the description covers the returned data (IDs, names, directories, jobs) and usage context (IDs consumed by other tools). It doesn't mention prerequisites like API enablement (a sibling tool iterm2_enable_api suggests this may be needed), but the description is largely sufficient for this simple tool type.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has 0 parameters, and schema description coverage is effectively complete (no properties to document). The description adds value by explaining what the returned data contains and how to use the IDs, which addresses informational needs since there's no output schema. Baseline 4 for 0 params 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 a specific verb+resource ('List all iTerm2 windows, tabs, and panes') and clearly specifies what data is returned: shorthand IDs, names, working directories, and running jobs. It also explicitly notes which pane the user is currently in, adding useful scoping detail.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context for how to use the tool ('Shows which pane you are in' and 'Use these shorthand IDs with other tools'), implicitly distinguishing it from sibling tools that send input, split panes, or read output. However, it doesn't explicitly state when not to use this tool versus alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so the description carries full burden. It states the tool reads the screen buffer and returns visible text, which implies a read-only operation, but doesn't clarify details like whether this captures scrollback or only the currently visible viewport, whether the text is cleared/stale, or if there are timing implications for reading live terminal output.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences with zero waste. States the action and what's returned. Could arguably be a single sentence, but the brevity is appropriate for such 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?

For a single-parameter read tool with no output schema, the description covers the basic purpose. However, it doesn't clarify the return format (is it raw text, lines, structured?), whether scrollback is included, or how this differs from iterm2_status for reading pane content. Given the tool's simplicity, this is adequate but not rich.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already clearly documents session_id with examples of shorthand formats. The description doesn't add meaning beyond the schema, but since coverage is complete, 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?

Clear verb+resource: 'Read the screen buffer contents of a specific iTerm2 pane.' This distinguishes from siblings like iterm2_send_text (which writes) and iterm2_list_panes (which enumerates). It's specific about what it does but doesn't elaborate on output format beyond saying visible text is returned.

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 iterm2_current_pane or iterm2_status. It's implied that this is for reading terminal output, but there's no explicit when/when-not guidance or mention of alternatives for different reading scenarios.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden for safety disclosure. Sending Ctrl+C/D/Z are potentially disruptive (interrupting, suspending, EOF/logout) — the description does at least flag that these actions interrupt processes. But it doesn't note that Ctrl+D can log out/log off, that these are one-way (no undo), or the irreversible nature of some effects. Reveals the core effect but lacks deeper safety 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?

Two concise sentences with zero waste. States the tool name's content and provides a concrete use case example. Well front-loaded and efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple 2-param tool with 100% schema coverage and no output schema, the description plus schema cover the essential needs. The behavior (sending control characters) is straightforward and complete. It could mention what happens on success/failure but this is a simple fire-and-forget action, so current coverage is largely 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 description coverage is 100%, so the description itself adds little beyond schema. The enum values and their meanings are fully spelled out in the parameter descriptions (e.g., 'c' for interrupt/SIGINT). The description simply repeats 'Ctrl+C, Ctrl+D, Ctrl+Z, or Ctrl+L' from the schema with no additional format/usage nuance. Baseline 3 is appropriate since schema carries the load.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states it sends control characters (Ctrl+C/D/Z/L) to an iTerm2 pane and gives purpose ('interrupting processes or clearing the screen'). Verb+resource+scope are specific. It doesn't explicitly distinguish from sibling send_text, but the 'control character' focus is reasonably 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?

Description gives concrete use cases ('interrupting processes or clearing the screen') that imply when it applies. However, it doesn't explicitly contrast with iterm2_send_text (which sends regular text) or state when NOT to use it. Usage is implied, not explicitly differentiated against siblings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the behavioral disclosure burden. It does state the 'as if typed by the user' behavior and the newline default (via the false-setting option in the description), which adds useful behavioral context. However, it doesn't disclose what happens with special characters, whether the pane must be active/focused, error behavior, or whether the command targets the currently visible pane.

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 waste. Front-loaded with the core purpose, followed by the one behavioral qualifier (Enter). Every phrase 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?

The tool is a straightforward send-text operation with no output schema and a 100%-covered 3-param schema, so the description is reasonably complete. However, for an interactive terminal mutation tool with no annotations, it could benefit from noting prerequisites (e.g., API enablement via iterm2_enable_api sibling) or clarifying behavior when the pane isn't visible/focused, which are plausible failure modes for a real-world agent calling this tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the schema documents all three parameters. The description adds value by explaining the newline default behavior ('press Enter after the text, default true') and the effect of setting newline=false ('type text without executing'), which goes beyond what the raw schema states. This is meaningful added semantics.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb (send text/commands), the target resource (an iTerm2 pane), and the 'as if typed by the user' behavioral qualifier, plus the optional Enter behavior. It distinguishes reasonably from siblings like iterm2_send_control_character (which sends special keys) and iterm2_read_pane (which reads), though it doesn't explicitly name these alternatives.

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 ('send text/commands') but provides no explicit when-to-use guidance or when-not-to-use exclusions relative to siblings. For example, it doesn't clarify when to prefer this over iterm2_send_control_character or iterm2_current_pane. The use case is fairly evident for an interactive terminal tool, so implied usage is acceptable but not explicit.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the burden. It discloses the directional fallback behavior (left if current is rightmost) which is useful. However, it doesn't describe what 'current pane' means precisely, whether it returns an identifier or a pane object, or any failure behavior (e.g., what happens with no side pane).

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 wasted words. States the action, the return semantics, and the use case all in compact form. Every sentence 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?

No output schema exists and no annotations are given, so the description must cover behavior fully. It explains the directional logic and use case, but lacks detail about the return value format, how it identifies the pane, and interactions with tools like iterm2_send_text or iterm2_split_pane. Adequate but with notable gaps given the zero annotation coverage.

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 takes 0 parameters with 100% schema coverage (empty schema is fully documented). Since there are no parameters to explain, the description has no burden here. Baseline 4 for zero-parameter tools 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?

Clear specific verb+resource (Get the side pane) with explicit directional behavior stated. Distinguishes from siblings like iterm2_current_pane and iterm2_list_panes by specifying adjacency logic (right side, or left if rightmost).

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?

States usefulness for 'interacting with an adjacent terminal pane' which implies when to use it, but doesn't explicitly mention alternatives (e.g., iterm2_list_panes for a broader view, iterm2_read_pane for content). No when-not-to-use guidance given.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It discloses that a new pane is created (mutating action) and states the return value (session ID), which is helpful. However, it doesn't mention whether the original pane remains active, how to determine the new dimensions, or any prerequisites (e.g., iTerm2 must be running).

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 efficient sentence that states purpose, behavior, and return value with no wasted words. It front-loads the core action and mentions the result. Could potentially note caveats but is appropriately concise for the simplicity of the tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a straightforward two-parameter split operation with full schema coverage, the description covers the essentials: purpose, behavior, and return value. The lack of output schema means the description appropriately notes the session ID return. Gaps include no mention of error scenarios (invalid session ID) or whether splitting is synchronous. 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?

Schema coverage is 100% with detailed parameter descriptions. The schema already explains the vertical boolean semantics and the session_id shorthand format thoroughly. The description adds the session ID return value context, which contributes meaning beyond the schema. Description does not need to duplicate what the schema already covers well.

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?

Clear verb+resource+action: splits an iTerm2 pane horizontally or vertically, creating a new pane. It also states the return value (session ID). It distinguishes from siblings like iterm2_send_text and iterm2_list_panes, though it doesn't explicitly differentiate from iterm2_side_pane which sounds similar.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies when to use it (when you need to split a pane), but provides no explicit exclusions or alternatives. There's a sibling named iterm2_side_pane which could be confusingly similar, but the description does not clarify when to choose one over the other.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided and no output schema, the description carries the full burden of behavioral disclosure. It states the tool 'Check[s]' status, implying it's a non-destructive read operation, but it doesn't disclose what the return value looks like (e.g., boolean, status message, error type). For a diagnostic tool, the return format is meaningful and unstated.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence, zero waste, well-suited for a zero-parameter diagnostic tool. Could arguably add a brief note about the return value, but for its purpose the description is appropriately concise.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is simple (no params, no output schema, no annotations), so the description is fairly complete. However, for a status/health-check tool, understanding what 'ready' means and what the response indicates would help the agent decide follow-up actions. The absence of any return-format guidance leaves a notable 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?

The tool has 0 parameters and 100% schema coverage (empty schema fully describes the input). With no parameters, the description doesn't need to explain parameter meaning. A baseline 4 is appropriate since there's nothing to document.

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: checking if the iTerm2 Python API is configured and ready. The verb 'Check' plus the resource 'iTerm2 Python API' is specific. It's a diagnostic/status tool, distinct from sibling tools which all perform terminal operations (send text, split pane, etc.).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies this tool is a prerequisite check before using other iterm2 tools, but does not explicitly state when to use it or when not to. The sibling tools suggest it should be used before operations like iterm2_send_text, but the description doesn't name alternatives or provide exclusion guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.