get_shape_docsReturn the full CodePic shape reference — all element types, their fields, data payloads, and JSON examples. Call get_shape_catalog first for concise shape selection and container capabilities; use this tool when you need complete fields or type-specific data (e.g. select options, triangle direction, callout tail). No authentication required.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full disclosure burden. It adds a useful behavioral detail ('No authentication required') and describes what will be returned. It does not mention response size or formatting, but this is a low-risk read-only documentation lookup.
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 concise sentences with no filler: purpose is front-loaded, sibling routing is second, and authentication is last. Every sentence contributes actionable information.
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?
With no parameters, no output schema, and no annotations, the description still tells the agent what the tool returns, when to use it versus get_shape_catalog, and that no auth is needed. Nothing essential is missing for invoking this documentation tool correctly.
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 has zero parameters, so there are no parameter semantics for the description to clarify beyond the schema. The baseline of 4 applies because parameter description is unnecessary here, and the description adds value by explaining the kind of content returned.
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 states a specific verb ('Return') and a clear resource (the full CodePic shape reference), listing what it contains: element types, fields, payloads, and JSON examples. It also differentiates itself from the sister tool get_shape_catalog by highlighting full versus concise reference material.
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 tells the agent to call get_shape_catalog first for concise selection and container capabilities, and to use this tool when complete fields or type-specific data are needed. This is clear routing between siblings with concrete examples.
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.