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

Although annotations already mark readOnlyHint, idempotentHint, and destructiveHint, the description adds key behavior beyond those flags: the dataset is gated behind a subscriber key/Legend tier; verification status is NEVER silently filtered and appears as columns; product filter drops rows meaning 'not detected' rather than 'does not use'; cursor must be passed with the SAME filter arguments and changing filters refuses the cursor. This gives an agent safety-relevant and semantic behavior that annotations alone wouldn't convey.

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 information-dense but every clause earns its place: the corpus distinction, access tier, verification semantics, product detection semantics, and cursor behavior are all core to correct invocation. There is no fluff or repetition of schema content; it is front-loaded with the end-customer vs firm distinction, which is the most important routing signal.

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, six optional params, and a sibling set that includes get_sap_client_profile and search_firms, this description fully disambiguates where and how to use it. It covers access requirements, result semantics, filtering semantics, and pagination constraints. Nothing critical an agent needs to know before calling is missing.

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 documents every parameter. The description adds value beyond the schema by explaining the detection semantics of the product enum, the 'never silently filtered' verification columns, and the cursor's same-filter requirement. It does not repeat schema details, so a 4 is appropriate; a 5 would require even more domain-specific parameter nuance beyond what the schema gives.

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 explicitly identifies the corpus (SAP end-customers), contrasts it with the sibling tool search_firms (services firms), and highlights the Legend tier requirement. It also says exactly what 'product' filtering means in terms of detection flags, so an agent can distinguish this tool from get_sap_client_profile and search_firms.

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 first sentence explicitly contrasts with search_firms: end-customers vs firms that sell services. It also explains the paid subscriber key / Legend tier context, tells the agent that verification status is always served and not silently filtered, and describes detection semantics so the agent can decide when to use this versus more detailed profile tools. This is strong 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.