Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@PismoSzyteNaMiare MCP Server Create a power of attorney for my brother to handle my bank affairs."
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Integrate PismoSzyteNaMiare into Claude, Cursor, VS Code, and any MCP-compatible AI assistant.
Generate umowy kupna-sprzedaży, pełnomocnictwa, wypowiedzenia umów, umowy pożyczki, and protokoły zdawczo-odbiorcze directly from your AI assistant.
No API key required. Free forever.
Add to ~/Library/Application Support/Claude/claude_desktop_config.json:
{
"mcpServers": {
"pismoszytenamiare": {
"command": "npx",
"args": ["pismoszytenamiare-mcp"]
}
}
}Connect via the Glama connector or directly:
https://softvoyagers-pismoszytenamiare-mcp.azurewebsites.net/mcpRelated MCP server: LegalForge MCP Server
Tool | Description |
| Generate a legal document PDF from structured input data |
| List all supported document types and their required fields |
| Preview a document before generating the final PDF |
PismoSzyteNaMiare generates professionally formatted Polish legal documents, including:
Umowa kupna-sprzedaży — sales contract generator for vehicles, real estate, and other assets
Pełnomocnictwo — power of attorney generator with customizable scope and duration
Wypowiedzenie umowy — contract termination letter generator for leases, subscriptions, and services
Umowa pożyczki — loan agreement generator with interest rates and repayment schedules
Protokół zdawczo-odbiorczy — handover protocol generator for apartments, offices, and equipment
Each document type supports full customization of parties, terms, and clauses. All generated documents are valid under Polish law.
This MCP server is a thin client over the PismoSzyteNaMiare REST API.
All requests are forwarded to https://pismoszytenamiare.pl — no data is processed or stored here.
Transport | Usage |
stdio |
|
HTTP |
|
Part of the SoftVoyagers free API portfolio.
Product | Domain |
LinkMeta | |
PageShot | |
PDFSpark | |
OGForge | |
LinkShrink | |
Faktuj | |
QRMint | |
PageDrop |
Get example data from the PismoSzyteNaMiare API. Replace with your real tool.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | Optional query parameter |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden, yet it discloses nothing about safety, permissions, return behavior, or side effects. Only the verb 'Get' weakly implies a read operation, which is minimal disclosure for a tool with zero annotation coverage.
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 text is short and front-loaded with the purpose, which is good. But the second sentence ('Replace with your real tool') is authoring meta-instruction that provides no value to a calling agent, so not 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?
With no annotations, no output schema, and a placeholder resource name, the description does not compensate for the missing behavioral and return-value context. An agent cannot confidently determine what to expect from a call.
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% with a single optional 'query' parameter, so the schema already documents the parameter. The description adds no syntax, format, or meaning beyond what the schema provides, making the baseline 3 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 states a verb (Get) and a resource (example data) plus the source API, so the basic purpose is parseable. However, 'example data' is a placeholder rather than a real resource, and the instruction to 'Replace with your real tool' signals this is a stub. It distinguishes from example_post only implicitly via the GET verb.
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?
There is no guidance on when to use this tool versus the sibling example_post, nor any conditions, prerequisites, or exclusions. The agent is left to infer usage entirely from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Post data to the PismoSzyteNaMiare API. Replace with your real tool.
| Name | Required | Description | Default |
|---|---|---|---|
| input | Yes | Input data to process |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden, and it discloses nothing: no auth requirements, no side effects, no idempotency or failure behavior, no indication of what is created or returned. A mutation tool with zero behavioral disclosure.
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?
Short, but the second sentence is boilerplate placeholder text that carries no operational meaning and signals an unfinished definition. Brevity here reflects under-specification rather than efficient editing.
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?
With no annotations, no output schema, and a placeholder description, nothing tells the agent how to call this safely or what to expect. The definition is not usable as written.
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% for the single "input" parameter, so the schema already documents it. The description adds no format, encoding, or content guidance beyond that, which is the baseline expectation when the schema does the work.
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?
"Post data to the PismoSzyteNaMiare API" names a verb and a target, but the target is an unnamed template placeholder and "Replace with your real tool" explicitly admits the content is not real. An agent cannot determine what resource is being posted or how this differs from the sibling example_get.
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?
No when-to-use guidance, no conditions, no exclusions, and no mention of the sibling example_get even though it is the obvious read counterpart to this write tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0example_getexample_postScored across 2 tools
The two tools are distinguishable by HTTP semantics (get vs. post), so there is no direct overlap. However, both descriptions are generic placeholders ('example data') and give no domain context, leaving real boundaries unclear.
Both names follow the same predictable <noun>_<method> pattern (example_get, example_post), which is easy to parse. The 'example' placeholder noun is not a meaningful domain entity, but consistency itself is solid.
With only two tools, the surface is thin for any real API server, and both are explicitly marked as placeholders. It is borderline rather than an extreme mismatch, since a minimal get/post pair can be a legitimate starting scope.
Only read and create-style operations exist; there is no update, delete, search, or domain-specific lifecycle coverage. As a template with no real surface, it cannot support meaningful agent workflows.
Compliant legal documents from your AI assistant: 1,100+ templates, 15 countries, free preview.
Fill in 1,000+ legal PDF templates in many languages, get a signed PDF back. Free, no API key.
Generate attorney-drafted NDAs, MSAs, DPAs, and more as PDF, ODT, or Markdown. No account required.
Create real Word .docx files from your AI chat: proposals, quotes, contracts, statements of work.
