Skip to main content
Glama
Sign In

Grafizum Command Center

by com.grafizum
OverviewDiscussionsAdmin

Declare the project, or set the sync mode

configure_connection
Idempotent

Set up THIS connection, in one of two ways. Pass project_id with the folder or repository you are working in to declare where this session works: the server checks the evidence, remembers the binding, and checks every write against it. Pass mode ("auto" or "manual") instead to choose whether the connection keeps the dashboard current automatically or only when the owner asks. Exactly one of them per call.

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

Input Schema

NameRequiredDescriptionDefault
modeNoSet how this connection syncs; do not combine with project_id.
folderNoThe folder you are working in, as evidence for project_id.
reasonNo
project_idNoThe project this session is working on; pair it with folder or repository as evidence.
repositoryNoThe repository you are working in, as evidence for project_id.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already cover the safety profile (not read-only, idempotent, non-destructive), and the description still adds real behavior: the server validates the supplied evidence, persists the binding, and thereafter checks every write against it. Manual mode is also explained as owner-triggered syncing. What happens on failed evidence validation or insufficient permissions is left unstated.

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?

Three sentences, each doing distinct work: the two paths, then the exclusivity constraint last where it acts as a checklist. No filler and no restatement of the title or name.

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-required-parameter, five-field mutation tool with annotations covering safety, the description adequately explains intent, the two usage paths, and the exclusivity rule. Loose ends remain: the free-text 'reason' field is never explained, and with no output schema the agent gets no hint about what a successful configuration returns or confirms.

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 80% schema coverage the baseline is 3, and the description earns above that by defining the enum meanings the schema leaves bare ('auto' keeps the dashboard current, 'manual' waits for the owner) and by explaining that project_id must be paired with folder or repository as evidence. It omits any explanation of the 'reason' parameter, which the schema also leaves undocumented.

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

Purpose4/5

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

States a specific action (configure THIS connection) and enumerates its two distinct behaviors: binding this session to a project, or selecting a sync mode. An agent can tell it is a session-level configuration tool distinct from sibling read/query tools, though no sibling is named to sharpen the boundary.

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?

Gives a clear trigger for each branch (pass project_id + evidence to declare the workspace; pass mode to control dashboard syncing) and an explicit mutual-exclusion rule: 'Exactly one of them per call.' It does not name an alternative tool for related needs (e.g. reading the current binding), so there is no explicit when-not guidance.

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

All Grafizum Command Center toolsInspect
Try in Browser
Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources