AI Architectures

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

Beyond the annotations, it discloses important behavior: changes are made as a new version, earlier versions remain in the studio, and credits are spent (usually 60 to 600 per change). These details are consistent with destructiveHint=false and provide cost/versioning context that an agent needs before invoking a mutation.

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 trigger condition and examples, then covers versioning, cost, and the required follow-up call. Every sentence adds relevant operational context with no filler.

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 mutation complexity, the description covers versioning, cost, and post-call workflow, and an output schema exists for return values. The main omission is guidance on where to get drawing_id before calling, though the sibling tools make that inferable.

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 50%. The 'change' parameter is already documented in the schema and the description adds useful examples, but 'drawing_id' has no schema description and is not explained in the description, so the definition only partially compensates for the coverage gap.

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 states a specific verb and resource: changing one of the user's CAD drawings in words. It gives concrete natural-language examples and distinguishes the operation from read/list/start siblings by emphasizing modification via drafter.

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 clearly says when to use the tool: when the user asks to change a CAD drawing in words, with multiple examples. It also says to call get_cad_drawing afterward, but it does not explicitly name when-not conditions or point to the exact sibling for obtaining drawing_id.

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

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

Beyond the readOnly/idempotent/non-destructive annotations, the description discloses substantial behavior: returned fields include drafter commentary, room names, a preview image, a studio link, and account-gated DXF/DWG/PDF links; download links expire after 10 minutes and must be re-fetched. It also explains the blocking wait semantics for running drawings, which is exactly the kind of context annotations do not cover.

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 purpose and entry point are front-loaded in the first clause, and nearly every phrase carries useful information (returned artifacts, link expiry, waiting). However, it is a single dense sentence with nested parentheticals, so readability could be improved by splitting the return-contents and wait behavior into separate sentences.

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, annotations establish the safety profile, and the schema fully documents both parameters. The description fills the remaining gaps—what the response contains, link lifetime, account gating, and blocking wait behavior—leaving nothing an agent needs in order to call it correctly.

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 drawing_id and wait_seconds are already documented in the schema, including the wait_seconds default and maximum. The description restates the wait behavior ('waits up to wait_seconds') without adding format or edge-case detail beyond the schema, so the baseline of 3 is appropriate.

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 gives a specific verb and resource ('check a drawing') and anchors it to the exact lifecycle tools that produce one ('start_cad_drawing', 'list_my_cad_drawings'). It also enumerates what is retrieved (status, drafter feedback, room names, preview, links), so an agent can distinguish it from change_cad_drawing or prepare_cad_drawing_link without opening the 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 clearly says when to use this tool: after start_cad_drawing or when a drawing came from list_my_cad_drawings, and it explains the waiting behavior for in-progress drawings. It does not explicitly exclude cases or name sibling alternatives for mutation (e.g., change_cad_drawing), so it falls short of full 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.

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

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=false and destructiveHint=false, so the safety profile is fully covered. The description adds only usage timing, saying nothing about auth requirements, caching, or return content, though the existing output schema covers the latter.

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?

A single front-loaded sentence stating the trigger and the resource, with no filler. Every clause earns its place.

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 zero parameters, full annotation coverage and an output schema, the definition has all structural support it needs. The description could add a note that the balance is account-wide rather than per-drawing, but nothing essential 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline is 4. The description correctly implies no inputs are needed.

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 names the resource (AI Architectures credits/account balance) and implies a read, so an agent can tell it retrieves remaining credits. It doesn't use an explicit verb like 'retrieve' and doesn't frame itself against siblings, but no sibling touches credits, so confusion risk is low.

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 an explicit trigger: when the user asks how many credits are left before starting or changing a drawing, which maps onto start_cad_drawing and change_cad_drawing. It lacks any when-not guidance, but the trigger condition is concrete enough to route correctly.

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

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

Annotations declare readOnly/idempotent/non-destructive and the description is fully consistent with them. Beyond the annotations it adds the crucial behavioral fact that no work is performed here — it only returns a page and the user uploads the photo themselves — which prevents an agent from expecting a rendered image back. It does not mention whether these renders consume credits, which the sibling get_credit_balance implies are tracked.

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 trigger condition is front-loaded and the return behavior is stated at the end in one short sentence. The middle is a long comma-separated list, but each item earns its place as an intent-to-enum mapping rather than filler.

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 an output schema present, the description needn't describe the return payload, and it still usefully says the response is a page URL plus an upload instruction. For a single-parameter routing tool this is close to complete; only the cost/credit implication is unaddressed.

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%, so the enum values and their terse 'What the user wants to do' description are already documented. The description goes beyond that by translating natural-language user intents ('virtual staging', 'before/after examples', 'clean floor plan image from a sketch or scan') into the corresponding enum members, which is exactly the mapping an agent needs to pick a value.

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 states a concrete outcome — it returns the web page that performs a specific AI Architectures imaging task, and the user uploads their photo there. The enumerated task list makes the resource scope unambiguous. It does not, however, explicitly contrast itself with overlapping siblings such as get_cad_drawing or start_cad_drawing, so an agent must infer the boundary from the task names alone.

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 opening clause gives a clear trigger condition ('when the user wants ... from a photo or image') and lists eight concrete scenarios that map to the actual work. There are no explicit exclusions or named alternatives, which matters here because 'a CAD drawing from a sketch' overlaps conceptually with the sibling CAD tools.

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

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world behavior, so the safety profile is covered. The description adds genuinely useful context beyond that: the response is exhaustive ("every floor plan image", "all free download links") and enumerates the download formats (PDF plan set, DXF per level, IFC, GLB), and the word "free" implies some links may be gated.

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?

