Ask ArchiGPT (architecture & design expert)

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

Annotations already declare the safety profile (readOnlyHint false, destructiveHint false, openWorldHint true, non-idempotent), so the description's job is to add what they cannot. It does so meaningfully: cost of 1 credit per ~3000 words, the statelessness of each call, and the image-attachment behavior. It still doesn't describe response shape or latency, but this is solid added 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?

Three front-loaded sentences with no filler; the capability list, the image instruction, the statelessness warning, and the credit cost each carry distinct information. Slightly dense in the opening enumeration, but nothing is wasted and the most actionable guidance comes early.

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?

With only one required parameter, no output schema, and annotations covering safety, the description supplies what an agent actually needs: scope, image handling, statelessness, and cost. The only unresolved point is the mild tension between 'each call is a standalone question' and the persona_id parameter that 'remembers this conversation'; the description never reconciles those, and no return-shape note exists (acceptable given no output schema).

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 baseline is 3. The description goes beyond the schema for the two semantically tricky parameters: it explains that the message must be self-contained ('put the details it depends on into the message') and that an image should be attached in order to discuss it, which clarifies intent rather than just repeating field definitions.

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?

States a specific verb (Ask) and resource (Luw.ai's ArchiGPT, an AI architect) and enumerates concrete capability areas: design advice, feng shui, space planning, materials/colors, technical questions, and square-meter estimation from an image. That capability list cleanly separates it from generation-oriented siblings like luw_interior_design, luw_exterior_design, or luw_render, which produce assets rather than answer questions.

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?

Gives clear operating context: attach an image when the question is about an image, and treat each call as a standalone question so all dependent details go into the message. It never explicitly names an alternative sibling or states when NOT to use this (e.g. when the user wants a generated render instead of advice), so it falls short of a full 5.

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