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

Annotations already state readOnlyHint=true, openWorldHint=true, and destructiveHint=false, covering the safety profile. The description adds useful behavioral context beyond annotations: the result is scoped to businesses 'this connection can reach' and includes IDs, plus it clarifies that the business argument belongs to other tools, not this one.

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 carry all necessary information with no filler. The core purpose is front-loaded, and the cross-tool note is placed second, making the description easy to scan and act on.

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, read-only list tool with an output schema and clear annotations, the description covers what the tool returns, its scope, and its relationship to every other tool in the set. Nothing essential is missing for an agent to invoke 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?

The tool has zero parameters, so there is nothing for the schema or description to document. The description's mention of the optional 'business' argument is clarifying for sibling tools but not a parameter of this tool, matching the 0-parameter 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 uses a specific verb and resource: 'List the Manager businesses this connection can reach, with their ids.' It also distinguishes itself from the sibling tools by explaining how every other tool depends on an optional 'business' argument, so an agent can tell this tool enumerates business IDs rather than performing a manager 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?

The description clearly implies this tool is used to discover reachable businesses and their IDs, and it explains the relationship to all other tools via the optional 'business' argument. It does not explicitly name an alternative tool or state a hard 'when not to use' rule, but the context is clear enough for selection.

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?

Annotations already provide readOnlyHint=true and destructiveHint=false, so the description doesn't contradict them. It adds the requirement of 'Raw read' permission in the control panel, which is valuable prerequisite knowledge. It also implies direct access with no catalog validation, which is useful 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 concise, front-loaded with the core purpose and examples, and each sentence adds value: the purpose, the scope, and the permission requirement. 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?

Given the output schema exists, return values are covered. The description covers purpose, usage scope, and permissions, which is strong. However, with 0% schema coverage and no explanation of 'params' and 'business', an agent might not know how to construct those parameters correctly, leaving 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?

The schema has 0% description coverage, so the description carries the burden. It explains the 'path' parameter with examples, but provides no explanation for 'params' or 'business' parameters. Since the schema only gives types without semantics, the description partially compensates but is incomplete.

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

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

The description clearly states the tool performs a GET on any Manager API path, with examples, and explicitly scopes it to paths the catalog does not model. This distinguishes it from other manager tools like manager_get and manager_list.

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?

It says to use only for paths the catalog does not model, which provides a clear condition. However, it doesn't explicitly say when not to use it (e.g., when the catalog does model the path) or mention alternatives like manager_get or manager_catalog.

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?

Annotations declare openWorldHint=true and readOnlyHint=false, so the description doesn't need to restate mutability; it adds the meaningful detail that this bypasses per-resource tick boxes and requires the separate 'Raw write' permission. It also lists allowed methods, clarifying the scope of the open-world 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?

Three terse sentences, each earning its place: scope, permission caveat, and routing advice. The most decision-relevant detail ('escape hatch') 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 an escape hatch with 2 required params and an output schema, the description covers what the tool is, when to avoid it, and what permission it needs. It's slightly thin on body/business parameter semantics, but those are optional and the schema carries type info.

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

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

Schema description coverage is 0%, so the description carries the burden, but it only covers method and path indirectly ('any method… any Manager API path'). The optional body and business parameters are left entirely unspecified, which is a gap for an escape-hatch 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 opens with 'Escape hatch' and a concrete verb phrase: 'send any method (POST/PUT/DELETE) to any Manager API path.' It clearly scopes the tool as generic raw API access and distinguishes it from managed siblings by naming the preferred 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?

It explicitly says to prefer manager_create / manager_update, and explains the special permission requirement (separate 'Raw write' box) that gates use. It doesn't enumerate every scenario, but gives enough directional guidance to route an agent toward the managed tools when possible.

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?

Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is covered. The description adds context about what the catalog exposes (documents, lists, reports, settings) and that it reflects operations allowed by current tick boxes, which is useful behavioral context beyond the annotations. It doesn't contradict annotations.

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

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

The description is two sentences, front-loaded with the core purpose and scope, and includes a clear usage directive. Every sentence earns its place, and the filtering guidance is concise. No wasted words.

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

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

The tool has an output schema, so return values are covered. The description explains the tool's role as a discovery mechanism and mentions filtering. However, it doesn't explain the 'allowed_only' parameter or the 'business' parameter, which could be important for correct invocation. Given the output schema exists and the description covers the main use case, this is slightly above average but not fully complete.

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

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

