Sabag 3D Studio

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered elsewhere. The description adds that the content is static business facts about a specific studio, but says nothing about freshness, caching, or response shape beyond the field list.

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 with zero waste: the content inventory comes first, the usage trigger second. Nothing is padded or restated from 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?

There is no output schema, but the description compensates by listing the returned fields explicitly (phone, WhatsApp, email, address, hours, area served, price level). Combined with annotations covering the safety profile and a fully documented param, an agent has everything needed 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%, and the single 'fields' parameter is fully documented in the schema including dot-notation syntax. The description never mentions this filtering parameter, so it adds nothing beyond the schema — 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+resource ('get_business_info' → contact details and facts about the studio) and enumerates the exact contents: phone, WhatsApp, email, address, hours, area served, price level. That enumeration makes it immediately distinguishable from siblings like get_faq or get_product.

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 before telling a person how to reach the studio' gives an explicit triggering condition rather than leaving usage implied. It does not name an alternative tool or state when not to use it, which keeps it out of the 5 tier.

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, idempotentHint, non-destructive, and closed-world, covering the safety profile. The description adds only topical content, no behavioral context such as result structure, freshness, or size of the FAQ set.

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 short sentence with zero filler, appropriately sized for a trivial read-only lookup. It is a fragment rather than a front-loaded statement of action, but nothing is wasted.

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 zero-required-param, read-only, no-output-schema tool with rich annotations, this is minimally sufficient: it tells the agent the content domain. It omits the one thing that would most help selection — routing guidance against search_site and the other get_* siblings.

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% and the single optional 'fields' parameter is fully documented in the schema, including dot-notation examples. The description adds nothing about it, 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?

The description expands beyond the name/title by naming the FAQ's content scope (prices, files, materials, timing, delivery), which hints at what an agent will retrieve. But it is a noun phrase with no verb and no explicit differentiation from siblings like search_site or get_business_info, which could plausibly surface similar content.

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 statement of when to use this tool, when not to, or which sibling to prefer. An agent must infer on its own whether a pricing question belongs here or in get_quote_options or search_site.

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, and non-destructive, so the safety profile is covered. The description's only added information is that the payload includes a description and FAQ, but it says nothing about behavior on a missing id, completeness of the record, or format.

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?

It is short, but the single fragment is under-specified rather than efficient — it conveys almost no actionable information and is not structured as a usable instruction.

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 no output schema, the description carries the burden of explaining what is returned; it only vaguely names two payload elements. For a lookup tool with a fields projection option, an agent needs to know the record shape and failure behavior, neither of which is present.

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%, with the id parameter documented ("The id from the list") and fields explained including dot-notation examples. The description adds no parameter meaning beyond the schema, 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?

The description is a noun phrase ("A product with its description and FAQ") that essentially restates the title "One product" without a verb or clear retrieval framing. It gives no differentiation from the sibling list_products or any hint that it fetches a single record by id.

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 indication of when to use this versus list_products, get_faq, or get_business_info. The single-product-by-id intent must be inferred entirely from the parameter name and the title.

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, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds that the returned project includes its full markdown description, but it does not mention not-found behavior, error handling, or whether field selection affects the response shape.

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 a single compact sentence with no wasted text. It front-loads the resource and return content, though it omits a verb that would make the purpose immediately unambiguous.

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 two-parameter lookup with rich annotations and a fully documented schema, the description is adequate but sparse. It explains the notable return content but does not address retrieval failure behavior or the relationship to the list tools, which would help an agent invoke 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%, and the schema documents both parameters, including the dot-path behavior for fields. The description adds no parameter-specific meaning beyond the schema, so the baseline score 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 identifies the resource (a past project) and notable return content (full markdown description), but it is a noun phrase rather than a clear verb+resource statement. It does not explicitly distinguish this single-project retrieval tool from the sibling list_projects or list_project_types tools.

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?

