Marks a received invoice or expense as paid for tax-evidence bookkeeping, optionally setting the payment date (defaults to today).
Označí přijatou fakturu (výdaj) jako zaplacenou — pro daňovou evidenci se skutečnými výdaji.
| Name | Required | Description | Default |
|---|---|---|---|
| paid_date | No | Datum úhrady YYYY-MM-DD. Default dnes. | |
| expense_id | Yes | ID výdaje (název PDF bez přípony). |
| Name | Required | Description | Default |
|---|---|---|---|
| result | Yes |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Bez anotací nese popis plnou tíhu, ale podává jen účel — zmiňuje vazbu na daňovou evidenci skutečných výdajů, což je užitečný dopad operace. Neuvádí však, zda je označení vratné, co se stane při opakovaném volání, ani jaká oprávnění jsou potřeba.
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?
Jediná věta, ihned sděluje akci a objekt, bez zbytečných slov. Nic podstatného nechybí ani nepřebývá.
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?
Jde o jednoduchý mutační nástroj se dvěma plně popsanými parametry a existujícím výstupním schématem, takže popis je téměř dostačující. Rezervou je chybějící informace o chování při již zaplaceném výdaji a o možnosti vrácení.
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?
Krytí schématu popisy je 100 % (expense_id jako název PDF bez přípony, paid_date s defaultem dnes), takže popis nemusí parametry vysvětlovat. Popis k nim nic dalšího nepřidává, což při úplném schématu odpovídá základu 3.
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?
Uvádí konkrétní sloveso (označí jako zaplacenou) i objekt (přijatou fakturu/výdaj) a závorkou 'výdaj' ji odlišuje od faktur vydaných. Chybí však výslovné odlišení od sourozeneckých nástrojů 'mark_paid' a 'record_payment', se kterými se dá snadno splést.
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?
'Pro daňovou evidenci se skutečnými výdaji' naznačuje kontext použití (režim skutečných výdajů), ale není řečeno, kdy zvolit tento nástroj místo 'mark_paid' nebo 'record_payment', ani jaké jsou předpoklady (např. že výdaj existuje a není již zaplacený).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.