Schema description coverage is 0%, so the description must compensate. The description mentions 'search' and 'group' as filters, which maps to the 'search' and 'group' parameters, but it doesn't explain 'limit', 'business', or 'allowed_only'. The description adds some meaning for two of five parameters but leaves the others undocumented. Baseline 3 is appropriate since the description partially compensates but doesn't fully cover all 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 purpose: browsing the resource catalog of a business, listing documents, lists, reports, and settings, with operations allowed by current tick boxes. It also explicitly says to start here when you don't know a resource name, distinguishing it from other manager_* tools. The verb 'browse' and resource 'resource catalog' 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 explicitly says 'Start here when you do not know a resource name' and mentions filtering with 'search' or 'group'. This gives clear guidance on when to use this tool versus alternatives like manager_list or manager_get. It also implies it's a discovery/exploration tool, which is distinct from the more specific manager_* operations.

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?

Annotations already indicate readOnlyHint=false, idempotentHint=false, and destructiveHint=false, so no contradiction exists. The description adds meaningful behavioral context beyond annotations by warning that high-risk resources require explicit user consent and by stating that the operation returns the new record Key, which helps set expectations for the call result.

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 well-organized sentences: the core purpose and examples come first, followed by the technical shape guidance and the risk-safety instruction. Every sentence adds necessary information and there is no filler.

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

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

For a create operation with an output schema available, the description covers the key operational details: what to create, how to structure fields, what to expect in response, and when to seek user approval. The only notable omission is the 'business' parameter, which would otherwise make the guidance fully complete.

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

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

Schema description coverage is 0%, so the description must compensate. It does explain 'fields' in detail, including that it is Manager-native JSON and should mirror an existing record's shape from manager_get, and it implies 'resource' via the list of record types. However, the optional 'business' parameter is never described, leaving a gap in an otherwise useful parameter explanation.

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 opens with a specific action ('Create a record') and enumerates concrete resource examples (invoice, payment, customer, journal entry, tax code), making the tool's purpose immediately clear. It naturally distinguishes itself from sibling tools like manager_get, manager_update, and manager_delete by focusing on creation and returning the new Key.

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 practical usage context: it tells agents to copy the fields shape from manager_get and instructs that high-risk resources require explicit user confirmation first. It does not explicitly name when not to use this tool or direct agents to alternatives, but the create-versus-read/update/delete distinction is clear from context.

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?

Beyond what annotations already declare (destructiveHint=true, readOnlyHint=false), the description adds critical behavioral disclosures: deletion is permanent with no undo, the user must be confirmed first, and the deleted document is returned in the response so it can be re-created. This directly complements and enriches the annotation safety profile.

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. The destructive action is front-loaded, followed immediately by the most decision-critical caveat (no undo) and the recovery mechanism (returned document). Every clause 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?

With an output schema present and annotations covering destructiveness, the description covers the key behavioral caveats an agent needs to act safely. The main gap is parameter semantics, but that is accounted for separately; the tool's critical safety and recovery context is present.

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

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

Schema description coverage is 0%, so the description carries the full burden of explaining parameters, but it does not clarify what 'resource', 'key', or 'business' mean or how they relate to the record being deleted. The term 'record' loosely maps to 'resource' but never explicitly, leaving the agent to guess parameter formats.

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

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

The description states a specific verb and resource — 'Delete a record permanently' — which clearly distinguishes it from siblings like manager_get, manager_create, and manager_update. The permanence qualifier adds important scope that separates it from any soft-delete or move-to-trash behavior.

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 clear operational context: because there is no undo, the agent must confirm with the user first. It does not explicitly name alternatives or exclusion conditions, but the confirm-first instruction effectively routes the agent's decision-making around this irreversible action.

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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows this is a safe read. The description adds that it returns the exact shape and mentions non-guessable field names, which gives insight into the data model. However, it does not disclose details like error cases, pagination, or authentication, but given the annotations, a 3 is appropriate.

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

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

The description is two sentences with no filler. It front-loads the core purpose and then provides usage guidance, all in a compact and efficient manner. Every clause 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?

With 3 parameters, no schema descriptions, and only an output schema, the description fails to explain the 'resource' and 'business' parameters, which are crucial for correct invocation. The agent cannot determine what valid resource values are or how to construct the request without additional information, making the description incomplete.

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

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

Schema description coverage is 0%, so the description must explain all parameters. It only explains 'key' (by its Key GUID), leaving 'resource' and 'business' undocumented. Since the schema provides no descriptions, the agent has to guess what 'resource' refers to, which is a significant gap.

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

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

