Anakin

Official

Overview Schema Source Related Servers Discussions Admin

wire_build

Destructive

Create and publish new scraper actions for sites missing from the catalog. Provide URL and goal; optionally add actions, country, or login credentials. The scraper is auto-tested before release.

Instructions

Request brand-new Wire actions for a website that isn't in the catalog yet — a full catalog build. Describe the site (website_url) and what to build (goal); optionally list the discrete capabilities as actions (each becomes its own action), pin the proxy exit country, and attach a login credential to build actions behind a sign-in. Wire generates and auto-tests the scrapers, then publishes them. Asynchronous — the response's build_request carries an id and status "pending"; when it completes, its skipped list names anything the build could not deliver. Charges credits (login builds cost significantly more than public builds), refunded automatically if the build fails. Track progress with wire_build_status. Only use this after wire_discover / wire_catalog confirm no existing action covers the site.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`goal`	Yes	Natural-language description of what the action should do or extract. Be specific — the builder synthesizes the scraper from this.
`force`	No	Build even if similar actions already exist for the domain (otherwise the request is rejected with ACTION_EXISTS).
`actions`	No	Optional list of discrete capabilities to build, each as its own action (e.g. ["search products", "get product details"]). Omit to let the builder infer them from `goal`.
`country`	No	Optional 2-letter country code (e.g. "US") — the scraper is built and tested through an exit IP in that country. Use when the site geo-gates its content.
`catalog_id`	No	Optional — attach to an existing catalog instead of creating one.
`credential`	No	Optional login credential, for building actions behind a sign-in (a login build — costs significantly more credits than a public build). Plain shape: { type: "plain", username, password }. Vault shape (an entry in a connected 1Password/Azure identity source): { type: "vault", source_id, source_ref }. Either shape may add `login_url` when the login form lives somewhere other than website_url. The password is used once by the builder to sign in and is never stored.
`visibility`	No	Action visibility. Defaults to private.	private
`website_url`	Yes	The site to build an action for. The domain is extracted automatically.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`status`	No	"ok" on acceptance.
`build_request`	No	The created build request — its `id` and `status` ("pending") track the asynchronous build; once finished, `skipped` names anything the build could not deliver.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.4.1Sep 22, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Beyond the annotations (destructiveHint, openWorldHint), the description reveals critical behaviors: it is asynchronous, returns a build_request with an id and 'pending' status, lists skipped items on completion, and mentions credit charges with automatic refunds on failure. It also discloses that login builds cost more. This is rich, non-obvious information that annotations alone do not convey.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is longer than average but earns its length given the tool's complexity (8 parameters, nested credential object). It front-loads the primary purpose and then logically covers parameters, async behavior, cost, and usage condition. Each sentence adds information; there is no redundancy. A slightly tighter structure would be ideal, but it remains efficient.

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?

With an output schema present, return values are already specified. The description covers the essential context: when to use (after discovery), async nature, tracking via build_status, credit implications, refund policy, and the skipped list on failure. It also explains the credential variations and the force flag. Nothing an agent needs to invoke this tool correctly is missing.

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?

Schema coverage is 100%, so parameters are already documented. The description adds meaningful semantics: for goal it notes 'the builder synthesizes the scraper from this,' for actions it says 'each becomes its own action,' for country it explains 'built and tested through an exit IP in that country,' and for credential it details the plain/vault distinction and that passwords are never stored. This goes beyond the schema, though the schema already carries the definitions.

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 opens with a precise purpose: 'Request brand-new Wire actions for a website that isn't in the catalog yet — a full catalog build.' It names the verb (request/build), the resource (Wire actions), and the condition (not in catalog). It explicitly distinguishes itself from siblings by referencing wire_discover / wire_catalog as prerequisites, making the tool's role unmistakable.

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?

The description gives explicit when-to-use guidance: 'Only use this after wire_discover / wire_catalog confirm no existing action covers the site.' It also directs the agent to track progress with wire_build_status and notes that similar existing actions cause rejection unless force is set. This provides clear context for choosing this tool over alternatives like wire_discover or wire_read_action.

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