There is no guidance on when to use get_project versus list_projects or other siblings, nor any stated prerequisites such as obtaining the id from a list. Usage must be inferred from the tool name and required id parameter.

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 this as a read-only, idempotent, non-destructive, closed-world call, so the safety profile is covered structurally. The description adds a genuine behavioral trait beyond them: 'Free text is accepted too' tells the agent the returned choices are advisory rather than a hard enum, which affects how it should validate or constrain user input.

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 short sentences with no filler. The resource identity and the covered field groups are front-loaded, and the caveat about free text follows immediately after.

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 zero-required-parameter reference lookup with full annotation coverage, the description gives enough to call it correctly: what it returns, what fields it covers, and that the values are non-exhaustive. The only minor gap is not indicating the shape of the returned choice structure, which matters little since no output schema exists but the payload is trivially inspectable.

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 optional 'fields' parameter is fully documented in the schema, including the dot-notation behavior, so the description correctly does not repeat it. It adds nothing beyond the schema, which is acceptable at this coverage level but not value-adding.

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?

It identifies the resource specifically as the choice set for the sibling request_quote and enumerates the field groups covered (project type, scale, material, colour), so an agent can tell it returns form option data rather than records. It lacks an explicit verb ('returns'/'lists') and doesn't distinguish itself from list_project_types, which overlaps on the project-type dimension.

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?

Linking the tool to request_quote implies the workflow (fetch choices before composing a quote), but that sequencing is left for the agent to infer. There are no explicit when-to-use/when-not statements and no routing away from list_project_types or get_business_info, which are the plausible confusable siblings.

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, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description adds genuine business context beyond that — prices are quoted in ILS and availability is included — but says nothing about pagination behavior, result ordering, or catalog size limits.

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 short sentence with no filler, and the most useful detail (currency) is front-loaded. It is efficient rather than padded, though its brevity comes at the cost of specifying the action.

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 4-parameter list tool with no output schema, the description should at minimum state that it returns a paginated collection and what a product record contains. The ILS price and availability note partially covers the return shape, but paging and record structure remain undocumented.

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 page, per_page, search and fields are each documented in the schema itself. The description adds no parameter-level meaning beyond hinting that availability is filterable/relevant; baseline 3 applies where the schema does the heavy lifting.

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 and its payload ("Ready-made 3D-printed products with price (ILS) and availability"), which tells an agent what data it yields, but it never states the action (browse/list all) and does not distinguish it from get_product, list_services, or search_site. The listing behavior is only inferable from the tool name, not the description.

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?

There is no guidance on when to use this tool versus get_product (single-item lookup) or search_site, nor any note that search/page/per_page are the filtering and paging controls. The agent must infer usage entirely from the name and schema.

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. The description adds only the newest-first ordering; it doesn't mention pagination behavior or defaults beyond the schema, so added value beyond annotations is modest.

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 compact sentences, front-loaded with the resource and ordering, then the optional filter source. No wasted text.

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 read-only listing tool with full schema coverage and annotations, the description covers resource, ordering, and filter provenance. Pagination behavior is left to the schema, which is acceptable but makes it slightly incomplete.

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 baseline is 3. The description adds useful cross-tool linkage for the type parameter (slug from list_project_types), but says nothing about page, per_page, or the fields projection parameter.

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 resource (completed projects portfolio) and ordering (newest first). It doesn't explicitly contrast with get_project for single-project retrieval, but the plural/listing scope is clear enough to distinguish it from get_project and list_project_types.

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 when to use the type filter (a slug from list_project_types), but gives no explicit when-to-use vs. alternatives guidance, no mention of retrieving a single project via get_project, and no pagination usage context.

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, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered elsewhere. The description adds no behavioral context of its own — no indication of what the returned categories are, whether the list is static, or how they relate to projects.

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?

It is short and front-loaded, but that brevity comes from under-specification rather than efficiency — the single fragment carries almost no information. Length is fine; content is the problem.

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 read-only list tool with no output schema and complete annotations, the description still needs to say what a "category" record contains (e.g., an id and name usable when filtering or creating projects). Without that, an agent cannot confidently wire this tool's output into downstream calls.

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 a single optional parameter at 100% schema description coverage, the schema fully documents the dot-path field projection. The description neither repeats nor extends that, so the baseline of 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 categories of projects" is a noun fragment that restates the name and title (list_project_types / "Project types") in synonyms, without a verb or scope. An agent learns nothing it did not already know from the tool name.

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?

