Skip to main content
Glama
Sign In

krobot

by io.github.Kromatic-Innovation
OverviewDiscussionsAdmin

Search resources

search_resources
Read-onlyIdempotent

Find the Kromatic method, example or template that fits the user's situation, such as checking demand for a feature before building it, testing whether people will pay a given price, getting first paying commitments before launch, or deciding whether to keep funding a project.

Method names rank far better than everyday wording, so include them: "fake door test", "pre-sales test", "sales pitch test", "concierge test", "pivot or persevere". If you are unsure which method fits, search {"query": "Index of Questions", "source_keys": ["real_startup_book"]}. Returns up to 20 ranked excerpts (limit, default 5), each with document_title, canonical_url, resource_type and document_external_key. These are excerpts, not whole pages. No sign-in needed.

Next: call read_resource with the best result's document_external_key.

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": {
      "query": "<query>"
    },
    "name": "search_resources"
  }
}

Input Schema

NameRequiredDescriptionDefault
limitNoNumber of excerpts, 1 to 20 (default 5).
queryYesWhat to find. Include method names where you can (see the tool description).
source_keysNoOptional. Only these sources: real_startup_book (method pages), blog_content (Kromatic blog), learning_library (courses, lessons, templates, MCP Server and Skill entries), tools_and_games.
resource_typesNoOptional. Only these types. Book Section = a method page of The Real Startup Book. Download = a template or worksheet; Download File = one file inside it. Tool = the full guide text for one of Kromatic's interactive web apps (e.g. Experiment Calculator, Startup Poker); Tools / Games = the website's link entry for the same apps, with less text. Prefer Tool when you want content.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already declare a read-only, idempotent, closed-world, non-destructive operation, so the bar is low, yet the description adds real substance: max 20 ranked excerpts with a default limit of 5, the exact return fields, the caveat that these are excerpts rather than whole pages, and that no sign-in is required. It also discloses the ranking heuristic (method names rank better than everyday wording), which is genuine behavioral insight.

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?

Front-loaded with purpose and use situations, then retrieval strategy, then a clear next step. Three compact paragraphs with no filler; the example method names are functional vocabulary rather than padding.

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?

No output schema exists, but the description names the returned fields (document_title, canonical_url, resource_type, document_external_key) and clarifies excerpts vs. full pages, so an agent knows exactly what it gets and what to do next. Nothing needed to invoke it 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 parameter meaning is largely already supplied, but the description adds query-formulation strategy ("Method names rank far better than everyday wording" plus a list of example method names) and a worked example combining query with source_keys. It adds little for limit or resource_types beyond what the schema enumerates.

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?

States a specific verb and resource ("Find the Kromatic method, example or template") and grounds it with four concrete user situations (demand check, price test, pre-sales, funding decision). That framing makes it immediately distinguishable from list_resources (enumeration) and read_resource (full page retrieval).

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

Usage Guidelines4/5

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

Gives explicit usage context and a fallback path: if unsure which method fits, run the "Index of Questions" query scoped to real_startup_book. It also routes onward ("Next: call read_resource with the best result's document_external_key"). The only gap is that it never states when to prefer list_resources or download_resource instead.

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

All krobot toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources