Public PIO product information and hypothetical employment-cost estimates. No account required.
Scored across 3 tools
The three tools have clearly distinct purposes: submit a calculation job, read the result of that job by ID, and read public product facts. The descriptions explicitly distinguish creating an estimate from polling/reading it, and get_public_product_facts is unrelated to employer-cost calculations.
All tool names use snake_case with a verb_noun structure: estimate_employer_cost, get_employer_cost_estimate, and get_public_product_facts. The verb choice is action-appropriate and consistent throughout.
Three tools is well-scoped for a narrow public calculator/information server. Each tool earns its place: submit estimate, retrieve estimate, and retrieve public facts.
The core cost-estimate workflow is covered: create a job and poll/read its result, plus public product facts. Minor gaps exist around cancelling jobs or listing estimate history/topics, but the described auto-expiry and anonymous design reduce their importance.
Submit an anonymous hypothetical salary scenario to the PIO website calculator. This creates a calculation job, never an employee, bill or payment. Do not use employee records or personal/company information. Explicit country, currency, period and gross/net basis are required. A processing response contains no confirmed amount: poll get_employer_cost_estimate with the returned estimate_id after retryAfterSeconds. Identical scenarios from the same caller resume the same job for 29 minutes. Totals cover returned components only; fees, deposits and unlisted benefits are not confirmed.
| Name | Required | Description | Default |
|---|---|---|---|
| salary | Yes | ||
| currency | Yes | ||
| language | No | en | |
| tax_year | No | Current year only, or null for the current year. | |
| region_code | No | ||
| country_code | Yes | ||
| salary_basis | Yes | ||
| salary_period | Yes |
| Name | Required | Description |
|---|---|---|
| status | Yes | |
| message | Yes | |
| available | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare readOnlyHint=false, openWorldHint=true, idempotentHint=true and destructiveHint=false; the description adds substantial context beyond them: it creates a calculation job rather than a record, identical scenarios from the same caller resume the same job for 29 minutes (concretizing the idempotency window), and the initial response contains no confirmed amount. It also bounds the result semantics (totals cover returned components only; fees, deposits and unlisted benefits are not confirmed), which is exactly the kind of disclosure annotations cannot carry.
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?
Six tightly packed sentences, front-loaded with the purpose and the anonymity constraint, each carrying distinct information about behavior or follow-up. It is long but not padded; slight compression of the totals-disclaimer clause would tighten it further.
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 an asynchronous, open-world job-creating tool, the description covers the critical gaps an agent needs: anonymity rules, async polling contract, idempotency window, and result-scope caveats, and an output schema exists so return structure needn't be explained. The only residual gap is the optional region_code/tax_year semantics.
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 only 13%, so the description must compensate, and it partially does by naming the required dimensions: country, currency, period and gross/net basis. However, it says nothing about region_code (a large enum that plausibly changes the calculation), tax_year, or language, leaving four of eight parameters with no narrative meaning beyond the schema types.
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: submit an anonymous hypothetical salary scenario to the PIO website calculator. It immediately clarifies what the operation is not (never an employee, bill or payment), which removes the most likely ambiguity for an agent reading the name.
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?
Explicitly excludes a whole class of inputs (do not use employee records or personal/company information) and routes the agent to the sibling tool get_employer_cost_estimate for polling with estimate_id after retryAfterSeconds. When-to-use, when-not-to-use, and the alternative are all spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read the calculation created by estimate_employer_cost using its opaque estimate_id. Keep that handle private. A completed calculation remains an estimate, not a quote or a complete employer cost. Do not resubmit a processing scenario.
| Name | Required | Description | Default |
|---|---|---|---|
| estimate_id | Yes |
| Name | Required | Description |
|---|---|---|
| status | Yes | |
| message | Yes | |
| available | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, non-destructive and open-world behavior, so the bar is lower; the description adds real value by flagging that the handle is opaque/private and that results are estimates rather than quotes, but it does not explain invalid/expired handle behavior or pagination.
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?
Four short sentences that are front-loaded with the core action and the safety caveat; the final sentence about resubmitting a processing scenario is terse and slightly cryptic but not wasted.
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?
With one parameter and an output schema present, the description need not describe return values, and it does cover state semantics (processing vs. completed). It is close to complete, missing only error/expiry handling guidance.
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 0%, so the description carries the burden and does supply provenance (created by estimate_employer_cost), opacity, and confidentiality of estimate_id, but it omits any hint of the strict 32-character format or what an invalid handle yields.
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 ('Read the calculation created by estimate_employer_cost') and ties the resource to the exact sibling that produces it, so an agent can immediately distinguish this read tool from the create tool.
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?
Makes clear the input must come from estimate_employer_cost and adds a negative rule ('Do not resubmit a processing scenario'), but never mentions get_public_product_facts or what to do when the estimate is still processing beyond that brief exclusion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read reviewed public PIO product information with source URLs. Select a topic; no account, team, employee information or private knowledge is accessed. This does not quote customer-specific pricing.
| Name | Required | Description | Default |
|---|---|---|---|
| topic | Yes | ||
| language | No | en |
| Name | Required | Description |
|---|---|---|
| status | Yes | |
| message | Yes | |
| available | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds genuinely new behavioral context: the content is 'reviewed', responses include source URLs, and no account, team or employee information is accessed. That privacy/scope disclosure is exactly the kind of value annotations cannot carry, though nothing is said about refresh cadence or coverage limits.
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 capability and then the scope exclusions, with zero filler. The only inefficiency is that 'Select a topic' spends a sentence on instruction without conveying the information the agent actually needs.
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?
An output schema exists, so return values need not be explained, and the privacy/scope disclosures cover the main risk surface. But for a two-parameter tool whose enums are entirely undocumented in the schema, leaving every topic value unexplained is a real completeness 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 0% and both parameters are bare enums, so the description must carry the burden. It only says 'Select a topic' without naming or explaining any enum value, and the values ('eor', 'cor', 'cost_estimator') are opaque acronyms an agent cannot resolve without domain knowledge. The 'language' parameter is never mentioned at all.
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 – 'Read reviewed public PIO product information with source URLs' – and scopes it against pricing content. An agent can distinguish it from the cost-estimate siblings because the description explicitly says it does not quote customer-specific pricing. The unexplained acronym 'PIO' costs it a point on absolute clarity.
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?
'Select a topic' implies usage, and the pricing disclaimer implicitly points at the estimate siblings for cost questions, but the description never names those alternatives or states the positive condition for choosing this tool. The agent must infer routing from the exclusion alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
estimate_employer_costget_employer_cost_estimateget_public_product_factsSearch Accent's public website and get non-binding budgetary estimates from published plan prices.
Plan automation pilots, estimate illustrative ROI and prioritize workflows. Public, no account.
Read-only, permission-scoped PIO team workflows for payments, payroll and employee onboarding.
Ecommerce sourcing, inspection and fulfillment planning. Base-cost estimates; no private data.
Add one secure layer between your agents and this server.