Temsor API — Turkey & EU business data

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

With no annotations, the description carries the full burden. It discloses all verification checks (syntax, domain mail exchanger, disposable, role, typo) and normalization, and explicitly states the absence of SMTP probing. It does not cover authentication needs or rate limits, but provides sufficient behavioral details.

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 informative but slightly verbose. It front-loads the main purpose and then explains the rationale. Every sentence adds value, though some trimming could improve conciseness.

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 3 parameters, no output schema, and no annotations, the description provides a good level of context about what the tool does and its methodology. It lacks details on output format and error handling, but is reasonably complete for a verification 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 low (33%), so the description must compensate. It explains the 'email' parameter by detailing the checks performed, but does not explicitly link the boolean parameters 'rejectRoleAccounts' and 'rejectFreeProviders' to their functions, though 'role-account detection' and 'disposable service' are mentioned. Adds some value but could be more 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 specifies a clear verb ('checks') and resource ('e-mail address'), and lists multiple verification aspects (syntax, domain mail receipt, disposable detection, role detection, typo correction, normalization). It distinguishes itself from competitors by explicitly stating what is not done (no SMTP probing).

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 explains what the tool does and does not do, and provides reasoning for its approach. It implicitly suggests when to use it (when reliable verification without SMTP probing is needed) but does not explicitly mention alternative sibling tools or when not to use it.

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 fully discloses key behaviors: local format check first, never returning 'invalid' on outage, returning 'unknown' with reason, reporting country service status, 24-hour caching, and company name when available.

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, well-structured, and front-loaded with the main purpose, followed by essential behavioral details without unnecessary repetition.

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 tool with no output schema, the description covers return values (unknown, reason, service status, company name) adequately, though it does not list all fields explicitly.

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%, and the description adds clarifying examples and the relationship between vatNumber and countryCode, enhancing understanding beyond 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 clearly states the tool validates an EU VAT number against the VIES register, with per-country format checks. It is distinct from sibling tools like email_verify or iban_validate.

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 (for EU VAT validation) and explains behavior during outages, but lacks explicit exclusions or direct comparisons to other tools.

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?

No annotations are provided, so the description carries full burden. It details validation behavior: checksum, length, structure, bank/branch resolution, and even describes corrective suggestions for wrong check digits. 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?

The description is well-structured, front-loaded with the main purpose, then contrasts with alternatives, and adds specific details. Every sentence adds value, though slightly verbose.

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, and the description does not specify the return format or error handling. It mentions bank/branch resolution and corrective suggestions but does not clarify how results are structured.

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. The description adds overall context but does not directly enhance parameter understanding beyond what the schema's Turkish descriptions provide.

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 validates IBANs from 70+ countries, including checksum, country length, account structure, and bank/branch resolution. It distinguishes itself from free libraries that only do mod-97 checksum.

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 contrasts with simpler IBAN validators, telling when to use this tool for thorough validation including country structure checks. It also mentions special handling for Turkish IBANs, providing clear usage context.

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 full burden and does so exceptionally well. It discloses the measurement boundary ('only `initialize` and `tools/list` are ever called — never `tools/call`'), the daily archival nature, and the security rationale (detecting prompt injection via description changes). This goes beyond basic functionality and addresses safety-critical 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 somewhat verbose but front-loaded with the core concept in the first sentence. Each paragraph adds critical context (why it exists, what it enables, safety boundary). Slightly long, but for a tool with 9 parameters and no annotations, the detail is justified.

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 complexity (9 optional parameters, multiple views, no output schema), the description provides strong context about purpose and safety but stops short of describing return formats. However, the schema's parameter descriptions plus the high-level overview make it a viable, complete enough description for an agent to select and invoke the 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 89%, so the schema already documents parameters well. The description adds context about the 'views' (search, changes, server, tool, stats) but does not elaborate on individual parameter syntax or formats, which the schema already handles adequately.

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 purpose with specific verbs: a 'searchable, dated archive' of MCP server tool surfaces, daily change feed, and rug-pull detection. It immediately distinguishes itself from the sibling tools (which handle validation, invoices, etc.) by focusing on MCP server introspection.

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 implicitly defines when to use this tool by outlining three capabilities the official registry cannot provide: tool-level search, uptime tracking, and detecting description changes. It doesn't explicitly compare to alternatives, but the context is clear enough given the unique domain.

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?

