Wikexa Knowledge

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

With no annotations, the description carries the burden of behavioral disclosure. It explains output format (sections array, infobox facts), states there's no HTML/wikitext to parse, and warns that long articles can flood context. It doesn't cover error cases or permissions, but for a read tool the key behaviors are disclosed.

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 concise, front-loaded with the core purpose, and every clause adds meaningful detail. It avoids redundancy with the schema and is well-structured with clear separation between purpose and usage tips.

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 compensates by specifying return structure (sections array, infobox facts, no markup). It also covers the main usage concern (context size) and references the sibling lookup. It omits minor details like error behavior, but overall it's sufficient for a straightforward article-fetching tool.

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?

Since schema coverage is 100%, the baseline is 3. The description adds value by explaining why `sections` and `max_chars` exist (to limit context flooding) and how to use them ("pull only the parts you need"), which is beyond what the schema states about their types and defaults.

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 clearly states the tool returns "The full text of an article" and distinguishes it from lookup()'s summary by emphasizing sections as a JSON array and infobox as key/value facts. It also explicitly contrasts with the sibling lookup tool, making its unique role evident.

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 explicitly says to use this tool "when lookup()'s summary is not enough," giving a direct when-to-use vs alternative. It also provides guidance on using `sections` and `max_chars` to avoid flooding context, which is actionable usage direction.

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. It discloses the multi-language behavior (one spelling returns entries in many languages), the content fields (senses, part of speech, etymology, pronunciation), and the coverage scope. It does not mention potential response size or errors, but this is a read-only lookup with no destructive effects, and the description gives a strong sense of what to expect.

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 longer than strictly necessary but every sentence earns its place by covering scope, multi-language behavior, filtering, and contrast with the sibling. It is front-loaded with the core purpose and packs detail efficiently without being rambling.

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?

Given there is no output schema, the description sufficiently explains what kind of information is returned (senses, POS, etymology, pronunciation). It also covers the main edge case of multiple language entries and how to handle it. It doesn't describe the exact return structure, but for a dictionary lookup this is adequate context for an agent to select and invoke the tool.

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 input schema already covers all three parameters (word, language, pos) with descriptions, so the base is 3. The description adds value by explaining that language is used to narrow the multi-language results (with example 'hund'), and that pos filters to one part of speech, reinforcing the schema semantics with concrete usage context.

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 clearly states the tool defines what a word means, with specific details on coverage (8.15M entries, historical and indigenous languages). It explicitly distinguishes itself from sibling lookup() by contrasting define('java') vs lookup('Java'), making the purpose unmistakable.

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 explicit guidance on when to use this tool ('Use this for words') versus lookup() ('and lookup() for things'), and explains how to narrow results using the language and pos parameters. This directly addresses the sibling alternative, which is exactly what usage guidelines should do.

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 discloses key behaviors: returns structured fields plus a ~200-token summary, sources from 10.2M entities, resolves aliases and Q-ids, and is free/no key. It lacks error-handling details, but covers the essential operational characteristics.

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?

Four sentences, all information-dense and non-repetitive. Front-loaded with the core purpose, then return format, efficiency comparison, alias handling, and cost. 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?

For a simple lookup tool with 2 params and no output schema, the description covers purpose, return structure, data scale, and alternatives. It could mention edge cases like missing entities, but overall sufficiently 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 coverage is 100%, so baseline is 3. The description adds value beyond schema by explaining alias resolution for the entity param and the cost-saving rationale, enriching understanding of both parameters.

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 clearly states the tool returns structured facts about any named thing (person, company, etc.), with a specific verb ('Returns') and resource. It distinguishes itself from siblings by explicitly contrasting with fetching an encyclopedia page, making its niche 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?

It gives explicit guidance: 'Prefer this over fetching an encyclopedia page' with a token-cost rationale, positioning lookup as the efficient choice versus article. The corpus parameter also provides when-to-use guidance for wikiquote, wikibooks, etc.

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 behavioral disclosure burden. It reveals the return shape ('titles with timestamps and edit comments') and how parameters affect results ('Pass topic to filter and hours to widen the window'), going beyond the schema. It does not discuss edge cases like empty results or ordering, preventing a higher score.

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 three sentences, front-loaded with the core purpose ('What changed in the last hours or days') and no wasted words. Each sentence serves a distinct role: what, when, and how.

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 tool with no output schema, the description adequately covers the return format and usage guidance. It lacks details on ordering or empty results, but the schema already documents parameter constraints, making this a solid 4.

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 the baseline is 3. The description adds meaningful context for two parameters: topic ('filter') and hours ('widen the window up to a week'), while limit is left entirely to the schema. This extra guidance justifies a 4.

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 clearly identifies the tool as returning recent changes: 'What changed in the last hours or days' and 'Returns titles with timestamps and edit comments.' It also distinguishes from siblings by positioning itself as the 'escape hatch' for facts newer than the training cutoff, implying other tools handle different lookup scenarios.

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 provides explicit trigger conditions: 'Reach for this whenever the answer could have moved since you were trained' with concrete examples (elections, appointments, acquisitions). It does not explicitly name a direct alternative tool like search, but references lookup() for follow-up, so it falls short of a 5.

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 provided, the description carries the full burden. It discloses rich behavioral details: ranking combines text relevance and monthly pageviews, follows redirects, and handles abbreviations (examples: 'usa' → United States). It also clarifies that it searches all corpora by default. This goes well beyond a minimal purpose statement, though it does not mention rate limits or error handling.

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 three sentences, front-loaded with purpose, then behavioral detail, then usage guidance. Every sentence earns its place. The examples are concrete and illustrative without unnecessary fluff.

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?

Given no output schema, the description explains the return structure ('ranked {title, wikidata_id, description, summary_snippet}'), the ranking behavior, corpus handling, and follow-up tools. With just 3 parameters and a simple return object, this description covers all essential aspects for an agent to use the tool effectively.

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 baseline is 3. The description adds some context (e.g., the effect of omitting `corpus`), but this is already present in the schema's own field description. No additional parameter-level meaning is provided beyond what the schema already documents.

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 opens with a specific verb+resource: 'Find the right title when you only have a partial name or a rough description.' It clearly states that the tool resolves entities to their canonical titles, distinguishing it from sibling tools lookup() and article() which serve different follow-up purposes.

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 explicitly tells when to use this tool (partial name/rough description) and provides direct alternatives: 'Follow up with lookup() for facts or article() for the text.' It also explains the corpus parameter behavior ('Searches every corpus at once unless you pass `corpus`'), giving clear usage context.

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