slack_schedule_message

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

Annotations already establish readOnly=false, destructive=true, and idempotent=true. The description adds some genuine governance behavior beyond those annotations: routing through a governed connector authority, Spring verifying the claimed effect, and approval_ref being needed to resume a write. However, it does not disclose what destructive side effect occurs or any scheduling-specific behavior, so it adds only partial 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 compact and well-structured with a short intro and a bulleted parameter list. Every line carries some information, and the routing constraint is front-loaded before the parameter details.

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 7-parameter connector operation with zero schema descriptions, the description is not complete enough to invoke correctly. It omits the actual Slack schedule_message argument shape, when approval_ref is required, what effect value to claim, and how this operation relates to post_message or delete_scheduled_message. The output schema exists, so return values are not the gap, but the input contract remains underspecified.

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 must carry the parameter documentation, and it does add one-line meanings for project_id, project_ref, connector_account_ref, idempotency_key, effect, and approval_ref. However, the central 'arguments' parameter is left as a circular 'JSON string of arguments for the connector operation', so an agent still cannot determine what payload Slack schedule_message requires, such as channel, text, or post_at. This is partial compensation, not full.

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 only restates the tool's identity: 'Slack connector operation schedule_message (platform tool slack.schedule_message)'. It never explains what scheduling a message entails, such as delayed delivery or required channel/time fields, so it is essentially a tautological label rather than a purpose statement. It also does not distinguish this tool from siblings like slack_post_message or slack_delete_scheduled_message.

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?

No when-to-use guidance is provided. The only contextual sentence, 'Routes only through the exact project/account governed connector authority', is an access constraint, not a usage criterion. There are no alternatives or conditions that would help an agent select this tool over other Slack messaging tools.

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