No annotations exist, so the description carries the full behavioral disclosure burden. It admits a critical limitation: 'The archive can only accumulate forward — it cannot be reconstructed after the fact.' It also explains the external condition (providers overwriting pages) that makes the endpoint necessary. Missing details like rate limits or auth are not covered, but for a query-only archive, the disclosed constraints are substantive.

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 compact yet substantive: the first sentence defines, the second motivates, the third lists use cases, and the final notes a limitation. Every sentence earns its place, with no repetition or filler. The structure is logical and front-loaded with the core purpose.

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 complexity (10 optional parameters, 3 enums, multiple views) and no output schema, the description provides a solid conceptual model: what the archive contains, why it exists, and how to retrieve full history via series/history. It does not enumerate the view parameter or event types, but those are covered by the schema, so the description is nearly complete. A brief example would have pushed it to 5.

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 80%, so the baseline is 3. The description does not explain any parameter syntax or values; it only provides contextual motivation. The two undocumented parameters (limit, severity) are not compensated for by the description, but since most parameters already have schema descriptions, the missing details are not critical.

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 'Dated archive of LLM prices, context windows, announced retirement dates and quiet delistings across 400+ models and 50+ providers,' which precisely states the tool's verb (archive), resource scope (LLM price and lifecycle data), and breadth. It also distinguishes from sibling series_history by noting that full-range queries are available there, so the tool's boundary is clear.

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 enumerates three concrete questions the tool answers (historical cost, quiet delistings, retirement date changes), making the 'when to use' unambiguous. It also provides direct alternative guidance: 'Price points land in the shared time series, so a full range query is available through series/history,' which tells users exactly where to go for a different need.

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?

No annotations are provided, but the description discloses key behavioral traits: the tool is read-only and performs daily independent measurements. It explains the drift detection logic (repeats must agree and differ from previous run) and notes that same-day disagreement is noise. It does not cover potential limitations or authentication implications, but the core behavior is well-explained.

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 paragraphs, structured with a summary sentence followed by detailed methodology. It is informative without being excessive, though some details (e.g., temperature 0, three repeats) could be condensed. The use of bold for key terms and clear separation of views aids readability.

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 complexity of the tool (5 parameters, 3 views, no output schema), the description covers the high-level purpose and methodology but fails to detail the return format for each view. It mentions what each view provides conceptually but not the structure (e.g., fields returned). The 'limit' parameter is unexplained in both description and schema. Without an output schema, the description should compensate with more return value details.

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 80% (4 of 5 parameters have descriptions). The description adds value beyond the schema by explaining the conceptual meaning of each view: e.g., 'aliases answers what was actually behind gemini-flash-latest on that day'. It also clarifies the relationship between parameters, such as severity being only for events view. However, the 'limit' parameter lacks description in both schema and description, missing an opportunity.

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 purpose: tracking model drift behind provider endpoints by daily probing. It specifies the exact verb 'record' and resource 'provider endpoint model drift', and the context of aliases and behavioral shifts. The tool is distinct from all siblings which are unrelated (email verification, VAT validation, etc.), so no confusion arises.

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 detailed context on methodology (daily probes, temperature 0, three repeats) and when drift is reported (repeats agree and disagree with previous run). It explains the three views (aliases, events, probes) and their purposes, implicitly guiding when to use each. However, it lacks explicit 'when to use' vs. 'when not to use' guidance, and no alternatives are mentioned, though none exist among siblings.

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 fully discloses behavioral traits: normalizes to E.164, classifies line types (including special ranges), resolves province for Turkish landlines, and returns both E.164 and national notation. Also honestly states the limitation on operator detection with portability caveat.

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?

