Lists the organisations this connection reaches: URL name (slug), name, plan and billing state. Call it first. Its grant says what the connection may do: a connection signed in through OAuth acts as one person in the one organisation they chose at sign-in, read only or read and write; an API key belongs to one organisation.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections.
No schema history has been recorded yet.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations supplied, the description carries the full burden and delivers: it explains that the connection's grant determines scope, distinguishing OAuth sign-in (one person, one organisation, read-only or read-write) from API key (one organisation). The access-level semantics are exactly the kind of context an agent cannot get from structured fields. It does not mention result size or pagination, a minor gap for an unbounded list.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with the operation and its return fields, then the call-order instruction, then the access model. No filler. The final sentence about API keys is slightly compressed but still earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter list tool with no output schema, the description covers what comes back, when to call it, and what governs the result set. The only omission is anything about result cardinality or ordering, which is minor here.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so the baseline is 4 and the description correctly does not waste words on nonexistent inputs. It instead spends that space on the grant semantics, which is the right allocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Opens with a specific verb and resource ("Lists the organisations this connection reaches") and enumerates the returned fields: slug, name, plan and billing state. The plural scope distinguishes it cleanly from the sibling get_organisation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
"Call it first" gives explicit sequencing guidance that no sibling tool provides, which is genuinely useful for orienting an agent. It stops short of saying when not to call it or pointing at get_organisation for detail, so it is strong but not exhaustive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
