Skip to main content
Glama

Forge Engine

by app.forgeengine

get_design_document

Read-only

The WHOLE design as one readable document — Vision (+ Project DNA) → every System spec → reference notes, compiled deterministically from the current design. Read this to understand a project end-to-end instead of walking list_systems → get_system N times. Returns markdown plus the project version it was compiled from. Long designs come back PAGED — the header says 'part N of M', call again with page: N+1 for the rest. Pass for_summary: true to get the condensed projection instead (every system's Goal + Boundary, tables stripped, one page) — that is what you should summarize from.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pageNoWhich part of the full document to return (default 1). The header tells you how many parts there are.
project_idNo
for_summaryNoReturn the condensed summarization source (all system goals + boundaries, no tables) instead of the full document

TDQS

A4.9/5.0
Behavior5/5

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

Annotations already indicate readOnlyHint=true, and the description adds significant behavioral context beyond that: deterministic compilation, paging with 'part N of M' header and page parameter, inclusion of the project version, and the condensed summary projection mode. This fully discloses the tool's behavior.

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?

The description is concise but information-dense: it covers purpose, use case, return format, paging behavior, and summary mode in four sentences. Each sentence earns its place with no redundancy or irrelevant detail, and the front-loaded main purpose is immediately clear.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (paging, summary projections, deterministic compilation), the description covers all essential aspects. It mentions the return type (markdown + version), paging mechanics, and the condensed form, making it fully self-sufficient for an agent to select and invoke correctly.

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?

The schema already describes 'page' and 'for_summary', and the description adds deeper meaning (e.g., header indicates total parts, for_summary returns goal+boundary with tables stripped). The project_id parameter lacks schema description but is self-explanatory; overall the description compensates well for the 67% schema coverage.

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?

The description clearly specifies the tool's function: returning the entire design as a single readable markdown document compiled deterministically from the current design. It also distinguishes itself from siblings by explicitly contrasting with the alternative of walking list_systems then get_system repeatedly.

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?

It provides explicit context for when to use this tool: to understand a project end-to-end, and specifically recommends using for_summary:true for summarization. It also contrasts with the alternative approach of listing systems and fetching each one, giving clear guidance without ambiguity.

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

All Forge Engine toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.6/5.0
Disambiguation5/5

Each tool has a clearly distinct purpose, with explicit distinctions between direct actions and proposals via Inbox. The verbs and object types (system, milestone, screen, element, balance) are unique enough that no two tools appear to do the same thing.

Naming Consistency4/5

Most tool names follow a consistent verb_noun snake_case pattern (get_system, propose_screen, update_element). Minor deviations like 'dedupe', 'search', 'next_task', and 'reorder' are single words or non-verb but remain readable and stylistically compatible.

Tool Count1/5

With 54 tools, this server vastly exceeds the typical MCP scope, hitting the 'extreme mismatch' threshold. Even for a complex domain, the sheer number will overwhelm agents and degrade selection performance.

Completeness5/5

The tool surface is remarkably complete, covering full lifecycle operations for all major entities, plus import, design generation, drift detection, status reporting, inbox handling, and rejection workflows. No obvious dead ends or missing operations for the stated purpose.

Resources