Adbull

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

The annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds that the content is a fixed set of company facts rather than a live or parameterized query, which is modest but useful context. With no output schema, it still does not say what shape the facts come back in.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

One sentence with the resource named first and the payload enumerated after it, so nothing is buried. The field list is dense but every item earns its place given the lack of an output schema.

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 describing return content, and the enumerated field list does that well. What is missing is the relationship to get_contact_options and whether the team/LinkedIn data is personal or organizational.

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 of 4 applies. The description correctly conveys that no input is needed by framing the response as a fixed set of facts.

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 resource (company facts about Adbull ApS) and enumerates the facts returned: address, CVR, contact details, opening hours, team roles/LinkedIn, and B-mærket certification. That distinguishes it from the sibling tools, which all cover different subjects (prices, services, articles, cases). It stops short of 5 because the tool name's relationship to the 'Om Adbull' title is never reconciled.

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 use this tool versus alternatives, even though it overlaps with the sibling get_contact_options on contact details. The agent must infer from the field list alone that this is the broad company-profile lookup rather than the contact-channel lookup.

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 and openWorldHint=false, and the description reinforces this with 'Nothing is sent by this tool' — a genuinely useful clarification, since a mention of a contact form could otherwise mislead an agent into thinking a submission occurs. It does not cover return format or freshness of the contact data, but the key behavioral risk is addressed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

One sentence, front-loaded with the payload ('links and details a person uses to contact Adbull'), with the non-obvious safety note tacked on last. No filler, 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?

There is no output schema, and the description compensates by enumerating what is returned (contact form links for two topics, phone, email). Combined with the safe-read confirmation, an agent has enough to call it correctly. Minor gap: no indication of whether phone/email are always present or depend on the chosen topic.

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 enum parameter is already fully documented in the schema, so the baseline is 3. The description does echo both enum branches in natural language ('new website (free design sketch)' vs. 'SEO and ads (free review)'), which slightly aids mapping between user intent and topic value, but it adds no new constraint such as the default when topic is omitted.

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 ('Get') plus the resource (contact links and details: contact form, phone, email) and even names the two contact-form variants. It is immediately clear what comes back. It does not explicitly contrast itself with siblings, but the resource is distinct enough that no confusion with get_company_info or get_prices is likely.

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 infer this is the tool for 'how do I reach Adbull' questions, and the topic split (free design sketch vs. free SEO/ads review) hints at when each path applies. There is no explicit 'use this when...' or exclusion against siblings such as get_services, which also describes Adbull's offerings.

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 a safe read (readOnlyHint=true) against a closed data set (openWorldHint=false), so the bar is lowered. The description still adds real context the annotations don't: currency (DKK), that prices exclude VAT, and that each package's included items are returned — details that directly affect how an agent presents the data.

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 tightly-packed sentence with zero filler, leading with the verb and resource and ending with the optional scoping clause. Every clause carries 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?

For a single-optional-param read tool with no output schema, the description covers the essentials and hints at the return payload ('what each package includes'), plus currency and VAT semantics. It stops short of describing the shape of the response (package tiers, how many packages), which is the only meaningful 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?

