TypeWriter MCP

add_entry

Add an entry to a Typewriter page by providing fields with name and type. Supports dialogue, speaker, and fact types, with id generated automatically.

Instructions

Add an entry to a page. fields = raw Typewriter entry JSON (needs 'name' and 'type'; id is generated). Common types: spoken_dialogue, option_dialogue, simple_speaker, permanent_fact.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "page": "<page>",
      "fields": "<fields>"
    },
    "name": "add_entry"
  }
}

Input Schema

Name	Required	Description	Default
`page`	Yes
`fields`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv2.0.0Aug 14, 2026

TDQS

A4/5.0

Behavior3/5

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

With no annotations, the description carries the burden of disclosing behavior. It adds useful facts: fields must contain 'name' and 'type', and 'id' is generated automatically. However, it does not mention permissions, success/error behavior, or any side effects beyond adding an entry. The transparency is partial.

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 two sentences, front-loaded with the core purpose, and the second sentence packs essential parameter details and common types without waste. Every word earns its place; no filler or repetition of the name/title.

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

Completeness4/5

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

For a two-parameter tool with one complex object, the description covers the critical details needed to construct a valid request: the fields parameter structure and supported types. However, it is quiet on return value/response and page reference ambiguity, making it slightly incomplete for an agent needing to invoke it correctly in all cases.

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 description coverage is 0%, so the description must explain parameters manually. It does well for 'fields' by describing the raw JSON format, required keys, and auto-generated 'id'. However, 'page' is left as a bare string with no explanation of whether it expects a page name or ID, a notable under-specification for one of two parameters.

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 states the tool's function with a specific verb ('Add') and resource ('an entry to a page'). It distinguishes itself from sibling tools like update_entry, replace_entry, and delete_entry by explicitly being the 'add' operation, with no ambiguity.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies the tool is used to create new entries on a page, and the list of common types suggests appropriate use cases. However, it does not explicitly say when to avoid this tool (e.g., for updates use update_entry) or name any alternatives. This is a clear gap for a tool with related siblings.

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

Deploy Server