Storskarvia

Reviewed 1h ago.

• tools: 10 tools scanned
• metadata: scanned

• mediumReviewRemote tools take credentials as input

  Whatever an agent passes to a remote tool leaves the machine. Never send connection strings, tokens or passwords to a third-party MCP server unless it is the service those credentials belong to.

  list_my_projects, prepare_factcheck, ground_claim

Tools (10)

• get_skarvia_info

  What Storskarvia is and how it's positioned. A professional writing studio for novelists, screenwriters, and video scriptwriters, staffed by an AI team that fact-checks, researches, and tracks continuity -- but never writes the user's prose for them.

• list_features

  The AI staff on Storskarvia and what each member actually does. Source: the "On staff" section of the current landing page.

• get_pricing

  Current Storskarvia pricing tiers, features, and monthly fact-check quotas. Built from config.PLANS, the same list /pricing renders from, so this can no longer drift from the page the way it did while it was kept by hand. The founder block is read live rather than described in prose. The note here used to say payments "aren't enabled yet" unconditionally, which went on being served after they were switched on, and the tiers listed full price while every human-facing surface offered a founding seat at half of it. An agent asked what Storskarvia costs answered with a price nobody was being charged and omitted the one on offer.

• list_guides

  Titles, slugs, and URLs of Storskarvia's evergreen craft/how-to guides. Reads the live GUIDES list straight from app.main (imported lazily -- see the comment on the import below) so this can never drift out of sync with what's actually published at /guides.

• get_guide

  Summary and URL for one guide, looked up by slug. Call list_guides first to get valid slugs.

• list_my_projects

  The authenticated user's Storskarvia projects (novels, screenplays, video scripts), each with the id, title and binder folder of its documents in binder order. A document id is what prepare_factcheck and submit_findings take. Requires a personal Storskarvia API key as a Bearer token.

• get_findings

  Findings for one of the authenticated user's fact-check or continuity runs. Ownership is enforced -- a check_id belonging to another user raises an error rather than leaking their data.

• prepare_factcheck

  Step 1 of a bring-your-own-agent fact-check. Fetches one of the authenticated user's documents (ownership enforced) plus the exact disclosure and method your agent MUST follow. Requires a personal Storskarvia API key as a Bearer token. After this, call ground_claim(claim) once per checkable claim you extract from `text`, then submit_findings(...) to store results.

• ground_claim

  Step 2 of a bring-your-own-agent fact-check. Runs Storskarvia's own server-side retrieval (Wikipedia + searxng) for one claim and returns the sources -- no verdict, no judgment. Your agent should judge the claim ONLY against these returned sources, never outside knowledge. Requires a personal Storskarvia API key as a Bearer token (this is not an open retrieval API).

• submit_findings

  Step 3 of a bring-your-own-agent fact-check. Stores your agent's findings as a real Storskarvia Check, visible on the same findings punch list as a staff-run check. Requires a personal Storskarvia API key as a Bearer token, and ownership of `document_id` is enforced. `disclosure` must be REQUIRED_DISCLOSURE copied verbatim -- proof the user was shown it before findings were presented -- or this raises a ToolError instead of storing anything. Each item in `findings` must have a non-empty quote/explanation, problem in {"contradicted","misleading"}, and a non-empty sources list; findings missing any of those are rejected wholesale (nothing partial is stored).