The description clearly states the verb 'Fetch' and the resource 'one record by its Key (GUID)' and specifies the output shape ('exact shape Manager stores it'). It also differentiates from siblings by indicating its role before updates and as a template for create, making it distinct from tools like manager_list or manager_create.

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

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

The description explicitly provides when to use this tool: 'Always do this before an update' and 'use an existing record as the template for a create'. It does not explicitly mention when NOT to use it or alternative tools, but the guidance is strong enough for an agent to understand the primary use case.

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?

Annotations already provide readOnlyHint=true and destructiveHint=false, so the safety profile is clear. The description adds valuable behavioral disclosure beyond annotations: 'Unsupported parameters are reported back rather than silently dropped.' This proactive error-behavior note helps agents anticipate failures, crediting 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?

Three sentences, no padding. The purpose is front-loaded, examples are compact, and the error behavior is a final line. Every sentence earns its place, making it highly scannable for an agent.

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

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

The description covers the core search/page behavior and date-filter semantics, and the output schema exists to explain return values. Yet with 11 parameters and zero schema coverage, several parameters remain opaque, and the required 'resource' parameter is not described beyond examples. The agent can likely call it, but edge parameters like extra_params and pagination are left vague.

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

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

With 0% schema description coverage, the description carries the semantic burden. It explains 'term' searches, 'sort_by' taking a column name, and date feeds accepting from_date/to_date with format YYYY-MM-DD. However, it leaves many parameters unexplained (skip, page_size, fields, business, extra_params, sort_by_desc), so compensation is only partial.

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

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

The description states the tool's verb and resource clearly: 'Search or page any Manager collection, report feed or list' with concrete examples (customers, sales_invoices, payments). This is specific and distinguishes the tool's broad enumeration/search role from siblings like manager_get and manager_catalog, though it doesn't explicitly name them.

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

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

The description gives context ('Search or page any Manager collection') and hints at parameter usage, but it does not explicitly say when to use this tool over alternatives like manager_get or list_businesses, nor does it mention exclusions or fallback tools. An agent must infer usage from the broad wording.

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?

Annotations already declare readOnlyHint, openWorldHint, and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral detail beyond those flags by specifying exactly what the read-only result contains and that it reflects the connection's current authorization 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?

Two sentences, no filler. The core purpose is front-loaded, the output details are compactly listed, and the usage hint earns its place. Every sentence adds 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?

Given an output schema, one optional parameter, and annotations covering safety, the description is complete enough for an agent to select and invoke the tool correctly. It states what the tool returns, the context in which it should be used, and the business scoping.

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

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

Schema description coverage is 0%, so the description must compensate. It only hints that the business parameter scopes results ('for a business') but does not explain the business identifier format, the meaning of null, or the default behavior. For a single optional parameter this is acceptable but not fully compensating.

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 ('Show') and names the resource (permissions of the current connection for a business), then enumerates the concrete outputs: totals per operation, rule origins, and resources with write access. This clearly differentiates it from sibling tools like manager_list or open_permissions_panel.

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?

It gives an explicit usage directive: 'Use it before telling the user something is not possible.' This is a clear, actionable trigger for when to call the tool. It does not, however, name alternatives or state when not to use it.

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

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

Annotations already indicate readOnlyHint=false, destructiveHint=false, idempotentHint=false, openWorldHint=true. The description adds important behavioral context: merge mode reads the live document first and changes only passed fields, while replace sends the body verbatim. It also warns that high-risk resources restate existing books. This goes beyond annotations, though it doesn't detail error handling or auth requirements.

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

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

The description is three sentences, front-loaded with the core action, then the warning, then the mode explanation. Every sentence adds value and there is no 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 has an output schema and annotations, the description covers the critical decision of merge vs replace and the high-risk confirmation requirement. It doesn't explain what 'key' refers to or how 'business' scoping works, but the output schema and sibling context likely cover some of that. For a mutation tool with openWorldHint, this is 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 description coverage is 0%, so the description must compensate. It explains the 'mode' parameter's two values and their semantics, and mentions 'fields' as the fields to pass. It doesn't explain 'key', 'resource', or 'business' in detail, but the description's focus on mode and fields covers the most ambiguous parts. The resource parameter is partially explained by the high-risk list.

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 updates a record in Manager, and distinguishes it from siblings by explaining the merge vs replace behavior. It names the resource and the action with a specific verb, and the context about high-risk resources helps differentiate it from manager_create and manager_delete.

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

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