There is no guidance on when to call this versus siblings such as list_projects or get_project, nor any prerequisite or exclusion. Given the sibling set mixes list_* and get_* tools, a note that this returns type taxonomy entries rather than projects would have been valuable.

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, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description adds only 'with links', a small hint about returned content and no detail on ordering, pagination, or completeness — modest added value above the annotations.

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 compact sentence with no filler, front-loading the resource. It is slightly under-specified for its length, but nothing is redundant.

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 zero-required-param read tool with full annotations and no output schema, this is adequate but thin: the description never clarifies what a 'main page' entry looks like or how services and pages are mixed in one payload, which matters for an agent deciding whether to call it or a narrower sibling.

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 single optional 'fields' projection parameter is already fully documented in the schema, including the dot-notation example. The description adds nothing to parameter meaning, 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?

It names the resource and gives concrete content examples ('architectural scale models, custom 3D printing'), which helps, but never states the action (listing/retrieval) and muddles scope by lumping 'services' with 'main pages'. It also doesn't distinguish itself from the many sibling list_* tools (list_products, list_projects).

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, no exclusions, and no pointer to alternatives such as search_site or get_product for individual lookups. The agent must infer from the tool name alone that this is a catalogue-style listing.

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?

Goes beyond the annotations: it discloses that a reference number is returned and that the studio usually responds within one business day. The consent gating and the requirement for genuine contact details are additional behavioral context. It does not mention that repeated submissions create separate requests (consistent with idempotentHint=false), which would have earned a 5.

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 compact sentences with the action and the critical 'ask first' constraint front-loaded. Minor redundancy with the schema's field descriptions (e.g., 'describe the project in message'), but nothing that wastes the reader's time.

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?

There is no output schema, and the description fills that gap by naming the return value (reference number) and the expected turnaround. With ten parameters and no annotations about permissions, the consent precondition is well covered. A brief note on whether submission is fire-and-forget or whether follow-up is needed would make it 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 100%, so the baseline is 3. The description adds operational meaning beyond the schema: it specifies that the name must be the person's real name, that phone or email is the contact path, that the project goes in message, and, crucially, the timing rule for consent. This raises it above baseline, though it does not explain optional fields like project_type or due_date.

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 ('Send a quote request to the studio') and ties it to a familiar analogue ('like the site's quote form'). This is clearly distinguishable from every sibling, which are all read/list/search tools, without needing to open a 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 concrete preconditions: ask the person first, use only their real name and phone or email, and set consent true only after they agreed. It stops short of naming an alternative path (e.g., what to do if the person hasn't consented), so it is clear context without explicit 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?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so safety is covered. The description adds corpus scope (what is indexed), which is genuinely useful, but says nothing about result ranking, result shape, or the default limit of 10 — behavior the agent would want to know before calling.

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 short sentences, zero filler, with the capability stated first and the usage trigger second. Ideal front-loading for a search entry point.

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 3-parameter read-only search with no output schema, the agent still lacks any sense of what comes back (snippets, records, IDs) or how to paginate/refine beyond the limit and fields params. The corpus scope is stated but the result contract is not.

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 67%: query documents Hebrew/English input and fields documents the dot-path projection syntax, while limit relies on its name and default/max constraints alone. The description contributes no parameter meaning at all, so this sits at the baseline rather than above it.

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 (search) and enumerates the corpus it covers: pages, past projects, products and guides. That is enough to distinguish it from the point-lookup siblings like get_product and list_projects, though it never names them explicitly.

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 for any question about what the studio has done or sells" gives a clear positive trigger condition. It stops short of any when-not guidance or explicit routing to get_product/get_project for exact retrieval, so the agent must infer the boundary.

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