GitJog — Hungarian legislation

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

Annotations already provide readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds useful behavioral detail beyond the schema: output is restricted to differing sections and presented as old/new text in line-by-line blocks, which helps the agent anticipate the response shape.

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, front-loads the core purpose, and adds only the essential source guidance for dates. Every sentence earns its place with no filler or redundancy.

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 annotations, 100% schema coverage, and no output schema, the description adequately explains the tool's behavior and output format. It could mention ordering, empty-result behavior, or validation constraints, but the core information needed to invoke the tool correctly is present.

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%, but the description adds meaningful guidance by telling the agent that the time-state dates come from `szakasz` or `valtozasok`, linking parameter values to sibling tools. This is value beyond the schema's basic date format descriptions.

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: comparing two time states of a law and returning only differing sections with old and new text in line-by-line blocks. This clearly differentiates it from siblings like fetch or szakasz by emphasizing the diff-focused output.

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 clear context on how to obtain the date inputs ('Az időállapotok napjait a `szakasz` (§ nélkül) vagy a `valtozasok` adja'), pointing to sibling tools. It does not explicitly state when not to use this tool versus alternatives, but the use case is reasonably 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 declare readOnlyHint, idempotentHint, and non-destructive behavior, so the safety profile is covered. The description adds useful context about id provenance and format, but does not disclose error behavior or return structure beyond 'full text'.

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; it front-loads the purpose and id format. Every element 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 read-only tool with one parameter and rich annotations, this description is sufficient: an agent knows what to pass and what it will receive. No output schema exists, but the return value is stated directly.

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 only says id is a non-empty string, so the description carries the burden for parameter meaning. It explains that the id is a search result identifier in 'slug#anchor' format, which is meaningful guidance not present in 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 states that the tool returns the full text of a `search` result for a given id, and specifies the id format as 'slug#anchor'. This clearly distinguishes it from sibling search tools, which would return result lists rather than full content.

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 'Egy `search`-találat teljes szövege' makes the intended workflow clear: call this after obtaining a search result id. It does not explicitly name alternatives or exclusions, but the usage context is strongly implied.

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 carry the safety profile (read-only, idempotent, non-destructive), and the description adds genuinely useful behavior beyond them: Hungarian stemming, a 4000-character truncation on returned § text, and the dual search/resolution mode. The truncation limit is exactly the kind of behavioral disclosure an agent needs to avoid assuming full-text output.

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 dense sentences with zero filler: the use-case hook is front-loaded, followed by mechanism and output shape. 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?

With no output schema, the description correctly covers the return shape (§ text up to 4000 chars + URL) and the end-to-end workflow ('citable in one round'). Parameters are fully documented in the schema and safety in annotations. Missing only minor items — no-result behavior, pagination, and sibling disambiguation — none of which block a correct first call.

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 rich examples for q (free-text and citation formats) plus defaults for limit and hatalyos, so the schema carries the parameter burden. The description adds only the stemming nuance for how q is processed and the output cap, which are marginal to parameter semantics — 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 states a specific purpose: full-text search of Hungarian laws with stemming, plus citation/reference resolution, returning the full § text and URL. The opening question 'Melyik § szabályozza X-et?' and the title make the scope (Hungarian legislation) unmistakable. However, it never explicitly distinguishes itself from the sibling 'search' (same meaning) or 'szakasz' (section retrieval), so sibling differentiation is only implicit.

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 frames a clear use case — 'Which § regulates X?' — and enumerates both accepted input modes (free text vs. citation like 'Fftv. 18. §'), which is solid contextual guidance. It does not state when NOT to use this tool or name alternatives among the siblings, so exclusions are absent.

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 (readOnlyHint=true, idempotentHint=true, destructiveHint=false), lowering the bar. The description adds one useful behavioral fact beyond annotations — the return value is an id shaped for `fetch` — which matters because there is no output schema. No contradiction exists: a read-only search is consistent with 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?

