e-conomic MCP Server and API by Cotlet

Create entry in e-conomic

e_conomic_create_entry

Read-onlyIdempotent

Create entry in the user's own e-conomic account from ChatGPT, Claude or any AI agent. Returns how to do it in e-conomic step by step (screens, buttons, fields) and opens nothing by itself; then do it with the cotlet_browser_* tools in the user's e-conomic Cloud Browser. e-conomic's official API: Yes, e-conomic has a full REST API with customers, draft and booked invoices, invoice PDFs and journal vouchers (checked 14 Oct 2026), but you get it through a developer agreement: you create an app that holds an AppSecretToken, and each accounting user grants it access with an AgreementGrantToken.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "e_conomic_create_entry"
  }
}

Input Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 9, 2026

TDQS

A3.5/5.0

Behavior4/5

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

Annotations already mark the tool as read-only, idempotent, and non-destructive. The description reinforces this by stating it returns instructions and opens nothing, and it adds what the output contains (screens, buttons, fields). This goes beyond the annotations to explain the return content and safety behavior.

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

Conciseness2/5

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

The essential behavior is front-loaded in the first two sentences, but the rest of the description digresses into e-conomic's API, developer agreement, and token details, which are irrelevant to this tool's function. This bloat distracts from the core purpose and makes the description overly long for a zero-parameter read-only tool.

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

Completeness3/5

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

Given the tool's simplicity (zero parameters, no output schema, read-only annotations), the description covers the core behavior and workflow with browser tools. However, it could better clarify how to invoke it in context (e.g., whether it requires conversational context) and avoid the misleading 'Create entry' phrasing. It is adequate but has notable gaps in precision.

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

Parameters4/5

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

The tool has zero parameters, so the baseline is 4. The description does not need to explain parameter meanings, and none are present.

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

Purpose3/5

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

The description states it returns step-by-step instructions for creating an entry and explicitly says it opens nothing by itself, which clarifies the actual read-only nature. However, the name and opening phrase 'Create entry' strongly imply a write action, creating ambiguity about what the tool actually does. It does distinguish itself from sibling browser tools by specifying they perform the action.

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 gives a clear workflow: call this tool to get instructions, then use the cotlet_browser_* tools to execute the steps in the user's e-conomic Cloud Browser. This tells the agent when and how to use it relative to siblings. It lacks explicit when-not-to-use cases, but the context is sufficiently clear.

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

All e-conomic MCP Server and API by Cotlet tools Inspect

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

Need Help?