Skip to main content
Glama

Check tax number

billingo_check_tax_number
Read-onlyIdempotent

Validate a Hungarian tax number against NAV and retrieve the company data before creating a partner; requires a live NAV Online Számla connection.

Instructions

Looks up a Hungarian tax number at NAV and returns the company data behind it. Use this to validate a tax number before creating a partner. Works only when the Billingo account has a live NAV Online Számla connection (not available on sandbox accounts).

Input Schema

NameRequiredDescriptionDefault
tax_numberYesFull Hungarian tax number with hyphens, e.g. "12345678-2-42".

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv0.1.3
    • changedInput schema / properties / tax_number / description
      Previous value: -"Hungarian tax number, e.g. \"12345678\" or \"12345678-2-42\"."New value: +"Full Hungarian tax number with hyphens, e.g. \"12345678-2-42\"."
    • removedInput schema / properties / tax_number / minLength
      Removed value: -1
    • addedInput schema / properties / tax_number / pattern
      Added value: +"^\\d{8}-\\d-\\d{2}$"
  2. First observedv0.1.0

TDQS

A4.2/5.0
Behavior4/5

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

Adds real context beyond the annotations: it calls out to NAV, requires a live NAV Online Számla connection, and is unavailable on sandbox accounts. It does not cover failure modes for invalid numbers or response shape, but the external-dependency disclosure is valuable.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three tight sentences, front-loaded with the action and followed by usage and the key constraint. Nothing is redundant.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a one-parameter read-only lookup with full schema coverage, the description covers what it does, when to use it, and the account-level prerequisite. Return-value detail is limited to 'company data' given no output schema, but that is a minor gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with a single parameter fully described including a pattern and example. The description adds no additional parameter meaning, so the schema baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource (looks up a Hungarian tax number at NAV) and what it returns (company data behind it). This is clearly distinguishable from sibling partner/listing tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says to use it to validate a tax number before creating a partner, which is a clear usage context. It also states the operational precondition (live NAV Online Számla connection, not sandbox), though it names no alternative tool.

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