Skip to main content
Glama
Sign In
olostep-mcp

olostep-mcp

by olostep
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Answers

answers
Read-onlyIdempotent

Retrieves a factual answer from live web pages and returns it with source URLs, optionally shaped as a flat JSON object of requested fields.

Instructions

Use this when the user asks a factual question the live web can answer in a sentence or a few fields, such as a company's founding year, a CEO's name or a product's current price. Searches and reads the pages itself and returns the answer with its source URLs, optionally as a flat JSON object of the fields you list in json. For a list of items from one page (latest blog posts, a price table), call scrape_website on that page instead.

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": {
      "task": "<task>"
    },
    "name": "answers"
  }
}

Input Schema

NameRequiredDescriptionDefault
jsonNoOptional shape for the answer: a flat JSON object of the fields you want. Example: { "book_title": "", "author": "", "release_date": "" }. Keep it flat. Deeply nested shapes or long lists are unreliable.
taskYesQuestion or task to answer using web data.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv1.0.21
    • removedInput schema / $schema
      Removed value: -"http://json-schema.org/draft-07/schema#"
    • changedInput schema / properties / json / description
      Previous value: -"Optional JSON schema/object or a short description of the desired output shape. Example object: { \"book_title\": \"\", \"author\": \"\", \"release_date\": \"\" }"New value: +"Optional shape for the answer: a flat JSON object of the fields you want. Example: { \"book_title\": \"\", \"author\": \"\", \"release_date\": \"\" }. Keep it flat. Deeply nested shapes or long lists are unreliable."
  2. Addedv1.0.0

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already declare readOnly, openWorld, idempotent and non-destructive, so the safety profile is covered. The description still adds real context: the tool performs its own searching and page reading, returns answers paired with source URLs, and warns that deeply nested JSON shapes or long lists are unreliable — a genuine behavioral limitation. It does not mention latency or per-call limits, keeping it short of a 5.

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?

Three sentences, front-loaded with the use case, then the return behavior, then the sibling redirect. No filler and no repetition of annotation data.

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?

With only two parameters and no output schema, the description carries the return-value burden and does it: answer text plus source URLs, optionally shaped as flat JSON. Minor gaps remain about how multiple sources are presented and whether long answers are truncated.

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 explains both `task` and `json` thoroughly — including the flatness warning, which the description largely echoes. The only added meaning is the implicit scoping of what `task` should contain (a question answerable in a sentence or a few fields), which is modest.

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+resource: it answers factual questions by searching and reading live web pages, and returns the answer with source URLs. It explicitly contrasts itself with scrape_website for list-from-one-page tasks, so an agent can route correctly without opening either schema.

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

Usage Guidelines5/5

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

Gives a concrete when-to-use condition ('a factual question the live web can answer in a sentence or a few fields', with examples like founding year, CEO name, current price) and names the alternative tool plus the condition that selects it (lists from one page → scrape_website).

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

Deploy Server

Other Tools