Check micro-entity company accounts: raw figures in, validated balance sheet and deadlines out.
Scored across 20 tools
Each tool has a clearly distinct purpose: search vs lookup by name/number, save vs check vs explain accounts, and deadline eligibility vs penalty cost vs reminder tracking are explicitly separated. Overlaps in the deadline/filing domain are well handled by the descriptions.
All names use snake_case and most follow a verb_noun pattern such as list_saved_filings, check_accounts, and track_company_deadlines. A few noun-phrase names like dormant_figures, late_filing_penalty, sample_accounts, and server_status are minor deviations from the pattern.
20 tools is on the heavy side for an accounts-preparation assistant and sits at the borderline where the set starts to feel broad. Most tools earn their place, but some deadline/filing helpers could likely be consolidated.
The surface covers the full practical lifecycle: company discovery, prior-year retrieval, categorization, figures derivation, validation, explanation, save/update/list/delete filings, dormant accounts, deadlines, extensions, penalties, and deadline tracking. Actual submission is intentionally out of scope, so the absence of a submit tool is not a real gap.
Categorise bank-statement transaction descriptions into the fixed vocabulary this product maps to balance sheet lines (sales, software, owner-in, …). Send description strings only, never amounts or dates. Sum the amounts per returned category yourself, then call totals_to_figures. One statement import is one quota unit; previously seen descriptions are answered from a shared cache free.
| Name | Required | Description | Default |
|---|---|---|---|
| tradingType | Yes | What the company does, to resolve ambiguous merchants. One of: software, consulting, creative, retail, construction, property, hospitality, other. lookup_company suggests one from the SIC codes. | other |
| descriptions | Yes | The raw description strings, one per transaction. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover the safety profile (readOnly, idempotent, non-destructive, openWorld), and the description layers on real operational facts: one statement import equals one quota unit and cached descriptions are free. It stops short of stating the exact return shape (e.g. whether categories come back one per input string), so it is strong but not exhaustive.
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 sentences, all load-bearing and front-loaded: what it does, what to send, what to do next. No filler or repetition of the title.
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 no output schema, the description carries the return burden and does indicate that categories are returned per description, enough to reconstruct the workflow. It could be slightly more explicit about the mapping result (one category per input string, unmatched handling), which is the only remaining gap for a 2-parameter tool.
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 already 100%, so the baseline is 3. The description adds meaning beyond the schema by constraining what descriptions must and must not contain, and it frames tradingType's ambiguity-resolution role; it does not, however, add syntax or cardinality guidance beyond what the schema says.
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 (categorise) and resource (bank-statement transaction descriptions) plus the target vocabulary. It also names the downstream sibling totals_to_figures, so the agent can place it in a workflow without opening another 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 explicit input constraints (send description strings only, never amounts or dates), the required follow-up step (sum amounts per category yourself, then call totals_to_figures), and cost context. The routing to both the next tool and the schema-level lookup_company hint leaves little to infer.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Derive a small-company balance sheet (micro-entity, in UK terms) from raw figures and validate it. Returns the derived sheet for the current and prior year, the figures the authority would reject (negatives where it wants a positive, share capital left at nil), and whether they are complete enough to hand to a filing product. It does NOT check that the sheet balances and cannot: retained earnings is derived as the balancing figure, so each column always agrees with itself. Do not tell anybody their sheet was checked for internal consistency within a column. It DOES compare the two columns to each other: when this year's reserves do not equal last year's plus this year's result it returns a warning, which most often means last year was wrong and the comparative needs restating. Free and instant: call it after every change to the figures. All money in major units (pounds not pence, dollars not cents). Pass lastFiledAs from lookup_company and it also warns when figures showing activity are about to be filed dormant again.
| Name | Required | Description | Default |
|---|---|---|---|
| figures | Yes | The figures behind a small-company balance sheet. ALL amounts in major units. | |
| lastFiledAs | No | What the last accounts were filed as, straight from lookup_company's company.lastAccountsType. Pass it through; do not guess it. | |
| jurisdiction | Yes | ISO country code. GB is the only jurisdiction with full support. | GB |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly/idempotent annotations, it discloses the crucial limitation that it cannot check that the sheet balances (retained earnings is the balancing figure), the cross-column reserves comparison warning and its likely meaning, free/instant cost, and major-units convention. This is rich behavioral context the annotations cannot convey.
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: purpose, then return values, then the two limitation/comparison caveats, then cost and currency. The 'Do not tell anybody their sheet was checked...' sentence is slightly discursive but carries an important framing constraint; overall tight for the amount of critical guidance.
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, yet the description fully describes the return (derived current/prior-year sheet, rejected figures, completeness flag) and the warnings from lastFiledAs. An agent has everything needed to call and interpret it.
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, but the description adds meaning to lastFiledAs (source is lookup_company's company.lastAccountsType, and what it triggers: a dormant-filing warning) and clarifies major-unit currency. That is genuine value beyond the schema.
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: 'derive a small-company balance sheet... from raw figures and validate it', with the exact return contents enumerated. This clearly distinguishes it from siblings like explain_accounts or totals_to_figures.
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?
Explicit 'call it after every change to the figures', plus instructions to pass lastFiledAs from lookup_company rather than guessing. It also carves out what it does not do, preventing misuse.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Whether a company can still apply to its registrar for more time to file, how many days are left to apply, and what being late costs if that window is missed. This is usually the most useful thing to tell somebody who has just found a deadline: applying is free, takes about 15 minutes, and has to be done BEFORE the deadline it extends, so the option expires on the same day the penalty starts. Returns nextAction first. It PREPARES an application and can never submit one: the application is made by a director on the registrar’s own service, which this tool links to. It does not file accounts. Give a company number to read the deadline off the register (quota-charged, cached results free), or give the dates yourself and it costs nothing.
| Name | Required | Description | Default |
|---|---|---|---|
| today | No | Defaults to the server's date. Supply it to test a boundary. | |
| filing | Yes | Which deadline. Only accounts can be extended; ask about the other and it says so. | accounts |
| periodEnd | No | The accounting reference date. Bounds how much extra time could be granted. | |
| jurisdiction | Yes | ISO country code. Register access exists for GB and AU. | GB |
| companyNumber | No | Read the deadline and period end off the register. Omit if you supply the dates. | |
| filingDeadline | No | The normal filing deadline, if you already have it. Skips the register request. | |
| alreadyExtended | Yes | True if this deadline has been extended once already. Do not guess it, ask. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover the safety profile (readOnlyHint, idempotent, openWorld, non-destructive). The description adds genuinely useful operational context: quota-charged register reads vs free cached results, register access limited to GB and AU, and that it PREPARES but can never submit an application. With annotations already carrying safety, this is solid added context, though exact quota costs and cache expiry semantics remain unspecified.
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 core answer and the return-shape hint ('Returns nextAction first') and the never-submits constraint is prominent. It is information-dense but runs long with several parenthetical asides, slightly hurting scanability.
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 exists, so the description correctly compensates by naming the primary return field ('nextAction first'). Combined with input-mode, cost, and jurisdiction caveats, 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%, so the baseline would be 3, but the description adds real semantic guidance beyond the schema: the companyNumber-vs-dates tradeoff (register read costs a quota unit, supplying dates is free) and the instruction not to guess alreadyExtended. It adds meaning rather than restating field names.
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: whether a company can still apply for a filing extension, days remaining, and the cost of missing the window. It is clearly distinguishable from siblings like check_accounts and late_filing_penalty, and it explicitly says what it does not do (does not file accounts).
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 explicit when-to-use context ('the most useful thing to tell somebody who has just found a deadline'), the alternative path (the registrar's own service, which the tool links to), and the two input modes with their cost tradeoffs. It also states the hard rule that application must happen BEFORE the deadline it extends.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete one saved filing by id, permanently. Confirm with the person before calling this; there is no undo and no trash.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The id from list_saved_filings. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and idempotentHint=true, but the description adds meaningful detail beyond them: the deletion is permanent, there is no undo and no trash, and a human confirmation is required first. It does not mention auth/permission requirements, but the added behavioral context is substantial.
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 short sentences, front-loaded with the action and scope, then the safety precondition. Every clause earns its place with no 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 single-parameter destructive mutation with no output schema, the description covers permanence, irreversibility, and the confirmation requirement. Missing only error behavior (e.g., what happens on an invalid or already-deleted id), which is a minor 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 coverage is 100% and the single id parameter already documents its origin ('The id from list_saved_filings'). The description only restates 'by id' without adding format or lookup detail, so the baseline 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?
The description states a specific verb (delete), resource (one saved filing), and scope (by id, permanently). It is unmistakable against siblings like save_filing or list_saved_filings, though it never explicitly names an adjacent tool to route away from.
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 a clear precondition: confirm with the person before calling, because the action cannot be undone. It does not discuss when deletion is appropriate versus alternatives such as keeping or re-saving a filing, so it stops short of full when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The complete set of figures for a dormant company: share capital, the matching cash, and zeros everywhere else. The register says when the last accounts were filed dormant, and for those companies this collapses the whole form to one call. Amounts in major units.
| Name | Required | Description | Default |
|---|---|---|---|
| shareCapital | Yes | Issued share capital in major units. 1 is the overwhelmingly common figure. |
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's added value is the 'whole form collapses to one call' compaction behaviour and the 'major units' convention. It does not address how the tool resolves the target company when the schema takes no company identifier, nor any return shape beyond the field list.
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 sentences, front-loaded with the output content before the routing rationale and the units caveat. Little waste, though 'Amounts in major units' partially duplicates the schema and the register remark is slightly indirect.
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, and the description does enumerate the returned figures, which compensates somewhat. The notable gap is the unstated company-selection mechanism implied by 'the register says when the last accounts were filed dormant' against a schema with no company parameter, leaving an agent unsure how the call is scoped.
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?
With one parameter at 100% schema coverage, the schema already documents shareCapital, its default of 1, and the major-units convention. The description restates 'Amounts in major units' but adds no new meaning, so the baseline 3 is correct.
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 states precisely what the tool produces – the full set of dormant-company figures (share capital, matching cash, zeros elsewhere) – and identifies the trigger condition (companies whose last accounts were filed dormant). However, it never names a verb for the action and does not differentiate itself from close siblings like totals_to_figures, sample_accounts, or get_prior_year_figures, so an agent must infer the distinction from the domain alone.
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?
'For those companies this collapses the whole form to one call' implies the tool is the shortcut when the register shows a dormant filing, which is useful routing information. But no alternative is named and no exclusion is stated for non-dormant companies, so the when-not case is left implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Turn a short factual account of what went wrong into the reason text for an application for more time to file accounts, framed in the terms the registrar actually applies. It uses only the facts you give it: it will not invent circumstances, and where something is missing it leaves a bracketed placeholder rather than filling it in. The person must check every sentence before using it, because they are certifying it to the registrar. Ask them what happened, do not supply it yourself. This tool does not submit the application and does not file accounts. Quota-charged as an explanation; identical input is answered from cache free.
| Name | Required | Description | Default |
|---|---|---|---|
| jurisdiction | Yes | ISO country code. Register access exists for GB and AU. | GB |
| circumstances | Yes | What actually happened, in the person's own words, with dates. Facts only. If you do not have this, ask them for it rather than writing it. | |
| expectedReadyBy | No | When they expect the accounts to be ready, if they have said. Never estimate it. | |
| whyItStoppedTheAccounts | No | How the event stopped the accounts being prepared, if they have said. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the annotations, which only declare read-only/idempotent/non-destructive. The description discloses that it will not invent circumstances, emits bracketed placeholders for missing facts, is quota-charged as an explanation, and answers identical input from cache for free. Those are exactly the behavioral traits an agent needs before calling.
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-loaded with the core transformation in the first sentence, then proceeds to constraints and cost. Every sentence carries information, though the passage is dense and runs long relative to the schema's self-documentation.
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 no output schema, the description carries the return-value burden and does so adequately: it says the output is reason text with bracketed placeholders for gaps. It doesn't specify the exact return shape (plain string vs. structured), which is the only meaningful residual gap for a 4-parameter drafting tool.
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 the schema already documents jurisdiction, circumstances, expectedReadyBy and whyItStoppedTheAccounts, including 'Never estimate it'. The description reinforces the facts-only constraint on circumstances but adds no new syntax, format or selection detail. Baseline 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 output (turn a factual account into the reason text for an extension application) and names the domain framing (the terms the registrar applies). It also draws the boundary against adjacent tools: 'does not submit the application and does not file accounts', which separates it from check_filing_extension and save_filing in the sibling list.
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 operating context: the practitioner must ask the person what happened rather than supplying facts, and the person must check every sentence before certifying it. The 'does not submit / does not file' clause functions as an explicit when-not. No sibling tool is named as the alternative, so it stops short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
A plain-English reading of a set of figures, written for a director who is not an accountant: what the derived balance sheet says about the company and anything that needs attention before filing. Only the derived sheet is sent to the model, no company name or number. Quota-charged; identical figures are answered from cache free.
| Name | Required | Description | Default |
|---|---|---|---|
| figures | Yes | The figures behind a small-company balance sheet. ALL amounts in major units. | |
| jurisdiction | Yes | ISO country code. Register access exists for GB and AU. | GB |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only/idempotent/non-destructive, and the description adds genuinely new operational context: only the derived sheet (no company name or number) is sent to the model, the call is quota-charged, and identical figures are served free from cache. Privacy, billing and caching behaviour are exactly the traits an agent cannot get from structured fields.
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 sentences, no filler, and the deliverable is front-loaded ahead of the operational caveats. Slightly dense in the middle clause but every sentence earns its place.
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 no output schema, the description still tells the agent what comes back (a plain-English reading plus anything needing attention before filing) and how the input is handled. Combined with the verbose schema, 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 description coverage is 100% and every nested figure carries its own definition, so the schema does the heavy lifting. The description adds no additional parameter meaning (e.g. currency-unit assumptions or what the figures object must contain), so baseline 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+resource (a plain-English reading of a set of figures/derived balance sheet) and makes the audience and deliverable explicit ('written for a director who is not an accountant'). It does not differentiate from the nearby sibling check_accounts, which plausibly also surfaces issues 'before filing', so an agent could confuse the two.
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?
Implies usage context (needs a human-readable narrative for a non-accountant before filing) but never states when to pick this over check_accounts or sample_accounts, nor any prerequisites. The routing must be inferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read last year's figures out of the company's last filed accounts at Companies House, ready to drop into the *Prior fields of check_accounts or save_filing. Saves typing seven numbers from a PDF and gets the comparatives exactly as filed. GB only, and only when the last accounts were filed digitally. Quota-charged; cached results are free.
| Name | Required | Description | Default |
|---|---|---|---|
| companyNumber | Yes | The GB company number. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive and open-world, so the safety profile is covered. The description adds genuinely non-structured context: 'Quota-charged; cached results are free' and the GB-only, digitally-filed precondition. It stops short of describing failure behavior when accounts aren't digital or available.
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 dense sentences, front-loaded with purpose, followed by destination and constraints. 'Saves typing seven numbers from a PDF' is a value proposition rather than filler, and no sentence is redundant.
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 no output schema, the description still conveys the shape of the return ('seven numbers', 'comparatives exactly as filed') and where they land, plus quota/caching and jurisdiction limits. Minor gap: it doesn't say what happens on quota exhaustion or non-digital filings.
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?
Only one parameter exists and schema coverage is 100%, so the schema fully documents companyNumber (though it doesn't explain the GB number format). The description says nothing about the parameter itself; baseline 3 applies when the schema carries the load.
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 last year's figures out of the company's last filed accounts at Companies House') and ties the output to concrete downstream consumers (check_accounts, save_filing *Prior fields). An agent can distinguish it from siblings like lookup_company or dormant_figures 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?
Explicitly scopes use ('GB only, and only when the last accounts were filed digitally') and names exactly where the result should be dropped. Both the when and the when-not conditions are given, leaving nothing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
What missing a Companies House accounts deadline costs. Given the due date, returns days remaining or overdue, the penalty band already incurred, and what the next band costs, the number that makes someone act today. UK private companies only.
| Name | Required | Description | Default |
|---|---|---|---|
| accountsDue | Yes | The accounts due date, from lookup_company or a Companies House letter. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover the safety profile (readOnly, idempotent, non-destructive), so the bar is lower; the description still adds real context by disclosing what the tool computes (days remaining/overdue, penalty band, next-band cost) and constraining applicability to UK private companies. It does not contradict any annotation, though it says nothing about rate limits or where penalty-band rules come from.
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 sentences, front-loaded with the outcome and ending with the scope restriction. Slightly padded by the promotional phrase 'the number that makes someone act today,' which adds flavor rather than information.
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 single-parameter, read-only calculation with no output schema, the description covers what is computed, the shape of the result, and the jurisdictional scope, which is enough for correct invocation. It stops short of stating that figures are statutory estimates or covering edge cases such as already-filed accounts.
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% and the schema already documents the single accountsDue parameter, including its source (lookup_company or a Companies House letter). The description adds no format or sourcing detail beyond that, so baseline 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 computation (penalty cost of missing a Companies House accounts deadline) plus what it returns (days remaining/overdue, incurred band, next band cost). This is clearly distinguishable from siblings like check_filing_extension and track_company_deadlines, which handle extensions and tracking rather than cost.
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?
Only implicit guidance via 'Given the due date', and the closing 'UK private companies only' scope note. It never says when to choose this over check_filing_extension or track_company_deadlines, nor any prerequisite for obtaining the due date beyond the schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The countries this server knows about and what it can actually do in each: which have a real accounts engine, which registers can be searched or looked up, the currency, and the identifiers each jurisdiction files under. Call this first when unsure.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true and destructiveHint=false, so the safety and idempotency profile is fully covered by structured data. The description's added value is the enumeration of the per-jurisdiction capability fields, which hints at the shape of the result, but it says nothing about format, ordering, or size of the response.
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 sentences with zero filler. The resource is front-loaded, the enumerative colon list is compact, and the actionable instruction ("call this first") is placed last where it reads as the takeaway.
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 no parameters, no output schema, and annotations already carrying the safety profile, the description covers the only real gap: what the returned jurisdiction records contain. It enumerates those fields, so an agent can decide whether this tool answers its question without opening anything else.
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, which is the baseline-4 case. The description correctly implies a parameterless, whole-server listing and introduces no parameter concepts, so there is nothing to mislead about.
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 names the resource (the countries/jurisdictions this server supports) and, unusually, enumerates the facets of each entry: accounts engine availability, searchable vs. lookup-only registers, currency, and filing identifiers. That is a specific picture of what the tool returns, and it distinguishes this capability-listing tool from the many per-company siblings like lookup_company or search_companies.
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?
"Call this first when unsure" is an explicit positive usage directive that tells the agent this is the orientation/discovery entry point before other calls. It does not name specific alternatives or state when NOT to call it, so it stops short of the full when/when-not/alternatives pattern.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The user's saved filings, most recently touched first, with every figure in major units. This is the same list the website dashboard shows. Start here when asked about "my accounts" or "my company".
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already indicate readOnlyHint=true, destuctiveHint=false, and idempotentHint=true, so safety is covered. The description still adds useful behavior: return ordering, normalization of figures to major units, and equivalence to the website dashboard list. It doesn't say anything about result size or empty-state behavior, which is a minor gap.
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 resource and ordering front-loaded and the routing guidance last. Every sentence adds new information with no 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?
With no parameters and no output schema, the description has to convey what the list is, how it's ordered, and how figures are denominated—and it does all three. It could go further on typical list size or whether all filings or only recent ones are returned, but nothing essential for calling it 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?
The tool has zero parameters, so there's nothing left to interpret—the baseline is 4. The description doesn't introduce any parameter-like concepts that would confuse the agent.
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 has a clear verb-plus-resource combination ('the user's saved filings') and specifies scope details such as ordering ('most recently touched first') and normalized units. It doesn't explicitly distinguish itself from siblings like list_tracked_companies or get_prior_year_figures, but the routing hint about 'my accounts'/'my company' partially covers that gap.
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?
'Start here when asked about "my accounts" or "my company"' gives a clear entry-point condition that an agent can act on. It stops short of naming alternatives or when-not-to-use cases, 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.
Every company this user gets deadline reminders about, including the ones implied by their saved filings. Shows the next accounts deadline and days remaining where a register record is already cached. Free: this never contacts a register.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnly/idempotent/non-destructive, so the bar is low, and the description clears it by adding real behavioral context: the call is free and never contacts a register (no external calls or cost), and results are partial because the deadline and days-remaining fields appear only where a register record is already cached. The partiality disclosure is the kind of thing an agent could otherwise misread as missing data.
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, each carrying distinct payload: scope, return content, and cost/behavior. Scope is front-loaded and there is no filler or restatement of the title.
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 no parameters and no output schema, the description carries the whole burden and mostly does: it names the entities returned and the conditional fields. It stops short of describing the shape of each entry (e.g. company identifiers, ordering), which leaves a small gap for a list tool.
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?
Zero parameters, so the baseline of 4 applies. The description correctly adds no parameter talk and instead spends its words on scope and result content.
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 resource and an unusually precise scope: 'every company this user gets deadline reminders about, including the ones implied by their saved filings.' That scope definition separates it from list_saved_filings (only saved filings) and from the track/untrack mutation siblings 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?
Usage is only implied: 'Free: this never contacts a register' tells the agent to prefer this when live register data is unnecessary, but no alternative is named and no explicit when-not condition is given. Adequate, not directive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look a company up on its public register (Companies House for GB, ABN Lookup for AU) by its registered number. Returns the full public record: name, status, registered office, officers, SIC codes, accounting period, plus both filing deadlines with days remaining and the late-filing penalty already incurred if overdue. Rate limited and quota-charged; cached results are free. Find the number first with search_companies.
| Name | Required | Description | Default |
|---|---|---|---|
| jurisdiction | Yes | ISO country code. Register access exists for GB and AU. | GB |
| companyNumber | Yes | The register identifier: GB company number (e.g. 15379140) or AU ABN. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, openWorld), and the description adds substantial behavior beyond them: the full field set returned, days remaining on both filing deadlines, the late-filing penalty already incurred when overdue, rate limiting, quota charging, and that cached hits are free. That is exactly the cost/auth context annotations cannot express.
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 dense sentences: purpose first, return payload second, cost/routing last. Every clause carries information an agent needs and there is no repetition of the tool name or 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?
With no output schema, the description carries the full burden of describing returns, and it enumerates the record contents plus computed deadline/penalty fields. Combined with the quota and prerequisite disclosures, an agent has everything needed to call this correctly and budget for it.
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 the baseline is 3, but the description adds real meaning by mapping jurisdictions to registers ('Companies House for GB, ABN Lookup for AU') and confirming the identifier is a register-specific number rather than a free-text name. It does not, however, explain how IE/US behave given they appear in the enum.
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 ('Look a company up on its public register'), names the concrete registers behind each jurisdiction, and identifies the required key ('by its registered number'). It is clearly distinguishable from the sibling search_companies, which the description positions as the discovery step.
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 routes the agent: 'Find the number first with search_companies' states the prerequisite and names the alternative tool, so an agent without a company number knows not to call this one. No misleading or missing usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
A real worked example: nil turnover, a director loan, a near-empty bank account, the simplest accounts the UK regime permits. Use it to demonstrate check_accounts or as a template for a first-year company. Amounts in major units.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnly, idempotent, openWorld, and non-destructive behavior, so the bar is lower. The description adds useful content-level context about what the sample contains and that amounts are in major units, though it does not describe any operational traits beyond the annotations.
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 description is three tight sentences with no wasted words. It front-loads the sample's identity and contents, then states usage, then adds the unit note.
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, output-schema-less sample fixture, the description provides enough context: what the sample contains, what it is for, and the units used. The annotations cover the safety profile, so nothing essential 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?
The tool takes zero parameters, so per the rubric the baseline is 4. The description's note about amounts in major units adds data-format context, but there are no input parameters to clarify.
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 identifies the resource as a worked sample accounts fixture and details its contents (nil turnover, director loan, near-empty bank), which clearly distinguishes it from live-data siblings like check_accounts. An agent can tell it provides a static example rather than performing analysis.
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 explicitly says to use it to demonstrate check_accounts or as a template for a first-year company, giving clear intended contexts. It does not state when not to use it or name a competing alternative beyond check_accounts, so it falls short of the top score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Save a set of figures to the user's account, or update a saved one by passing its id from list_saved_filings. Figures in major units. The filing is saved even when validation finds problems, because a work in progress is worth keeping, and the problems come back in the response so you can raise them.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | Omit to create. Pass an id from list_saved_filings to update that filing. | |
| label | No | A name for the filing, e.g. "SparkGames year to 31 Dec 2025". | |
| figures | Yes | The figures behind a small-company balance sheet. ALL amounts in major units. | |
| identifiers | No | Register identifiers, e.g. {"companyNumber": "15379140"}. Tax references (UTR, EIN, TFN) are never stored and are silently dropped. | |
| jurisdiction | Yes | GB | |
| categoryTotals | No | Where the figures came from, when a bank statement fed them: signed major-unit totals per category code from categorise_transactions. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With readOnlyHint=false, destructiveHint=false and idempotentHint=true already supplied, the description still adds real behavioural value: validation problems do not block the save, and those problems are returned in the response rather than thrown. That persistence-of-invalid-data trait is exactly the kind of thing annotations cannot convey.
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 sentences, front-loaded with what the tool does before the behavioural rationale. The closing clause ('because a work in progress is worth keeping, and the problems come back in the response so you can raise them') is slightly long but each clause carries distinct information.
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 mutation tool with no output schema, the description compensates by describing what comes back on validation failure, and the required parameters are well covered. Auth/account scoping is only implied ('the user's account') rather than spelled out, which is the main remaining 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 83%, so the field-level semantics (including id, identifiers and categoryTotals) are already carried by the schema. The description's 'Figures in major units' constraint is valuable but is duplicated verbatim in the figures object description, so it adds little beyond structured data.
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 first sentence names a specific verb and resource ('Save a set of figures') and immediately disambiguates the create-vs-update semantics, pointing to list_saved_filings as the id source. An agent knows exactly what this tool does and which sibling supplies the input for the update path.
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 clearly states the condition for the update path ('passing its id from list_saved_filings') versus omitting the id to create. It gives no exclusion guidance against neighbours such as check_accounts or explain_accounts, so the routing story is good but not exhaustive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find a company by name on its public register and get back its registered number, status and address. This is how you reach lookup_company when the person only knows the name. Free of the daily quota; lightly rate limited.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | The company name, as someone would say it. | |
| jurisdiction | Yes | ISO country code. Register access exists for GB and AU. | GB |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, open-world and non-destructive, so safety is covered. The description adds genuinely new operational context: it is 'free of the daily quota' but 'lightly rate limited', which the annotations do not convey and which affects call planning.
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 tight sentences, each carrying distinct information (purpose, routing to lookup_company, quota/rate behavior), with the core purpose front-loaded. Nothing is redundant.
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 no output schema, the description carries the return-value burden and does name the key fields returned (registered number, status, address), plus rate-limit context. Adequate for a search tool, though it could note result cardinality or pagination behavior.
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 both params (query, jurisdiction) are fully documented in the schema, including the enum. The description adds no syntax or format detail beyond what the schema already provides, so baseline 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 ('Find a company by name on its public register') and enumerates the return (registered number, status, address). It explicitly positions itself relative to lookup_company, so an agent can distinguish the two without opening either 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 clear when-to-use condition ('when the person only knows the name') and names the alternative path (lookup_company). It does not state when NOT to use this tool (e.g. when a registered number is already known), which slightly limits it below a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
What this deployment can actually do right now: which integrations are configured, whether your token is valid, and how much of each daily quota you have left. Call it when a tool refuses and you want to know whether the feature is off or used up.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description usefully adds that this reads external state (which integrations are live, token validity, quota consumption)—in effect describing the observable return surface of a call with no output schema. It stops short of stating auth requirements or throttling behavior.
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 sentences, no filler: the first front-loads what the call returns, the second front-loads when to use it. Every clause carries information an agent 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?
For a no-parameter, read-only diagnostic with full annotation coverage and no output schema, the description supplies the missing pieces: the return surface and the decision context. Nothing an agent needs to call this correctly is absent.
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 for the description to disambiguate; the 4 baseline for a no-param tool applies. The description correctly spends no words on input semantics and instead explains what the parameterless call reveals.
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 states a concrete resource—deployment capability right now—and enumerates the specific facts it reports (configured integrations, token validity, remaining daily quota). An agent can tell at a glance that this is a diagnostics/health tool and that no sibling in the list (all filing/company tools) does the same thing, though it is framed as a question rather than a verb+resource statement.
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 explicit trigger condition: call it when a tool refuses and you want to distinguish 'feature is off' from 'quota used up'. That tells the agent both when to reach for this tool and what question it answers, with no inference required.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Turn categorised bank-statement totals into balance sheet figures, applying the rules that stop an import lying: only income categories reach turnover, only expense categories reach operating costs, and the owner topping up the account is never sales. Totals are signed major units per category code; get codes from categorise_transactions.
| Name | Required | Description | Default |
|---|---|---|---|
| totals | Yes | Signed totals per category code, major units, e.g. {"sales": 60000, "software": -1200}. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive), so the description rightly spends its budget on behavior the annotations cannot express: the classification rules that map income to turnover, expenses to operating costs, and owner top-ups away from sales. It does not state how unrecognised category codes are handled, which is the main remaining gap.
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 sentences, front-loaded with the verb and outcome before the rule detail, and the closing sentence handles input provenance. The colon-separated clause list of rules is dense but each clause carries distinct accounting meaning, so little is 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 no output schema, return values need not be explained, and the description covers the input contract and the classification semantics well for a single-parameter tool. It leaves open error behavior for unmapped or missing category codes, which for a rule-applying transform is a modest omission.
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%, and the schema already documents the sign convention, major-unit requirement, and per-category-code shape. The description largely restates 'signed major units per category code'; its only added value is pointing to categorise_transactions as the source of codes, which merits baseline 3 rather than higher.
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 ('turn categorised bank-statement totals into balance sheet figures') and immediately distinguishes the transformation from sibling framing by naming the upstream tool categorise_transactions. Its role is separable from dormant_figures, explain_accounts, and get_prior_year_figures 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?
It identifies the correct upstream step ('get codes from categorise_transactions'), which tells the agent when this tool applies in the workflow. It stops short of explicit when-not-to-use guidance or naming alternatives such as dormant_figures for non-trading periods.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Watch a company by its register number and get reminded before its filing deadlines. Which channels are actually available depends on the server: the reply reports what will really be sent, and it can be nothing at all, so read it rather than assuming. No saved filing is needed: this is for the deadline itself, which matters months before any figures exist. Reminders go out on a ladder of days before the deadline (default 90, 60, 30, 14, 7, 1), and each one states the company, the deadline, the date, the days remaining and the penalty for missing it. Calling this again updates the settings and un-mutes a company that was untracked.
| Name | Required | Description | Default |
|---|---|---|---|
| push | Yes | Send reminders as web push to signed-in browsers. | |
| Yes | Send reminders to the account email address. | ||
| jurisdiction | Yes | ISO country code. Deadline reminders exist where the register publishes deadlines. | GB |
| companyNumber | Yes | The register identifier: GB company number (e.g. 15379140) or AU ABN. | |
| remindDaysBefore | No | Days before the deadline to warn, e.g. [60, 14, 1]. Omit to use this server’s default ladder. Only the tightest rung that applies is ever sent, so a long ladder does not mean a burst of messages. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the annotations by warning that available channels are server-dependent and the reply 'can be nothing at all, so read it rather than assuming' — a crucial caveat with no output schema. It also discloses the idempotent re-call behavior (updates settings, un-mutes) and the content of each reminder, which the annotations do not convey.
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-loaded with the core action, and the dense single paragraph mostly earns its sentences. It is slightly heavy, mixing caveats, ladder defaults, and re-call semantics in one block without visual breaks.
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 no output schema, the description carries the return-value burden and does so ('the reply reports what will really be sent, and it can be nothing at all'), plus channels, reminder content, and penalty mention. An agent has everything needed to call and interpret it.
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 the baseline is 3, but the description adds the concrete default ladder (90, 60, 30, 14, 7, 1) and the 'only the tightest rung that applies is ever sent' semantics for remindDaysBefore, which the schema does not spell out. It stops short of describing the jurisdiction/channel interplay in depth.
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 ('Watch a company by its register number and get reminded before its filing deadlines') and clearly distinguishes itself from sibling untrack_company_deadlines and list_tracked_companies. An agent can identify the operation without opening the 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?
Explains the context for use ('No saved filing is needed: this is for the deadline itself, which matters months before any figures exist') and the effect of re-calling (updates settings, un-mutes). It does not explicitly name alternative tools like untrack_company_deadlines, so it falls just 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.
Stop sending deadline reminders about a company. This mutes rather than forgets, which is the only thing that holds: a company implied by a saved filing would otherwise be re-added by the next scan. track_company_deadlines un-mutes it again.
| Name | Required | Description | Default |
|---|---|---|---|
| jurisdiction | Yes | ISO country code. Deadline reminders exist where the register publishes deadlines. | GB |
| companyNumber | Yes | The register identifier, as in track_company_deadlines. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and idempotentHint=true, but the description adds the crucial nuance that is not in the annotations: this mutes rather than deletes, so filings are preserved and re-tracking would otherwise be triggered by the next scan. That clarifies what the 'destructive' flag actually removes (tracking state, not data).
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-loaded with the action in the first sentence and trimmed to three sentences. The middle sentence ('which is the only thing that holds') is slightly convoluted, but the mute-vs-forget distinction earns its place.
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 two-parameter mutation with no output schema, the description plus annotations cover the essentials: safety profile, reversibility, and the non-obvious re-scan behavior. The only omission is failure behavior or confirmation of what the call returns.
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% with only two required parameters, so the schema already documents jurisdiction (enum + meaning) and companyNumber. The description adds no parameter-level detail, leaving this at the baseline for fully covered schemas.
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: stop deadline reminders for a company. It explicitly contrasts with the inverse operation by naming the sibling track_company_deadlines, so an agent can distinguish positive from negative tracking without inspecting schemas.
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 clearly frames this as the off-switch for reminders and names track_company_deadlines as the way to reverse it, giving an explicit alternative. It does not state prerequisites or exclusions (e.g., whether untracking a company that was never tracked errors), so usage guidance is clear but not exhaustive.
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.
categorise_transactionscheck_accountscheck_filing_extensiondelete_filingdormant_figuresdraft_extension_reasonexplain_accountsget_prior_year_figureslate_filing_penaltylist_jurisdictionslist_saved_filingslist_tracked_companieslookup_companysample_accountssave_filingsearch_companiesserver_statustotals_to_figurestrack_company_deadlinesuntrack_company_deadlinesUK company lookup, filing deadlines, late penalties and Corporation Tax maths. No account.
Free Companies House deadline checks for UK companies: due dates, penalties, dormancy signals.
US company filing obligations, plus a 25-check bookkeeping diagnostic. Sourced, dated, no signup.
Prepare UK company accounts and CT600 Corporation Tax returns with the director (sign-in).
Add one secure layer between your agents and this server.
