horoscoop.app

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

Annotations already declare readOnly/idempotent/non-destructive, so the description is free to add real value: it says the response is the full text for the day, that dates are in Dutch time, and that a link to the page is included. That is useful return-content context beyond the annotations, though nothing is said about missing dates or failure 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?

A single front-loaded sentence covering resource, scope, date semantics, and return payload with no filler. 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 still tells the agent what comes back (full daily text plus page link), and annotations carry the safety profile. Only edge cases such as an unavailable date or a future date beyond the published range are unaddressed.

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, but the description adds meaning the schema lacks: the date is interpreted in Netherlands time and the default is 'vandaag'. The sign enum's language-mapping hints live in the schema and are not repeated, which is correct.

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 verb-and-resource: fetch the daily horoscope text for a zodiac sign, for today or a chosen date, plus the page link. The 'dag' granularity inherently separates it from weekhoroscoop/maandhoroscoop/jaarhoroscoop, though no sibling is named explicitly.

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?

Usage is implied by the 'daghoroscoop' scope and the note that an empty date means today, but there is no explicit statement of when to pick this over week-/maand-/jaarhoroscoop or other siblings. An agent must infer the routing from names alone.

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, and closed-world, so the safety profile is fully covered. The description adds genuine value by disclosing the computation source (Swiss Ephemeris) and the exact data points returned, but says nothing about time basis, timezone, or precision.

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 that front-loads the core concept ('de stand van de hemel nu') and then lists the return contents. Nothing is redundant, though the colon-separated list gets slightly dense.

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 parameters and no output schema, the description carries responsibility for describing return values, which it does by enumerating the four data categories. Only a note on the time basis (server time vs. UTC) and geographic assumptions would make it fully 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?

The tool takes zero parameters, so there is no parameter semantics to explain and the baseline of 4 applies. The schema's additionalProperties:false and empty properties leave no ambiguity 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 names a specific resource ('de stand van de hemel nu') and enumerates exactly what is returned: sun/moon sign, moon phase, retrograde planets, and next full/new moon. That makes it clearly distinct from the horoscope siblings, though it never names an alternative to steer the agent away from 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?

The word 'nu' (now) plus 'vandaag' in the title implies this is the current-snapshot tool, so usage is inferable. However, there is no explicit statement of when to pick this over maankalender or daghoroscoop, and no exclusions or prerequisites.

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 safety (readOnly, idempotent, non-destructive, closed world), so the bar is lower. The description does add one genuinely useful behavioral fact beyond them: the response is a summary (title + core) plus a link, not the full horoscope text — relevant because no output schema exists.

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 resource and return shape come first. It is efficient, though it leaves room for a short routing clause without becoming bloated.

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 two-parameter read tool with complete schema coverage and no output schema, the description covers what it returns and the scope. The only meaningful gap is the absence of any comparison to the sibling day/week/month horoscope tools.

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% and both parameters are fully documented in the schema, including the 2026/2027 range, the 'empty means this year' default, and the Dutch sign enum with translation hints. The description adds nothing beyond that, 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?

Names a specific resource — the yearly horoscope for one zodiac sign — and states what comes back (title plus core text and a link to the full horoscope). The period word 'jaar' implicitly separates it from daghoroscoop/weekhoroscoop/maandhoroscoop, but that distinction is never made explicit.

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?

Usage is only implied by the tool name and period word; there is no explicit 'use this when the user asks for an annual reading, not a daily/weekly one' routing. With three sibling horoscope tools at other periods, an explicit exclusion sentence would materially help selection.

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 safety (readOnly, idempotent, non-destructive, closed-world), so the description's added value is its content disclosure: the result is only the title and first paragraph, with the full text behind a linked page and a free account. That is exactly the kind of expectation-setting an agent cannot get from 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?

Two short sentences with no filler; the payload scope is stated first and the truncation caveat second. 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?

There is no output schema, so the description must describe return content, and it does: title plus first paragraph, with a pointer to where the rest lives. For a single-parameter read tool this is essentially sufficient, missing only explicit sibling routing.

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% and the enum already carries Dutch-to-English sign translation guidance, so the description adds no parameter detail. Baseline 3 applies since the schema does all the work.

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 and period: 'de maandhoroscoop van deze maand voor een sterrenbeeld'. This clearly separates it from daghoroscoop, weekhoroscoop and jaarhoroscoop by period, though it never names those siblings explicitly.

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?

Usable scope is implied by the period word 'maand', so an agent can infer it should pick this over the daily or yearly variant. There is no explicit statement of when to use it, when not to, or any pointer to the 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?

Beyond the annotations (readOnly, idempotent), the description discloses real behavioral constraints: coverage is limited to 2026 and 2027, times are in Dutch time, and each entry includes zodiac sign. That is meaningful context an agent cannot get from the structured fields.

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 that front-loads the resource, then the year range, the output fields and the timezone. 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?

For a read-only, zero-required-param lookup with no output schema, the description covers scope, year restriction, timezone and returned fields. Only minor gaps remain, such as behavior for out-of-range months, which is a small omission.

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 the JJJJ-MM pattern and the 'empty means current month' default already documented in the schema. The description's 'in een maand' merely restates the month scope and adds no format or edge-case detail, so 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?

