Joinery: ERP, ecommerce, CRM and accounting system integration quotes

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 by structured data. The description adds only that the payload is comprehensive in scope, without saying what happens for an unknown slug, whether an error is raised, or how large the response is. It neither contradicts nor meaningfully extends 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?

It is a single front-loaded sentence with a colon-delimited list, which is structurally sound and short. But several list items are vague ('what you get', 'any operations'), so brevity comes at the cost of specificity rather than being purely efficient.

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, so the description is the only source of return-value information, and it does gesture at the main content categories. Against the simplicity of a one-parameter read tool with rich annotations, that is roughly adequate, but the undefined slug and absent error/edge-case behavior leave gaps.

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 single parameter, slug, has 0% schema description coverage, so the description carries the full burden and does not meet it — 'slug' is never explained as the service identifier, its expected format, or where to obtain it. The items listed ('request fields', 'operations') describe response content, not the input, so they do not compensate for the schema 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 conveys that this is a detail-lookup for a single service and enumerates the kinds of content returned (request flow, response, scope/limits, fields, operations). However, it never states an explicit verb and shifts terminology from the tool name's 'proposition' to 'service', which leaves the agent to infer that these are the same entity. The singular framing loosely implies a contrast with list_propositions, but no explicit differentiation is made.

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 when-to-use guidance at all: nothing says to call this instead of list_propositions when the agent already has a slug, and nothing mentions the sibling tools. The description also never hints at what precondition must hold (a valid slug) before calling.

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 a closed-world scope, so the safety profile is covered. The description adds that results are one-line summaries grouped into 'lookups that run instantly' and 'requirements you can send', which is useful context but does not say how many items appear or what happens on an empty result.

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 with no filler, and the core purpose arrives first. The trailing colon clause is slightly cryptic in phrasing but does add the two-category framing rather than padding.

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 parameters, no output schema, and annotations carrying the safety profile, the description supplies most of what an agent needs: the resource, the summary-level detail, and the two categories of items. It could go further by stating that describe_proposition should follow for full detail, which is the main remaining gap.

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; the baseline is 4. The clause about instant lookups versus sendable requirements adds a little framing about what the listed items are, though it is really return-value information rather than parameter meaning.

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 ('List Joinery's services') and states the granularity of what comes back ('with a one-line summary'). It implicitly contrasts with describe_proposition by emphasizing one-line summaries, but never names that sibling, so the differentiation is left to inference.

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 can guess this is the entry-point catalog and that describe_proposition should be used for depth, and submit_request for sending a requirement. Neither the when-not case nor the alternative is stated explicitly.

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 annotations already declare this is a non-readonly, non-destructive, non-idempotent write, so the safety profile is covered. The description adds a useful behavioral detail—the submission is stored and assigned a reference number—but says nothing about permissions, side effects, notification behavior, or what the returned reference means.

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, front-loaded with the action and resource, with no filler. The brevity is efficient, though it borders on under-specification for a 10-parameter tool.

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 write tool with 10 parameters, nested objects, no output schema, and only 40% schema description coverage, two sentences are not sufficient. The description omits required-vs-optional guidance, the meaning of the reference number, and any indication of what happens after submission.

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 40% for 10 parameters, so the description is expected to compensate, and it adds no parameter meaning at all. It does not explain slug, need, action, budget, timing, quantity, geography, or requested_fields, leaving several nested objects effectively undocumented outside the schema's own sparse field 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 states a specific verb ("Send") and resource ("a requirement") with a target ("one of Joinery's services"), which is clear enough to tell it apart from the read-only siblings describe_proposition and list_propositions. The only wrinkle is terminological drift between 'request' in the tool name and 'requirement' in 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 when-to-use or when-not-to-use guidance and no explicit reference to the sibling tools. The description only says where a requirement goes, not under what circumstances an agent should submit one versus describing or listing propositions.

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