Well-structured: opening summary, usage context, detailed behavior, and honest limitation. Each paragraph is purposeful, though the last paragraph could be slightly tighter without losing clarity.

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 no output schema, the description covers key aspects: input format, two output notations, line type classification, province resolution, and operator caveat. It is fairly complete for a complex validation tool, though explicit output structure details would enhance completeness.

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% (both parameters described), so baseline 3. The description adds significant semantic value by explaining that defaultCountry defaults to TR, and how Turkish numbers are handled in depth (area codes, special ranges). This goes beyond the schema's minimal 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 clearly states the tool validates and normalizes phone numbers to E.164, classifies line type, and resolves province for Turkish landlines. It distinguishes from sibling tools by focusing on phone validation with Turkish specifics.

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 recommends use in signup and checkout flows for canonical storage and early error rejection. Also clarifies what the tool does not do (report current mobile operator) and provides caveats about number portability, helping the agent avoid misuse.

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 the matching algorithm (transliteration, fuzzy matching), the explanation of hits, and the `asOf` archive limitation. It does not mention authentication, rate limits, or explicit read-only behavior, but for a screening tool the key behavioral aspects are well covered.

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 structured paragraphs with all sentences contributing new information—no filler. It is somewhat lengthy but appropriately detailed for an 8-parameter tool, and it is front-loaded with the main purpose.

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 tool with no output schema, the description explains the hit explanation and `coverage` field, and provides parameter usage notes. It lacks explicit response structure details and error conditions, but is sufficiently complete for an experienced engineer.

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 88%, giving a high baseline, and the description adds meaningful guidance: `birthYear` as the 'single strongest false-positive filter', `type` narrowing removes false positives, and `asOf` being bounded by archive coverage. This goes beyond the schema, though not all parameters receive such enhancements.

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 a specific verb ('Screens a name') and resource ('six official sanctions lists'), enumerating the exact lists (OFAC, UN, EU, OFSI, SECO, Canada). This clearly distinguishes it from sibling verification and parsing tools.

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?

Provides clear guidance on when to supply `birthYear` (strongest false-positive filter) and `asOf` for auditor questions, implying intended contexts. However, it doesn't explicitly contrast with alternatives or state when not to use it, so it falls short of 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 provided, the description carries the full burden of behavioral disclosure. It reveals key traits: data normalisation ('normalised to one unit'), gap-filling behavior ('fillGaps carries the last value across weekends and holidays'), and evidence attachment ('source URL and content hash for every point'). It also explains the catalog behavior when seriesId is empty. This is substantial, though it does not cover all edge cases or response format.

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, consisting of three sentences that each serve a distinct purpose: stating the main return value, giving the current data source and normalization detail, and explaining two key parameters plus the catalog behavior. There is no fluff or repetition; 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?

Given 6 parameters, no annotations, and no output schema, the description does a good job conveying the tool's behavior and key features. It clarifies a non-obvious normalization nuance and parameter behavior. However, it does not describe the exact return structure (e.g., the shape of 'change statistics' or the receipt object), which would be useful given no output schema. Still, for a query tool, this is above-average completeness.

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 description adds meaning beyond the schema for several parameters. It explains fillGaps (which has no schema description) as carrying last value across weekends/holidays, and includeEvidence as attaching source URL and hash. It also gives concrete examples like `tcmb.usd` for seriesId. However, to, from, and limit are not addressed in the description, and schema descriptions cover to/from/seriesId/includeEvidence. Overall, the description compensates well for gaps 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 clearly states the tool's function: 'Returns the accumulated history of public data series with change statistics and a source receipt for every point.' This is specific about the verb (returns), resource (accumulated history), and includes distinguishing details (change stats, source receipt). It also mentions the current data source (Turkish Central Bank FX bulletin), which differentiates it from sibling tools that are mostly validation utilities.

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 usage context: it explains the current ingestion source, how to list the catalogue by leaving seriesId empty, and the behavior of fillGaps and includeEvidence. It does not explicitly state when NOT to use this tool versus alternatives, but the sibling tools are so different (validation tools) that the intended use is clear. This is solid context, though not an explicit exclusion.

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?

No annotations provided, but the description fully discloses behavior: checksum verification (fully for S10, not-verified otherwise), ranked list for Turkish carriers, and explicit out-of-scope (delivery status). Rationale given for design decisions.

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 somewhat lengthy but every sentence adds value. It front-loads the main purpose and then explains nuances. Could be slightly tighter, but still 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?