One sentence, front-loaded with the purpose, then the enumerated payoff. No filler and nothing repeated from the annotations or schema beyond what routing requires.

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 one-parameter read tool with rich annotations and an output schema, the description covers purpose, provenance of the input, and the scope of the payload. Minor gap: it says nothing about behavior when the slug is unknown or the plan has no free downloads.

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% and the single slug parameter is already documented as "The plan slug from search_house_plans." The description's reference to sourcing a plan from search_house_plans reinforces the same fact rather than adding new semantics such as format or validation behavior, so the 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?

Specific verb (show/retrieve) plus a specific resource (one house plan) and it enumerates exactly what detail is returned: description, every floor plan image, and all free download links. It explicitly distinguishes itself from search_house_plans by positioning this as the detail view of a result found there.

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?

"Use this to show one house plan from search_house_plans" makes the upstream prerequisite and the selecting scenario clear in a single clause. It stops short of explicit exclusions (e.g., what to do if you only have a name, or not to call it in a loop for a list), so it is clear context rather than full 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.

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world, so safety is covered. The description adds real value beyond them: the id is opaque, unique, and stable across token refresh, reconnection, and email/name changes — exactly the fact an agent needs to decide whether it can cache it.

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?

Two sentences, zero filler, with the identity-and-stability guarantee front-loaded before any caveats.

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 an output schema present and annotations covering safety, the description is nearly complete; the only omission is any hint about auth failure or error behavior, which is minor for a zero-arg read.

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?

Zero parameters, so the baseline is 4. The mention of 'the opaque id' refers to the return value rather than a parameter, which the output schema already covers.

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?

Specific verb ('Return') plus a precisely scoped resource ('the AI Architectures account behind this connection'), and it clarifies that the opaque id is the account id. Nothing among the CAD-drawing siblings could be confused with it.

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?

Usage is only implied — an agent infers it should call this to identify/cache the current account. There are no explicit when/when-not statements or named alternatives, though the sibling set (all CAD drawing operations) makes the choice fairly obvious.

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

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

Annotations already cover the safety profile (readOnlyHint, idempotentHint, destructiveHint=false, closed-world), so the description's added value is the ordering guarantee ('newest first') and the live-state field ('whether one is being drawn now'), both genuinely useful. It omits any mention of result capping or pagination, which matters because the limit maxes at 30.

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?

Two sentences, zero filler: the usage condition comes first, the result shape second. Every clause carries information not present elsewhere.

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-value detail is optional, yet the description usefully summarizes it. The main gap is that it never signals that the list is capped (default 10, max 30), leaving the agent unaware it may need to widen the limit for a complete inventory.

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 0% for the single 'limit' parameter, and the description never mentions a limit, page size, or truncation behavior. With the lowest coverage tier, the description is expected to compensate, and here it provides nothing beyond the schema's type/default/max.

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?

Specific verb ('Lists') plus resource ('drawings in the Plan Chat CAD studio') with an explicit ownership scope ('their own'). The scope word 'own' alone distinguishes it from show_community_cad_drawings, and the stated return fields (id, title, version count, in-progress flag) further pin down what the agent gets back.

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 a clear triggering condition: 'Use this when the user asks about their own drawings.' The ownership qualifier implicitly excludes the community listing and single-drawing siblings, but it never names get_cad_drawing or show_community_cad_drawings as alternatives, so routing for a single drawing or a community browse is left to inference.

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

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

Annotations already declare readOnly/idempotent/non-destructive, but the description adds the crucial cost and side-effect guarantee: nothing is drawn or charged until the user presses send on the site. That is exactly the non-obvious behavior an agent needs to reassure a user about.

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?

Two sentences, front-loaded with the usage condition and ending with the return value and cost guarantee. Dense and nearly waste-free, though the first sentence is a long clausal 'or ... or ...' chain that could be tightened.

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?

Output schema exists and annotations cover safety/idempotency, so the description only needs to explain the trigger conditions and what the link does — both are covered, including the no-charge caveat. Nothing an agent needs to call this correctly 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?

