List the primary sources the corpus can search, and what each covers.
Use this to discover the valid `sources` filter values for
`search_italian_tax_sources` and to understand the corpus's coverage.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
| Name | Required | Description | Default |
|---|---|---|---|
| sources | Yes | ||
| disclaimer | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true. Description adds that it returns list of sources and their coverage, and that it helps discover valid filter values for a sibling tool, providing full behavioral context.
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 waste. First sentence states purpose, second explains usage. Front-loaded and efficient.
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 0-parameter tool with output schema and helpful annotations, description fully covers purpose and context, including relationship to sibling 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?
Input schema has 0 parameters, so baseline is 4. Description adds nothing about parameters as there are none.
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?
Description clearly states it lists primary sources and what each covers, and explains its use for discovering valid filter values for search_italian_tax_sources. This distinguishes it from siblings (calculate, compare, 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?
Explicitly guides to use for discovering valid sources filter values and understanding corpus coverage. Does not specify when not to use, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Each tool has a clearly distinct purpose: calculate targets one specific regime, compare evaluates all regimes side-by-side, and the two source tools cleanly separate listing available sources from searching their contents. There is no realistic risk of selecting the wrong tool for a task.
Tool names follow a consistent lowercase snake_case verb-first pattern, e.g. calculate_italian_tax, compare_italian_regimes, search_italian_tax_sources. The one minor deviation is list_tax_sources, which omits the 'italian' descriptor that appears in the other source/search tool.
Four tools is a well-scoped size for this server's purpose: two calculation/regime tools and two source-discovery/search tools. Each tool has a distinct and necessary role, with no redundant or filler tools.
The set covers the main workflows: single-regime calculation, cross-regime comparison, source discovery, and corpus search. Minor gaps exist, such as no explicit tax-year selection and no direct tool for retrieving raw tax tables outside of search, but the source search tool can mitigate these.