Polargate

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

No annotations are provided, so the description carries the full behavioral burden. It usefully discloses that the response includes the page markdown, which is real content information, but it says nothing about whether the call is read-only (only implied by "Get"), how missing slugs or locales behave, or any rate/permission constraints.

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 tight sentences with zero filler; the core purpose is front-loaded and the prerequisite follows. Every sentence 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?

With no output schema, the description takes reasonable responsibility by noting the markdown content of the returned page. However, for a two-parameter fetch tool it leaves the locale parameter entirely unexplained and gives no guidance on not-found behavior or default language.

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 50%: the slug parameter is documented in the schema with examples, and the description reinforces it by telling the agent to obtain the slug from list_cases. The locale parameter has only an enum and no explanation in either place — the description never mentions locale, language fallback, or default behavior.

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 — retrieves the full case study for one project — and adds the notable detail that the page markdown is included. It distinguishes itself from the sibling list_cases by scoping to a single project, though it does not contrast with get_page, whose scope is less clear.

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 list_cases first to find the slug" gives a concrete prerequisite and routes the agent to the correct sibling for slug discovery. It stops short of stating when not to use this tool (e.g., vs. get_page) or what happens if the slug is unknown.

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, and it does disclose the important trait that the response is the full page text rendered as markdown rather than HTML or a summary. It says nothing about authentication, handling of invalid routes, or whether navigation/boilerplate is included.

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 purpose stated before the invocation instruction. Nothing restates the name or 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?

For a single-parameter read tool with no annotations and no output schema, the description covers what it returns and how to address it. Only failure behavior for bad routes and any auth expectation are left unstated, which is a minor gap at this complexity.

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 already 100% and the schema documents 'route' as a path starting with '/'. The description goes beyond that by giving two concrete route examples, including a locale-prefixed one (/es/work/hotel-marien), which hints that localized paths are valid 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 resource ('any page on polargate.ai') and the return format ('as markdown'), which is enough to distinguish it from the specialized siblings like get_case and get_pricing. The verb 'read' is implied rather than written, but the intent is unambiguous.

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 tells the agent how to invoke it ('Give the route') but never says when to prefer this generic fetch over get_case, get_pricing, list_products, or search_site. Usage is inferable from the 'any page' scope, which is the definition of implied 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?

No annotations are supplied, so the description carries the full disclosure burden. It does add real behavioral context beyond the schema: pricing is deliberately unpublished and quotes arrive privately in writing after a first call. It is silent on the locale parameter's effect, on whether the content varies by locale, and on the read-only/retrieval nature of the call.

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. The content inventory is front-loaded and the second sentence delivers the key expectation-setting fact about unpublished prices. The parenthetical enumeration is long but each item is informative, so it stays efficient overall.

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, parameter-light retrieval tool with no output schema and no annotations, the description covers what the tool returns and the important pricing policy caveat. The only real omission is any guidance on the locale parameter, which is minor given the enum is self-explanatory.

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?

There is one optional parameter with a self-documenting enum (en/es/nl) and 0% schema description coverage. The description says nothing about locale, so it adds no meaning beyond the enum values themselves. The enum largely compensates, keeping this at the minimum-viable baseline rather than lower.

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 concretely and enumerates its contents (Discovery Sprint, fixed-price projects, Care, Grow, AI visibility audit) with the attributes returned (inclusions, audience, billing). That is specific enough for an agent to know it is the engagement/pricing overview. It does not, however, distinguish itself from near-neighbours like list_services or how_to_start, 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 the tool for questions about engagement models or cost. There is no explicit when-to-use statement and no routing advice against siblings such as list_services or how_to_start. The one genuinely useful cue is the negative one — 'Polargate does not publish prices' — which sets expectations for the call.

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 and no output schema, the description carries the full behavioral burden. It implies read-only informational content but never confirms it is a non-destructive read, does not describe the return format, and does not explain how the locale parameter changes behavior. For a zero-annotation tool this is a significant disclosure gap.

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 compact sentence with no filler; the topical content is front-loaded immediately after the tool label. It is appropriately sized, though the colon-list structure reads more like a topic index than a definition.

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-optional-parameter informational tool with no output schema, the description gives a reasonable sketch of what content is returned. However, it omits the locale parameter's effect and any read-only confirmation, leaving small but real 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 locale parameter has 0% schema description coverage and is not mentioned in the description at all. The phrase 'languages spoken' refers to page content, not the locale selector, so the description does not compensate for the missing enum semantics or explain that locale filters/selects the returned language.

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 content the tool surfaces (what the brief asks, answer time, languages, work location), which signals it returns 'how to engage Polargate' information. However, it never states an action verb or the resource type (page? document?), so an agent must infer that this is an informational content-retrieval tool rather than a mutation. It is distinguishable by topic from siblings like get_pricing, but the purpose is implied rather than stated.

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 alternatives among the many sibling tools (get_page, search_site, get_pricing). The only usage signal is the topical implication that this is the tool for 'starting a project' questions, which is left entirely to inference.

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 at all, the description carries the full behavioral burden. It usefully discloses that clients are only named where they consented — a genuine authorization nuance — but says nothing about ordering, result volume/pagination, or read-only status, which an agent calling a list endpoint would benefit from.

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 tight sentences with no filler, and the content is front-loaded ahead of the filtering note. The return-field enumeration in sentence one is slightly long but each item is informative 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?