Despite no output schema, the description explains return values (canonical link, ranked list, verification status) and covers edge cases, limitations, and rationale. Complete for the intended use.

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%, but description adds context: country hint narrows candidates, tracking number accepts spaces/dashes. It also explains behavioral implications (ranked list) beyond parameter definitions.

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 identifies carrier, validates tracking number, and returns canonical tracking link. The verb 'identifies' and specific resource 'carrier for tracking number' are precise, and the tool is distinct from siblings which are other validation/address tools.

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 explains when to use (order systems routing customers) and provides context about limitations (Turkish carriers overlapping, ranked list). No explicit alternatives mentioned, but siblings are other domains, so the guidance is 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?

Fully discloses behaviors: handles abbreviation chaos, cross-checks province/postcode, repairs misspelled districts, returns confidence score, and lists unparsed fields. No annotations exist, so the description carries full burden and excels.

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 concise paragraphs, front-loaded with the main action. Every sentence adds value, no 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?

No output schema, but the description details return components (neighbourhood, street, etc.), confidence score, and unparsed field, making it complete for the tool's purpose.

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 has 2 parameters with 100% description coverage. The description adds value by explaining address as 'free-form' and defaultProvince as fallback, but the schema already describes them adequately.

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?

Clearly states the tool splits a free-form Turkish address into specific components (neighbourhood, street, etc.), with a precise verb (Splits) and resource (Turkish address). It distinguishes itself from siblings like tr_validate or tr_invoice_parse by focusing on address parsing.

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 mentions it is built for shipping, checkout, and CRM systems, providing context for when to use. However, it does not state when not to use or compare to alternatives like a generic address parser.

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 fully bears the burden. It explains the holiday lookup table, the Hijri calendar issue, and the behavior for unannounced years (confirmed:false). This is highly transparent and goes beyond basic expectations.

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 paragraphs with no wasted words. The first sentence delivers the core purpose, and the second expands on important behavior. It is well-structured 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?

No output schema is provided, and the description does not detail the return structure beyond mentioning confirmed:false. This leaves some ambiguity about response format, which is a gap given the tool's complexity.

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 descriptions cover all parameters (100% coverage), so baseline is 3. The tool description adds context for the countHalfDaysAsWork parameter by explaining half-day eves and provides overall operational context, justifying a score above baseline.

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 that the tool adds or counts business days, accounting for Turkish holidays. It explicitly mentions two modes (add and count), but does not differentiate from sibling tools, though none compete directly. This is clear but not exceptional.

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 concrete use cases: 'For delivery promises, SLA clocks, payment terms and shipping estimates.' This gives good context for when to use the tool. However, it does not discuss when not to use it or mention 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It effectively does so by explaining carry-forward behavior (`effectiveFrom`, `carriedForward: true`), change events with percentage moves, and the inclusion of source URL and content hash for auditability. This goes well beyond a basic operation description.

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 dense paragraph that front-loads the primary purpose and then flows into usage details and audit features. Every sentence contributes meaningful information without redundancy or fluff, achieving a high information-to-word ratio.

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 and no annotations, the description is remarkably complete. It covers the main query modes, edge cases (such as unchanged prices), and the nature of the response (including fields like `effectiveFrom`, `carriedForward`, source URL, and content hash). An agent can confidently select and invoke the tool based on this description alone.

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 83%, which sets a baseline of 3. The description adds meaningful semantics beyond the schema: it explains that `asOf` carries forward the previous price if unchanged, that `from`/`to` returns percentage changes, and that `province` empty lists coverage. While not every parameter gets such depth (e.g., `includeDistricts`), the added value is substantial.

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: retrieving petrol, diesel, and heating-oil pump prices for all 81 Turkish provinces, with support for past-dated prices. It uses a specific verb ('prices for...') and resource ('81 Turkish provinces'), and its focus on fuel prices distinguishes it from the sibling tools (e.g., email verification, invoice parsing).

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 concrete usage scenarios: using `asOf` to get the price on a specific date, using `from`/`to` to retrieve change events, and leaving `province` empty to list coverage. It gives clear context on when to use different parameter combinations, but it does not explicitly state when not to use the tool or mention alternatives (though no direct siblings exist).

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 fully discloses key behaviors: totals are recomputed, VKN/TCKN checksums verified, amount written in Turkish, and the tool does not sign or transmit. This is comprehensive for a financial 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?

