MCP tools
Unyform exposes tools to your coding agent through two separate channels, and this page catalogs both in full.
- The standalone MCP server (the
unyform-mcpbinary you register with your editor) publishes 12 tools the agent calls on demand — "search the blueprints," "check this policy." See the MCP server guide for installation and registration. - The gateway injects 7 managed tools (the
_gw_*family) into model requests automatically whenever blueprints are attached. The agent never sees these in its own tool list; the gateway intercepts the calls, runs them against your org's database, and feeds results back before the next model round. See Context injection.
Note
Live means the tool calls the backing API or database and returns real data. Stub means it returns a fixed "not yet available" placeholder — the schema is published so agents can discover it, but the implementation is pending.
Standalone MCP server tools
Registered via unyform-mcp, these 12 tools span four groups. Every tool returns
a text result; parameters and required-ness are taken verbatim from the tool's
published JSON Schema.
Blueprint tools
Use these to pull your org's coding standards into the agent's context — search the blueprint catalog, fetch a specific blueprint (or one section of it), or get the org's conventions compiled to markdown for the file you're editing.
| Tool | Parameters | Returns | Status |
|---|---|---|---|
search_blueprints | query: string (required); context: string (optional) | Blueprints (id, name, description) whose name or description match the query, scoped to your org, as pretty-printed JSON. The context parameter is accepted but not used by the current backend call. | Live |
get_blueprint | id: string (required); section: string (optional) | The full blueprint by id, or — when section is passed — just that named section, as JSON. | Live |
get_conventions | file_path: string (required) | The org's conventions compiled to markdown (naming, structure, testing, style). file_path is required but the returned conventions are org-wide, not file-specific. | Live |
Policy tools
Use these to check work against your org's policies before or after the agent produces it — ask whether an action is allowed, validate a file's content against blueprints and policies, or list active policies.
| Tool | Parameters | Returns | Status |
|---|---|---|---|
check_policy | action: string (required); content: string (required) | A text decision: Decision: ALLOW or Decision: BLOCK, plus the reason and matched policy names. The schema advertises ALLOW, WARN, or BLOCK, but the handler currently maps the API's allowed/blocked result to ALLOW or BLOCK only. | Live |
validate_output | file_path: string (required); content: string (required) | Pass/fail validation of the file against blueprints and policies, as JSON, with each violation's rule, message, severity, and suggestion. | Live |
get_policies | (none) | A fixed JSON placeholder: an empty policies array and a message directing you to check_policy. No dedicated listing endpoint exists yet. | Stub |
Steering tools
Use these to keep a human (and the audit trail) in the loop — request approval before a risky action, report a completed action for logging, or get convention-framed guidance for a task you're about to start.
| Tool | Parameters | Returns | Status |
|---|---|---|---|
request_approval | action: string (required); rationale: string (required) | A text acknowledgement that the request was logged, with guidance to proceed with caution. Routing to a real approval workflow happens only if your org has one configured. | Live |
report_action | action: string (required); result: string (required) | A text acknowledgement that the completed action was logged for the audit trail. | Live |
get_guidance | task_description: string (required) | The task description wrapped together with your org's conventions (fetched live) as actionable guidance. Falls back to general best-practice guidance if conventions can't be retrieved. | Live |
Context tools
These would surface ecosystem-level context — architecture overviews, module structure, recent decisions. All three are stubs today: they return a descriptive "not yet available" message listing what they will eventually provide.
| Tool | Parameters | Returns | Status |
|---|---|---|---|
get_ecosystem_context | repo: string (optional) | A fixed "not yet available" message describing the future payload (architecture overview, key patterns, dependency graph, tech stack). | Stub |
get_architecture | path: string (optional) | A fixed "not yet available" message describing the future payload (module structure, dependencies, interface contracts, data flow). | Stub |
get_recent_decisions | (none) | A fixed "not yet available" message describing the future payload (recent ADRs, design-change history, migration plans, deprecation notices). | Stub |
Gateway-injected managed tools
The gateway appends these 7 _gw_* tools to a model request only when the
runtime config has blueprints attached. The model may call them to browse
blueprints and codebase conventions; the gateway executes each call against the
blueprints / blueprint_versions tables, returns the result as a role: tool
message, then strips both the _gw_* calls and their definitions before the
final response reaches you. You never register or see these directly.
Warning
These tools are internal. The _gw_ prefix is reserved — the
gateway routes anything starting with it through this managed path and removes it
from end-user-visible output. Do not define your own tools with this prefix.
Blueprint discovery tools
The model uses these to find and read blueprints it was told are available, so it can ground its output in your actual conventions rather than guessing.
| Tool | Parameters | Returns | Status |
|---|---|---|---|
_gw_search_blueprints | query: string (required) | JSON { "blueprints": [...] } — up to 10 blueprints (id, name, description) matching the query via ILIKE, scoped to the org. | Live |
_gw_get_blueprint | blueprint_id: string (required) | JSON { "name", "content" } — the blueprint's name and latest-version content (graph adapter fills content when the JSON column is empty). | Live |
_gw_get_blueprint_section | blueprint_id: string (required); section: string (required) | JSON for the requested top-level key of the blueprint content; on a miss, an error plus available_sections. | Live |
Codegraph idiom tools
Idioms name the canonical symbol for a given purpose ("the way we format a date here"). The model uses these before writing new code so suggestions match the codebase instead of generic stdlib snippets.
| Tool | Parameters | Returns | Status |
|---|---|---|---|
_gw_codegraph_list_idioms | blueprint_id: string (required); family: string (optional) | JSON { "count", "idioms" } — up to 100 idioms ordered by adoption desc, optionally filtered by family (e.g. hook, component, util, error, data, service). Pulled from content.idioms. | Live |
_gw_codegraph_idiom_lookup | blueprint_id: string (required); purpose: string (required) | JSON { "matches" } — the top idioms whose purpose/family best match the free-form purpose (substring-fuzzy, adoption-weighted); an error + hint when nothing scores high enough. | Live |
Codegraph pattern tools
Patterns describe conventions — error handling, naming, structure, testing, security — with examples and rules. They mirror the idiom tools but return convention text rather than a canonical symbol.
| Tool | Parameters | Returns | Status |
|---|---|---|---|
_gw_codegraph_list_patterns | blueprint_id: string (required); category: string (optional) | JSON { "count", "patterns" } — up to 100 patterns ordered by adoption desc, optionally filtered by category slug (error_handling, naming, structure, api_design, testing, documentation, security). Returns a hint when no analysis exists yet. | Live |
_gw_codegraph_pattern_lookup | blueprint_id: string (required); name_or_id: string (required) | JSON { "matches": [pattern] } — a single pattern matched by exact UUID id or case-insensitive name, with its full convention text, examples, and rules; an error + hint on a miss. | Live |