Linkora Source

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

Annotations already declare the safe read-only, idempotent profile, so the bar is lower; the description still adds real context by listing what is returned (line items, commission band, payment timing, exclusions) and the key caveat that it is an estimate not a quotation and that >100 km travel is flagged rather than priced.

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 tight sentences, front-loaded with the computation performed, then outputs, then the estimate/scope caveat. Each sentence carries distinct information 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?

With no output schema, the description usefully enumerates the return contents and the estimate/flagging caveats, which is enough to call a stateless calculation tool correctly. The one gap is the unresolved relationship to get_pricing.

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 each of the six inputs with examples (man-days, SKU counts). The description adds no per-parameter meaning beyond what the schema provides, making the baseline 3 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 (estimate/arithmetic) and resource (fees from published rates) with scope: per-job checks and/or commission for an order value. Clear and distinct in function, but it never names or differentiates itself from the sibling get_pricing, which an agent could easily confuse it with.

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 implied by the mention of order value and per-job checks, so an agent can infer it is for producing a fee estimate. However, there is no explicit when-to-use vs get_pricing, nor any stated prerequisites or exclusions guiding selection between the two pricing-related 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, closed-world, non-destructive behavior, so the safety profile is fully covered. The description's added content (what the profile covers, including exclusions) is informative but is more content enumeration than behavioral disclosure; no auth, freshness, or size expectations are given.

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 leads with the return contents, then the usage cue. Dense but readable; slightly list-heavy rather than wasteful.

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 no-parameter, read-only info tool with no output schema, the description appropriately enumerates what the response will contain and when to reach for it. Nothing an agent needs to invoke it 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?

The tool takes zero parameters, so the baseline is 4 – there is nothing for the description to disambiguate.

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 a concrete resource and enumerates its contents (identity, location, money flow, buyer types, exclusions, contact), so an agent knows exactly what it fetches. It never distinguishes itself from siblings like list_buyer_types or get_pricing, whose subject matter it partially overlaps.

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?

'Start here to decide whether a buyer's need is in scope' gives a clear situating instruction that positions the tool as an entry point. It stops short of naming alternatives or exclusion criteria for when another tool should be used instead.

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 and destructiveHint=false, so the safety profile is covered. The description earns credit by disclosing that the answers are 'published' (curated, not live-computed) and by explicitly stating what is NOT covered (freight, customs, warehousing, design), which prevents the agent from expecting answers that do not exist.

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 front-loaded sentence with no filler; the long topic enumeration is dense but each item carries routing value. The trailing 'Optionally filter by a keyword' is second-position where it belongs.

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 single-optional-parameter read-only lookup with no output schema and full annotation coverage, the description gives sufficient scope information — including negative scope — for an agent to call it correctly. Only the filter's match behavior (substring vs. semantic) is left unstated, a minor 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?

Schema description coverage is 100% and the single query parameter's meaning is fully documented in the schema with examples. The description's 'optionally filter by a keyword' merely restates the parameter's optionality without adding matching semantics, 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 names the resource (published FAQ answers) and enumerates the topic scope — scope, minimum order, payment, failed inspections, refunds, NDAs, samples, absences, non-offerings — so an agent knows exactly what content lives here. It is clear but does not distinguish itself from the sibling search_guides, which also returns 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?

Usage is only implied: the topic enumeration hints at when this tool answers a question, and 'optionally filter by a keyword' describes the filter's optionality rather than when to choose this over search_guides. No when-not-to-use or alternative routing is 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 readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is covered. The description adds genuinely useful behavioral context by disclosing the scope of what is returned (rates, banded commissions, retainer, examples, exclusions, travel/payment terms), which matters because there is no output schema. It could state whether rates are current/dated, but the added value is real.

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 sentence with the key qualifier (USD) front-loaded and no filler. The parenthetical enumeration is dense but every item is a distinct content category, so it 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?