The description is well-structured and informative at ~150 words. It is slightly verbose in the middle paragraph but front-loaded with purpose. Minor trimming could improve conciseness.

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 17 parameters, nested objects, and no output schema, the description covers core behavior but omits return format details (XML structure) and error handling or validation failure responses. Completeness is adequate but not full.

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 53%, and the description does not add much beyond the schema for individual parameters. It explains why totals are ignored but lacks per-parameter elaboration. 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 builds a UBL-TR e-Invoice or e-Archive XML from JSON, computing totals and validating parties. It distinguishes from sibling tools (e.g., tr_invoice_parse serves the opposite direction), and the title confirms the purpose.

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 explains the tool's role in the invoicing workflow—it does NOT sign or transmit—and implies prerequisites (certificate, integrator). However, it does not explicitly state when to avoid using it or contrast with alternatives, though siblings are unrelated.

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 fully carries the burden. It reveals key behaviors: namespace independence, normalization of single-line documents to arrays, and reporting amount mismatches in warnings, which is critical for correct use.

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 with three sentences, front-loaded with purpose. The third sentence is slightly marketing but adds context. Minor deduction for potential 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 no output schema, the description provides a high-level view of output structure (parties, line items, taxes, totals). More detail on the exact JSON structure would improve completeness, but for a simple parser it is adequate.

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 has 100% description coverage for the xml parameter. The tool's description adds context about processing but does not significantly enhance semantics beyond the schema. 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 clearly states the tool converts UBL-TR XML to clean JSON with specific outputs (parties, line items, taxes, totals). It distinguishes from the sibling tool tr_invoice_build, which is for building invoices.

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 use for parsing UBL-TR documents, but does not explicitly state when to use this tool over alternatives or provide exclusions. The context of sibling tools gives some guidance.

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?

No annotations provided, so the description carries full burden. It discloses handling of both decimal separators, application of Turkish rules, and mandatory status for e-invoices. However, it does not mention limits (e.g., maximum amount) or handling of negative amounts.

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 informative paragraph, front-loading the purpose before adding details. It is efficient but could be more structured (e.g., bullets) for clarity.

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 absence of an output schema and moderate complexity, the description covers the core behavior and rationale well. It lacks details on error handling or constraints, but it is largely complete for the intended use.

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 50%. The description adds context about why the tool behaves as it does (Turkish rules) but does not detail each parameter individually. It provides value beyond schema but not comprehensively for all parameters.

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 converts a monetary amount to Turkish words for invoices, cheques, and promissory notes. It specifies the unique Turkish rules (e.g., 'bin' not 'bir bin'), distinguishing it from generic libraries and sibling tools.

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 indicates use cases like Turkish e-invoices, cheques, and notes. It doesn't explicitly state when not to use it, but the context is clear. No alternatives are mentioned, but siblings do not overlap.

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 discloses pure local computation, microseconds latency, deterministic results, and extra resolution details (bank, province, GS1 prefix). This fully informs the agent of 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?

Two sentences deliver purpose, value, and performance characteristics. No redundancy; front-loaded with core functionality.

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 no output schema, the description covers what is validated, auto-detection, and supplementary info. It is sufficient for an agent to understand input and expected behavior.

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%, but description adds that type auto-detects from format and explains extra resolution per type, adding value beyond the schema's enum 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 clearly states it validates multiple Turkish identifiers (national ID, tax number, IBAN, etc.) with auto-detection. It distinguishes from siblings like iban_validate by covering all types in one endpoint.

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 this is the unified tool for Turkish IDs and numbers, but lacks explicit when-to-use vs alternatives. The context of sibling tools like iban_validate and phone_validate suggests differentiation but not stated.

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