Get the business details
invoices_get_profileThe business details used on quotes and invoices, the next numbers, and what is still missing before documents can be sent. Free.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
invoices_get_profileThe business details used on quotes and invoices, the next numbers, and what is still missing before documents can be sent. Free.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so safety is covered. The description adds genuine value by enumerating the payload (business details, next numbers, missing setup items), which matters because no output schema exists. It does not describe the return structure or what happens when no profile is configured, and the trailing 'Free.' is ambiguous.
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?
It is a single tight sentence that front-loads the payload description. The dangling 'Free.' fragment adds ambiguity rather than information and is the only wasted element.
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?
For a zero-parameter read with no output schema, the description covers the important ground: what comes back and why an agent would care (readiness to send documents). What remains missing is minor – return shape and behavior when the profile is unset.
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?
The tool takes no parameters, so there is nothing for the description to disambiguate; the baseline for zero-parameter tools is 4.
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 concretely names what the tool returns: business details used on quotes/invoices, next document numbers, and missing prerequisites before sending. That is more specific than the title alone. It does not, however, distinguish this read from the sibling invoices_set_profile, which an agent could easily confuse with it.
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?
Usage is only implied – the mention of 'what is still missing before documents can be sent' hints at a pre-send readiness check. There is no explicit instruction on when to call this versus invoices_set_profile, and no stated prerequisites or follow-up actions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.