Schema description coverage is 100% and the single parameter is fully documented with an enum in the schema, so the baseline is 3. The description only restates that the filter is optional and scoped to one service; it adds nothing about the enum values or what happens with an invalid service.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Specific verb ('Get') plus a well-scoped resource ('Adbull's indicative price packages in DKK excl. VAT, with what each package includes'), which is naturally distinct from siblings like get_services or get_company_info. It doesn't explicitly name a sibling it must not be confused with, so it falls just short of 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?

'Optionally for one service' implies both the unfiltered (list all packages) and filtered (single service) modes, so the calling pattern is inferable. However, there is no guidance on when to prefer this over get_services, nor any prerequisite such as resolving service slugs first.

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 a safe, closed-world read. The description adds real value by disclosing the exact payload: currency (DKK), VAT basis (excl. VAT), and the presence of sub-services, so the agent knows the shape of the result without an 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?

A single front-loaded sentence with zero filler; the parenthetical category list and field enumeration both earn their place. Slightly dense with two stacked lists, but no wasted prose.

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 input schema, no output schema, and minimal annotations, the description carries the return-value burden and does so well by naming every returned field. Only gap is not clarifying the relationship between 'starting price' here and the sibling get_prices.

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 no parameters, so there is nothing for the description to disambiguate; the baseline applies. The description correctly notes the result covers all service categories without any filtering input.

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 ('List Adbull's services') and enumerates the service categories and returned fields (short description, page URL, starting price in DKK excl. VAT, sub-services). It does not explicitly differentiate itself from the sibling get_prices, even though pricing appears in both.

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: call it to get an overview of what Adbull offers. There is no explicit when-to-use or when-not, and no routing to alternatives such as get_prices for deeper pricing questions, despite the overlap.

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 and openWorldHint=false, so the safety and scope profile is covered. The description adds useful behavioral context by explaining that the tool returns a link which starts the test for a given website, that the test is free, uses Google PageSpeed, and covers mobile and desktop. It does not describe link lifetime, whether results are returned directly, or any rate limits, leaving minor gaps.

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, well-structured sentence that front-loads the primary action and resource. Every clause contributes useful context 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?

For a simple one-parameter tool with no output schema, the description is largely complete: it implies the return type (a link), explains the link's purpose, and names the test platform and device coverage. It could be improved by clarifying whether the link is returned as a string or object and whether the link expires, but it is sufficient for correct invocation.

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 parameter 'url' is fully documented with an example format. The description only adds the phrase 'for a given website', which does not provide meaningful additional semantic detail beyond the schema.

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 ('Get a link') and resource ('Adbull's free website speed test'), along with the underlying engine (Google PageSpeed) and coverage (mobile and desktop). This is clearly distinct from the sibling tools, which are informational getters for company info, contact options, prices, services, articles, and cases.

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 tool (when a website speed test link is needed) but does not explicitly state when to use it versus alternatives or when not to use it. Since no sibling tool offers a comparable speed test, the use case is fairly self-evident, but the guidance is only implicit.

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 and openWorldHint=false, so the safety profile is covered. The description adds useful scope (Danish-language articles with cited sources, topic areas) but says nothing about ranking, result count behavior, or what a match looks like.

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 well-formed sentence with the resource front-loaded and no filler. It is appropriately sized for a simple search tool, though the topic list could be trimmed slightly.

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 a documented two-parameter schema, no output schema, and annotations covering safety and openness, the description carries the remaining burden of defining the corpus — which it does. Only the relationship to sibling search tools is left unaddressed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% — both query and limit (1-20, default 8) are documented with examples in the schema. The description adds no parameter detail beyond what is already structured, so 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 (Adbull's Danish articles) plus the topic scope, so the agent knows exactly what corpus is queried. It does not explicitly distinguish itself from the close sibling search_cases, so it stops short of 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?

Usage is only implied: an agent can infer this is for keyword lookups of article content, but there is no guidance on when to prefer it over search_cases, nor any mention of prerequisites or exclusions. Minimum viable routing information.

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 and openWorldHint=false, so the safety profile is covered. The description's real contribution is scope disclosure that matching is limited to title and summary (not the full case body) and that an unfiltered call returns cases, but it says nothing about result counts, ordering, or pagination.

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, no filler, with the core action front-loaded and the filtering behavior second. Every clause adds information an agent would otherwise have to guess.

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 tool with annotations covering safety and no output schema, this is nearly sufficient — only the behavior on an empty or no-match query remains unspecified.

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 100% schema coverage the baseline is 3, and the description earns above that by disclosing what the query actually matches against (title or summary) and that it is a word match rather than full-text — semantics the schema's "Word to look for" line does not convey.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

"Find Adbull's client cases" states a specific verb and resource, and the follow-up clause narrows the search surface to title and summary. It never distinguishes itself from the adjacent search_articles sibling, so an agent comparing the two must infer from the noun alone.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied rather than stated: the description makes clear this is an optional-filter lookup for cases, but gives no when-to-use/when-not guidance and never names search_articles or get_company_info as the alternative for other resource types.

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