Agentic Fabrication Network (AFN)

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

With no annotations provided, the description carries the full burden, and it delivers: it discloses that the payment page collects shipping/email, that the tool returns checkout_url, and that UFP places the vendor order automatically after payment. It does not, however, mention idempotency or any side effects beyond order placement, so a small deduction is warranted.

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 four sentences covering purpose, timing, parameter rule, and return behavior—every sentence earns its place. It is front-loaded with the primary action and contains no redundant 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?

For a complex tool with 17 parameters and no output schema, it provides the essential workflow: when to call, what to pass, how to handle optional address fields, and what to do with the returned checkout_url. It skips detailed per-parameter explanations for fields like return_url and billing_*, but the general 'only if volunteered' rule and schema descriptions partially fill that gap, so it is not fully complete.

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 only 47%, so the description must compensate. It does so by stating 'Only pass address fields if the user already volunteered them', which covers the many optional address/billing params, and it implies that offer_id and shipping_option_id are required. This adds meaning beyond the schema without describing every field.

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 'Create the order and get a hosted payment link for a chosen offer', which uses a specific verb ('create') and resource ('checkout') and clearly distinguishes this from sibling tools like get_order_status and list_orders. The scope is unambiguous and action-oriented.

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 explicitly states when to call ('as soon as the user picks an offer + shipping speed'), what not to do ('do NOT ask for their address first'), and when to pass address fields ('Only pass address fields if the user already volunteered them'). This gives clear timing and exclusion guidance without needing to name alternatives.

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?

With no annotations, the description carries full burden and meets it: discloses a ~40s blocking behavior, the need for immediate invocation, and the lack of added value if board is already populated. It also implies the tool is safe to call without side effects, though not explicitly stating read-only.

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 dense sentences, each essential: condition+action, execution instructions, and a critical exclusion. Information is front-loaded with the primary purpose and constraint. No filler or repetition.

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?

