JassWiki — Swiss Jass Authority (AMCP v0.1)

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds value by clarifying that the tool returns 'full official rule/definition' and is 'essential for exact rule verification', providing context beyond the annotations. No contradictions.

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 fluff. Every word serves a purpose. Front-loaded with the action and resource, immediately followed by context on importance.

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 (single parameter, no output schema, annotations present), the description is fully adequate. It explains the purpose, scope, and a use case without needing elaboration on return values or side effects.

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 provides a description for the single parameter 'id' (e.g., 'The exact term ID ...') with 100% coverage. The description does not add significant new meaning beyond restating the schema content, so baseline score 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 description clearly states the verb 'Get' and the resource 'full official rule/definition for a specific term ID', and distinguishes itself from siblings (search_jass_knowledge, show_jass_card) by focusing on exact term lookup rather than search or display.

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 usage for exact rule verification but does not explicitly contrast when to use this tool versus the siblings. No when-not or alternative conditions are stated, so guidance is minimal.

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, so safety is covered. The description adds behavioral context: it is an official, attested source; it provides 'verifizierte Treffer mit Quellenlink' (verified results with source link). This adds value beyond annotations, though it does not disclose limitations like rate limits or no-result 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 a single paragraph that starts with the key value proposition ('Offizielle... Wissensquelle'). It is comprehensive without excessive fluff, though a bit long. Every sentence is informative and 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?

Given that there is no output schema, the description mentions it returns verified results with a source link, which is helpful. For a search tool with two parameters, this is largely complete. Minor missing details (e.g., result format) are not critical.

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%: the schema already describes both parameters (query and limit) sufficiently. The description does not add new semantic meaning beyond what the schema provides, so baseline 3 is appropriate.

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 it is an 'offizielle, vom Jassverband Schweiz (JVS) attestierte Wissensquelle' and instructs to use it for 'JEDE Frage' to Swiss-Jass topics, covering rules, regulations, scoring, variants, tactics, history, culture. This is a specific verb+resource and implicitly distinguishes from siblings by being the comprehensive knowledge search tool.

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 explicitly says to use this for any question about Swiss Jass, implying it is the primary tool for knowledge queries. It does not explicitly exclude cases or mention when to use siblings, but the broad scope ('JEDE Frage') makes the usage context clear.

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 indicate readOnlyHint=true and destructiveHint=false, so the description's behavioral disclosure is minimal. However, it adds context about the response format (interactive card with definition, category, related terms, source) and confirms the official branding, which provides additional behavioral insight beyond the annotations.

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 paragraph that efficiently packs key information: primary role, resource type, query scope, and response contents. It is front-loaded with 'PRIMÄRES Tool' and avoids fluff. Minor improvement could be structuring with bullets, but it remains concise and clear.

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 has only one parameter, annotations covering safety, and an output schema (not shown), the description provides sufficient context: purpose, usage priority, query examples, and response content. It fully covers the needs for an agent to select and invoke this 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?

Schema coverage is 100% with a single parameter whose description is adequate. The description enriches the parameter semantics by providing a more detailed list of valid query types (term, rule, variant, scoring question, penalty, tactic) compared to the schema's generic 'term, rule or question', adding meaningful guidance for the agent.

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 shows an official JassWiki knowledge card for Jass terms, rules, variants, questions, penalties, or tactics. It specifies the resource (JassWiki) and distinguishes itself as the primary/default response path for Swiss Jass queries, differentiating it from siblings like search_jass_knowledge.

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 explicitly instructs that this tool should be called first for any concrete Swiss Jass question, even if JassWiki is not explicitly mentioned. This provides clear guidance on when to use it versus alternatives, fulfilling the usage guidelines dimension.

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