MYOB Codex MCP
Server Quality Checklist
Latest release: v0.2.0
- Disambiguation3/5
Most tools are clearly separated by entity (invoice, bill, customer), but there is overlap between generic raw/entity tools and entity-specific tools (e.g., myob_entity_list vs myob_invoice_list). The alias myob_oauth_authorize duplicates myob_oauth_authorize_business, and myob_raw_commit_mutation vs myob_commit_operation vs myob_approval_approve creates boundary confusion.
Naming Consistency4/5The overwhelming pattern is myob_<resource>_<action> (e.g., account_list, invoice_get), with only a few deviations like myob_commit_operation (missing resource prefix) and myob_oauth_authorize_business (compound action). Overall, the naming is predictable and readable.
Tool Count2/5With 63 tools, this is far above the typical 3-15 well-scoped range. While the MYOB domain is broad, the number of tools creates a heavy decision surface for agents, and many are list-only variants that could be consolidated.
Completeness4/5The toolset covers a wide range of MYOB entities (accounts, customers, suppliers, invoices, bills, payments, inventory, jobs, etc.) with list/get operations, and prepare/commit flows for core mutations. The generic raw endpoint tools and metadata tools fill most gaps, though some mutations (e.g., employee, job) are only possible via the raw layer.
Average 3/5 across 63 of 63 tools scored. Lowest: 1.3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 8 commits in the last 12 weeks
- Last stable release on
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add
glama.jsonto the root of your repository:{ "$schema": "https://glama.ai/mcp/schemas/server.json", "maintainers": [ "your-github-username" ] }Then . Browse examples.
Add related servers to improve discoverability.
How to sync the server with GitHub?
Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.
To manually sync the server, click the "Sync Server" button in the MCP server admin interface.
How is the quality score calculated?
The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).
Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.
Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).
Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.
Tool Scores
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does not explain what 'prepare create' actually does—whether it stages a mutation, validates a payload, or returns a transaction ID. The phrase 'using the endpoint registry' is cryptic and adds no clarity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise in length, but it is not well-structured or informative. It lacks any front-loading of key details, such as what the tool returns or how the endpoint registry works. The brevity does not compensate for the absence of useful content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with five parameters, no annotations, and an output schema, the description is severely incomplete. It does not explain the prepare/commit workflow, how this tool fits into the entity creation process, or what the output schema represents. The agent is left without enough context to safely invoke this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description provides no parameter information. All five parameters (entity, layout, summary, json_body, business_id) are left unexplained, and the description fails to add any meaning beyond their names. 'layout' and 'summary' are particularly ambiguous in the context of a create operation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Prepare create for a supported entity using the endpoint registry' is vague and generic. It uses a tautological phrase ('prepare create') and does not specify which entities are supported or how this tool differs from the many sibling prepare_create tools. It fails to communicate the tool's specific role in the creation workflow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus the numerous specific prepare_create tools (e.g., myob_customer_prepare_create) or myob_entity_prepare_update. The description does not mention any workflow context, prerequisites, or alternatives, leaving the agent without direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for disclosing behavior. It reveals nothing about side effects, permissions, OAuth flow behavior, or any other behavioral traits. The alias statement alone provides no transparency into the tool's actual operations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise in form. However, it is under-specified and lacks substantive information, so it doesn't fully earn its place. It provides minimal value beyond the tool name, but it does reference a specific sibling, which is some content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an OAuth authorization tool with two boolean parameters and no output schema, the description is drastically incomplete. It fails to explain the tool's purpose, the authorization flow, parameter effects, or any return values. Given the complexity of OAuth operations, this is completely inadequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage and the description does not mention or explain any parameters. It fails to compensate for the lack of schema descriptions, leaving the meaning of 'manual' and 'open_browser' entirely unclear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description merely states it is an alias for another tool without specifying what the tool actually does. It lacks a clear verb+resource description and does not distinguish itself from siblings beyond referencing one. This is only slightly better than a tautology, as it doesn't explain the underlying function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not indicate when to use this tool versus alternatives, nor does it mention exclusions or prerequisites. The alias reference implies interchangeability with myob_oauth_authorize_business, but that's not actionable guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It does not disclose whether this tool makes a network call, whether it mutates data, whether authentication is required, or what the output schema represents. The term 'prepare' hints at a two-phase commit but that is not explicitly stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, so it is concise. However, it is under-specified, omitting essential information about behavior and parameters. It is concise but not effectively informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a complex tool with 6 parameters, nested objects, and an output schema, yet the description is only one sentence. It does not explain the prepare/commit workflow, return values, or parameter relationships. The tool is severely under-documented given its complexity and the absence of annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not describe any of the six parameters. While parameter names like 'entity', 'uid', and 'json_body' are self-explanatory, the description adds no clarity about formats, relationships, or how 'layout' and 'summary' affect the operation. The description fails to compensate for low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies the action 'prepare update' and the resource 'supported entity', which is somewhat clear. However, it does not explain what 'prepare' means or distinguish this generic tool from sibling update tools like 'myob_customer_prepare_update' or 'myob_raw_prepare_mutation'. The phrase 'using the endpoint registry' is vague.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. The description does not mention any specific contexts, prerequisites, or exclusions, and it fails to differentiate this tool from the many other prepare tools in the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations available, the description carries the full burden of disclosing behavioral traits. It only says 'List customer payments' and gives no indication of read-only nature, pagination behavior, filtering capabilities, authentication requirements, or return format. This is wholly inadequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and front-loaded, but it is under-specified rather than concise. It omits critical information, making the brevity a deficiency rather than a strength.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has three optional parameters and an output schema, yet the description explains nothing about the result structure, pagination through 'top', filter syntax, or how business_id affects the query. It is incomplete for a list operation with no annotations or schema descriptions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no explanation of the 'top', 'filter', or 'business_id' parameters. The tool name and one-line description add no meaning beyond the raw schema, failing to compensate for the complete absence of parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('customer payments'), clearly distinguishing the tool from sibling tools like supplier payment list. However, it lacks explicit scope details and does not differentiate from similar list tools beyond the resource name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as myob_receive_money_list or myob_supplier_payment_list. There is no mention of prerequisites, filtering context, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations to lean on, the description carries the full burden of disclosure. It only states 'List employees' and gives no information about pagination, filtering, authentication, rate limits, or whether the operation is read-only, which is a significant gap for a tool with no other metadata.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but under-specified. Being concise does not compensate for the lack of useful information; this is closer to an empty shell than a well-structured description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has output schema, but the description gives no context about when to call it, what the output contains, or how the parameters affect results. This is inadequate even for a simple list tool, especially given the abundance of sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no explanatory value for the three parameters ('top', 'filter', 'business_id'). The agent is left with only names and defaults, which is insufficient for correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List employees' clearly identifies the action (list) and the resource (employees). It distinguishes from sibling list tools by resource name, but doesn't explicitly address alternatives or scope, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like myob_entity_list or other list-specific tools. There are no prerequisites, exclusions, or context clues to direct the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. The two-word description provides no information about authentication requirements, pagination behavior, whether the operation is read-only, or how the optional 'business_id' affects results. This is a critical gap for a list tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (two words) but is under-specified rather than efficiently informative. It lacks any structural elements like parameter details or usage notes, making it too terse to be useful for an AI agent deciding whether and how to invoke the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (2 parameters, no annotations, an output schema not referenced in the description), the description is completely inadequate. It provides no context about what constitutes a 'job', how results are structured, or how the business_id parameter scopes the listing, leaving the agent with insufficient information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description fails to mention either parameter ('top' or 'business_id'). The description does not compensate for the schema's lack of documentation, leaving an AI agent without semantic understanding of these parameters beyond their names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List') and resource ('jobs'), making the basic purpose clear. However, it does not differentiate from sibling list tools like myob_invoice_list or myob_customer_list, which also follow the 'list <entity>' pattern.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives, no mention of prerequisites (e.g., requiring an authorized business), and no context about selecting a specific business via the 'business_id' parameter. The description simply states the action without any usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of disclosing behavior. It only states 'List purchase bills' without mentioning pagination limits, required authentication, output format, or any side effects. This is a significant gap for a tool that likely performs an API read.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief (one sentence), which is concise in length but not appropriately sized for the information needed. It front-loads the core purpose but omits essential details, making it under-specified rather than efficiently compact.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While an output schema exists, the description fails to explain the tool's behavior beyond a basic list operation. It lacks information about filtering, pagination, authorization requirements, or relationship to other bill-related tools. For a tool with three parameters and no annotations, this is insufficient contextual completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not compensate by explaining any of the three parameters (top, filter, business_id). The tool name and description give no clue about how these parameters affect the query, leaving the agent to guess their semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List') and the resource ('purchase bills'), making the core purpose unambiguous. However, it does not explicitly differentiate itself from sibling tools like myob_bill_get or other list tools beyond the natural 'list vs. get' distinction, so it stops short of a full 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives. It does not mention that it is for retrieving multiple bills as opposed to a single bill via myob_bill_get, nor does it introduce the filter or pagination parameters. There is no exclusionary or alternative tool reference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavioral traits. It only says 'List inventory items' and offers nothing about pagination behavior (e.g., the 'top' parameter), filtering semantics, business_id scoping, or the structure of the response. The lack of any behavioral detail leaves the agent without crucial operational information.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with no wasted words, which is a plus. However, its brevity crosses into under-specification, as it omits essential parameter and usage context. It is a single, clear sentence but not appropriately sized for a tool with multiple parameters and no other documentation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has three parameters (top, filter, business_id), no annotations, no schema descriptions, and an output schema that is not explained, the description is grossly incomplete. It does not adequately prepare the agent to invoke the tool meaningfully, understand parameter effects, or interpret results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the schema itself provides no explanatory text for any of the three parameters. The description does not compensate by explaining what 'top', 'filter', or 'business_id' mean or how they affect the listing. The agent is left to guess, which is a significant gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List inventory items.' clearly states the verb 'List' and the resource 'inventory items', making the tool's primary function obvious. However, it does not distinguish this tool from siblings like 'myob_entity_list' or 'myob_inventory_item_prepare_create', so it only meets the bar for clarity without sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There is no mention of the intended use case, prerequisites, or scenarios where a different tool (e.g., 'myob_entity_list' or 'myob_inventory_item_prepare_create') might be more appropriate. This is a complete lack of usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It simply states 'List supplier payments' and offers no details about pagination, filtering behavior, authentication requirements, rate limits, or any other operational characteristics. This is starkly insufficient for a tool with no structured safety hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short and technically concise, but it crosses into under-specification. It lacks the substance needed to be useful, making the sentence not earn its place. A description this minimal is closer to a placeholder than an efficient summary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has three optional parameters, no annotations, and an output schema, the description should provide at least some context on how to use the parameters and what the tool returns. It does neither. The description is incomplete for a list operation that supports filtering and limiting, and it doesn't clarify how this relates to other payment or bill listing tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% — the description does not mention or explain any of the three parameters (top, filter, business_id). Since the schema itself lacks descriptive text for these parameters, the description should compensate but completely fails to do so. The parameter names are mildly self-explanatory, but the description adds no semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear verb+resource combination: 'List supplier payments.' It clearly indicates the tool lists supplier payments, which distinguishes it from related tools like myob_customer_payment_list at a basic level. However, it doesn't explicitly differentiate itself from sibling tools such as myob_bill_list or myob_spend_money_list, so it stops short of full sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention any preferred context, prerequisites, or exclusions. Users are left to infer that it is the go-to for listing supplier payments, but there is no explicit 'when to use' or 'when not to use' information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full burden of behavioral disclosure. It does provide one useful signal—'High-risk approval required'—but it fails to explain whether the tool mutates data, what side effects occur, how approval is obtained, or how it interacts with commit/approve operations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short, but this is under-specification rather than effective conciseness. While 'High-risk approval required' adds value, critical details about the prepare process, required payment fields, and approval next steps are missing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is complex (free-form json_body, approval workflow, related prepare/commit siblings), yet the description provides almost no contextual information. It fails to explain the required data, the approval flow, or what the output schema represents, making it inadequate for an agent to use safely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no parameter guidance. json_body is a free-form object with no documented structure, and business_id is unexplained. Since the description does not compensate for the missing schema coverage, the agent has no idea what content to put in json_body.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Prepare recording') and identifies the resource ('a customer payment'), distinguishing it from the sibling supplier payment tool. However, it doesn't clarify what 'prepare' means operationally—whether it stages a draft, requires a commit step, or creates immediately.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool versus alternatives like raw_prepare_mutation, entity_prepare_create, or the equivalent supplier payment prepare tool. The phrase 'High-risk approval required' implies an approval workflow but doesn't explain how this tool fits into the prepare/commit/approval lifecycle.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It says 'List' but does not explicitly state that the operation is read-only, nor does it disclose pagination behavior, filtering semantics, or required authentication. The minimal description provides almost no behavioral context beyond the literal action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The single sentence is concise and front-loaded, but it is severely under-specified. It omits essential information about parameters, use cases, and behavior, which is more under-specification than appropriate conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema and three optional parameters, the description is woefully incomplete for a tool in a large sibling family. It does not explain how it relates to authentication, business selection, or filtering, and it offers no guidance on when to prefer it over other list tools. The agent is left with almost no actionable context beyond the tool name.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has three parameters (top, filter, business_id) with 0% description coverage, and the tool description does not mention any of them. The agent receives no explanation of what these parameters mean, how they affect the query, or their valid values, making parameter usage entirely opaque.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List') and the resource ('receive-money transactions'), which directly matches the tool name and distinguishes it from sibling list tools. However, it lacks elaboration on returned data or MYOB-specific terminology, leaving some ambiguity for unfamiliar users.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives like spend_money_list or customer_payment_list. It does not mention any conditions, prerequisites, or exclusions, leaving the agent to infer usage solely from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It hints at risk via 'high-risk approval required' but fails to explain side effects, whether preparation writes data, idempotency, or response behavior. Minimal transparency beyond the approval warning.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded, but under-specification outweighs conciseness. Every sentence is vague and misses critical workflow details that would justify its brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex prepare operation with nested objects and an output schema, the description is severely incomplete. It doesn't mention return values, commit/approval next steps, or relationships to sibling tools like myob_commit_operation, leaving the agent without essential operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no parameter information. json_body is an open object with no field guidance, and business_id is ignored entirely. The description adds zero value for parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies a specific action ('prepare') and resource ('receive-money transaction creation'), making the basic purpose clear. It distinguishes from sibling prepare tools by targeting receive-money specifically, though it doesn't explain what 'prepare' entails.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives such as myob_raw_prepare_mutation or myob_entity_prepare_create. The 'high-risk approval required' note is a prerequisite, not a usage guideline, and there's no mention of fit in the prepare/commit/approval workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. 'List tax codes.' offers no behavioral detail such as authentication needs, pagination behavior, business context filtering, or side effects. This is insufficient for safe autonomous invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification rather than effective conciseness. A single phrase without supporting detail does not earn credit for concise structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Even with an output schema present, the description lacks essential context. It does not clarify whether a business_id is required, how pagination works, or what distinguishes this list from related list endpoints.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain the 'top' or 'business_id' parameters. The agent has no idea what these parameters mean or how to use them correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List tax codes.' clearly states the action (list) and the resource (tax codes). It distinguishes this from most sibling tools by naming a specific entity, though it doesn't explicitly differentiate from other list tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. It does not mention prerequisites, typical use cases, or why an agent might choose this over other list tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states 'List chart of accounts,' which implicitly suggests a read-only operation but does not explicitly confirm this, nor does it describe pagination, default business context, or any side effects. The behavior is left largely to inference.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is an efficient single sentence with no filler words. It is front-loaded with the action, but it is minimalistic to the point of under-specification, lacking necessary parameter context without becoming bloated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of three optional parameters and an output schema, the description is incomplete. It does not explain how to use business_id or filter, what the output contains, or how it relates to the broader MYOB authorization flow. The description is adequate only for a barebones list operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has three parameters (top, filter, business_id) but the schema description coverage is 0%, and the description does not mention any of them. The parameter names give some hint, but the description adds no meaning to clarify their purpose, format, or defaults beyond what the bare schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List') and the resource ('chart of accounts'), which distinguishes it from sibling list tools like tax_code_list and job_list. However, it is almost a restatement of the tool name and does not elaborate on what a chart of accounts includes, so it is clear but minimally informative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus myob_account_get or other list tools, nor does it mention any context such as the need for a selected business or authorization. There are no usage alternatives, prerequisites, or exclusions mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavioral traits. It only states 'List bank accounts' and does not mention pagination (via 'top'), filtering (via 'business_id'), authentication, data scope, or any side effects. Since this is a list operation, the behavior is relatively simple, but the complete absence of behavioral context is a significant shortfall.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, succinct sentence that front-loads the purpose. There is no redundancy or unnecessary detail. However, it is so short that it misses crucial information, so it cannot earn a perfect score for structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although an output schema exists (so return values are covered), the description lacks essential context. There are no annotations to indicate safety or side effects, and the tool's role relative to the many sibling list tools is unexplained. For a tool with two optional parameters, this description is incomplete and leaves significant gaps for an agent trying to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema descriptions are entirely absent (0% coverage), and the description does not compensate. It does not explain the meaning of 'top' (likely the maximum number of records to return) or 'business_id' (which business's accounts to list). The parameter names are somewhat suggestive, but the tool provides no semantic clarification, leaving an agent to guess.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'List bank accounts.' This clearly indicates what the tool does, and the name 'myob_bank_account_list' distinguishes it from the sibling 'myob_account_list' (which likely lists general accounts). However, it does not explicitly differentiate itself from siblings beyond the resource name, so it misses the top score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. It does not mention any context, exclusions, or related tools. For example, it does not clarify when to use this instead of 'myob_account_list' or how it fits into the MYOB workflow. This is a clear gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only restates the function name ('Get any contact') and does not explain the scope of 'any contact', required authorization, error conditions, side effects, or return format. This is a minimal repetition rather than a transparent disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler, which is efficient. However, it is under-specified for a tool with two parameters and no annotations, bordering on too terse to be genuinely useful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations, so the description is the sole source of context. It fails to explain what constitutes a 'contact', how business_id affects the lookup, or what the agent should expect in the response. For a tool with this complexity, the description is not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, but it only mentions 'by UID' without explaining the nature of the UID or the optional business_id parameter. No additional meaning is added beyond the schema titles; business_id is entirely ignored.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action (get) and a specific resource (contact) with the key lookup parameter (UID). It differentiates from list tools (e.g., myob_customer_list) but does not explicitly distinguish it from the more generic myob_entity_get, which weakens sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives like myob_entity_get or the various list tools. It provides no context, exclusions, or complementary usage instructions, leaving the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description is the sole source of behavioral information. It only states 'List customers,' which is accurate but omits any details about pagination, filters, required authorization, or return structure. This is a minimal, non-misleading statement but lacks substantive transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exceptionally concise at two words, with no wasted text. However, it is so sparse that it lacks substantive content; while appropriately short, it does not fully earn its place by providing necessary context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 optional parameters and an output schema, the description is far too incomplete. It does not explain filtering, pagination limits, or business context, leaving the agent with insufficient information to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention any of the three parameters (top, filter, business_id). The agent receives no explanation of their meaning or usage, leaving the parameter semantics entirely undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists customers, providing a verb and resource. However, it does not distinguish this tool from sibling list tools like myob_entity_list or myob_contact_get, so it stops short of full differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool over alternatives. There is no mention of prerequisites, context, or exclusions, leaving the agent without direction on tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for disclosing behavior. It only mentions 'using the endpoint registry', but does not explain how unsupported entities are handled, pagination behavior, response format, or authentication needs. This is a significant transparency gap for an unannotated tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that efficiently states the core action. However, it may be too terse, sacrificing necessary detail for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the generic nature and six parameters with zero schema descriptions, this description is far from complete. It does not cover how to specify entities, apply filters, or interpret the output, making it insufficient for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not compensate. It only vaguely references the entity parameter, leaving top, filter, orderby, max_items, and business_id completely unexplained. The agent has no idea how to use these parameters effectively.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool lists records for a supported MYOB entity, using 'List' as a specific verb and referencing the entity resource. It implicitly distinguishes itself from specialized list tools (e.g., myob_account_list) by being entity-generic, though it doesn't explicitly say so.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this generic tool versus the many specialized list tools (e.g., myob_account_list, myob_customer_list). There is no mention of alternatives, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the operation is 'high-risk' and requires approval, which is useful context. However, it does not describe what 'preparing' entails, whether it mutates data directly, what the approval process is, or what the user should expect in response beyond the output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, with only two sentences. Both sentences carry information: the purpose and the risk/approval requirement. It front-loads the core function. However, it is under-specified, but the conciseness itself is appropriate given the lack of detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and sibling approval tools, the description is incomplete for an agent to use correctly. It does not explain the prepare-commit workflow, what json_body should contain, or how approval integrates. The description is too sparse for a tool with a required flexible object and significant risk.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention json_body or business_id at all. The required json_body parameter is a flexible object with additionalProperties true, leaving the agent completely without guidance on its structure or required fields. The description adds zero value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Prepare general journal creation.' It uses a specific verb ('prepare') and resource ('general journal'), which distinguishes it from other prepare tools for different entities. However, it does not explicitly differentiate from similar prepare-then-commit workflows, so it's clear but not fully sibling-distinctive.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like myob_raw_prepare_mutation or myob_commit_operation. The 'High-risk approval required' warning hints at a workflow but does not explain the prepare/approve/commit sequence or when to choose this over other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full behavioral burden. It says 'Return', suggesting a read-only operation, but does not explicitly state that it has no side effects, require specific authorization, or mention error cases. The description adds little beyond what the tool name implies, leaving the agent without important behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the main action. It is efficient but under-specified; it lacks necessary details about the entity parameter and the nature of 'write flow'. This is not concise in the value-added sense—it omits critical information that should be present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations, no output schema, and a sparse description, the tool is incomplete from an agent's perspective. There is no explanation of the return structure, no examples, and no mention of prerequisites like selecting a business. For a metadata utility, this missing context hinders correct invocation and use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter 'entity' with zero description coverage, and the description only generically refers to 'for an entity'. It does not explain valid entity names, expected format, or examples, forcing the agent to guess what values are acceptable. The description fails to compensate for the lack of schema-level parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear verb ('Return') and identifies the resource ('known MYOB endpoint paths and write flow for an entity'). This distinguishes it from sibling metadata tools like list_domains and get_tool_catalog, which target different resources. However, 'write flow' is somewhat vague and could be interpreted in different ways.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives. It only implies use for retrieving schema-related metadata, but does not mention contexts like preparation flows, authentication requirements, or when to prefer entity-specific getters. There is no reference to sibling tools or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden of behavioral disclosure. It only says 'List' which implies a read-only operation, but it does not mention pagination, filtering behavior, required authorization, or response characteristics. The output schema exists but does not compensate for the lack of behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no fluff. It efficiently conveys the core action. However, it is so terse that it borders on under-specification, although that flaw is better captured in other dimensions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a list tool with three parameters and zero schema coverage, the description is incomplete. It does not explain filter usage, default limits, or business_id handling. The output schema exists but does not compensate for the missing parameter semantics and usage guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides zero explanation of 'top', 'filter', or 'business_id'. An agent has no idea what filter syntax to use, how 'top' behaves (e.g., limit or page size), or how 'business_id' scopes the query. This is a critical gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'List spend-money transactions.' This clearly identifies the tool as a read-only listing operation for spend money transactions, distinguishing it from sibling tools like myob_receive_money_list or myob_bill_list. However, it does not explicitly name alternatives or differentiate on scope, so it falls short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives, no exclusions, and no context about prerequisite conditions. The description simply states the action without any hint of appropriate use cases, which is insufficient for an agent deciding between many list tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behaviors, but it only states 'High-risk approval required,' which adds a risk flag. It doesn't explain the prepare workflow, whether a draft is created, if it can be undone, or how it interacts with the approval and commit tools.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded, but the first phrase largely repeats the tool name. It earns points for having no waste, but could add more structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an open object parameter and no schema descriptions; the description does not compensate with instructions or context about the approval workflow. An agent cannot reliably construct a valid request from this description alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description says nothing about json_body or business_id. With schema coverage at 0%, there is no explanation of what the json_body should contain, leaving the agent to guess the structure of a spend-money transaction.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as preparing spend-money transaction creation, distinguishing it from sibling tools like myob_receive_money_prepare_create. However, 'prepare' is not elaborated, so it doesn't fully clarify the staging nature beyond what the name implies.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus the generic myob_entity_prepare_create or myob_raw_prepare_mutation, nor does it mention the eventual commit/approval steps. The 'High-risk approval required' statement is a caution, not a usage guideline.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only says 'List suppliers' and does not disclose any behavioral traits such as read-only nature, pagination behavior, filtering options, authentication requirements, or rate limits. This is insufficient for the agent to understand side effects or constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with no wasted words, but it is so under-specified that it lacks the structure expected of a helpful description. It reads more like a label than a structured explanation, slightly above the 'Process' example but still not adequately organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has three parameters, no annotations, and no schema descriptions, the description is far from complete. It does not mention the business_id context, filter syntax, pagination limits, or what the output represents. Even with an output schema present, the description fails to provide the necessary operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides three parameters (top, filter, business_id) with types and defaults but no descriptions (0% schema coverage). The description does not compensate by explaining the meaning or usage of these parameters, leaving the agent without the necessary information to use them correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List') and the resource ('suppliers'), which is a specific verb+resource pair. It distinguishes itself from sibling tools like 'myob_customer_list' by explicitly naming the suppliers resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage is implied: use this tool when you need a list of suppliers. However, there is no explicit guidance on when to use it versus alternatives (e.g., myob_entity_list or myob_supplier_prepare_create), nor any mention of required context like an authorized business.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. 'List' implies read-only, but it doesn't explicitly state safety, mention pagination via the 'top' parameter, or clarify how filters work. It lacks details on response behavior or any rate limits, leaving the agent with limited understanding.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no redundant words. It is front-loaded with the main purpose. While minimal, it earns its place by stating exactly what the tool does, aligning with conciseness standards.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and 3 optional parameters, the description is incomplete. It doesn't explain the semantics of top, filter, or business_id, nor does it clarify the scope of 'general journal records' in the broader context of sibling tools. The one-liner is insufficient for an agent to use it effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no information about the three parameters (top, filter, business_id). The defaults and types are visible in the schema, but their meaning and usage are entirely unexplained, so the agent cannot make informed parameter choices.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List general journal records.' clearly identifies the action (list) and resource (general journal records). It distinguishes from siblings like account_list or customer_list, though it doesn't elaborate on what constitutes a 'general journal record' or how it differs from other list tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of typical use cases, prerequisites, or exclusions. The description simply states what it does without context on selecting it among the many sibling list tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must fully disclose behavior. It adds a warning about high-risk approval, which is useful, but it fails to disclose whether this preparation has side effects, creates temporary data, or is idempotent. The meaning of 'prepare' in the context of the API is left ambiguous, leaving the agent uncertain about the operation's impact.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with no wasted words—'Prepare recording a supplier payment. High-risk approval required.' is front-loaded and direct. However, the brevity comes at the cost of essential details, but for the dimension of conciseness and structure, it is efficiently organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a supplier payment record with nested objects and no parameter documentation, this terse description leaves major gaps: the workflow (prepare → approve → commit), the required json_body structure, and the implications of 'high-risk' are all unexplained. The existence of an output schema does not compensate for the lack of operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has two parameters, including a complex json_body object with additionalProperties allowed, and schema description coverage is 0%. The description provides zero guidance on what fields json_body should contain or how business_id is used, so the agent must guess the structure from the schema alone, which is insufficient for a payment record.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear verb-resource structure ('Prepare recording a supplier payment') that identifies the target entity (supplier payment) and the action (prepare). This distinguishes it from sibling tools like 'myob_supplier_payment_list' and 'myob_customer_payment_prepare_record'. However, it doesn't elaborate on what 'prepare' entails beyond recording, so it's clear but not fully specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'High-risk approval required' provides contextual guidance that the operation is not a simple read and likely requires an approval workflow, but it does not explicitly mention when to use this tool versus alternatives like the commit_operation or other prepare tools. The usage is implied rather than stated, with no exclusions or named alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It states the action but not the consequences, permissions, reversibility, or response format. The term 'Deny' implies mutation but lacks detail about what happens to the operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, front-loaded with the verb, and contains no waste or redundancy. It is appropriately sized for the minimal information it conveys.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is too minimal for a tool with no annotations and no output schema. It does not explain the approval workflow context, what a denial does, or how parameters should be provided. The sibling tools suggest a workflow but this tool is not placed within it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention any of the three parameters (operation_id, denied_by, reason). It fails to add meaning beyond the schema, leaving the agent without guidance on how to fill them.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Deny) and the resource (prepared or approved MYOB write operation), distinguishing it from sibling tools like myob_approval_approve. It is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides minimal context that the tool is for operations in 'prepared or approved' state, but does not explicitly state when to use it over alternatives or exclude other states. No alternatives are mentioned, and the guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior, but it only restates the tool's name. It does not mention pagination, filtering, or business context. However, it is not contradictory.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It is appropriately concise for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description lacks context for parameters and usage, making it incomplete for an agent to select and invoke correctly. It barely informs the agent beyond the tool's name.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain the three parameters (top, filter, business_id). The agent is left without semantic understanding of these inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('sales invoices'), clearly distinguishing it from sibling tools like myob_invoice_get (which retrieves a single invoice) and myob_bill_list (which lists bills). It states exactly what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not mention when to use this tool versus alternatives like myob_invoice_get or other list tools, nor does it describe any prerequisites or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It does state 'read-only,' which is a key safety trait, but it does not discuss authentication requirements, error behavior, parameter handling, or response formats. This is minimal transparency for a raw endpoint tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise—two short sentences. However, the second sentence ('This tool is read-only') is largely redundant with 'Read' in the first sentence, so it slightly wastes words, though it is still tightly structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a raw, generic GET tool with three parameters, no output schema, and no annotations. The description fails to cover how the parameters interact, what constitutes a valid path, expected return structure, or any operational caveats, making it highly incomplete for its complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero description coverage, and the description does not explain any of the three parameters (path, params, business_id). The agent is left to infer their meaning from names alone, which is insufficient for a raw API tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: reading any MYOB Business API endpoint via GET. This distinguishes it from sibling tools that target specific entities (e.g., myob_invoice_get, myob_account_list) and from mutation tools like myob_raw_prepare_mutation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this raw GET tool versus dedicated list/get tools, nor does it mention exclusions or alternatives. It simply states the action, leaving the agent without contextual selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses one key behavioral trait: the operation requires approval before commit. However, it does not explain what 'prepare' entails (e.g., validation, locking, creating a pending request), what happens after approval, or any side effects. The description is too sparse to provide adequate transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (two sentences) and front-loaded, but it is under-specified rather than concise. The first sentence mostly restates the tool name, and the second adds a single caveat. While there is no wasted wording, the brevity comes at the cost of necessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema, so return values need not be explained. However, with zero parameter documentation, no annotations, and minimal description, the overall context is incomplete. The agent lacks guidance on how the approval workflow operates, what identifiers are needed, and how the json_body should be structured, making the description insufficient for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, and the description provides no details about the parameters (uid, json_body, business_id). The description does not explain what 'uid' refers to, what 'json_body' should contain, or the role of 'business_id'. This leaves the agent unable to construct valid arguments without external knowledge.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool prepares an update to a supplier contact, using a specific verb ('prepare') and resource ('supplier contact'). It distinguishes from sibling tools like myob_supplier_prepare_create (create vs update) and myob_entity_prepare_update (specific to suppliers).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions 'Requires approval before commit', which implies a two-phase workflow (prepare then approve/commit). However, it does not explicitly specify when to use this tool versus alternatives, nor does it mention prerequisites such as having a valid supplier UID or authorization. The usage context is implied but not fully explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It adds one behavioral constraint (exact approval_phrase format) but does not disclose side effects, required permissions, reversibility, or what happens after approval—significant gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no wasted words. It front-loads the primary purpose and then adds the critical phrase requirement, making it concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and a complex approval workflow, the description is minimal. It lacks context about the approval lifecycle (e.g., whether approval triggers commit), error cases, or prerequisites, leaving the agent without enough information to use the tool safely and effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It only adds meaning for approval_phrase (the exact format), while operation_id, approver, and reason are left to be inferred from their names. This is insufficient for a 4-parameter tool with no schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Approve') and the resource ('a prepared MYOB write'), which aligns with the tool's name and distinguishes it from sibling approval tools like deny. It does not explicitly name alternatives, but the purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies that this tool should be used after a 'prepared MYOB write' and provides the exact approval phrase format, which is a usage guideline. However, it does not explicitly state when not to use it or mention alternatives like deny or commit, leaving the usage context partially implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral transparency. It discloses that the tool sets a default, implying a state change, but does not mention side effects, permissions required, reversibility, or whether the business_id must belong to an authorized business. This is a significant gap for a mutation-like tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with 13 words, front-loaded with the action, and contains no fluff. Every word earns its place, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of annotations and output schema, the description is too thin. It does not explain what happens on success (e.g., confirmation, return value), prerequisites (e.g., having an authorized business), or whether the default persists across sessions. A simple one-line description is insufficient for a state-changing operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one required parameter, business_id, with no description, and the tool description does not explain it beyond the term 'business/company file'. The description adds minimal meaning over the parameter name, leaving the agent to infer the identifier's format or origin. With 0% schema coverage, the description should compensate but does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: setting the default MYOB business/company file for future tool calls. It uses a specific verb and resource, but does not explicitly distinguish it from sibling tools like myob_business_list_authorized or myob_company_get_context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'for future tool calls' provides clear context about when to use this tool—before subsequent operations that require a business context. However, it does not mention alternative tools or exclusions, such as when not to use it or whether the business must already be authorized.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for disclosing side effects. It only says 'Requires approval before commit,' which hints that the action is non-final, but it does not clarify what 'prepare' does (e.g., validation, draft creation), what data it consumes, or any effects on the system.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short sentence with no redundant words. It picks up the essential purpose and a key constraint, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool operates in a complex prepare/commit/approval ecosystem with siblings like myob_commit_operation and myob_approval_*. The description omits the overall workflow, how to proceed after preparation, and the structure of json_body. Despite having an output schema, the description leaves too much to be inferred for a non-trivial operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description never mentions json_body, layout, or business_id. It fails to provide any guidance on what fields are needed for a purchase bill, what layouts are valid, or how to specify the business context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb+resource: 'Prepare creation of a purchase bill.' It clearly distinguishes this from sibling tools like myob_bill_prepare_update (update) and myob_bill_list/get (read), and from generic prepare tools like myob_entity_prepare_create.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Requires approval before commit' implies a two-phase workflow and signals that this is not the final commit step. However, it does not explicitly state when to prefer this tool over alternatives or mention any exclusions, such as using myob_bill_prepare_update for existing bills.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It only states that it returns context, but does not disclose side effects, authentication requirements, or what 'selected' means (e.g., whether it returns null if none is selected). This is a significant gap for a tool that could have state-dependent behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no wasted words. It conveys the essential function without verbosity, making it easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although the tool is simple with no parameters or output schema, the description is vague about what constitutes 'context'. It does not specify return fields, behavior when no business is selected, or relationship to other business-selection tools. This leaves the agent with insufficient information to fully understand the tool's output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema coverage is 100%. The baseline for 0 params is 4, and the description adds no parameter-specific information, which is appropriate since there are no parameters to explain.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('Return') and resource ('selected MYOB business/company file context'), which distinguishes it from sibling tools like listing files or setting defaults. However, it does not explicitly differentiate from alternatives or elaborate on what 'context' entails, so it falls short of a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There is no mention of usage context, prerequisites, or exclusions, leaving the agent to infer when this getter is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the key approval-before-commit requirement, which is important, but provides no detail on authentication requirements, what happens after preparation, or how the approval workflow proceeds. This is minimal but non-trivial transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single 10-word sentence that leads with the action ('Prepare update') and adds the critical approval constraint. It is concise and front-loaded with no filler, earning top marks for its size.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a prepare-mutation tool with approval flow and three parameters, this one-line description is insufficient. It omits how json_body should be structured, how the approval process is initiated or completed, and how this tool relates to generic prepare/commit tools. While an output schema exists, the text alone leaves significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description provides no parameter explanations. 'uid' and 'business_id' are somewhat self-explanatory from names, but 'json_body' is an opaque additionalProperties object with no guidance on expected shape, required fields, or update semantics, leaving the agent unable to construct a valid request.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
Description uses specific verb 'Prepare update' and resource 'customer contact', clearly indicating it stages an update for a customer. It does not, however, distinguish itself from the generic myob_entity_prepare_update sibling or mention the specific fields that can be updated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'customer contact' implies this tool is for updating customer data, and the approval mention gives some context. Yet it does not explicitly contrast with create/delete tools, generic entity update, or explain when the generic myob_entity_prepare_update should be used instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It discloses one key behavior: approval is required before commit, which signals a staged, non-final operation. But it doesn't mention side effects, permissions, or what happens after approval, leaving significant ambiguity. This is more than minimal but insufficient for full transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose and a critical constraint. It contains zero filler words, making it efficiently structured for quick parsing. The brevity is a strength, not a weakness, in terms of conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description is incomplete for an operation with an open json_body and an approval workflow. It fails to explain the prepare-approve-commit sequence, how to use the approval tools, or what to pass in json_body. Given the complexity of the tool and the many sibling prepare tools, this is a significant gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description provides no parameter information. The json_body parameter is an open object (additionalProperties: true) with no hints about required fields, and the description doesn't even mention that json_body should contain the inventory item details. The agent is left without any guidance beyond the schema's bare type declarations.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool's purpose: 'Prepare inventory item creation' specifies the verb 'prepare' and the resource 'inventory item creation', distinguishing it from sibling prepare tools (e.g., customer, supplier). However, it doesn't elaborate on what 'prepare' entails beyond staging, so it's not as rich as a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Requires approval before commit' implies a two-phase workflow, giving some context about when this tool is appropriate (when approval is needed) and hinting that the operation is not final. However, it doesn't explicitly mention alternatives (like raw_prepare_mutation) or state exclusions (e.g., 'use this only for inventory items').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It says 'Start MYOB OAuth consent' but does not disclose side effects, whether it blocks, opens a browser, or requires user interaction. The parameters `open_browser` and `manual` are not explained, leaving key behavioral traits undisclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loaded with the primary action and a brief usage note. Every word earns its place; there is no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite being part of an OAuth flow with related tools like myob_oauth_exchange_code, the description does not explain what happens after consent, how to use the result, or the role of the parameters. For a tool with no annotations and no output schema, this is insufficient context for an agent to know the full flow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no information about the `manual` or `open_browser` parameters. It fails to compensate for the schema gap, leaving parameter meaning entirely to inference from names and defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool starts MYOB OAuth consent for a single business/company file. The phrase 'one business/company file' provides a scope qualifier that distinguishes it from the sibling myob_oauth_authorize, though it does not explicitly name the alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The instruction 'Repeat once per business' gives clear usage context, indicating this tool should be called per business, and likely multiple times for multiple businesses. It does not mention when not to use it or explicitly contrast with siblings, but the repetition guidance is a concrete usage directive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full burden. It discloses the approval requirement, which is valuable, but doesn't explain whether this operation is read-only or creates a pending draft, what side effects occur, or how to proceed after preparation. The short two-sentence description leaves significant ambiguity about the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no filler. Each sentence contributes: the first states the action, the second states the critical prerequisite (approval).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (nested json_body, no annotations, no param docs), the description is insufficient. It doesn't explain the prepare/commit workflow, what the output schema contains, or how to construct a valid request. Users would need external knowledge to use this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no parameter guidance. The parameters (layout, json_body, business_id) are entirely unexplained; json_body is a nested object with additionalProperties:true, making it especially important to document. The description fails to compensate for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: to prepare a sales order creation. It uses a specific verb ('prepare') and resource ('sales order'), distinguishing it from sibling tools like invoice_prepare_create or bill_prepare_create. The mention of approval adds context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage in a two-phase flow (prepare then approve/commit) but doesn't explicitly state when to use this tool vs alternatives like myob_entity_prepare_create or myob_raw_prepare_mutation. No exclusions or alternative recommendations are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It does disclose a potential auth requirement ('New MYOB OAuth flows may require businessId from consent instead') and 'Try to' suggests possible failure. However, it doesn't state whether the operation is read-only, what happens on failure, or return format. The transparency is partial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no fluff. The first sentence states the action, the second provides a caveat. Every word earns its place, and it is front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema and no annotations, the description should explain return values and prerequisites. It mentions a potential OAuth issue but leaves 'accessible company files' ambiguous and does not describe what the list contains or how results are delivered. It is minimally sufficient but lacks important context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 adds no parameter-specific detail because none exist. It mentions businessId as an external requirement from consent, which is context beyond parameters but not parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the verb 'list' and resource 'company files', but the phrase 'Try to list accessible company files' is vague and hedged. It doesn't clearly define what 'company files' means or differentiate from sibling list tools like myob_account_list or myob_invoice_list. The mention of OAuth flows and businessId adds ambiguity rather than scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool versus alternatives. The note about 'New MYOB OAuth flows may require businessId from consent instead' hints at a prerequisite but does not state clear conditions or alternatives. No exclusions or comparisons with sibling tools are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavioral disclosure. 'Get' and 'preview' imply a read-only operation, but the description does not explicitly state that this call does not modify or consume the approval, nor does it mention authentication requirements, error behavior, or what 'full preview' entails.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no unnecessary words. It efficiently conveys the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is too terse. It does not explain what a 'full approval preview' contains, how it integrates with the approval workflow (list/approve/deny), or any preconditions (e.g., the operation must exist). An agent would need additional context to confidently invoke this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage and one required parameter, operation_id. The description adds that it is for 'a MYOB operation', providing minimal context, but does not explain what an operation is, where to obtain the ID, or its format. It only partially compensates for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get the full approval preview for a MYOB operation' uses a specific verb ('Get') and resource ('full approval preview') with a scope ('for a MYOB operation'), clearly distinguishing it from siblings like myob_approval_list_pending (lists), myob_approval_approve/deny (mutations).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives. Usage is implied by the name and sibling context (list pending → get preview → approve/deny), but not stated in the description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It only states the action without mentioning read-only semantics, error handling, auth requirements, or return format. For a getter, some minimal safety profile (e.g., 'this is a read-only operation') would be expected.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded with the verb and resource. There is no unnecessary wording, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with two parameters and no output schema, the description provides the core function but omits important context like the role of business_id, whether the record includes all fields, and behavior when the UID is not found. It is minimally viable but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description must compensate. It references 'uid' but does not explain the optional 'business_id' parameter, which is left completely undocumented. The description adds no meaning beyond the schema's property names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get a chart-of-accounts record by UID.' This specifies the verb (get), the resource (chart-of-accounts record), and the identifier (UID), distinguishing it from siblings like myob_account_list and myob_entity_get.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The use case is implied by the description: use when you have a UID and need a single chart-of-accounts record. However, there is no explicit guidance on when to prefer this over alternatives such as myob_account_list, nor any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the tool only prepares creation (not immediate creation) and that approval is required before commit. However, it does not describe what happens upon preparation, the output, or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, both meaningful: the first states purpose, the second states the key constraint. It is front-loaded and waste-free, though it could include more detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a preparation tool with a required nested json_body and no parameter documentation, the description is incomplete. It leaves the agent without workflow steps (what to do after preparation, how to approve/commit) and without parameter expectations. The output schema may help but is not referenced.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no information about the json_body, layout, or business_id parameters. The tool requires a json_body object with unspecified structure, so the agent receives no guidance on how to populate it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool prepares creation of a sales invoice, using a specific verb ('prepare') and resource ('sales invoice'). This distinguishes it from sibling tools like myob_invoice_prepare_update and myob_invoice_prepare_delete, as well as from other entity prepare tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states 'Requires approval before commit,' providing clear context about the workflow and when to use the tool (as a preparation step before approval/commit). It does not explicitly name alternatives or exclusions, but the workflow context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the two-phase nature (prepare, then approval required before commit), which is valuable behavioral context. Yet it omits details on side effects, whether changes are staged or validated, and the exact approval process.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that is easy to parse and gets straight to the tool's purpose. However, it is so short that it omits any parameter or workflow hints that would be valuable without bloat.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (4 parameters, nested json_body, approval workflow, no annotations), the one-line description is insufficient. Even with an output schema present, the agent lacks guidance on constructing the update and navigating the approval-commit cycle.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, and the description offers no parameter-level detail. It doesn't explain the meaning of 'uid', 'json_body', 'layout', or 'business_id', leaving the agent to guess how to structure the update payload.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'prepare update' and the specific resource 'sales invoice', distinguishing it from sibling tools like create, delete, and generic entity updates. It precisely conveys what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description notes the critical prerequisite 'Requires approval before commit', which helps the agent understand the workflow context. However, it does not explicitly state when to use this tool versus alternatives like myob_entity_prepare_update or how it fits with approval tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It does disclose a key side effect—storing encrypted tokens—which signals a write operation and persistence. However, it doesn't mention whether existing tokens are overwritten, what happens on failure, or any security/auth requirements beyond the exchange itself. The disclosure of 'encrypted' is useful but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single, well-structured sentence that immediately states the action, target, and outcome. No filler words or redundant information, making it highly scannable and efficient for an agent to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The OAuth flow is inherently complex and involves multiple steps (authorize, exchange, refresh). This description gives only the bare action without explaining the surrounding context, expected return format, failure modes, or prerequisites. Given no annotations and no output schema, a one-sentence description is insufficient for an agent to fully understand when and how to invoke this tool correctly in a broader workflow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning to 'code' (OAuth code) and 'business_id' (one MYOB business), which helps map to the schema. However, it does not explain the 'state' parameter at all, despite the schema having a default of null. Since schema coverage is 0%, the description partially compensates but leaves a gap for one parameter and does not specify formats or how to obtain the code.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('exchange') and identifies the resource ('OAuth code for one MYOB business') and the outcome ('store encrypted tokens'). It clearly distinguishes this from sibling tools like 'myob_oauth_authorize' or 'myob_oauth_refresh' by emphasizing the manual exchange for a single business, making the tool's purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It doesn't mention prerequisite steps (e.g., obtaining the OAuth code) or under what circumstances a manual exchange is preferred over automated flows. Sibling tools like 'myob_oauth_authorize_business' and 'myob_oauth_exchange_redirect_url' underscore the need for context, but the description remains silent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that tokens are 'locally stored,' which is informative, but it does not state whether remote authorization is also revoked, whether removal is reversible, or how it affects default business selection. With no annotations, the description carries the full transparency burden but only partially fulfills it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is direct, action-focused, and free of unnecessary words. It front-loads the verb and resource with maximum efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool, the description is adequate but lacks important context about side effects (e.g., whether server-side authorization is invalidated) and post-removal behavior. There is no output schema, so return values are not explained; however, simplicity is a mitigating factor.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The one parameter (business_id) is not described in the schema, and the description's phrase 'one MYOB business/company file' indirectly clarifies its purpose. However, it does not explicitly explain what business_id represents, its format, or how to obtain it, so it adds limited value beyond the type definition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Remove locally stored OAuth tokens') and the scope ('one MYOB business/company file'), distinguishing it from global logout tools like myob_oauth_logout. It is specific, verb-first, and resource-targeted.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool versus alternatives such as myob_oauth_logout or myob_business_list_authorized. The description does not mention prerequisites, intended scenarios, or exclusion cases, leaving the agent to infer usage solely from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description correctly discloses that the tool 'mutates MYOB' and 'requires a valid approval token', which are critical behavioral traits. However, it does not discuss reversibility, idempotency, or consequences of invalid tokens, leaving gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loading the primary action and then adding essential safety context. Every word earns its place with no redundancy or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with two parameters and no output schema, and the description covers the core purpose and safety. However, it does not explain the surrounding workflow (e.g., how to obtain an approval token, relationship to prepare/approve tools) or return values, leaving some contextual gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the burden. It implicitly explains 'operation_id' as the approved operation and 'approval_token' as the required token, but provides no format, source, or constraints. This adds some meaning but is minimal.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Commit any approved MYOB operation.' This is a specific verb (commit) and resource (approved MYOB operation). It distinguishes from siblings by emphasizing 'approved', implying a workflow with prior approval, but does not explicitly name alternatives like myob_raw_commit_mutation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies it should be used for approved operations requiring a token, but it does not explicitly state when not to use it or mention alternative tools. The context is clear but exclusions and alternatives are missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses that this is a preparation step, not a direct deletion, and that approval is critical, which suggests a workflow and potential consequences. However, it does not explain what 'prepare' entails, what the output contains, or what happens after approval (e.g., requiring commit), leaving significant behavioral aspects undisclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no fluff. Every word adds meaning: 'Prepare', 'deletion/void-style removal', 'sales invoice', 'where MYOB permits it', and 'Critical approval required' are all essential. It is well-structured for quick parsing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While an output schema exists, the description is too minimal for the tool's complexity. It doesn't mention the two-step prepare/commit pattern (evident from sibling tools), the significance of 'layout' or 'business_id', or any prerequisites like authentication or authorization. The agent would lack enough context to correctly invoke and integrate this tool into a workflow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no explanation of the parameters (uid, layout, business_id). While the parameter names are somewhat self-explanatory, the description adds zero value for understanding their roles, formats, or defaults. This is a minimal score because the description fails to compensate for the schema's lack of descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('Prepare deletion/void-style removal') on a specific resource ('a sales invoice'), and distinguishes this preparation step from actual deletion by noting it is where MYOB permits it. It also clearly differentiates from sibling tools like prepare_create/prepare_update by focusing on removal.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for invoices that MYOB allows to be deleted or voided, but does not explicitly state when to use this versus alternatives (e.g., raw mutations or update). The warning 'Critical approval required' gives a caveat but no explicit context about the two-step prepare/commit flow or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It adds value by specifying the statuses ('pending or approved') and the context ('awaiting user/accountant action'), which goes beyond the tool name. However, it does not explicitly disclose that this is a read-only operation, nor does it describe the response format, pagination, or ordering. Moderate transparency, with room for more detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single 13-word sentence that front-loads the action ('List') and succinctly states the resource with the relevant status scope. Every word contributes to meaning, with no unnecessary filler or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list operation with zero parameters and no output schema, the description gives a reasonable overview. However, the phrase 'pending or approved' creates ambiguity: are these two separate statuses or a combined state? Additionally, it neither clarifies what fields will be returned nor whether the list includes any metadata. The description is minimally sufficient but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema confirms this with 100% coverage. Since there are no parameter semantics to explain, the baseline of 4 is applied. The description correctly does not attempt to describe parameters, as none exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action ('List') and the resource ('MYOB operations awaiting user/accountant action') with the status scope 'pending or approved'. This distinguishes it from siblings like myob_approval_get (single item) and approve/deny (action items). However, the inclusion of 'approved' in a tool named 'list_pending' introduces slight ambiguity about the exact set of items returned.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the use case: seeing operations that require attention. It does not explicitly state when to use this tool versus alternatives such as myob_approval_get, myob_approval_approve, or myob_approval_deny. There is no when-not-to-use guidance, making this merely implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses a key behavior: content_base64 is stored in a pending payload until approved. This goes beyond the tool name, but it does not mention other behaviors like authentication requirements, file size limits, or what happens if not approved. Some context is added, but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two short sentences. The first announces the purpose, the second provides essential context about the pending payload. Every word earns its place, with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is moderately complex with 5 parameters and an output schema. The description covers the core purpose and the pending-approval behavior, and the output schema handles return values. However, with zero schema descriptions and no annotations, more context is needed—such as what parent_path refers to, when approval occurs, or any prerequisites. It is adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It only explains content_base64 ('stored in the pending payload until approved'), which adds semantic value for that parameter. However, it does not explain parent_path, file_name, business_id, or content_type. The names are partially self-explanatory, but parent_path remains ambiguous and none are fully described.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Prepare attachment upload.' The verb 'Prepare' and resource 'attachment upload' are specific, and the second sentence 'content_base64 is stored in the pending payload until approved' clarifies that it stages content for a later approval step, distinguishing it from direct upload tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by naming the operation, but it does not explicitly state when to use this tool versus alternatives. It mentions the pending/approval flow, which hints at a two-phase process, but it lacks explicit guidance such as 'use this when you need to upload an attachment that requires approval.' No alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It adds a useful behavioral nuance about layout being needed for some details, but does not mention read-only behavior, errors, or business context requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two clear, front-loaded sentences. The first states the core action; the second adds a specific caveat. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 4-parameter tool with no output schema and no annotations, the description is too sparse. It omits business_id semantics, valid entity values, and what 'layout' actually returns, leaving gaps for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains layout's purpose and implies entity/uid from names, but business_id is left entirely unexplained, making the compensation partial.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get one MYOB record by entity and UID' with a specific verb and resource. It distinguishes from list/raw tools by emphasizing one record retrieval and the layout caveat for invoice/bill/order details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The layout note implies usage for invoice/bill/order details, but there is no explicit guidance on when to use this tool versus specific getters like myob_invoice_get. No alternatives or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the behavioral nuance that supplying a layout switches to a layout-specific endpoint, which is valuable. However, it omits other traits like authentication requirements, error behavior, or how the response varies between layouts.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, the first states the core action and the second adds a conditional nuance. No filler or repetition; structure is front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get tool, the description covers the primary action and one conditional behavior, but with no output schema and no parameter details for business_id, the context is incomplete. The meaning of 'layout' and the response shape remain ambiguous, lowering completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain parameters. It only adds meaning for 'layout' (switches to a detail endpoint) and leaves 'uid' and 'business_id' unexplained. UID is self-explanatory, but business_id is not mentioned at all, leaving a significant gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Get invoice by UID', which states a specific verb and resource, clearly distinguishing it from sibling tools like myob_invoice_list or myob_bill_get. The second sentence adds a conditional detail about layout-specific endpoints, further refining its purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for retrieving a single invoice by UID but does not explicitly compare it to alternatives such as myob_invoice_list or explain when to prefer this over other getters. The layout condition provides a usage hint but no exclusions or decision criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for disclosing side effects. It states what the tool does at a high level (exchange the URL) but does not mention network calls, auth state changes, whether it is reversible, or any potential destructive effects. This is a significant gap for OAuth-related tooling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. It communicates the core purpose efficiently without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of an OAuth exchange flow and the absence of annotations or output schema, this description is incomplete. It does not explain the OAuth flow context, what happens after a successful exchange, or any required prior steps (e.g., obtaining the redirect URL from an authorization step). The agent would need to infer too much.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates by explaining that the redirect_url parameter should contain code, businessId, and state. This adds meaningful context beyond the schema's bare 'Redirect Url' label, though it could have further detailed the URL format or encoding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Exchange') and resource ('full MYOB OAuth redirected URL'), and specifies the URL contains code, businessId, and state. This clearly distinguishes it from the sibling tool myob_oauth_exchange_code, which likely operates on just the code.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool should be used when you have the full redirect URL from the OAuth flow, but it does not explicitly state when to use it over alternatives like myob_oauth_exchange_code, nor does it mention any exclusions or prerequisites. Usage context is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the behavioral disclosure burden. It does reveal that supplying layout switches to a layout-specific detail endpoint, which is useful. However, it does not disclose the return format, authentication needs, or error behavior, leaving the agent to infer these.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only two sentences: the first states the core purpose, and the second adds a crucial conditional. It is front-loaded, succinct, and free of unnecessary filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get tool, the description is adequate but sparse. It lacks any mention of the return value or business_id role, and without an output schema, the agent has no expectation of the response shape. The layout detail adds valuable context, but gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must clarify parameter meanings. It explains uid (the key) and layout (triggers an alternate endpoint), but business_id is entirely unaddressed. This partial compensation is helpful but incomplete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and resource ('bill by UID'), which is specific and distinguishes it from list/mutation siblings. The additional note about layout-specific endpoints further defines the tool's scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the purpose: retrieve a specific bill. However, there is no explicit guidance on when to prefer this over other get tools (e.g., myob_entity_get, myob_raw_get) or how the layout parameter should be chosen. The conditional about layout is a usage hint but lacks a recommendation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It discloses a critical behavioral trait—that the update is not immediately committed and requires approval first—which informs the agent that this is a non-destructive, staged operation. It does not mention return formats or other side effects, but the approval requirement is a significant and useful disclosure that goes beyond the raw tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, zero wasted words. The description is front-loaded with the core purpose and immediately adds the critical approval requirement. It is appropriately sized for the tool's function, being both concise and informative within its scope.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description omits essential context for a mutation-with-workflow tool. It does not explain how the approval step is initiated (e.g., via myob_approval_approve), how the prepared update is retrieved, or what happens to the update if approval is denied. The lack of annotations and parameter descriptions makes this description insufficient for an agent to fully understand the end-to-end flow of preparing, approving, and committing a bill update.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not compensate. It gives no explanation of what 'uid', 'json_body', 'layout', or 'business_id' mean in the context of updating a bill. The only hint is the phrase 'update of a purchase bill,' from which one might infer that 'json_body' contains changed fields and 'uid' identifies the bill, but this is left implicit. The description adds minimal value over the schema's property names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb+resource combination ('Prepare update of a purchase bill') that clearly distinguishes this from sibling tools like myob_bill_prepare_create (create vs. update) and read-only tools like myob_bill_get. It also notes the two-phase nature with 'Requires approval before commit,' reinforcing its unique role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for updating a purchase bill via the prepare/approve/commit workflow, and 'Requires approval before commit' provides a clear prerequisite. However, it does not explicitly mention when to use this tool over generic alternatives like myob_entity_prepare_update or myob_raw_prepare_mutation, nor does it mention exclusions. The usage context is clear but not explicitly framed against alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses the key behavioral trait that approval is required before commit, but does not elaborate on the preparation process, side effects, or error conditions. This is minimal but not misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, immediately front-loaded with the action, and no filler words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a free-form json_body and a two-phase prepare/approval/commit workflow, but the description only mentions approval. It doesn't explain what to do after preparation, how to find the required schema, or what the output means. The output schema exists but the overall workflow is under-specified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, and the description only mentions 'customer contact' which implies json_body contains customer data but provides no field-level guidance. business_id is entirely unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool prepares creation of a customer contact, which distinguishes it from sibling update/create tools. The phrase 'Requires approval before commit' also clarifies this is a preparatory step, not a direct creation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It implies the use case is to initiate a customer creation that needs approval, distinguishing it from direct commit operations. However, it does not explicitly name alternatives or the follow-up approval/commit tools, so usage context 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.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It indicates the token is 'stored' (implying state mutation) but does not disclose side effects like invalidating old tokens, network calls, authorization requirements, or failure outcomes. For a state-changing OAuth operation, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 13 words, front-loaded with the action ('Refresh') and including essential scope. Every word contributes value, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one optional parameter and no annotations or output schema. The description covers the core action and business scoping, but omits return behavior and preconditions (e.g., existing authorization token). This makes it adequate for basic invocation but not fully self-contained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description compensates by explaining that business_id optionally targets 'one business or the default business'. This gives meaningful semantics to the parameter beyond the bare schema, though it doesn't specify the ID format or accepted values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the verb 'refresh' with a specific resource 'stored MYOB OAuth access token' and scopes it to 'one business or the default business', clearly distinguishing it from sibling tools like myob_oauth_authorize or myob_oauth_logout. This is a specific verb+resource+scope structure.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for refreshing tokens as part of an OAuth flow but does not explicitly state when to use this tool vs alternatives, nor does it mention prerequisites or exclusions. It belongs to a lifecycle but this is not articulated, so usage is implied rather than explicitly guided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses that the tool 'mutates MYOB', warning of side effects, and requires a valid approval token, an auth requirement. However, it omits details about failure behavior, reversibility, or return values.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences front-load the action and every sentence adds value: the first states the operation, the second warns of side effects and the token requirement. No redundant filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no annotations and no output schema, so the description must be complete. It lacks information about the prepare→approve→commit workflow, error scenarios, and what the tool returns, making it inadequate for a mutation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate. It only references the approval token's validity but does not explain what operation_id refers to or how to obtain a valid token, leaving the agent with insufficient meaning for both parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('commit') and resource ('approved raw MYOB mutation'), clearly indicating the action. It also distinguishes from siblings like myob_commit_operation by specifying 'raw' and the need for approval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (after a raw mutation has been approved) and states a clear prerequisite ('requires a valid approval token'). However, it does not explicitly name alternatives or provide when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It reveals a critical behavior: this tool only prepares the request and delays any actual API call until later approval and commitment. It also implies an approval mechanism, which is key context. However, it doesn't disclose details about validation, request storage, or the exact meaning of 'approved' and 'committed' in relation to sibling tools.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of exactly two sentences, each earning its place. The first states the primary purpose, and the second adds a crucial behavioral constraint. There is no redundant wording or unnecessary repetition, making it well-structured and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the tool is complex (7 parameters, raw API access, two-phase workflow) and the description is too sparse. It does not explain the approval/commitment process, how to correlate with myob_raw_commit_mutation or approval tools, or what happens to the prepared request. It also lacks parameter guidance, making it incomplete for a tool of this scope.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds a little semantic meaning by restricting method to POST/PUT/PATCH/DELETE, but it provides no explanation of path, json_body, risk_level, business_id, or params. The parameter titles in the schema are thin, and the description does not clarify required values, defaults, or how they interact. This is a significant gap that the description fails to fill.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Prepare any MYOB POST/PUT/PATCH/DELETE request.' This is a specific verb+resource pair that distinguishes this raw mutation preparation tool from sibling read tools (myob_raw_get) and commit tools (myob_raw_commit_mutation, myob_commit_operation). It also differentiates from entity-specific prepare tools by emphasizing 'any' request.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool via the phrase 'does not call MYOB until approved and committed,' which indicates a preparation step in a larger workflow. However, it provides no explicit alternatives or exclusion criteria, such as 'use entity-specific prepare tools when available' or 'use this for endpoints not covered by other tools.' The guidance is implicit, not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
It discloses the approval requirement and the prepare-before-commit pattern, which are meaningful behavioral traits. Yet, with no annotations, the description carries the full burden and omits details about side effects, permissions, or what the preparation creates, leaving some opacity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short, direct sentences that front-load the core action and immediately follow with the critical approval caveat. Every word earns its place with no wasted content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with a free-form json_body parameter, the description is too sparse. It does not explain what data should go into the body, connect to the approval workflow tools (like myob_approval_list_pending), or indicate any prerequisites, leaving the overall workflow fragmented.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, and the description provides no parameter guidance. While 'json_body' and 'business_id' are somewhat self-explanatory, the free-form 'json_body' object lacks any structure or field hints, leaving agents to guess its contents.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('Prepare creation') and target resource ('supplier contact'), distinguishing it from update/delete and other entity-specific tools. It also adds the approval context, making the purpose immediately understandable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description conveys that this is a preparation step that requires approval before committing, which gives a clear usage context. However, it does not explicitly mention alternatives or when not to use it, though the sibling tool names provide some implicit differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description accurately describes the read-only nature via the verb 'List', but it does not disclose details like whether it requires authentication, what it returns if no businesses are authorized, or whether it has any side effects. With no annotations provided, the description carries the burden, and it only provides minimal behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is clear and front-loaded. It conveys the essential information without any filler, achieving high conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (no inputs, no output schema), the description is mostly complete: it names the resource and the scope. It could benefit from clarifying what the returned list contains (e.g., IDs, names) but this is not critical because the operation's purpose is obvious.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema coverage is 100% by default. The description doesn't need to explain any parameters, and the baseline of 4 applies. It adds no param information because there are none to add.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'List' with a clear resource ('MYOB businesses/company files') and a scope ('already authorised on this machine'). It distinguishes this tool from siblings like myob_company_list_files or myob_auth_status by emphasizing the authorization and local machine context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives. It does not mention situations where one would prefer this over myob_auth_status or myob_company_list_files, nor does it state any prerequisites or post-conditions. The usage context is only vaguely implied by the description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, this description carries the burden. The verb 'Show' indicates a read-only operation, but the description does not explicitly state that it avoids mutations, does not refresh tokens, or what happens if unauthenticated. It adds minimal context beyond the name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states the exact purpose without any filler. It is appropriately sized for a zero-parameter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple nature (no parameters, no output schema), the description is mostly complete, but it could clarify what 'status' includes (e.g., token expiry, selected business name) or confirm it does not perform any side effects. Still, it's sufficient for a status tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 logically has no parameter details to add, and the schema already covers everything (100% coverage).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Show') and names the exact resources: MYOB OAuth authentication, token, and selected business status. This clearly distinguishes it from sibling tools like OAuth flow tools or business management tools, which perform actions rather than report status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies its use as a status-checking tool but does not explicitly state when to use it relative to alternatives, nor does it mention any prerequisites or common contexts (e.g., checking auth before other operations).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the behavioral burden. 'Return' implies a safe read-only operation, and 'mutation policy' hints at important context, but it does not explicitly state that no changes are made, nor does it disclose any limitations or authentication requirements. The action is clearly read-only, so a 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that directly states the purpose without any filler words. It is concise and well-structured, earning a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is sufficient for a simple zero-parameter metadata tool. It states the return value ('catalog of major MCP tools and mutation policy') and format ('machine-readable'). No output schema exists, but the description gives enough context for an agent to understand what to expect, making it complete for the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the input schema is an empty object. The description does not need to explain parameters; the baseline of 4 applies. It adds value by describing what the catalog contains (mutation policy), which is not evident from the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'Return a machine-readable catalog of major MCP tools and mutation policy.' It specifies a distinct resource (catalog) and scope (major MCP tools and mutation policy), which differentiates it from siblings like myob_metadata_list_domains and myob_metadata_get_entity_schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for programmatic discovery of available tools and mutation policy, but it does not explicitly state when to prefer this over alternative metadata tools. No exclusions or alternative names are mentioned, though the context suggests this is the go-to for a high-level catalog.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the transparency burden. It adds scoping context ('supported by this MCP server') but does not disclose whether authentication is required, what the response format looks like, or any other behavioral details. The read-only nature is implied by 'List' but not made explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that communicates the tool's purpose with no wasted words. It is appropriately concise for a simple metadata listing tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, simple listing tool, the description is mostly complete: it states what is listed and the scope. However, it could further note that the returned domains are used as input for other metadata tools like myob_metadata_get_entity_schema, which would improve integration context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is an empty object with zero parameters, so no parameter explanations are needed. The description's mention of 'entity domains' adds no additional parameter semantics beyond the schema, but the baseline for zero-parameter tools is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists MYOB entity domains supported by the MCP server. It uses a specific verb ('List') and resource ('MYOB entity domains'), and distinguishes itself from siblings like myob_metadata_get_entity_schema and myob_metadata_get_tool_catalog by focusing on domains.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is used for discovering available domains, but it does not explicitly state when to use it versus alternatives, nor does it provide exclusions or references to sibling tools. Usage context is inferred from the tool's simplicity and name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses a destructive local action ('clear all stored tokens') and notes the scope ('from this machine'). However, it does not mention whether the server-side session is also invalidated or whether re-authorization is required afterward, leaving some behavioral ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the verb 'Clear', contains no filler words, and is appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter logout tool with no output schema, the description sufficiently conveys the core function. It could mention the resulting state (no tokens remaining) or next steps, but this is not critical for a simple clear operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description has no need to explain parameter semantics. Per the rubric, 0 parameters sets a baseline of 4, and the description correctly omits parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Clear'), the resource ('stored MYOB OAuth tokens'), and the scope ('from this machine'). It distinguishes itself from sibling OAuth tools like refresh or auth status by indicating a logout/clear operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you want to log out and clear stored credentials, but it does not explicitly say when to use this tool versus alternatives (e.g., myob_business_remove_authorization). No exclusion criteria or alternative tool references are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
GitHub Badge
Glama performs regular codebase and documentation scans to:
- Confirm that the MCP server is working as expected.
- Confirm that there are no obvious security issues.
- Evaluate tool definition quality.
Our badge communicates server capabilities, safety, and installation instructions.
Card Badge
Copy to your README.md:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/jaeko44/myob-codex-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server