Skip to main content
Glama

IUSTORIA – průvodci a právní kalkulačky

by cz.iustoria
OverviewDiscussionsAdmin

Odeslat poptávku z formuláře

poptavka_odeslat
Destructive

Jen pro formulář poptávky, který otevře nástroj poptavka; model tento nástroj nevidí ani nevolá. Připraví poptávku, kterou uživatel sám vyplnil a odeslal tlačítkem ve formuláři, a pošle mu na zadaný e-mail odkaz k potvrzení. Kanceláři IUSTORIA poptávka odejde až poté, co ji uživatel na stránce z odkazu potvrdí. Vyžaduje jednorázový token formuláře. Přílohy nepřijímá. Odesláním poptávky nevzniká smlouva ani vztah advokáta a klienta. EN: Only for the enquiry form (app-only, hidden from the model). Prepares the enquiry and emails the user a confirmation link; the firm receives it only after confirmation.

Input Schema

NameRequiredDescriptionDefault
emailYesE-mail, na který přijde odkaz k potvrzení. EN: Email for the confirmation link.
jazykNoJazyk komunikace: cs (výchozí), en, de, fr. EN: Language of communication.
jmenoYesJméno a příjmení. EN: Full name.
lhutaNoBěží ve věci lhůta: ano, ne, nevim. EN: Is a deadline running.
popisYesStručný popis věci, bez listin a citlivých údajů; nejvýše jeden odkaz. EN: Short description of the matter.
tokenYesJednorázový token formuláře z _meta výsledku nástroje poptavka. EN: One-time form token from the poptavka result.
oblastYesOblast, které se věc týká. EN: Area of law.
telefonNoTelefon (nepovinný). EN: Phone (optional).
lhuta_datumNoKdy lhůta končí, RRRR-MM-DD (jen u lhuta ano). EN: Deadline date.
protistranaNoProtistrana: jméno nebo firma (nepovinné, kvůli prověření střetu zájmů). EN: Other party (optional).
beru_na_vedomiYesUživatel bere na vědomí, že poptávku posílá kanceláři IUSTORIA, že tím nevzniká smlouva a že případná spolupráce se bude řídit smlouvou a VOP. EN: User acknowledges the enquiry goes to IUSTORIA and creates no contract.
bez_citlivych_udajuYesV popisu nejsou citlivé údaje (zdraví, rodná čísla, čísla účtů). EN: No sensitive data in the description.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.4/5.0
Behavior5/5

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

Beyond the annotations (non-readonly, destructive, open-world, non-idempotent), it discloses the full side-effect chain: a confirmation link is emailed, the firm receives nothing until the user confirms, a one-time token is required, attachments are rejected, and no contract/attorney-client relationship is formed. This is exactly the extra behavioral context annotations can't convey.

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

Conciseness4/5

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

Front-loads the scope constraint and side-effect flow, every sentence carries information. The Czech and English blocks are duplicative by design, which is acceptable for bilingual clarity but slightly inflates length.

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

Completeness5/5

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

For a form-triggered send with no output schema, the description covers prerequisites (token from poptavka), irreversible side effects, confirmation gating, and legal caveats — everything needed to reason about the call without an output schema.

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%, so the schema already documents all 12 parameters including the token, email, and enum fields. The description only reiterates the token requirement and the no-attachment rule, adding marginal meaning over the schema. Baseline 3 applies when the schema does the heavy lifting.

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?

The description states a specific verb and resource — sending an enquiry from the form — and immediately distinguishes itself from the sibling tool poptavka, which opens the form. An agent can tell exactly what this does and how it relates to the form flow.

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?

It names the alternative context explicitly ('only for the enquiry form opened by poptavka', 'model doesn't see or call it') and pins the token to poptavka's result. Usage conditions are clear, though framed as a negative ('do not call') rather than offering richer routing alternatives.

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

All IUSTORIA – průvodci a právní kalkulačky toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources