Show organisation and workspaces
get_contextShow the authenticated organisation, access and up to 50 workspaces. Page with cursor.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| cursor | No |
Output Schema
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
get_contextShow the authenticated organisation, access and up to 50 workspaces. Page with cursor.
| Name | Required | Description | Default |
|---|---|---|---|
| cursor | No |
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections.
Input schema / properties / cursor / anyOfPrevious value: -[
- {
- "maxLength": 4096,
- "type": "string"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "maxLength": 65536,
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+]Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint=false and destructiveHint=false, so the safety profile is fully covered. The description contributes one genuinely useful behavioural detail — a 50-workspace cap with cursor paging — but says nothing about what happens past that cap or whether more results exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with the primary payload first and pagination second; nothing is padded. The word 'access' is slightly vague, but the text is otherwise efficient.
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?
An output schema exists, so return structure needn't be explained, and the description covers the key operational fact an agent needs (limit of 50, paginate via cursor). Minor gap: no mention of whether truncated results are signalled, but for a simple read-only context call this is close to sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% for the single 'cursor' parameter, so the description carries the burden. 'Page with cursor' does explain the parameter's purpose as pagination, which is more than the bare schema gives, but it doesn't state where the cursor comes from (presumably a prior response) or how to detect the last page.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description gives a concrete verb-and-resource set: it returns the authenticated organisation, its access, and up to 50 workspaces. That is specific enough for an agent to distinguish it from siblings like get_workspace_usage or list_datasets, though it doesn't explicitly contrast itself with any of them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no statement of when to call this versus alternatives, no prerequisites, and no exclusions. The agent must infer from the description alone that this is the context/bootstrap call for discovering the org and its workspaces.
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.