The description explicitly says when to use default merge mode and when to use replace mode, and instructs the agent to confirm with the user for high-risk resources. It also explains why merge is normally preferred because PUT replaces the whole document. This is strong usage 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?

Annotations already declare readOnlyHint and destructiveHint, so the description does not need to restate safety. It adds useful behavioral detail beyond them: the panel is local, opens in the browser, returns a URL, and 'changes apply immediately, no restart.' This gives the agent practical expectations about side effects and deployment.

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 tight sentences: the first covers action and return value, the second explains user purpose and runtime behavior. No filler, no repetition of schema or annotations, and the most decision-relevant 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?

Given the tool is simple, has rich annotations, and includes an output schema, the description covers the core action and return. However, it leaves a material gap: the open_browser parameter is entirely undocumented, and the description does not clarify how to choose this tool over the sibling manager_permissions. It is minimally viable but not fully complete.

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

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

Schema description coverage is 0% and the description does not mention the open_browser parameter at all. The agent cannot tell what happens when open_browser=false or how the boolean alters the tool's behavior. The name alone is not enough, especially since the tool is called 'open_permissions_panel' yet may optionally not open a browser.

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

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

The description states a specific verb and resource: 'Open the local permissions control panel in the browser and return its URL.' It clearly distinguishes this from the sibling manager_* tools by emphasizing a local browser panel rather than an API-driven management 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?

It gives strong contextual cues about when to use the tool: when the user needs to tick resource permissions, add businesses, or manage access tokens. It does not explicitly name alternatives or provide exclusion criteria, but the 'local ... in the browser' framing implies a different use case than the manager_permissions or manager_list 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?

Annotations already mark this read-only/non-destructive, and the description adds the key behavior: PDFs are rasterised per page and image paths are returned, while images are passed through unchanged. It does not mention side effects like temporary file creation, but the annotation safety profile lowers that 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?

The core command and the critical ALWAYS warning are front-loaded, and the combine guidance is compressed into conditional sentences. The phrase 'which is the right shape when the pages are one document' slightly restates the earlier 'joins the pages of ONE document', but the overall length is appropriate and 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?

With an output schema present, the description doesn't need to document return values in depth, and it covers the main decision an agent faces (PDF vs image, one document vs several). Minor omissions like dpi semantics and temporary-file behavior do not prevent correct selection or invocation.

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

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

The schema has 0% description coverage, so the description must carry parameter meaning. It explains combine's allowed values and the one-document vs multi-document decision rule, but dpi is left entirely to inference and file_path is only implied as 'file'. This is a real but not fatal gap.

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

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

The description opens with a concrete transformation ('Turn a file into something Manager will accept as evidence') and names the exact failure it prevents (Image field rejects PDFs). It clearly identifies this as a pre-attachment rasterisation step, which separates it from the sibling manager_* CRUD 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?

It gives an explicit ALWAYS rule for PDFs before attaching, says images pass through untouched, and provides conditional guidance for combine='vertical'/'horizontal' vs 'none' based on whether pages form one document. It also adds an exclusion: never merge two different proofs. This is 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?

Beyond the readOnlyHint/openWorldHint/destructiveHint annotations, the description reveals that the tool re-reads the Manager's API description and rebuilds the catalog from it, and explains when that is needed. No statement contradicts the annotations; rebuild appears to refer to refreshing local catalog state, not an external destructive write.

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 tight sentences front-load the action and then give the concrete maintenance use cases. There is no repetition of the tool name or filler.

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

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

The output schema and annotations cover return shape and safety, and the description covers triggers. However, the undocumented business parameter is a real gap for correct invocation when non-default behavior is intended, and no relationship to catalog inspection tools is explained.

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, business, has no schema description and is not mentioned anywhere in the tool description, leaving its meaning and effect entirely unexplained. With schema description coverage at 0%, the description needed to compensate but did not.

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 names a specific action ('re-read the Manager instance's own API description and rebuild the resource catalog') and a unique resource, the resource catalog. This is clearly distinct from sibling tools like manager_catalog or manager_list, which inspect rather than rebuild the catalog.

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?

It gives explicit trigger conditions: after upgrading Manager or when a resource seems missing. It does not name exclusions or the alternative manager_catalog for checking whether a resource is present, so it stops short of a full when-not-to-use statement.

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