Ask AI about Simpro, Xero, Deputy, Employment Hero, Dialpad, ELMO, Moveware and fleet data you own.
Scored across 15 tools
Most tools have clearly distinct purposes: read vs write calls are explicit, search_records (paging/browse) vs summarize_records (aggregation) vs get_record (fetch by id) are well delineated, and discover_operations vs discover_questions split app actions from canned questions. The only mild overlaps are get_started/list_connections (both surface connection health) and whoami/get_started (setup verification), but descriptions guide selection adequately.
Names follow a consistent snake_case verb_noun pattern (list_companies, search_records, get_record, call_read_operation, discover_questions). The single deviation is whoami, which breaks the verb_noun convention, but this is a minor, idiomatic exception in an otherwise predictable scheme.
Fifteen tools is a well-scoped set for a multi-source data-bridge server, with discovery, reading, aggregation, connection/company management, onboarding and feedback each earning a distinct slot. No redundant or filler tools are present.
The surface covers the full read/query lifecycle (discover, list, search, get, summarize), write/destructive actions via call_write_operation plus discover_operations, and company/connection management and feedback. Minor gaps—no direct connection-creation tool (deliberately done on TradieBridge's own pages) and no dedicated delete/update primitives—are workable via the generic operation tools.
Answer one of the questions the instructions name (discover_questions describes them) in one call, reading the source's copy server-side. arguments are the question's own; a missing or wrong one answers with the arguments it takes. Without connection_id every source that answers the question answers it, each under answers with its connection_id, connection, source and as_of: two sources measure different ledgers, so read them side by side and never add them. connection_id narrows to one source.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | The question's name, e.g. receivables. | |
| arguments | No | The question's arguments. Omit for none. | |
| connection_id | No | Only this source's answer; list_connections names them. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already carry the safety profile (readOnlyHint=true, destructiveHint=false, openWorldHint=false). The description adds meaningful context beyond them: execution happens server-side against the source's own copy, each answer carries connection_id/connection/source/as_of, and it warns that answers from distinct sources must never be summed because they measure different ledgers.
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 action is front-loaded and there is no filler, but the prose is a run-on tangle ('each under answers with its connection_id') that forces re-reading. Length is defensible for the concepts covered; readability is not.
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 does the work of disclosing the response shape (per-source entries with connection_id, connection, source, as_of) and links to discover_questions and list_connections for the dependent lookups. Enough for an agent to call and interpret it, aside from not covering pagination or partial-failure 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 the baseline is 3, but the description adds behavioral semantics the schema cannot: 'arguments' belong to the named question and a missing/wrong argument elicits an error response listing the expected arguments, and connection_id scopes the result to a single source rather than filtering within one.
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 uses a specific verb (answer) plus the resource (one of the named questions) and points at discover_questions for the question catalogue, which separates it from sibling read tools like get_record and search_records. It is clear what the tool does, though the dense phrasing blurs the edges a little.
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 states that questions are enumerated by discover_questions, that connection_id narrows to one source, and that omitting connection_id fans out to every qualifying source. That is real when-to-use guidance, but it never says when a sibling (e.g. get_record or search_records) would be the better choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run one of the read-only operations discover_operations lists, with the arguments it named. A path argument goes at the top level ({"id": 7}). It changes nothing. You never name a company: the tenant comes from your token.
| Name | Required | Description | Default |
|---|---|---|---|
| params | No | Arguments for the operation. Omit for none. | |
| operation | Yes | As listed by discover_operations, e.g. "connections#show". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already carry readOnlyHint=true, destructiveHint=false and openWorldHint=false, so 'It changes nothing' is largely redundant. The genuinely additive line is the auth constraint — 'You never name a company: the tenant comes from your token' — which is not derivable from any structured field and prevents a common misuse.
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, front-loaded with the core action and the source of valid operations. 'It changes nothing' is the only near-redundant sentence against the readOnlyHint annotation, but it is brief enough to earn 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?
Covers the three things an agent must know to call it correctly: where operations come from, how arguments are shaped, and how tenancy is resolved. With no output schema, return shape is left implicit, though it is defined per-operation by discover_operations, so the gap is minor for a generic dispatcher.
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 parameters are already documented; baseline is 3. The description adds a concrete argument shape ({"id": 7}), which is useful, but 'goes at the top level' is ambiguous given the schema requires a wrapping 'params' object, so the added value is partial.
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 ('Run one of the read-only operations') and names the sibling (discover_operations) that supplies the valid operation list, which cleanly separates it from call_write_operation. It is slightly abstract because the concrete operations live elsewhere, but an agent can tell what this tool is for 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?
The prerequisite is explicit: only operations that discover_operations has listed may be run here, and the read-only framing implicitly routes writes to call_write_operation. It stops short of an explicit 'use X instead when...' exclusion, but the context is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run one of the write or destructive operations discover_operations lists, with the arguments it named. It changes data in TradieBridge. A path argument goes at the top level ({"id": 7}); a write's fields go nested under the key discover_operations printed them against ({"connection": {"name": "Main"}}). You never name a company: the tenant comes from your token.
| Name | Required | Description | Default |
|---|---|---|---|
| params | No | Arguments for the operation. Omit for none. | |
| operation | Yes | As listed by discover_operations, e.g. "connections/syncs#create". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, destructiveHint=true, idempotentHint=false, and openWorldHint=false, so the safety profile is covered. The description adds genuinely non-redundant context: that data in TradieBridge is changed and that tenant scoping is implicit from the token. It does not describe reversibility or response behavior, which keeps it below a 5.
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, followed by the two most useful details (mutation and tenant scoping) and the argument-shaping rule. Slightly dense in the middle with the inline JSON examples, but every sentence carries 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 generic dispatch tool with no output schema, the description covers the operation source, mutation semantics, tenant scoping, and argument shape, which is what an agent needs to call it correctly. It omits what the call returns and how destructive effects are surfaced, a minor gap given the generic 'params' contract.
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 both parameters are documented, so the baseline is 3. The description goes beyond the schema's generic 'Arguments for the operation' by explaining argument shaping: path args at the top level and write fields nested under the key discover_operations printed, with concrete JSON examples.
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 ('Run one of the write or destructive operations') and ties the tool to its discovery source (discover_operations), which cleanly separates it from call_read_operation in the sibling list. An agent can tell what it does and where the valid operation names come 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 clearly states the prerequisite (operations must come from discover_operations, with the arguments it named) and adds a useful constraint ('You never name a company: the tenant comes from your token'). It never explicitly names call_read_operation as the read-only alternative, so the when-not guidance 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.
What a source's backup holds. Without resource: every resource key with what it means, how many records it holds and what it hangs off, and the keys that hold none. Name one resource or several to add when each last synced and the columns search_records filters and orders by and summarize_records sums and groups by.
| Name | Required | Description | Default |
|---|---|---|---|
| resource | No | A resource key, or several, e.g. ["invoices", "customer_payments"]. | |
| connection_id | No | Omit when only one of the company's sources holds the resource; list_connections names them. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, non-destructive, non-open-world, and non-idempotent behavior, so the safety profile is covered. The description goes beyond that by enumerating what each mode returns (resource keys, meanings, record counts, parent relationships, sync times, filterable/orderable/summable columns), which is genuinely additive.
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?
Purpose is front-loaded, but the two sentences are dense run-ons ('how many records it holds and what it hangs off', 'the columns search_records filters and orders by and summarize_records sums and groups by') that are hard to parse. The mode-based colon structure helps, but the prose is longer than it needs to be.
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 and zero required parameters, the description correctly carries the return-value burden and specifies the content of both call modes. What's returned is well covered; only the practical trigger for using this versus sibling introspection tools is thinly addressed.
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 baseline is 3. The description earns above baseline by explaining the functional difference the `resource` parameter makes — omitting it yields the full inventory, including it enriches output with sync times and column semantics — adding meaning beyond the schema's terse 'a resource key, or several'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with the noun phrase 'What a source's backup holds' rather than a clear verb+resource statement, so the tool's action is left implicit. It does convey that the tool reports on resources/records, but the oblique framing ('what it hangs off') is vaguer than a clean 'Describe the resource keys in a source'.
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 distinguishes two modes ('Without resource: ...' vs 'Name one resource or several to add ...'), which is useful contextual guidance. However it never states when to pick this tool over siblings like discover_operations or get_started; the references to search_records/summarize_records are relational, not alternative-routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search everything else TradieBridge can do, beyond the tools listed here — every screen and action in the app, named as "controller#action", with the arguments each one takes and the tool that runs it: call_read_operation for a read, call_write_operation for a write. Each refuses the other kind. Use it when no dedicated tool fits. Search by word: "export", "sync", "member".
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | Filter by substring, e.g. "invoice". Omit for all. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover the safety profile (readOnlyHint=true, destructiveHint=false, openWorldHint=false, idempotentHint=false), so the bar is lower. The description adds real value beyond them by disclosing the catalog content and the important behavioral trait that the two downstream call tools are mutually exclusive by operation kind. It does not mention result limits or pagination, so not a 5.
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 what is searched, then the return shape, then the usage condition and examples in three tight sentences. Minor slack remains in the em-dash aside about screens/actions, but nothing is wasteful.
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 burden of describing returns, and it does: operation identifiers, their arguments, and the tool that executes them. It omits result-set size limits and what happens on an empty match, which is a modest gap for a discovery 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% and the schema already documents the single optional query substring filter. The description only echoes that with the phrase "Search by word" and extra examples, adding flavor but no syntax or matching-rule detail beyond the schema. 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 names a specific verb (search) and resource (every screen and action in the app not covered by a dedicated tool), and specifies the exact return shape: "controller#action" plus arguments plus the tool that runs it. It is clearly distinguishable from the sibling call_read_operation / call_write_operation, which this tool is upstream of.
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 states the selecting condition explicitly ("Use it when no dedicated tool fits") and routes the follow-up: call_read_operation for reads, call_write_operation for writes, each refusing the other kind. Concrete query examples ("export", "sync", "member") show how to invoke it when the exact name is unknown.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The questions ask_question answers in one call, for the sources this company holds: each one's name, what it answers and the arguments it takes, as a JSON schema. A question two sources share is listed under each, answered from that source's own records. Filter by source, or by a word or topic (money, tax, jobs, customers, sales, schedule, staff).
| Name | Required | Description | Default |
|---|---|---|---|
| topic | No | Only questions whose name, topic or description holds this word. | |
| source | No | Only this source's questions, as list_connections names it. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds genuinely non-obvious behavior: the result is a JSON schema per question, and a question shared by two sources is listed under each and answered from that source's own records — a deduplication/ownership rule an agent could not infer from 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?
Three sentences, front-loaded with what the tool returns and followed by the shared-question rule and filter options. Dense but every sentence carries information; no filler or restated 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?
There is no output schema, but the description compensates by describing the shape of each returned entry and its per-source ownership semantics. Combined with full schema coverage on both optional filters, an agent has enough to call it correctly, though it never says what the invocation returns if no source/topic matches.
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 schema already explains both filters, so the baseline is 3. The description adds example topic values (money, tax, jobs, customers, sales, schedule, staff) that guide value selection, but offers nothing extra on the source parameter beyond what the schema states.
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 exact resource (the questions ask_question answers), what each entry contains (name, what it answers, its arguments as a JSON schema), and scopes it to the sources this company holds. It explicitly ties itself to the sibling ask_question as the answering counterpart, so an agent can tell discovery apart from invocation without opening a 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 tells the agent how to narrow results (by source, or by a word/topic) but never states when to prefer this over ask_question or that it should be called first to find what is answerable. Usage is strongly implied by the 'questions ask_question answers' framing but not spelled out as a when-to-use rule or exclusion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Records from a source's backup, whatever the system, exactly as the source sent them, with the records each one names (links) and the records hanging off it (related, first 50 of each). id is the source's own ID, or the id search_records returned; ids reads up to 20 at once. fields keeps only those keys of each document: top-level keys or dotted paths such as Contact.Name.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | ||
| ids | No | Several ids, instead of id. | |
| fields | No | Keys or dotted paths to keep, e.g. ["Name", "Contact.Name"]. | |
| related | No | Default true. False leaves out links and related records. | |
| resource | Yes | A resource key from describe_resources. | |
| connection_id | No | Omit when only one of the company's sources holds the resource; list_connections names them. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint=false, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds genuine behavioral context beyond that: records are returned raw, links and related records are included with a 'first 50 of each' truncation disclosure, and fields filtering behavior is described.
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?
It is dense and front-loaded with the return shape before parameter behavior. The single run-on paragraph packs multiple ideas via parentheticals, which is efficient, though it borders on unwieldy for a first read.
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 by explaining raw record content, links, related records, and the 50-item cap. Combined with high schema coverage on inputs, an agent has enough to invoke it correctly, with only minor gaps around the singular/plural id interplay.
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 83%, so the schema already documents most parameters, which sets a baseline of 3. The description adds value beyond the schema by clarifying that 'ids reads up to 20 at once' and that id is the source's own ID or one returned by search_records, neither of which is stated in 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?
The description conveys a specific resource and its retrieval semantics: raw records from a source's backup 'exactly as the source sent them,' plus links and related records. It is clearly distinguishable from search_records, whose returned ids it references. The only minor gap is that the noun-phrase opener leads with what is returned rather than an explicit verb.
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 implies a workflow by noting that 'id is the source's own ID, or the id search_records returned,' giving an implicit routing hint to search_records. However, it never states when to prefer get_record over summarize_records or the read/write operation tools, and gives no exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Where this business is in setting up TradieBridge: the systems connected, whether a backup holds records yet, and the one next step. Call it first when nothing is connected, when the person has just signed up, or when they ask how to start. next_step.say is what to tell the person, in your own words; when next_step.url is present, give them that link to open. Systems are connected, and API keys, passwords and card details entered, only on TradieBridge's own pages: never ask for one in chat or pass one to a tool. Call it again once they say they are done.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, non-destructive, and non-idempotent, so the description only needs to add context. It does: it explains how to consume the output (next_step.say in your own words, offer next_step.url as a link) and imposes a security constraint (never request keys, passwords, or card details in chat or pass them to a tool). It does not describe failure modes or what happens when setup is incomplete, 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?
Front-loads the resource ('Where this business is in setting up TradieBridge') before the triggers and the security rule. Four clauses are somewhat dense but each carries distinct, actionable information, 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, the description must explain the return shape, and it does: connected systems, backup-record status, and a single next step with say/url fields. Combined with the call-timing guidance and the security constraint, nothing an agent needs to call and act on this tool 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 the baseline is 4. The description instead clarifies the semantics of the returned next_step.say and next_step.url fields, which is a sensible use of the space.
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 scope: the business's onboarding state in TradieBridge, including connected systems, whether a backup holds records, and the single next step. An agent immediately understands this is an onboarding-status read, and no sibling tool (whoami, list_connections) covers this same ground.
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 trigger conditions — call it first when nothing is connected, right after sign-up, or when the person asks how to start — and a re-invocation condition ('call it again once they say they are done'). The when/when-again guidance is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the companies this connection reaches, with the person's role in each and which one it is acting in now. Every other tool answers about that one company; switch_company moves it.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With annotations covering read-only safety (readOnlyHint=true), the description adds valuable context beyond structured data: it explains that this tool reveals the connection's reach and the current active company, and that all other tools operate within that one company. It doesn't discuss pagination or rate limits, but for a simple listing tool this is adequate.
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 sentence front-loads the purpose and return contents; the second clarifies the tool's role relative to other tools.
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?
Given zero parameters, read-only annotations, and no output schema, the description is nearly complete. It could mention that no pagination occurs or that output format is a list, but for a simple discovery tool it provides 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?
The tool has zero parameters, so the baseline is 4. The description still adds meaning by clarifying what each listed item contains (company name implicitly, person's role, current status), which goes beyond the empty 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?
The description clearly states a specific verb+resource ('List the companies this connection reaches') and adds scope detail about what is returned (person's role, current company). It explicitly distinguishes this tool from siblings by naming switch_company and contrasting behavior.
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 provides a strong implicit context: the tool is for seeing available companies and the current active one, and explicitly states the relationship to other tools ('Every other tool answers about that one company; switch_company moves it'). It doesn't state when not to use it, but the alternative is named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the company's sources, each a copy of one system: id (pass it as connection_id to the other tools), name, source, web address, the company or organisation backed up, sync health, when it last synced and how many records the backup holds.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds genuinely non-structured context: it enumerates the returned fields and discloses the cross-tool parameter aliasing (id → connection_id), which the agent cannot learn from the schema or 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?
A single front-loaded sentence that leads with the action and resource, then enumerates outputs. The parenthetical about connection_id is well placed. Slightly dense in the field list, but nothing 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 and no parameters, the description carries the burden of explaining what comes back, and it does so thoroughly for a zero-argument list tool. It omits pagination or ordering behavior, a minor gap for a list endpoint.
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 the baseline is 4. There are no arguments to explain, and the description instead spends its words on the return shape, which is the more useful information here.
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 gives a concrete verb and resource ('List the company's sources') and clarifies what a source actually is ('each a copy of one system'), which distinguishes it from list_companies. It does not explicitly contrast itself with any sibling, but the resource is unambiguous.
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?
There is no explicit when-to-use or when-not-to-use guidance, and no sibling alternatives named. The one embedded usage cue is downstream: it tells the agent the returned 'id' is passed as 'connection_id' to other tools, which implies this is a discovery step before other calls.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find records of one resource in a source's backup, whatever the system, highest source ID first, or largest first by order_by (ascending: true for smallest or oldest; empty values last). query matches a source ID as a prefix or a name holding every word; filters and order_by take the columns describe_resources lists. Answers the total that match and, when more remain, next_before_id to pass back as before_id (with order_by, raise limit instead). Each result's id is what get_record takes. For totals and counts use summarize_records instead of paging.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Default 25, at most 200. | |
| query | No | ||
| filters | No | Column filters, from the columns describe_resources lists for the resource: {"<column>": "value"}, {"<column>": ["one", "another"]}, {"<column>": {"contains": "acme"}}, {"<date column>": {"gte": "2026-04-01", "lte": "2026-06-30"}}. Operators: eq, ne, in, not_in, gte, lte, contains, null. | |
| order_by | No | A number or date column describe_resources lists, to rank by. | |
| resource | Yes | A resource key from describe_resources, e.g. invoices. | |
| ascending | No | ||
| before_id | No | The next_before_id a previous page answered. | |
| connection_id | No | Omit when only one of the company's sources holds the resource; list_connections names them. | |
| modified_since | No | ISO 8601 time; only records the source changed since then. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, non-destructive, not open-world), and the description adds genuinely new behavior: default ordering (highest source ID first, empty values last), ascending semantics, and the pagination contract (next_before_id returned and fed back as before_id). It stops short of mentioning permissions, rate limits, or ordering stability across pages.
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?
Purpose and ordering lead, then matching, pagination, and routing to siblings — a well front-loaded order with no filler. The sentences are dense and occasionally run-on (multiple parenthetical clauses), which slightly slows parsing.
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 contract itself (total matches, next_before_id, per-result id) and covers the pagination and ordering knobs for a 9-parameter tool. Nothing essential to invoking or correctly paging this tool 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 78%, so the baseline is 3, but the description adds real meaning beyond the schema for query (source-ID prefix or name matching every word), ascending (smallest/oldest direction), and before_id (round-trip from next_before_id). It does not clarify modified_since or connection_id beyond the schema's own wording.
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 records of one resource in a source's backup, whatever the system') with its default ordering rule. It distinguishes itself from siblings by explicitly naming summarize_records and get_record and describing how results chain into them.
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-not guidance ('For totals and counts use summarize_records instead of paging') and when-to guidance for downstream consumption ('Each result's id is what get_record takes'). It also explains the alternative path when order_by is set ('raise limit instead' of paging).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send TradieBridge's builders an idea or a problem in the user's own words; they read every one. Use it when the user wishes TradieBridge did something it does not (a source, a field, a question, a report), when a question cannot be answered from the copy, or when something looks wrong (a missing record, a figure that differs from the source, an error). Read the title and details back to the user and send only once they agree. details says what they were doing, what they expected and what happened, naming the source and record IDs involved. Never include a password, API key or token.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | Yes | idea for something new or better, problem for something wrong. | |
| title | Yes | One line, at most 150 characters. | |
| details | Yes | At most 5000 characters. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover the safety profile (readOnlyHint=false, idempotentHint=false, destructiveHint=false), but the description adds real behavior: a human reads every submission, the title/details must be read back and agreed before sending, and credentials must never be included. The read-back rule is especially valuable given idempotentHint=false, where a duplicate send is costly.
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?
One dense paragraph that is front-loaded with the purpose and then the trigger conditions. It is long for a three-field tool, but nearly every clause carries operational weight (triggers, read-back, content requirements, secret exclusion), 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?
For a low-complexity, no-output-schema submission tool, the description covers purpose, triggers, required content and a safety constraint. The only gap is what happens after sending (confirmation, ticket ID, expected response time), which an agent would otherwise have to discover.
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 goes beyond the schema's bare length limits by specifying what details should contain: what the user was doing, what they expected, what happened, and the source and record IDs involved. Only 'kind' and 'title' get no extra guidance beyond their schema descriptions.
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 ('Send TradieBridge's builders an idea or a problem') and immediately characterizes the artifact as being in the user's own words. An agent can tell this apart from ask_question or the generic call_write_operation 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?
Gives three concrete triggering conditions: a capability the product lacks, a question that cannot be answered from the copy, and something that looks wrong. The second condition implicitly routes away from ask_question, and the confirmation instruction ('send only once they agree') constrains when the call may actually fire.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Count, sum, average, min or max over one resource's records in one call, of any source, optionally per group. Takes the same query and filters as search_records. column is a number column from describe_resources (min and max also take a date). measures asks several figures at once, e.g. ["count", "sum", "avg"] over column, or "sum:" for another column; the answer is then values, keyed as asked. group_by is a column, week:/month:/quarter:/year:, or a list of two, e.g. ["", "month:"]. A week is named by its Monday. Groups come largest first, or in date order when a date is bucketed, at most 100.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Groups to answer. Default and most 100. | |
| query | No | ||
| column | No | What to sum, average, min or max: a column describe_resources lists. | |
| filters | No | Column filters, from the columns describe_resources lists for the resource: {"<column>": "value"}, {"<column>": ["one", "another"]}, {"<column>": {"contains": "acme"}}, {"<date column>": {"gte": "2026-04-01", "lte": "2026-06-30"}}. Operators: eq, ne, in, not_in, gte, lte, contains, null. | |
| measure | No | Default count. | |
| group_by | No | e.g. <column>, month:<date column>, or ["<column>", "quarter:<date column>"]. | |
| measures | No | Several figures in one call, in place of measure. | |
| resource | Yes | A resource key from describe_resources, e.g. invoices. | |
| connection_id | No | Omit when only one of the company's sources holds the resource; list_connections names them. | |
| modified_since | No | ISO 8601 time; only records the source changed since then. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare it a safe read (readOnlyHint=true, destructiveHint=false), so the bar is lower; the description still adds real behavioral context beyond them: group ordering (largest first, or date order when bucketed), the hard cap of 100 groups, week-start convention (Monday), and that results are keyed to the measures asked. It stops short of describing error modes or empty-result 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?
Dense but front-loaded, leading with the capability and then resolving parameter grammars; no filler sentences. The telegraphic phrasing (e.g. 'the answer is then values, keyed as asked') is efficient though occasionally clipped for a 10-parameter 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 tool with a nested group_by shape and no output schema, the description covers the tricky parts: aggregation verbs, multi-measure output keying, group ordering, group cap, and date-bucketing syntax. connection_id and modified_since are left entirely to the schema, but those are adequately documented there, so nothing critical 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 90%, so baseline is 3, but the description genuinely enriches sparse schema fields: it explains the 'sum:<column>' syntax inside measures, the week:/month:/quarter:/year:<date column> grammar and two-element list form for group_by, and that min/max also accept a date column. This adds value beyond the terse schema descriptions.
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 precise set of aggregation verbs (count, sum, average, min, max) over one resource's records, with optional grouping and cross-source scope. It also anchors itself against the sibling search_records ('Takes the same query and filters as search_records'), so an agent can distinguish it from row-retrieval tools like get_record/search_records without opening a 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?
The shared-query note with search_records implies the division of labor (aggregate vs. fetch rows), but there is no explicit 'use this instead of X when Y' rule or when-not-to-use guidance. Usage is inferable rather than stated, which lands at minimum-viable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Point this connection at another of the companies list_companies gives. Every tool after it answers about that company until it is switched again. Takes the company by name or id.
| Name | Required | Description | Default |
|---|---|---|---|
| company | Yes | The company, by name or id as list_companies gave it. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare idempotentHint=true, readOnlyHint=false and destructiveHint=false, so safety is partly covered. The description adds the genuinely non-obvious behavior: this mutates persistent session state that silently changes how all subsequent tools interpret their calls — a real trait 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?
Three short sentences, zero filler, and the core state-changing behavior is front-loaded before the persistence note. Every sentence 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?
With one required parameter, full schema coverage, no output schema and annotations covering safety, the remaining thing an agent must know — that the effect is session-persistent — is stated. Nothing essential for correct invocation 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 description coverage is 100%, so the parameter is already documented as 'by name or id as list_companies gave it.' The description's 'Takes the company by name or id' repeats that information without adding format, disambiguation, or error-handling semantics. 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 (point/switch) and the resource it repoints — the connection's active company — and explicitly contrasts it with the sibling that supplies valid values (list_companies). An agent can distinguish this from read/write operation tools 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 tells the agent when this applies: 'Every tool after it answers about that company until it is switched again,' and names list_companies as the source of acceptable values. No exclusions are given, but no sibling competes for the same job, so this is clear context rather than a gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the authenticated TradieBridge user and company. Use to confirm the connection works.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, destructiveHint:false, and openWorldHint:false. The description adds value beyond them by disclosing the return subject (user and company) and the implicit auth requirement via "authenticated," plus the connection-diagnostic intent.
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 what is returned before the usage hint, with no redundant or filler content. 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 parameters and no output schema, the description carries the return-value burden. It names the returned entities (user, company) at a high level, which is adequate for a simple identity probe, though field-level detail of the response 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 no parameters, so per the rubric the baseline is 4. There is nothing for the description to clarify, and it correctly avoids inventing parameter semantics.
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 (Return) and resource (authenticated TradieBridge user and company), so the agent knows exactly what comes back. It does not, however, differentiate itself from related siblings like get_started or list_companies, so an agent must infer the boundary itself.
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?
"Use to confirm the connection works" gives a clear, actionable usage context. There are no explicit exclusions or named alternatives, but for a zero-arg identity probe the context is unambiguous and sufficient.
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.
get_startedask_question2 fields changedInput schema / properties / build_idRemoved value: -{
- "description": "Only this build's answer; list_connections names them.",
- "type": "integer"
-}Input schema / properties / connection_idAdded value: +{
+ "description": "Only this source's answer; list_connections names them.",
+ "type": "integer"
+}describe_resources2 fields changedInput schema / properties / build_idRemoved value: -{
- "description": "Omit when only one of the company's builds holds the resource; list_connections names them.",
- "type": "integer"
-}Input schema / properties / connection_idAdded value: +{
+ "description": "Omit when only one of the company's sources holds the resource; list_connections names them.",
+ "type": "integer"
+}get_record2 fields changedInput schema / properties / build_idRemoved value: -{
- "description": "Omit when only one of the company's builds holds the resource; list_connections names them.",
- "type": "integer"
-}Input schema / properties / connection_idAdded value: +{
+ "description": "Omit when only one of the company's sources holds the resource; list_connections names them.",
+ "type": "integer"
+}search_records2 fields changedInput schema / properties / build_idRemoved value: -{
- "description": "Omit when only one of the company's builds holds the resource; list_connections names them.",
- "type": "integer"
-}Input schema / properties / connection_idAdded value: +{
+ "description": "Omit when only one of the company's sources holds the resource; list_connections names them.",
+ "type": "integer"
+}summarize_records2 fields changedInput schema / properties / build_idRemoved value: -{
- "description": "Omit when only one of the company's builds holds the resource; list_connections names them.",
- "type": "integer"
-}Input schema / properties / connection_idAdded value: +{
+ "description": "Omit when only one of the company's sources holds the resource; list_connections names them.",
+ "type": "integer"
+}list_companiesswitch_companyask_questioncall_read_operationcall_write_operationdescribe_resourcesdiscover_operationsdiscover_questionsget_recordlist_connectionssearch_recordssend_feedbacksummarize_recordswhoamiQuery your books, company data, business health, and ship invoices from your AI assistant.
Ask your customer portal and CRM anything, in plain English
Ask your organization's connected business data in plain language, with each person's permissions.
Connect Claude, Cursor, or ChatGPT to your business data. Ask questions, get answers.
Add one secure layer between your agents and this server.
