invoice_processing__list_finance_incoming_services

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds valuable behavioral context beyond those annotations: MCP-server throttling at no more than 10 requests per 60 seconds and an explicit instruction to cache the result in the dialogue. No contradiction with annotations is present.

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, front-loaded sentences cover the result, the ID acquisition path, and the throttling/caching rule. Every sentence adds operational value with no filler or redundancy.

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 read-only list tool this is actionable: it gives the period framing, the organizationId source, and the rate-limit/caching behavior needed to call it correctly. It does not describe the return payload or pagination, but the list semantics and schema make the invocation sufficiently complete.

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 input schema already documents from/to as YYYY-MM-DD and organizationId as a GUID. The description adds the 'period' semantic and a concrete source for organizationId via organizations__get_organizations, but it does not elaborate on the request-wrapper structure or formatting beyond what the schema provides.

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 opens with a specific verb-noun phrase: 'List of acts of receipt of services for a period,' immediately identifying the resource and time scope. It clearly distinguishes this list endpoint from the singular get_finance_incoming_service and from the outgoing-service sibling by using 'прихода услуг.'

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?

The description provides a concrete prerequisite by pointing to organizations__get_organizations for obtaining organizationId, and it implies the period-based use case. However, it does not explicitly state when to prefer this over get_finance_incoming_service or list_finance_outgoing_services, so the usage guidance remains mostly implied.

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