EarlyLore

earlylore_save_note_or_evaluate

Save competitor insights or architecture decisions from your IDE back to your EarlyLore Notes (/notes), or start a new product idea evaluation task.

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": {
      "action": "<action>"
    },
    "name": "earlylore_save_note_or_evaluate"
  }
}

Input Schema

Name	Required	Description
`url`	No	Associated URL (optional for save_note; target website URL for start_evaluation)
`body`	No	Note body content (required for save_note)
`tier`	No	Evaluation model tier: standard (4-seat fast screening) or deep (8-seat Argon deep evaluation)
`title`	No	Note title (optional for save_note)
`action`	Yes	Action to perform: save_note or start_evaluation
`ideaText`	No	Product idea description to evaluate (required for start_evaluation)
`isPrivate`	No	Whether the evaluation is private to your account (default private)
`evaluationId`	No	Associated evaluation report UUID (optional for save_note)

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 12, 2026

TDQS

B3.2/5.0

Behavior2/5

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

With no annotations, the description carries the full behavioral burden and does not meet it. It does not say whether saving a note overwrites or appends, whether the evaluation is asynchronous and how results are retrieved, whether either action consumes credits, or whether authentication/workspace scoping is required.

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 compact sentence with the two actions front-loaded and no filler. It reads as a slightly run-on 'or' construction, but every clause carries information and nothing is redundant.

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

Completeness3/5

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

For a dual-action tool with 8 parameters, no annotations, and no output schema, the description covers the what but not the how or what-comes-back. An agent still lacks guidance on the lifecycle of a started evaluation and on save_note's write semantics, though the rich schema descriptions offset some of this.

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 the schema already documents all 8 parameters including enums (action, tier) and which fields belong to which action. The description adds only the '/notes' destination hint; it contributes no additional semantics about parameter interaction or defaults beyond the schema.

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?

The description names two concrete operations — saving notes to EarlyLore Notes (/notes) and starting a product idea evaluation task — which is more specific than the tool name alone and separates it from the read-only siblings (get_*, inspect_*, search_*). It is a compound tool, so the purpose is clear but bifurcated rather than a single crisp verb+resource.

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 usage through the two intents (save competitor insights / architecture decisions vs. start a new evaluation) but never states when to prefer one action over the other, nor any prerequisites or exclusions. No alternatives are mentioned, even though earlylore_get_evaluation exists as the natural follow-up to start_evaluation.

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

All EarlyLore tools Inspect

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

Need Help?