For a low-risk read tool with no output schema and no annotations, the description covers what the tool returns and how to filter, which is the core need. It still leaves the locale parameter's meaning and any notion of result set size or pagination 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 only 33%: industry is documented, while locale and service have bare enums with no explanation. The description partially compensates by naming the industry and service-line filters, but it leaves locale entirely unexplained (is it an output language or a filter?) and never clarifies the build/grow/care service values.

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 concrete resource (projects Polargate has delivered) and even enumerates the returned content — client attribution, outcomes, stack, live site link. It reads clearly against the singular sibling get_case, but never explicitly frames itself as the list-level counterpart, so the differentiation is inferable rather than stated.

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?

"Filter by industry or service line" gives usable invocation context for two of the three parameters, but there is no when-to-use guidance relative to get_case, search_site, or list_services, and no conditions under which the tool should be avoided.

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 provided, so the description carries the full burden of behavioral disclosure, and it delivers none: no statement that this is a read-only listing, no indication of what fields are returned, ordering, or whether/how the locale parameter changes results. The text is product marketing content rather than 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 scope constraint is front-loaded in the first clause, which is good. The remainder is largely promotional copy about PolarJay and PolarRabbit (including a URL) that consumes space without helping the agent invoke the tool, so it is not fully economical.

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 trivial no-required-parameter list tool with no output schema, the description is roughly sufficient to identify the resource, but it omits the locale semantics and any hint about the returned shape, so it is only minimally 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 description coverage is 0% and the single parameter (locale, enum en/es/nl) is never mentioned in the description. The description does not compensate for the gap by explaining what locale controls (language of returned names/descriptions), leaving the agent to guess.

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 scope precisely: 'Products Polargate makes and owns, as opposed to work for clients,' which distinguishes this tool from the sibling list_services. The verb 'list' comes from the name/title rather than the description, but the resource and boundary are unambiguous.

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 phrase 'as opposed to work for clients' implicitly routes the agent to list_services for client work, which is useful contrast. However, there is no explicit when-to-use statement or mention of the other list/search siblings, so the guidance is implied rather than 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?

No annotations are provided, so the description carries the full behavioral burden, yet it never states that this is a read-only, side-effect-free lookup. It describes the content of the response but says nothing about return format, catalog size, caching, or whether the listing is exhaustive or paginated.

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 dense sentence with no filler, and the primary information (the three service lines) is front-loaded. It is slightly list-heavy in the trailing clause 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?

With no output schema, the description does the work of previewing return fields (inclusions, timeline, staffing, pricing), which is the main thing an agent needs for a zero-required-parameter listing tool. It stops short of mentioning the locale switch or the shape/limits of the listing.

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% for the single optional 'locale' parameter, so the schema already documents the enum and default. The description adds nothing about language handling, and the baseline for a fully documented, non-required parameter set is 3.

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 specific resource (three service lines: build, grow, care) and enumerates what each entry carries, which is much more informative than a bare 'lists services'. However, it is a noun phrase with no verb, and it never distinguishes itself from siblings like list_products or get_pricing, which overlap heavily with 'capabilities' and 'how it is priced'.

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 exclusions, and no alternatives named. An agent must guess whether list_products or get_pricing is the better call when a user asks about services or prices. The only implied usage comes from the tool name itself.

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 does usefully disclose what is searched (title/description only, not full text) and what comes back (page URL plus markdown twin). It says nothing about result ordering, the effect of the limit parameter, or whether a missing match returns empty versus an error.

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, search behavior front-loaded followed by the return shape, with no filler. 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?

The description sensibly covers the absent output schema by naming the return values, and the language scope is noted. However, with no annotations and an undocumented limit parameter, an agent lacks enough to call this reliably at scale or to choose it over get_page.

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 and locale are documented in the schema, and the description adds that search spans all three languages, reinforcing locale. The limit parameter is undocumented in both the schema and the description, so its meaning and default must be guessed.

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 (find) and resource (pages) and scopes the search index to title/description words, which is more precise than a generic 'search'. It does not explicitly distinguish itself from the sibling get_page or the list_* tools, so the agent must infer the boundary.

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 verb 'find' versus the retrieval-oriented siblings like get_page and list_products, but the description never states when to search versus when to fetch a known page. No exclusions or prerequisites are given.

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