Syncretica MCP Server

generate_myth_embedding

Calculates a 1024-dimensional vector embedding for a myth record, enabling AI agents to compare, cluster, or search myths by vector similarity.

Instructions

Calculate 1024-dimensional vector embedding for a myth record.

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": {
      "id": "<id>"
    },
    "name": "generate_myth_embedding"
  }
}

Input Schema

Name	Required	Description	Default
`id`	Yes	Myth ID
`sync`	No	If true, wait synchronously for embedding generation to finish

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.0.0Nov 13, 2026

TDQS

C2.9/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full disclosure burden, and it says nothing about side effects (whether the vector is written to the myth record), idempotency or re-generation cost, rate limits, or what a caller gets back. The 1024-dimension detail is genuinely useful, but for an embedding-generation call with zero annotation coverage, the remaining behavioral gaps are large.

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?

One sentence, front-loaded with the action and the key output attribute. Nothing is wasted, but the terseness leaves obvious questions unaddressed rather than the sentence being padded.

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

Completeness2/5

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

With no annotations and no output schema, the description must explain the sync=false behavior (does it return a job handle? must the caller poll?) and the persistence/side-effect model, and it does neither. For a tool whose only real decision point is the boolean async flag, that gap matters.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so both 'id' and 'sync' are already documented in the schema, including the default. The description adds the embedding dimensionality but no meaning for either parameter. Baseline 3 is appropriate when the schema does the work.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

Names a specific verb and resource ('Calculate 1024-dimensional vector embedding for a myth record'), and the 'myth' qualifier separates it from the sibling 'generate_god_embedding'. The purpose is unambiguous, though it doesn't state whether the embedding is persisted or merely computed.

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

Usage Guidelines2/5

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

No guidance on when to call this instead of alternatives, no mention of prerequisites (must the myth exist? must it be changed?), and no mention of 'get_job_status' for the sync=false path despite that being an obvious follow-on in this catalog.

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