Taggun MCP by usefulapi

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds genuinely new behavior beyond that: the export is CSV, the returned text is truncated at 40,000 characters, and no scan is consumed. The truncation limit in particular is actionable and not available anywhere else.

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?

A single dense paragraph with the resource and options front-loaded, followed by the safety note, the truncation caveat, and the endpoint. Every clause carries information an agent needs; nothing is redundant with the schema or annotations.

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 one-parameter read tool with no output schema, the description covers the return format (CSV), the truncation behavior, and the underlying HTTP route, and it explains each input option. Nothing needed to call it correctly is missing.

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 coverage is already 100% and the enum values are self-explanatory, yet the description still adds meaning to each option (product_categories as the category taxonomy, known_merchants as merchant names/locations used for matching, product_codes as expected codes). That is real semantic enrichment on top of an already-documented single parameter.

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?

States a specific verb (read/export) and resource (account reference data) and enumerates the three exportable kinds with parenthetical explanations of what each contains. This distinguishes it cleanly from the scan and campaign siblings, which operate on receipts rather than stored account lists.

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 clause 'does not use a scan' explicitly steers the agent away from the scan_receipt siblings when the goal is fetching stored reference data, and the enumerated kinds make the selection condition concrete. It stops short of naming specific alternative tools or stating exclusions such as cost or prerequisites, so it is strong context without full routing guidance.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so safety is covered. The description adds real value beyond that by disclosing that no scan is consumed (a cost/quota-relevant trait) and by naming the exact endpoint GET /api/validation/v1/campaign/settings/{campaignId}.

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?

Two tight sentences: the rule contents lead, the scan exclusion and endpoint follow. No padding, and the parenthetical enumeration is informative rather than filler.

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?

There is no output schema, but the description compensates by enumerating the categories of rules returned (dates, merchants, products, fraud checks, prompts). Combined with the annotations and fully documented single parameter, an agent has everything needed to call it correctly.

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 coverage is 100% and the single parameter already documents itself, including pointing at taggun_list_campaigns as the source of IDs. The description adds nothing about the campaign_id beyond what the schema and endpoint template already convey, so the baseline of 3 is 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?

States a specific verb and resource ('stored validation rules of one campaign') and enumerates what those rules contain (dates, merchants, products, fraud checks, SmartValidate prompts). It also explicitly separates itself from the scan-based siblings with 'Does not use a scan,' so an agent can distinguish it from taggun_validate_receipt_campaign_url without opening any schema.

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?

'Does not use a scan' tells the agent this is the non-scanning retrieval path, implying it is the choice when campaign configuration is needed rather than receipt validation. There is no explicit when-not or a named alternative beyond the implicit contrast with the scan tools, so it falls short of a 5.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds genuinely useful operational context beyond the annotations: no scan/quota is used, empty results are normal rather than an error, and the failure mode when the feature flag is off.

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, front-loaded with the what and the return shape, followed by the two operational caveats an agent actually needs. The endpoint path is the only mildly redundant element and it is compact.

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, no-output-schema list tool, the description covers what comes back (ids), the normal empty case, and the feature-flag failure path. Only finer details such as ordering or error response shape are absent, which is acceptable here.

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 zero parameters, so there is nothing to document and the schema is trivially complete. The description correctly adds no parameter noise; baseline 4 applies for a parameterless tool.

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?

Specific verb (List) plus a narrowly scoped resource (the ids of receipt-validation campaigns on your Taggun account), and it states the return shape ('ids'). It does not name a sibling like taggun_get_campaign, but 'ids' makes the contrast with a detail-fetching tool inferable.

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?

Gives real preconditions: the Campaign Validation feature must be enabled, no scan is consumed, and an empty list is a normal result. It stops short of explicitly saying when to pick this over taggun_get_campaign, so condition-based routing is implied rather than stated.

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

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

