Wikexa Knowledge

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

With no annotations, the description carries the full burden. It discloses the output format (JSON) and that HTML/wikitext is stripped, which is useful. However, it doesn't mention potential error behaviors (e.g., missing titles, unmatched sections) or any rate limits. The mention of content caps implies large outputs, but other behavioral traits are unspecified, resulting in a mid-range 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 two sentences, front-loaded with the core purpose and output format, then efficiently explaining the control parameters. Every clause adds value—no filler or redundancy. It's compact yet comprehensive.

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 the tool's simplicity (3 params, no output schema), the description explains the return structure (structured JSON, sections, infobox) and how to constrain output. It misses details like error handling and what happens when a requested section doesn't exist, but overall it provides sufficient context for the agent to invoke it correctly. An explicit note about title aliases/Q-ids is in the schema, so not repeated. Slightly incomplete on edge cases, but solid.

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 schema already fully documents the parameters (title, sections, max_chars) with descriptions, so baseline is 3. The description adds extra meaning by explaining the purpose of sections ('fetch only the parts you need') and max_chars ('cap the payload') and why they exist ('to keep long articles from flooding your context'). This goes beyond the raw schema, enhancing the agent's understanding of when and how to use them.

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 provides a 'Full Wikipedia article as clean structured JSON' and specifies the structure (sections array, infobox key/value facts, no HTML/wikitext). The verb 'fetch' is implied and the resource is unambiguous. It distinguishes itself from siblings (lookup, recent, search) by focusing on retrieving the full article content in a structured format.

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 provides explicit guidance on when to use the `sections` and `max_chars` parameters, explaining they exist to keep long articles from flooding context. It doesn't explicitly compare with sibling tools or state when to prefer this over search/lookup, but the 'Full Wikipedia article' phrasing implies it's for retrieving complete article data. A slight gap is the lack of alternative tool mention, keeping it from 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, the description carries the full burden and discloses useful behaviors: it returns a summary of ~200 tokens, resolves aliases so different inputs map to the same entity, and is free/unlimited. It could mention error/not-found behavior, but this is solid coverage for a lookup 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?

Three sentences deliver purpose, input flexibility, and efficiency guidance without redundancy. The most important information (look up any entity, get structured facts + summary) is front-loaded.

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 tool with no output schema, the description is complete: it covers input format, alias handling, expected output, and cost rationale. It gives the agent enough to decide when to invoke and what input to provide.

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 schema already covers the entity parameter at 100%, and the description adds concrete alias equivalence examples ('Apple', 'Apple Inc', and Q312 map to the same entity). This reinforces the input semantics beyond the schema's field description.

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 'Look up any entity' and specifies the output (structured facts plus ~200-token summary), giving a clear verb+resource+scope. It further distinguishes the tool by describing alias and Wikidata Q-id resolution, so it is not just a generic search.

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 recommends using this tool over fetching a web page, citing token cost and reliability, which gives clear context for when to choose it. It does not name sibling tools (article, recent, search) or state when not to use it, but the guidance is practical.

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 of behavioral disclosure. It specifies the return format ('Returns titles with timestamps and edit comments') and the conceptual scope (recently changed articles). It does not mention edge cases, ordering, or error behavior, but the core behavior is sufficiently transparent.

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 two sentences long and front-loaded with the core purpose. It packs in use-case, output details, and a pointer to lookup() without any fluff. 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?

For a simple tool with three optional parameters, a fully documented schema, and no output schema, the description covers purpose, use case, return format, and cross-tool guidance. It gives the agent everything needed to select and invoke the tool 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?

The input schema has 100% coverage with descriptions for all three parameters (hours, limit, topic). The description adds a little by mentioning 'filtered by topic' and the time-based nature, but it doesn't provide per-parameter semantics beyond what the schema already documents. Baseline 3 is appropriate given the high schema coverage.

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's function: 'Articles changed recently, optionally filtered by topic.' It uses a specific verb ('changed') and resource ('articles'), and the 'freshness escape hatch' phrasing distinguishes it from sibling tools like lookup and search by emphasizing recent time-sensitive information.

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 provides explicit usage context: 'This is the freshness escape hatch for facts newer than your training cutoff — elections, appointments, releases, deaths.' It also names an alternative action ('resolve any of them with lookup()'). However, it doesn't explicitly state when not to use this tool versus search or article, leaving some room for ambiguity.

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 delivers: it explains ranking logic (full-text + pageviews), gives a concrete example, and enumerates return fields. It goes beyond a simple 'how' by explaining behavior, though it could mention read-only nature or error 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 description is concise—two sentences—with the core purpose front-loaded. The second sentence packs return format, ranking behavior, an example, and follow-up tools without redundancy. Every clause 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 2-parameter tool with no output schema, the description is complete: it defines the return structure, ranking behavior, provides an illustrative example, and suggests next steps. It covers all necessary context 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 schema already documents both parameters (query, limit). The description only references 'query' implicitly and does not add extra semantic detail about parameter usage or constraints.

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 'Find entities by fuzzy text match when you do not know the exact title,' combining a specific verb, resource, and scope. It distinguishes from sibling tools by emphasizing fuzzy matching and the follow-up advice for exact lookups.

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 guidance on when to use the tool: 'when you do not know the exact title,' and suggests follow-up tools. However, it doesn't explicitly mention when not to use it or compare with all siblings, leaving some room for inference.

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