AiSeek

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 fully covered elsewhere. The description adds that results include recent changes and listings, which is marginally useful, but says nothing about pagination, result limits, or how the two modes behave. With rich annotations the lower bar applies, so a 3 is appropriate.

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 carries both operating modes without filler. It is dense but every clause earns its place; only a slight loss for packing two behaviors into one unpunctuated alternative makes it less than ideal.

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?

No output schema exists, so the description is responsible for signaling what comes back, and it does list profile/listings/changes at a high level. With no required parameters and a dual-mode contract, however, an agent still lacks guidance on ambiguous input combinations and on the shape or volume of the returned listings.

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 67%: query and locale are documented in the schema, but slug is not. The description compensates partially by identifying slug as an 'AiSeek slug' and tying query to name lookup. That adds meaning beyond the bare schema, but it does not explain the slug format or the interaction between the two modes, so it stays at the baseline.

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 (company) and enumerates what is returned: profile, listings, and recent changes, plus a name-search mode. That is a clear verb+resource statement an agent can act on. It does not, however, contrast itself against siblings like search_changes or latest_changes, which also surface change data.

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?

Two modes are implied: pass a slug to fetch one company's profile/listings/changes, or pass a query to get a list of matching companies. That is useful routing context. But it never says what happens when neither or both are supplied, nor when the name-match path is preferable to other search tools, so the guidance stays implied rather than explicit.

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 cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower. The description adds genuinely useful context beyond them: the window is capped by the API key's plan tier (Free 7, Pro 30, Intelligence 90), which an agent needs to know before requesting large day ranges.

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 metric definition and followed by the operational cap. Dense but no filler; every clause carries meaning.

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 should carry return-value context, and it only gestures at it ('with its domains and last seven days'). For a 4-parameter, 0-required aggregation tool the plan-tier note is helpful, but the locale parameter and result shape remain unexplained.

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%, so the description must compensate, and it partially does: 'domains' maps to the domain enum, 'last seven days' maps to the days parameter and its default, and 'per country' maps to country. The locale parameter is never mentioned and no format/syntax details are added 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 names a specific resource (SeekMap's Change Heat per country) and states what it measures: verified change against the prior day, broken out by domain over the last seven days. It is distinguishable from siblings like get_change or latest_changes by its per-country aggregation, though it never explicitly contrasts itself with them.

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 is given and no sibling is named as an alternative. The plan-cap sentence describes a constraint on the window, not a condition for selecting this tool over another.

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 openWorld=false, so the safety profile is covered. With no output schema present, the description earns credit for disclosing the return shape (summary, scores, main subject, and source records with outlet, link, date, kind), which is genuinely useful context an agent cannot get elsewhere.

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 no filler that front-loads the core object and then enumerates the returned components. It is tight and readable, though it could better organize the id/locale relationship that currently only appears in the 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?

For a low-complexity single-fetch tool, the annotations cover safety, the schema fully covers both parameters, and the description covers the return contents in the absence of an output schema. The missing piece is usage routing versus latest_changes/search_changes, which prevents a top score.

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%: the id parameter is documented as coming from latest_changes or search_changes and locale is a fully described enum with a default. 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 title and description together convey that this fetches a single published change and its reporting sources, a specific resource that contrasts with the list-oriented siblings latest_changes and search_changes. However, the description is a noun phrase describing returned contents rather than stating the retrieval verb, and it never explicitly names a sibling it is distinct from.

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 gives no when-to-use or when-not-to-use guidance. The only routing hint ('The change id from latest_changes or search_changes') lives in the input schema, not the description, so the description itself does nothing to steer an agent among the six 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 readOnly, idempotent, and non-destructive behavior, so the safety profile is covered. The description adds real value with the Free-key gating rule (brief opens one day after publication), but says nothing about what the brief payload contains, its size, or freshness for paid keys. No output schema exists to fill that 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?

Two tight sentences with the core purpose front-loaded and the access caveat second, which is the right ordering. The phrasing 'the period's changes by section' is slightly compressed but not 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, zero-required tool this covers the essentials, and the Free-key caveat is a useful addition. However, with no output schema the description should say more about what a brief actually returns (sections, entries, structure), which it only gestures at.

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%: locale is documented in the schema, but the type parameter has no description. The phrase 'daily or weekly' does map the enum values to their meaning, partially compensating for the undocumented parameter. It adds no detail on defaults or how the two types differ in content.

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 (the latest daily or weekly brief) and describes its content (the period's changes by section), which is more concrete than the sibling names alone. It does not explicitly differentiate itself from close siblings like latest_changes or get_change, so it falls 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?

There is no statement of when to use this tool versus latest_changes, get_change, or release_calendar, even though those siblings clearly overlap. The Free-key timing note informs availability but does not route the agent between alternatives.

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, so the safety profile is covered. The description usefully adds ordering and page size, but says nothing about the pagination ceiling (page 0-25 at 20 per page) or whether a total count is available, which is the remaining behavioral gap for a paged list tool.

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; ordering and page size come before the per-item payload note. 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?

With no output schema, the description must partly carry the return-value burden; it does note that each entry includes its AiSeek page, which helps. It still omits the effective pagination cap and whether results can be exhausted, leaving the agent without a full picture of the result set.

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 both page and locale fully documented including defaults and bounds, so the baseline is 3. The description's '20 per page' corroborates the page parameter but adds no syntax or format 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?

States a specific resource (newest published changes), an ordering (newest first) and a page size (20 per page), which is more than a restatement of the name. It does not, however, distinguish itself from siblings like search_changes or get_change, so an agent must infer the difference.

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 sibling is named, despite search_changes, get_change and latest_brief being plausible alternatives. The 'newest first' framing hints at browsing rather than searching, but that is inference, not 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?

Annotations already declare readOnly/idempotent/non-destructive/closed-world, and the description adds a real behavioral constraint beyond them: the free-tier visibility window of yesterday/today/tomorrow in UTC, which affects what results an agent will actually get. It does not discuss pagination, rate limits or result size, so it stops short of 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?

One dense sentence that front-loads the resource and follows with scope and the free-key caveat; no filler. The tier limit is tacked on with a semicolon rather than being separated, but the size is appropriate.

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-param, no-required, read-only lookup with no output schema, the definition covers what it returns and the free-tier constraint, but leaves the coverage parameter's semantics and the practical default-window behavior unexplained.

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 75%: to, from and locale are described in the schema, but the coverage enum (19 categories) has no description anywhere. The description's 'central banks, statistics offices, earnings' hints at the coverage domain but does not explain the enum values, so it adds only marginal 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?

States a specific resource (scheduled releases and decisions) with concrete examples of the event types (central banks, statistics offices, earnings) and the temporal scope (between two times). It is clearly distinguishable from siblings like get_change, latest_changes and search_changes, though it never names those alternatives.

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 supplies a useful eligibility rule (Free keys see yesterday, today and tomorrow in UTC), which is genuinely actionable, but it gives no explicit when-to-use versus the sibling tools or any guidance on how to pick a date window.

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 and determinism profile is covered. The description adds one genuinely useful behavioral fact beyond annotations: only *published* changes are searched (draft/unpublished content is excluded) and results are relevance-ranked rather than chronological. It does not discuss result size, truncation, or what a returned change contains.

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; the ranking behavior is tucked into a trailing clause where it is easy to miss, which slightly undercuts the otherwise efficient structure.

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 three parameters, 33% schema coverage, and no output schema, the description should carry more load. It conveys scope and ordering but omits the shape of a returned 'change', the meaning of the limit cap (max 25), and any note on empty-result behavior, leaving meaningful gaps for an agent consuming the results.

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% (locale is the sole described parameter), so the description must compensate. It does add value for the required 'query' parameter by clarifying that it matches entity-like words (company, country, subject) rather than free-form full text, but it says nothing about 'limit' or about matching behavior for multiple terms. Partial compensation only.

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 and resource combination ('search published changes') plus the matching basis (keywords naming a company, country, or subject) and result ordering ('most relevant first'). It is clearly not a fetch-by-id or list-recent tool. However, it never names the closest siblings (latest_changes, get_change), so an agent must infer the boundary itself.

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 explicit when-to-use statement, no exclusions, and no mention of alternatives such as latest_changes for browsing or get_change for retrieving a known change. The keyword-search framing only weakly implies the use case, leaving routing between the seven sibling tools to inference.

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