Goes well beyond the annotations by disclosing that the call is billed against the caller's Taggun quota even when extraction fails, that it is never auto-retried, and that document content is not logged by this server. These cost/retry/data-handling facts are exactly the behavioral context annotations cannot express, and the lack of contradiction with readOnlyHint=false is consistent.

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 critical cost/quota warning is front-loaded in capitals before any other detail, and the remaining sentences each carry a distinct fact (formats, size cap, alternative, endpoint). It is dense but not padded, though the trailing POST path adds little for an agent already given the tool.

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 10-parameter, no-output-schema tool, the description covers cost, retention, format support, size limits and alternative routing. The only minor gap is any hint at the shape of the extraction result, though with no output schema that is reasonable to omit.

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%, so every parameter (near, detail, keep_stored, extract_time, ignore_merchant_name, etc.) is already documented in the schema. The description restates the base64 cap and formats but adds no syntax or semantics beyond that, so the baseline of 3 applies.

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?

States a specific verb and resource ("Extract structured data from a receipt or invoice sent as base64") and explicitly contrasts itself with the sibling taggun_scan_receipt_url. An agent can distinguish it from the URL-based scanner and the campaign validators without opening any schema.

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?

Gives a concrete routing rule to the alternative ("the base64 text is capped at 2,000,000 characters... for larger files use taggun_scan_receipt_url") and enumerates accepted formats. It stops short of stating when-not to use the tool relative to the campaign-validation siblings, but the primary selection decision is covered.

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

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

Adds substantial behavior beyond the annotations: the scan consumes quota and is billed even on validation failure, it is never retried automatically, and document content is not logged by the server. The 'WRITE' framing is consistent with readOnlyHint=false and openWorldHint=true rather than contradicting them.

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?

Front-loads the cost/quota warning, which is the highest-stakes fact, then the extraction summary and constraints in a compact block. It is dense but every sentence carries distinct information; the endpoint string is slightly redundant but useful.

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 non-idempotent, billed operation with no output schema, the description covers cost, retry behavior, privacy/logging, input formats and URL restrictions, and enumerates returned fields. It does not describe the failure/error response shape, which is the only notable gap.

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%, so the schema already documents all eight parameters including the simple/verbose enum and keep_stored privacy tradeoff. The description only restates verbose line-item behavior and file constraints, adding little syntax or default detail 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?

States a specific verb and resource ('Extract structured data ... from a receipt or invoice') and pins the input channel to 'a public https URL', which is what separates it from the sibling taggun_scan_receipt_base64. It also names the concrete output fields (merchant, date, total, tax, line items in verbose mode) and the underlying endpoint.

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?

Gives clear usage context: the URL must be a public host name with no IPs, localhost, credentials or non-default ports, and enumerates accepted formats/sizes. It does not explicitly route the agent to an alternative (e.g. use the base64 sibling when you have local bytes), so it stops short of the when/when-not/alternatives bar.

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

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

Adds substantial behavior beyond the annotations: the scan counts against quota even on failure, is never auto-retried, document content is not logged by the server, and the plan feature requirement. These are exactly the billing/side-effect facts an agent needs before invoking a WRITE operation, complementing readOnlyHint=false/idempotentHint=false.

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?

Dense but front-loaded: the WRITE/quota warning leads, then purpose, return value, prerequisites, and endpoint. Every sentence carries information, though the pricing parenthetical and endpoint string make it longer than strictly necessary.

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 write tool with no output schema, the description covers the return shape ('pass/fail with reasons'), billing consequences, storage/privacy behavior, prerequisite plan feature, and how to obtain the required id. Nothing an agent needs to call it correctly is missing.

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 coverage is 100%, so baseline is 3; the description adds value by tying campaign_id to taggun_list_campaigns and by cross-referencing the URL rules of taggun_scan_receipt_url. It does not explain the 'near' or 'language' hints, which is the only remaining gap.

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?

States a specific verb+resource pair (validate a receipt against a stored campaign) and scopes it precisely ('scan a receipt at a public https URL and check it against the rules of a campaign stored on your Taggun account'). It is clearly distinguishable from sibling taggun_scan_receipt_url (which only scans without campaign rules) and taggun_list_campaigns (which supplies ids).

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?

Gives concrete routing context: 'use taggun_list_campaigns for the ids', 'Same URL rules as taggun_scan_receipt_url', and the plan prerequisite ('Needs the Campaign Validation feature on your Taggun plan'). It does not explicitly state when to prefer a plain scan over a campaign validation, so it stops short of a full when/when-not statement.

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