Lists currently open Apple Numbers documents with pagination so you can inspect active spreadsheets without launching a stopped app.
List open Numbers documents. Does not launch a stopped application.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| offset | No |
Changes observed during successful MCP inspections.
v3.0.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive), so the bar is lower. The description adds genuinely useful context beyond them: only currently-open documents are returned, and a stopped application will not be launched to enumerate them, which tells the agent when the result may be empty.
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 with zero waste; the core capability is front-loaded and the caveat follows. Nothing is padded or repeated.
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 read tool with no output schema, the description covers what is listed and the app-state constraint, which is roughly adequate. It omits pagination behavior and any indication of return shape, which matters given two paginated parameters with no documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and both parameters (limit, offset) are undocumented anywhere. The description never mentions pagination, defaults, or bounds, so it does not compensate for the schema gap even though the parameters are conventional.
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?
States a specific verb and resource ('List open Numbers documents') and the scope qualifier 'open' usefully separates it from disk-wide listing. It does not explicitly name a sibling, but the combination of app (Numbers) and scope (open) makes it distinguishable from apple_pages_list_documents and apple_numbers_open without opening a 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?
There is no explicit when-to-use statement and no named alternative. The caveat 'Does not launch a stopped application' hints at a precondition (the app must already be running), but it is framed as a behavioral fact rather than routing guidance such as 'use apple_numbers_open first if the app is not running'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.