Ask Sentinel (SocialWTF In-House AI Assistant)

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=false, and destructiveHint=false, so the safety profile is covered. The description adds genuinely non-derivable behavior: it runs on in-house model infrastructure with no external API cost, works with or without a registered account, and automatically attaches a session token when available — all of which affect how an agent should call it. It stops short of noting that answers are non-deterministic and may take longer than a direct tool call, and 'draft posts' sits slightly in tension with the read-only hint unless the agent infers drafting is not publishing.

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: identity and capability first, disambiguation last. It is a single dense paragraph and mostly earns its sentences, though the 'zero outside API costs' phrase is product marketing rather than decision-relevant information 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?

An output schema exists, so return values need not be explained, and the description covers identity, capabilities, auth behavior, and the sibling distinction. Minor gaps remain: nothing about latency, non-deterministic answers, or whether Sentinel can trigger mutating actions on the agent's behalf, which matters for an open-world, non-idempotent tool.

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?

There is a single parameter with 100% schema description coverage, including length bounds and an example prompt, so the schema carries the semantics. The description adds the notion of what kinds of questions the prompt can contain, but no format, phrasing, or scoping advice beyond the schema's own example. Baseline 3 applies.

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: 'Converse directly with Sentinel, SocialWTF's in-house autonomous AI assistant,' and then enumerates concrete capabilities (catalog search, music/stem discovery, post and profile search, price comparison, post drafting, roadmap/architecture updates). It explicitly distinguishes itself from the sibling socialwtf_message, so an agent can route between them without opening either schema.

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 clear when-to-use context by listing the task classes Sentinel handles and by naming the alternative it is not ('Unlike socialwtf_message (which sends DMs to connected peers)'). What it does not do is tell the agent when to prefer a direct deterministic sibling (e.g. socialwtf_find_user or socialwtf_browse_ai_directory) over asking Sentinel in natural language, which is the main routing decision an agent faces here.

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