For a parameterless, read-only retrieval tool with no output schema, the description is complete enough: it covers what content is available without needing to explain arguments or return structures. The only meaningful gap is the absence of routing guidance against estimate_fees.

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 the baseline is 4 and there is no parameter semantics to compensate for. The description correctly adds no spurious argument guidance.

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 a specific resource (published prices/rates in USD) and enumerates the exact content categories returned: per-job checks, commission bands, retainer, worked examples, exclusions, travel and payment conditions. An agent can tell it is the static rate-list retrieval tool. It does not, however, distinguish itself from the sibling estimate_fees, which an agent might confuse it with.

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, no prerequisites, and no mention of the natural alternative estimate_fees (static published rates vs. a computed estimate). The agent must infer the routing decision entirely on its own.

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 closed-world behavior. The description adds useful content about what is returned: explicit 'fits when' / 'does not fit when' conditions and the page URL, plus the assurance that matching needs no inference.

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 no filler. The first front-loads what is listed and returned, and the second states the intended use.

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, parameterless read tool with annotations covering safety, the description is complete. It explains the returned content and usage, and no output schema is needed because the description names what is returned.

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 per the rubric the baseline is 4. There are no parameters whose semantics need to be explained.

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 the specific resource: the six buyer types served, with fit conditions and page URLs. It is clear enough to distinguish from siblings like list_services or get_faq, but it does not explicitly name any alternative tool.

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 a clear use case: 'Use it to match a buyer's situation without inference.' However, it does not state when not to use it or name a substitute tool, so exclusion guidance is absent.

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 closed-world, so safety is covered. The description adds genuinely useful context by enumerating the shape of the returned content per service, which matters since no output schema exists. It stops short of saying whether the catalog is static or user-specific.

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 sentence that front-loads the count and names of the four services, then the per-service fields. Dense but every clause carries information; slightly list-heavy for one sentence but no waste.

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 does the work of explaining what the agent will receive, and it names all four services plus the per-item breakdown. It omits nothing critical for a zero-parameter catalog read, though a hint about static versus dynamic content would round it out.

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; there is no parameter semantics to add or omit. The description correctly focuses on return content rather than inventing input options.

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 enumerates the exact resource contents — the four named services plus the per-service fields (what happens, what the buyer provides/receives, cost, timing, exclusions). This lets an agent tell it apart from pricing or FAQ siblings. The verb 'list' is only implicit in the name, so it does not quite reach a 5.

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 statement of when to call this versus alternatives such as get_pricing, estimate_fees, or get_faq, even though the mention of 'cost and timing' overlaps with those siblings. Usage must be inferred from the content list alone.

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 bar is covered. The description nonetheless adds genuine behavioral context beyond them: 'Nothing is submitted' clarifies that generating the link has no side effect, and it describes the handoff (buyer supplies name, company, email themselves).

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 tight sentences, front-loaded with the trigger and outcome, followed by the no-submission clarification and the privacy constraint. No filler or 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 no output schema, the description still tells the agent what is produced (a pre-filled brief link plus WhatsApp/email alternatives) and that no submission occurs. Combined with 83% schema coverage, 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 83%, so the schema already explains brief, target_market, order_value_band and language. The description only echoes one schema rule ('Never include personal details in the arguments'), and does not explain semantics of primary_need or how order_value_band affects commission. 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 concrete verb and artifact: turn a buyer requirement into a pre-filled brief link for the Linkora Source form, with WhatsApp and email alternatives. This is unambiguous and clearly distinct from sibling tools like estimate_fees, get_pricing or list_services.

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 condition ('When a buyer wants a quotation'), which tells the agent exactly when to reach for this tool. It does not name alternatives or exclusions, but the sibling set is functionally unrelated so the risk of misrouting is low.

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/openWorld=false, so safety is covered. The description goes beyond them by disclosing the return shape (titles, URLs, a direct answer, last-updated date) and the citation purpose, which is valuable given there is no output 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?

Two sentences, front-loaded with the search action and corpus, and the return-value sentence earns its place by compensating for the absent output schema. The long parenthetical is dense but informative rather than wasteful.

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 read-only search with no output schema, the description supplies the corpus scope and the return fields an agent needs. Missing only explicit alternative routing, which is a minor 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?

Schema coverage is 100%, so both query and limit are already documented in the schema. The description adds no format, language, or limit meaning beyond 'search', 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?

States a specific verb (search) and resource (Linkora Source's guides and comparisons), then enumerates the covered topics so the agent knows the corpus boundary. It is readily distinguishable from siblings like get_faq and list_services.

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: the parenthetical topic list signals when the tool is relevant, and 'for citing' hints at intent, but there is no explicit when-to-use/when-not comparison against get_faq, get_company_profile, or other siblings. Adequate but leaves routing to inference.

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