States a specific resource (volle en nieuwe manen) scoped to a month, plus the data returned (datum, tijd, sterrenbeeld). That clearly separates it from hemel_vandaag, maandhoroscoop and the other siblings, though it never names an alternative.

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?

Use is implied: consult moon phases for a given month. No explicit when-to-use / when-not-to-use guidance and no pointer to hemel_vandaag for a single-day view, so an agent must infer the routing.

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 and closed-world, so the safety profile needs no restating. The description adds genuine value by disclosing the response content (score range 1-5, sfeer, liefde, vriendschap, frictie), which matters because there is no output schema.

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 compact sentence that front-loads the core purpose and then enumerates the returned facets. No filler, no repetition of the title.

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 read-only tool with complete annotations and enum-documented inputs, the description covers purpose and return content adequately. Only the missing explicit usage routing keeps it from being fully 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% and both parameters already document the Dutch lowercase enum plus a full English-to-Dutch mapping, so the schema does the heavy lifting. The description adds no parameter-level meaning beyond that, which is the baseline 3 case.

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 specific operation and resource: compatibility between two zodiac signs, with the concrete outputs (1-5 score, atmosphere, love, friendship, friction). It is clearly distinct from the sibling horoscope/calendar tools, 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?

Usage is only implied — an agent can infer this applies when a user asks how two signs get along, but there is no explicit 'use this when' statement, no prerequisites, and no mention of alternatives such as the period horoscopes.

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, and closed-world, so the safety profile is covered. The description adds behavior beyond that: it discloses that the response includes the sign's date range and that boundary-day births produce a warning. It does not mention error behavior for an invalid date, which is a minor 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?

One sentence, front-loaded with the core mapping, followed by the two output details that matter (date range, boundary warning). No filler and nothing buried.

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 one-parameter lookup with no output schema, the description covers the input meaning, the primary return value, and the notable edge case (boundary day). Only the invalid-date/error path is unaddressed, which is minor given the schema's regex constraint.

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?

There is a single required parameter with 100% schema description coverage, including a JJJJ-MM-DD pattern, so the schema already carries the semantics. The description restates the parameter's meaning ('geboortedatum') but adds no format or edge-case detail beyond it. 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 names a specific verb+resource: it maps a birth date to a zodiac sun sign. It also previews the output (the sign's date range plus a boundary-day warning), which separates it from the horoscope-by-period siblings. It stops short of naming any sibling explicitly, so it is clear but not fully differentiated.

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 use case is strongly implied by the description ('welk sterrenbeeld hoort bij een geboortedatum'), but there is no explicit when-to-use, when-not-to-use, or pointer to an alternative sibling. An agent can infer the trigger from the name and description alone, but must do that inference itself.

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?

Adds real context beyond the annotations: the response is deliberately truncated to the title and first paragraph, and the rest lives on a linked page behind a free account. That sets correct expectations for output completeness and implicitly tells the agent this tool will not fetch the full article. Consistent with readOnlyHint, idempotentHint and openWorldHint=false, since no external retrieval is performed.

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 sentence, front-loaded with what is returned, followed by the crucial caveat about the truncated text. Nothing is repeated or wasted.

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 one-parameter read tool with full annotation coverage and no output schema, the description covers scope, return shape and the truncation limitation. It could still say what happens when no horoscope exists for the week or confirm the output language, but nothing essential to correct invocation is missing.

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% and the single enum parameter already documents the twelve Dutch sign names plus translation mappings. The description adds only the generic phrase 'voor een sterrenbeeld', so the schema is doing essentially all the work. 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?

States a specific verb+resource pair ('de weekhoroscoop van deze week voor een sterrenbeeld') and names the returned fields (titel en eerste alinea). The 'deze week' scope implicitly separates it from daghoroscoop/maandhoroscoop/jaarhoroscoop, but it never names those siblings or the condition that selects 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?

Usage is only implied: you call it when you want the current weekly horoscope for one sign. There is no explicit when-not, no mention of the daily/monthly/yearly siblings, and no note on what to do if the agent needs the full text instead of the excerpt.

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, non-destructive and closed-world, so safety is covered. The description adds only topical examples and says nothing about matching behavior (keyword vs. semantic), result volume, or ordering—modest added value given the annotation coverage.

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 the source and purpose before the examples. No filler, though the examples consume roughly half the text.

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 single-parameter search tool with rich annotations and no output schema, the essentials are present, but the description omits how matching works and what an agent should expect back, leaving a small gap an agent could stumble on.

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?

With schema coverage at 0%, the description carries the burden; the example topics do clarify what 'onderwerp' should contain. However, it gives no guidance on phrasing, language, or the documented 2–60 character constraint, so the one parameter is only partially explained.

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 verb (zoek) and resource (artikelen) tied to the Cosmic Journal source, and the examples ('Mercurius retrograde, volle maan of een sterrenbeeld') make the scope concrete. It implicitly separates itself from horoscope-generating siblings, but never names 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?

'over een onderwerp' plus the example topics implies when to use it (topical article lookup), but there is no explicit when-to-use/when-not guidance and no reference to alternatives like daghoroscoop or maankalender for date-based queries.

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