A single semicolon-joined sentence with zero filler: purpose first, workflow linkage second. Every word earns its place and the essential information 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?

The tool is minimally complex (one required param, no enums, no nesting), annotations carry the safety profile, and the description supplies the critical integration detail (result id feeds `fetch`). The notable gap is absence of differentiation from the `kereses` sibling, which leaves the tool's unique role slightly underspecified.

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%, so the description must compensate. It only does so implicitly: by stating the tool searches Hungarian laws, an agent can infer `query` holds the search text, but the description never explicitly defines the parameter's semantics, expected language, or matching behavior. Adequate for one obvious parameter, but not explicit.

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 verb and resource: 'Keresés a magyar törvényekben' (search in Hungarian laws), and adds a workflow fact by stating its result id is consumed by `fetch`. It stops short of 5 because the sibling `kereses` is almost certainly the same function in Hungarian, and nothing in the description separates `search` from it.

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 'az eredmény id-jét a fetch várja' communicates how the tool fits into a sequence (search first, then pass the id to fetch), which is genuine usage context. However, there is no explicit when-to-use/when-not-to-use guidance, and no routing to any alternative despite the ambiguous `kereses` sibling.

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 and idempotentHint=true, so safety is covered. The description adds behavioral detail about the no-section case (returns metadata, time-state list, TOC), which is beyond what annotations provide. However, it does not disclose any other behavioral traits (e.g., error handling, pagination), so it is adequate but not rich.

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 primary purpose, and the secondary case is stated in the second sentence. No redundant words; every phrase adds 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 tool is simple and the description covers the two modes of operation (with and without §), the date parameter, and the alternative ways to specify a section. It mentions the output (section text or metadata/TOC) even without an output schema. Minor omissions like error cases or pagination do not undermine completeness for a read-only retrieval 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?

Schema description coverage is 100%, so each parameter (slug, datum, horgony, paragrafus) is documented. The description adds the clarification that horgony and paragrafus are alternatives ('vagy'), which is a slight semantic addition. It does not compensate for any gaps, but there are none, so a baseline of 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 states a specific action: retrieving a § (section) of a regulation by anchor or number, optionally with text in effect on a given date. It also clarifies the fallback behavior (metadata, time states, TOC) when no § is given, and explicitly notes it does not return the full text, distinguishing it from likely sibling tools like fetch.

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 clear context on when to use the tool: to get a specific section's text at a point in time, or to get metadata/TOC without sections. It implicitly differentiates from full-text retrieval by saying 'nem a teljes szöveget', though it does not name specific sibling tools or give explicit exclusions.

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 mark readOnly/idempotent/non-destructive. The description adds useful behavioral context: one call is enough per notification, the cursor should be set to an initial timestamp and then to the response's 'kovetkezo_felveve_utan' field, and filters behave differently for live monitoring vs historical queries. No contradiction.

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 dense but not bloated; it front-loads the core purpose and organizes caller guidance by use case. The long second sentence packs several related details, but each clause contributes.

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 helps by naming the response shape ('érintett §-ok régi/új szövegével') and the next-cursor field. It lacks a full return-value description and explicit pagination semantics, but for an optional-parameter list tool the key invocation details are present.

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 value beyond schema by explaining how parameters combine: 'felveve_utan' as a pagination cursor over time, q for title word-start filtering, and since/until/slugs for historical lookups. It does not redefine parameter formats but clarifies intended usage.

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 operation precisely: 'Hatályba lépett módosítások listája az érintett §-ok régi/új szövegével' – a list of enacted amendments with old/new text of affected sections. It is clearly a query/list operation, but it does not explicitly differentiate itself from siblings like 'diff' or 'kereses'.

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 two explicit usage modes: monitoring with the 'felveve_utan' cursor plus q/slugs filtering, and historical questions using since/until/slugs. This is clear contextual guidance, though it never names alternatives or states when not to use the tool.

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