Atlantic Agentic Labs

Search the LightHouse documentation

search_docs

Read-onlyIdempotent

Search Atlantic's public LightHouse™ documentation, including the API reference (OpenAPI) and the MCP tool reference. Use it for any question about what LightHouse does and how: connectors, agents, approvals, spend limits, evidence, security, deployment, the API, the MCP server and the CLI. Returns up to limit passages, best first, each quoted exactly with a deep link (url), the docs version and build date; covered is false when the documentation does not answer the query. Quote the passages and cite their links; for the whole page call read_page with the link. Read only: no answer is generated and nothing is changed.

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_docs"
  }
}

Input Schema

Name	Required	Description	Default
`limit`	No	How many passages to return (1 to 8).
`query`	Yes	What to look for, in plain words or the exact terms the documentation would use. One topic per call. Examples: "how are approvals enforced", "connect Amazon S3", "POST /api/v1/keys", "hosted MCP OAuth scopes".

Output Schema

Name	Required	Description
`note`	No	A fixed note, where one applies.
`query`	Yes	The query as searched, after redaction.
`source`	Yes	What was searched.
`covered`	Yes	Whether the published material answers the query. False: say it is not covered.
`receipt`	No	An Ed25519 receipt over the passages, verifiable against https://ask.atlanticagenticlabs.com/.well-known/octy-keys.json; null if unsigned.
`results`	Yes	The best passages, best first; empty when not covered.
`evidence`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 14, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), and the description adds genuine behavior beyond them: best-first ordering, exact quoting with deep links, docs version and build date, and the `covered` flag being false when the docs don't answer. It also states no answer is synthesized, though "Read only: nothing is changed" largely restates the annotations. Minor redundancy, but the coverage-flag semantics are real added value.

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?

Front-loaded with purpose in the first clause and structured as purpose → topics → return shape → caveat → alternative. The long topic enumeration is dense but each item is load-bearing; only the closing "nothing is changed" line is redundant with the annotations.

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?

For a two-parameter read-only search with full schema coverage, rich annotations and an output schema, the description supplies everything an agent needs: scope, topic domain, ranking, citation duty, the `covered` failure signal, and the sibling handoff. No material gap remains.

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 coverage is 100% and both parameters are fully described there, including defaults, bounds and query examples, so the schema does the heavy lifting. The description only adds that results are capped at `limit` and ordered best first — useful but marginal beyond the schema.

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 ("Search Atlantic's public LightHouse™ documentation") and names the content covered (API reference/OpenAPI, MCP tool reference). It also routes to the sibling read_page for whole pages, so an agent can distinguish the two without opening a 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 an explicit use case ("any question about what LightHouse does and how") followed by a concrete topic list, and names the alternative (read_page) with the condition that selects it. Nothing about when to reach for this versus another tool is left to inference.

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

All Atlantic Agentic Labs 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?