Despite no output schema, the description explains the return value ('full board of offers'), the expected wait time, and the exact preconditions. It is sufficiently complete for a single-parameter tool with clear behavior, and it positions itself against sibling tools without needing further context.

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 schema already provides 100% coverage with 'Quote id from the still-quoting response', so the baseline is 3. The description adds no substantive parameter meaning beyond reinforcing 'just quote_id' and 'immediately', which are usage directives rather than semantic details.

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 uses a specific verb ('waits for... and returns') and clearly identifies the resource ('vendors' offers') and the trigger (empty board response). It sharply distinguishes from siblings by specifying the exact condition under which this tool is used, unlike generic 'finalize' naming.

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?

Explicitly states when to use (only after an empty board response and told to call it), how to use (call immediately, with just quote_id, say nothing substantive), and when NOT to use (never on a response that already listed offers). This provides clear decision-making rules and practical timing 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?

With no annotations, the description carries full burden and excels: it discloses substitution behavior for unknown materials/sizes, UFP auto-routing of design files, that UFP's saved intent applies and user-stated wins, that reorders re-shop across all vendors, that locked parts require share_key, and that offers return across vendors. It also explains tradeoffs like omitting material to let every maker bid, and notes where the 'routing.also_possible' field appears, which is valuable behavioral context beyond the schema.

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 long, but every sentence earns its place: it packs essential routing rules, file-format support, reorder semantics, and parameter guidance into a structured flow. However, it could be slightly tightened (e.g., the material parameter description inside the schema is exhaustive, and the paragraph-style listing of file formats could be trimmed). Not every sentence is strictly necessary, but all are informative, so a 4 is fair.

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 complex 41-parameter tool with no output schema and no annotations, the description is remarkably complete: it covers design-file input modes, process routing, reorders, locked parts, budget/review filters, shipping ZIP guidance, and special-case behaviors (e.g., decal cut style, bend_count for CNC, powder coat for sheetmetal). It even warns against interrogating the user and tells the agent to pass verbatim terms. The description leaves few gaps for an agent to misinterpret.

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?

Despite 100% schema coverage, the description adds significant semantics beyond parameter names: it explains the strategic meaning of material ('omit instead and each process quotes across its stocked materials so every maker can bid'), clarifies quantity defaults and vendor-minimum behavior, and defines the design_file/part_number/attachment_urls relationship. It resolves ambiguities like 'free-form asks resolve to the closest stocked material with a substitution note', which the schema alone does not convey. Parameter semantics are richly enhanced.

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+resource ('Get ranked, purchasable offers... for fabricating a physical item') and clearly distinguishes the tool from siblings by emphasizing it returns ranked offers like Google Flights, contrasting with checkout/order-status/refinement siblings. It names the main input modes (design file, URL, part_number) and process options, making the scope unmistakable.

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 description gives explicit when-to-use guidance: omit process when a user drops a file (UFP routes it), use part_number INSTEAD of design_file for reorders, require share_key for locked parts, and prefer design_file over file_url. It also notes that vendors parameter is usually OMIT and only passed when explicitly named, giving clear alternatives and exclusions.

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?

With no annotations, the description fully discloses behavior: returns caveats-first facts, tags sources (vendor-cited vs general), provides strength ladders, and explicitly states it never gives safety guarantees. This is comprehensive transparency.

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 detailed but well-structured, front-loading the core purpose. It is slightly long, but every sentence adds essential information. Could be tightened, but still efficient for the complexity.

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 no output schema, the description thoroughly explains what is returned. It covers all relevant aspects for a 3-parameter tool, including what the tool does and its limitations. Complete for its purpose.

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% with all parameters documented. The description adds value by explaining how 'question' is used to mine for intent, but does not significantly add beyond schema for 'process' and 'material'. Thus slightly above baseline.

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 clearly states the tool provides material intelligence for specific questions (strength, durability, heat, outdoor). It lists concrete outputs like published specs, comparative ladders, and finish options. The purpose is distinct from sibling tools which handle orders, quotes, and reviews.

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 description explicitly instructs to call the tool BEFORE answering material questions and to relay facts. It sets boundaries by stating it supplies facts only, not fitness or safety guarantees. While it doesn't mention alternatives, sibling tools are unrelated, so no confusion.

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?

No annotations are present, so the description carries the full burden. It discloses that this is a read operation returning status, ETA, and tracking, but lacks details on response structure, potential errors, or required permissions. Adequate for a simple read tool, but not rich.

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 entire description is one concise sentence that front-loads the action and key data points. No unnecessary words or repetition.

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 simple single-parameter lookup, the description covers the key return values (status, ETA, tracking). It does not explain how to obtain order_id, but sibling tools like list_orders likely provide that. The lack of an output schema is partially compensated by listing return items.

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 schema has only one parameter, order_id, with no description coverage. The parameter name is self-explanatory, and the description references 'a UFP order,' but does not explain the format or source of order_id. Minimal addition beyond the schema, but the parameter is unambiguous.

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 clearly states the tool checks status, ETA, and tracking for a single UFP order. The verb 'check' is specific, and the resource scope distinguishes it from sibling tools like list_orders.

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 description implies it is for a single order's status, but does not explicitly state when to use it instead of alternatives like list_orders. No exclusions or when-not guidance is provided.

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?

The description discloses that the tool structures feedback into stars/facets, updates existing reviews on resubmission, and requires user confirmation. It also warns against embellishing comments. With no annotations provided, the description fully carries the burden of behavioral disclosure.

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 somewhat long but every sentence serves a purpose: purpose, structuring rule, confirmation requirement, update behavior, and reference to list_orders. It's dense but not wasteful, with no redundancy.

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 tool with no annotations and no output schema, the description covers purpose, process, facet mapping, confirmation step, and update semantics. It adequately equips an agent to invoke it correctly, including handling ambiguous order references.

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 schema already provides 100% coverage with descriptions for all parameters. The description adds value by mapping user phrases to facet scores ('the cut was sloppy' -> quality) and clarifying comment brevity. This goes beyond the schema's parameter descriptions.

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 clearly states the tool records a verified-purchase review for a UFP order, with a specific verb ('record') and resource ('review'). It distinguishes from siblings like list_orders or get_order_status by focusing on submitting feedback.

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 explicitly instructs to confirm the drafted review with the user before calling, and to use list_orders first to resolve which order. It also notes one review per order with update semantics. While it doesn't list alternatives or exclusions, these guidelines are clear and actionable.

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?

With no annotations provided, the description carries the full burden. It discloses the ordering behavior (newest first) and the returned fields. It does not explicitly state it is read-only, but the action of listing without side effects is implied. This is sufficient for a list tool, though a note about no state change would have been more transparent.

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 two sentences long, front-loaded with the main purpose, and includes a concrete example of usage. Every sentence provides value without redundancy.

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 no input parameters and no output schema, the description covers the essential return fields, ordering, and a practical use case. It also differentiates from sibling tools, making the context complete for an agent to select and invoke 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?

The tool has zero parameters, and the schema coverage is 100% by default. Per rubric, a baseline of 4 is appropriate since there are no parameters to explain and the description adds no param-specific semantics 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 clearly states the tool lists the agent's recent UFP orders with a specific set of fields and sorting (newest first). It also explicitly distinguishes its role from siblings by noting it resolves vague references before calling get_order_status or leave_review.

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 description gives explicit when-to-use guidance: to resolve vague order references into a concrete order_id. It also names specific alternative tools (get_order_status, leave_review) and indicates this tool should be used before them, providing clear context and alternatives.

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?

With no annotations, the description carries the full burden for behavioral disclosure. It does reveal that the tool is internal and that the board refreshes itself, and it warns that the board is already final. However, it does not specify what happens if the tool is called manually (errors, side effects, return value), leaving some ambiguity about actual runtime behavior.

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 two concise sentences that front-load the INTERNAL warning and immediately give actionable prohibitions. Every clause earns its place, with no filler or repeated schema 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?

Given that this is an intentional internal-only tool with a single well-described parameter and no output schema, the description covers the essential context: what the tool is for, who calls it, and why the agent must not call it. It lacks explicit return/error details, but for a tool the agent is explicitly forbidden from invoking, the guardrails are sufficiently complete.

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 input schema fully describes quote_id as 'Quote id the board is watching' with 100% coverage, so the description adds no additional parameter semantics. The baseline of 3 applies because the schema already handles the parameter information.

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 clearly states that the tool is an internal callback used by the offer board to refresh itself while vendors finish pricing, which goes beyond the title. It also distinguishes itself from refine_quote, warning not to use that tool for re-inspection because it paints a duplicate board.

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 explicit, non-ambiguous usage rules: 'Never call this yourself' and explicitly warns against using refine_quote to look at the board again. It explains that the provided board is already final for its turn, so calling this tool is unnecessary.

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?

With no annotations, the description carries full responsibility for behavioral disclosure, and it excels: it explains that material/quantity changes re-price via warm vendor sessions, that constraints drop offers instantly without re-pricing, that labeled refines coexist (max 4) while unlabeled refines replace the baseline, that sort ordering is instant and presentation-only, and that quote_id alone triggers a re-read. These are meaningful behaviors beyond the schema.

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 long and dense, but appropriately so for a tool with 25 parameters and multiple operating modes. It front-loads the core purpose in the opening sentence and uses dash-separated examples efficiently. Some redundancy exists (e.g., process/vendor/ships_from each repeat the 'constraint, not new quote' pattern), but each sentence carries usable information.

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 complexity (25 params, no output schema, no annotations), the description covers all major modes: narrowing, spec changes, scenario comparisons, sorting, and re-reading. It does not describe the return format, but with no output schema the description is expected to cover return behavior; the 're-read to pick up preview images' hint partially addresses this. It is complete enough for an agent to invoke the tool correctly in most cases.

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 76%, so the schema already documents most parameters. The description adds genuine value by mapping natural-language examples to parameters ('only US vendors' → ships_from, 'only show A3D Manufacturing' → vendors), clarifying the spec-change vs. constraint distinction, and explaining sort_order + sort_label for judgment-based ordering. This goes beyond a simple restatement.

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: 'Narrow an existing quote' and 'CHANGE its spec', immediately distinguishing it from quote creation or finalization. It enumerates distinct actions (narrowing, spec change, scenario comparison, sort, re-read) with concrete examples, making the tool's purpose unmistakable even among siblings.

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 description gives clear guidance on when to use this tool ('existing quote', 're-read'), what to pass for different intents (ZIP, deadline, processes, vendors), and what not to pass (material/quantity as requirements terms). It also notes presentation-only sorting vs. re-pricing, but does not explicitly reference alternative sibling tools by name or state when not to use refine_quote in favor of another tool.

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?

With no annotations, the description carries the full burden. It discloses that the message is relayed via the network account, that contact details and links are stripped, and warns against including them. This is significant behavioral context beyond a simple 'send'.

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 purpose, then usage guidance. Every clause adds value: the flow reference, the confirmation step, and the network sanitization warning. No wasted words.

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 absence of output schema, the description still provides enough context: when to use, how to use, and a critical behavioral caveat. It is complete for a two-parameter send action with strong usage guidelines.

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 schema already documents both parameters. The description reinforces that message is in the user's words and relayed, but adds little beyond what the schema provides.

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 clearly states the tool sends the user's answer to a maker's question about a UFP order. It references get_order_status, distinguishing this as the complementary action to surfacing the question.

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?

Explicitly instructs to confirm the answer with the user before sending and ties usage to get_order_status surfacing an open question. Also provides a clear exclusion: never include emails, phone numbers, or URLs the answer depends on.

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