Skip to main content
Glama

Read the current space's global instructions before every new task

space_instructions_get
Read-only

Read the current space's global instructions before every new task

GET /api/v1/space-instructions

For multi-space accounts, call auth_verify, ask the user which space to use, and pass targetSpaceId. Space instructions are shared team background and default preferences: vision, mission, values, and design style. Read the latest version before each new task; the current user's explicit request takes precedence and this content never grants permissions or authorizes approving or merging change requests. Updating these settings requires workspace management access and the current expectedVersion. Change them only when the user asks; a conflict means reload and reconcile rather than overwrite.

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": "space_instructions_get"
  }
}

Input Schema

NameRequiredDescriptionDefault
targetSpaceIdNoBusabase space id. Call auth_verify first and ask the user which space to use when more than one is returned.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already mark this as a safe read, and the description adds substantial context beyond them: the content never grants permissions or authorizes approving/merging change requests, and updates require workspace management access and the current expectedVersion, with conflicts to be reconciled rather than overwritten. These are real behavioral guardrails an agent could not infer from readOnlyHint/destructiveHint.

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

Conciseness4/5

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

The read purpose and timing are front-loaded, and sentences carry information about auth, precedence, and update constraints. It runs slightly long for a single-parameter read tool because update semantics are folded in, but the material is not padding.

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 read-only, zero-required-parameter tool with no output schema, the description covers timing, space selection, precedence, and permission limits. Only the shape of the returned instruction content is left implicit, which is acceptable given it is a simple fetch.

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?

With one optional parameter at 100% schema coverage, the schema already documents targetSpaceId and the auth_verify workflow. The description restates the multi-space rule and connects the id to a space selection decision, adding modest but real routing value.

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?

States a specific verb and resource ('Read the current space's global instructions') plus the exact endpoint GET /api/v1/space-instructions. It is clearly distinct from the sibling space_instructions_update, which the description also references as the mutating counterpart.

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

Usage Guidelines5/5

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

Gives explicit timing ('before every new task'), a multi-space procedure (call auth_verify, ask the user, pass targetSpaceId), and a precedence rule (the user's explicit request wins over stored instructions). It also names the when-not for changes: only when the user asks, and only with management access plus expectedVersion.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.