Skip to main content
Glama
Sign In
myob-mcp

myob-mcp

by cotlet-connect
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

myob_close

Close the MYOB browser session when work is finished so credits stop running. Use it after completing invoice, bill, or payment tasks to end the automated session.

Instructions

Close the MYOB browser session when the work is done, so credits stop running.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "myob_close"
  }
}

Input Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.1.0

TDQS

A4.2/5.0
Behavior3/5

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

With no annotations supplied, the description carries the full behavioral burden. It usefully discloses the cost consequence ('credits stop running'), which is the key side effect of a terminate action, but it never says that the session ends and subsequent myob_click/myob_read calls will fail until myob_open is called again, nor whether unsaved browser state is lost.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single sentence, front-loaded with the action and followed by the reason, with no filler or redundancy. Every clause earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter, no-output-schema tool this is nearly complete: the action and its motivation are stated. The only meaningful gap is the post-close state (session terminated, must re-open before further browser actions), which an agent would need to sequence calls correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes zero parameters, so there is nothing for the description to clarify beyond the schema; the baseline of 4 applies. The sentence does not introduce any parameter-like confusion.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description gives a specific verb and resource ('Close the MYOB browser session') plus the rationale ('so credits stop running'). It is unambiguously distinct from the sibling actions like myob_open, myob_click, and myob_read, so an agent can pick it without opening any schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It states a clear trigger condition: close when 'the work is done.' That is real when-to-use guidance, but there is no when-not guidance (for example, do not call while a read or click sequence is still pending) and no named alternative beyond the implicit myob_open.

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

Deploy Server

Other Tools