Retrieve issuing business identities for invoice documents, with one profile per billing entity or tax registration, ordered newest first.
The identities you issue documents as, newest first.
One per entity you bill from — a business with two trading names or two tax registrations needs two. For how documents look rather than who issues them, see the branding profiles.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| cursor | No |
Changes observed during successful MCP inspections.
v0.1.2Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden, and it only discloses sort order ('newest first'). It never says this is a read-only operation, says nothing about pagination, page size limits, or what the response contains. For a cursor-paginated list tool, that leaves the agent guessing on the traits that matter most.
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?
Three short sentences with the conceptual definition front-loaded and the disambiguation pointer last. The emphasis asterisks and literary phrasing ('identities you issue documents *as*') cost a little precision, but nothing is padding.
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?
No output schema and no annotations, so the description would need to cover return shape and mutation safety—it covers neither. Combined with completely undocumented limit/cursor parameters, an agent cannot tell how many results come back or how to retrieve the remaining pages.
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 0%, so the description must explain both parameters, but it mentions neither 'limit' nor 'cursor'. The 'newest first' phrase hints at sort order but not at how to page or what a cursor represents, leaving the cursor parameter entirely undocumented anywhere in the definition.
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 defines the resource precisely—'the identities you issue documents *as*'—and implies enumeration via 'newest first', so an agent can infer a listing of business profiles. It also separates the concept from branding profiles ('how documents *look* rather than who issues them'). The verb itself is never stated outright, which keeps it short of a 5.
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?
It gives an implicit usage rule—one profile per billable entity, so a business with two trading names needs two—and routes a related-but-different need to branding profiles. There is no explicit 'use this when...' statement, no mention of the create/list relationship, and no guidance about paging through results.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.