ActionBridge

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

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=false, so the safety profile is fully covered by structured data. The description adds that the payload is informational content (dates, migration behavior, checklist), but says nothing about the form or depth of what is returned, which matters since there is no output 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?

A single front-loaded sentence that names the dates first and then the migration/checklist content, with no filler. It is dense but every clause maps to a distinct payload section, so nothing should be cut.

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 reference tool with full annotation coverage, the description covers the substantive questions an agent would have, including the key caveat that custom Actions do not migrate. It stops just short of indicating the return format or how authoritative/long the guidance is.

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 zero parameters, so the baseline is 4. The description correctly implies a parameterless lookup and prevents an agent from expecting to scope the query by date or product version.

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 names a specific resource (custom GPT retirement in ChatGPT, December 2026) and enumerates the exact content: key dates, what migrates automatically, what does not (custom Actions), and a rebuild checklist. It is clearly distinct from the sibling tools (client setup, OpenAPI conversion preview) by content, though it never names those siblings explicitly.

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 by the content scope: an agent would call this when it needs retirement dates or a migration checklist. There is no explicit when-to-use framing, no statement of when this guide is NOT the right choice versus get_mcp_client_setup or preview_openapi_conversion, and no prerequisites noted.

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 establish readOnlyHint, idempotentHint, non-destructive and openWorldHint=false, so the safety profile is fully covered structurally. The description adds useful scope information by enumerating the supported clients and the three auth models, which tells the agent what the returned instructions will cover. It stops short of describing the output shape (e.g. markdown vs. structured steps) or noting that the content is static reference material, which would have raised this score.

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 front-loaded sentence that states the deliverable first and then the coverage scope, with no filler or redundant restatement of the title. The client enumeration is dense but each item carries information; only minor cost is that the trailing clause makes the sentence 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?

For a documentation-generating tool with four params and no output schema, the description covers the client and auth dimensions well but omits the name parameter entirely and never indicates what the response looks like. An agent can call it correctly, but cannot predict whether the reply is a single blob or per-client sections.

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 75%, just under the high-coverage threshold, so the schema already documents server_url and the auth enum values in detail. The description restates the same client list and auth modes the enum defines, adding reinforcement but no new meaning such as URL format constraints or whether the name parameter affects the rendered instructions. 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 names a specific deliverable (step-by-step setup instructions) and a specific resource (remote MCP server URL added to a named list of clients), so an agent knows this is a documentation/guidance tool rather than an executor. It implicitly separates itself from siblings like custom_gpt_retirement_guide and preview_openapi_conversion by scoping to MCP client onboarding, though it never names 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?

Usage is only implied: an agent can infer it should call this when a user needs to connect an MCP server to a client. There is no explicit 'use this when' statement, no when-not condition, and no routing advice relative to the two sibling tools, leaving the agent to reason about selection on its own.

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, idempotentHint, openWorldHint=false and destructiveHint=false, so the safety profile is covered; the description still adds 'Nothing is stored and the API is not called' and lists the response contents, which is worthwhile given there is no output schema. It does not mention input size limits (the 1.5M character cap) or performance/validation-failure 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?

Front-loaded with the verb and result, followed by when-to-use and a safety note; every clause carries information. The enumerated output list is slightly long but earns its place because no output schema exists.

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 one-parameter, read-only preview tool with no output schema, the description covers what goes in, what comes back, side-effect guarantees, and the motivating use case. An agent has everything needed to call it correctly and interpret the result.

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 a single required parameter at 100% schema coverage, the schema already does the work. The description adds only marginal meaning — that the input is raw text and that a custom GPT Action schema is a typical example — which is useful framing but largely duplicates the schema's 'JSON or YAML' note.

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 verb and resource — 'Validate an OpenAPI 3.0/3.1 schema ... and show the MCP tools it converts to' — and enumerates exactly what the preview contains (tool names, method/path, hints, detected auth, errors). This clearly separates it from the sibling tools (a retirement guide and a client-setup helper).

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: 'Use this when someone wants to migrate a custom GPT Action or turn an OpenAPI spec into an MCP server.' That is clear context for selection. It stops short of naming when-not-to-use conditions or pointing at the siblings as the alternative path after a preview.

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