get_diagramFetch the current state of an existing CodePic diagram. Returns a compact summary of all elements with their IDs, types, positions, and parent-child relationships. Use this before update_diagram when you need to: add nested children to existing containers, make targeted edits to specific elements, or understand the current structure. Requires API Key authentication.
| Name | Required | Description | Default |
|---|---|---|---|
| documentId | Yes | Document ID to fetch |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries the full burden. It discloses return content (compact summary with IDs, types, positions, relationships) and the authentication requirement, which are valuable behavioral details. Not quite a 5 because it lacks mentions of error handling or exact response structure, but for a simple getter it is strong.
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, each contributing purpose, usage scenario, and auth requirement respectively. No fluff, well-structured and front-loaded.
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 single-parameter getter with no output schema, the description explains what is returned and when to use it. It is nearly complete, though it could mention whether the operation is safe/read-only explicitly, but given no annotations, this is already decent.
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 schema already fully describes the only parameter (documentId) with 100% coverage. The description does not add additional meaning about the parameter, so it remains at the baseline of 3.
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 clearly states the tool fetches the current state of an existing CodePic diagram, using a specific verb ('Fetch') and resource. It distinguishes itself from siblings like create_diagram and update_diagram by focusing on reading an existing diagram.
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?
Explicitly says 'Use this before update_diagram when you need to: add nested children...' providing concrete scenarios and naming the alternative tool. This gives clear when-to-use guidance.
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.
Each tool has a distinct purpose: create, get, update, list templates, and get shape documentation. No overlapping or ambiguous functions.
All tool names follow a clear verb_noun pattern (create_diagram, get_diagram, get_shape_docs, list_templates, update_diagram), with consistent use of underscores and action-first naming.
The tool count (5 listed, though count says 6) is well within the typical 3–15 range for this domain, providing a focused set without unnecessary bloat.
The set covers create, read, and update operations, but lacks a delete tool and a way to list all diagrams (only templates are listed). This leaves gaps in the lifecycle coverage, though the core diagram creation workflow is supported.