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

Annotations already declare readOnlyHint/idempotentHint/destructiveHint, and the description adds substantial behavioral mechanics beyond them: session persistence via mcp-session-id, 24h idle expiry, re-entering re-scopes, the authoritative reply structure (platform_tools/platform_tool_defs vs. composed_tool_defs), and REST twin behavior. No contradiction with annotations is present.

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 front-loaded with the core purpose and every major sentence adds distinct value (progressive disclosure, session lifecycle, REST twin, info tenants, return shape). However, it is somewhat verbose with minor redundancy: "authoritative" appears twice, and the final example sentence largely repeats schema documentation. Slightly trimmed would be ideal.

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 high complexity (session scoping, progressive disclosure, REST twin, no output schema), the description is remarkably complete: it explains the reply contents, session expiry/re-entry, re-scoping semantics, and the REST alternative. Minor gaps remain, such as error behavior for invalid/unknown tenant ids and clearer guidance on whether info tenants need to be entered.

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% (tenant_id with example "about-us"), so the baseline is 3. The description adds contextual meaning: tenant ids come from federation_list_tenants, appear in the REST twin body as {"tenant_id":"<entered tenant>"}, and are used in the worked example. This elevates it above baseline but does not reach 5 since the schema already documents the parameter 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?

The opening sentence states a specific verb+resource+outcome: "Enter a tenant to receive its tool surface (progressive disclosure)." It clearly distinguishes this from sibling federation_list_tenants (list vs. enter) and explains its gateway role, including info-tenant behavior. This is unambiguous and well differentiated.

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?

Explicit sequencing is given: "list tenants with federation_list_tenants, then enter one here." The description also names an alternative access path ("REST twin: POST /tools/<name>"), describes when re-entry is needed (24h idle expiry), and notes that info tenants serve read-only knowledge directly on tools/list. This is strong when-to-use guidance.

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