Only one parameter, and the schema documents it fully (building type, rooms, sizes, storeys, plot, any language). The description adds no format or content guidance for 'brief' beyond that, so the schema does all the work — baseline 3.

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 and resource (prepare a link that opens the Plan Chat CAD studio) and scopes it precisely: for users who want a CAD DXF/DWG floor plan but aren't signed in here or prefer the website. The conditions cleanly separate it from start_cad_drawing-style in-app generation without needing the schema open.

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 three concrete triggering conditions (not signed in, prefers the website, wants to attach a sketch there), which is explicit when-to-use guidance. It never names the in-app alternative (e.g. start_cad_drawing) so the routing is implied rather than stated.

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

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

Annotations already declare readOnly/idempotent/non-destructive, and the description goes further: library size (~500 plans), per-plan contents (floor plan image, room sizes, free PDF/DXF/IFC/GLB downloads), and the return shape (plan cards linking to the plan page and CAD studio). It also advises that filters are optional, adding behavioral context beyond structured fields.

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?

Front-loaded with the trigger condition, followed by library/return details and a filter-usage note; every sentence carries information. The download-format enumeration is slightly dense but still earns its place by telling the agent what users get.

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 an 8-parameter filtered search with an output schema already present, the description covers purpose, trigger, result shape, and filter behavior – more than enough for correct invocation. Nothing an agent needs 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 coverage is 88%, so the schema documents nearly every parameter, and the description correctly doesn't repeat those details. It does add one useful semantic point – that all filters are optional and should only be applied when the user asked – which is guidance the schema cannot convey.

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+resource (search a library of ~500 free house plans) and adds concrete examples of query intent plus what each plan contains. An agent can distinguish this from get_house_plan (single plan) and from the CAD-drawing siblings without opening any 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?

Opens with an explicit trigger ('Use this when the user wants ready-made house plans...') and gives illustrative example queries, so the when-to-use condition is unambiguous. The one gap is it never names a sibling alternative or a when-not-to-use case (e.g., fetching a known plan via get_house_plan), which keeps it short of a 5.

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

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world behavior, so the safety profile is covered. The description adds real value beyond that by characterizing the payload: preview, source brief, free DXF download, and a link to draw a similar one, plus that the output is unretouched genuine output. It does not mention pagination or the default/max item count.

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?

A single front-loaded sentence that starts with the usage trigger and then packs in scope, source, and per-item contents. No filler, no repetition of the title.

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 an output schema present, return values need not be spelled out, and the annotations fully cover the safety profile. The only residual gap is guidance on the 'limit' parameter and whether results are paginated, which is minor for a two-optional-param listing 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?

Schema coverage is 50%: 'query' is documented in the schema (with examples like 'townhouse', '3 bedrooms') while 'limit' is only constrained by min/max/default. The description mentions neither parameter, so it adds no meaning beyond the schema — adequate but not compensating for the coverage gap.

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 gives a specific verb and resource — 'Lists published drawings from the Plan Chat CAD studio' — plus the nature of the content ('real, unretouched output'). It implicitly distinguishes itself from list_my_cad_drawings via 'community/published', but never names that sibling outright.

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 opening 'Use this when the user wants to see what the AI drafter draws, or examples of AI-made CAD floor plans' gives a concrete trigger tied to user intent. There are no explicit exclusions or named alternatives, so an agent must infer that 'my drawings' routes elsewhere.

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

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

Annotations only declare non-read-only, open-world, non-idempotent, non-destructive; the description adds the costly, consequential details: account requirement, credit spend of 700–1,800 per drawing with a pointer to get_credit_balance, and a 1–5 minute asynchronous runtime before results are retrievable. This is exactly the behavior an agent needs before committing the user's credits.

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?

Front-loaded with the activation condition, then prerequisites, cost, latency and next step in that order. Every clause carries decision-relevant information; nothing is repeated from the title or annotations.

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 non-idempotent, credit-spending, multi-minute generation tool with a nested sketch object, the description covers trigger, prerequisite confirmation, cost, latency and the follow-up call. An output schema exists, so omitting a return-value breakdown is fine; the drawing_id hand-off is still noted.

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 explains brief, units, sketch and sketch_url. The description adds only mild context — that the sketch may be an attached photo/screenshot and is optional — and says nothing extra about the units enum or the brief's required content. Baseline 3 is appropriate.

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 and resource ('draw or design a floor plan as a real CAD drawing') and enumerates the produced artifact (layered, dimensioned plan with walls, doors, windows, furniture, dimensions, room names/areas). This clearly separates it from get_cad_drawing (retrieve) and change_cad_drawing (modify) without opening any 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?

Gives an explicit trigger ('when the user asks to draw... and wants it made now') plus a prerequisite ('confirm the brief with the user before starting') and the follow-up route ('then call get_cad_drawing with the returned drawing_id'). No explicit when-not or pointer to search_house_plans/get_house_plan for users who want an existing plan rather than a new drawing.

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