Hi, Moose AEO

List the site pages related to a topic

find_site_pages

Read-onlyIdempotent

Lists every page in the latest crawl of a Hi, Moose project that is related to a topic, for content inventories and audits of what already exists. Hi, Moose scores every indexed page against the topic, then a model checks each candidate and drops pages that only share a word with it. Returns all related pages, closest first, up to 500, each with URL, title, similarity score, page type and dates, plus how many pages were checked and whether the list was cut. Give the user the whole list unless they asked for part of it. Use check_site_coverage instead when the question is whether a topic is covered.

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": {
      "project": "<project>",
      "topic": "<topic>"
    },
    "name": "find_site_pages"
  }
}

Input Schema

Name	Required	Description
`limit`	No	Optional. Leave it out to get every related page (up to 500). Set it only when the user wants a shorter list.
`topic`	Yes	The topic, as a short phrase such as "AI SAST" or "SBOM generation".
`project`	Yes	The Hi, Moose project, by its name as shown by list_projects.
`urlContains`	No	Optional. Only pages whose URL contains this text, for example "/learn/".
`includePassages`	No	Optional. Also return the passage of each page that best matched the topic. Makes the result much longer. Default false.

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 10, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world, so the safety profile is covered; the description goes further and discloses the two-stage relevance pipeline (score, then model rejection of pages sharing only a word), ordering (closest first), the hard cap of 500, and that the response reports how many pages were checked and whether the list was truncated. Those are behavioral traits not derivable from the annotations.

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?

Purpose is front-loaded, followed by mechanism, return shape, and finally the alternative tool. Each sentence carries distinct information — no restatement of the title and no filler — and the routing guidance is placed at the end where it reads as a decision rule.

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?

There is no output schema, yet the description specifies the fields returned (URL, title, similarity score, page type, dates), the ordering, the cap, and the truncation/count metadata. Combined with the explicit sibling routing and full schema coverage, an agent has everything needed to call it correctly and interpret the result.

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?

With 100% schema description coverage, every parameter is already documented, including the limit default and the cost of includePassages. The description reinforces the limit behavior ("up to 500", give the whole list unless asked for part) but adds little that the schema does not already say, and says nothing about urlContains or project naming beyond the schema. Baseline 3 is appropriate.

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?

The description opens with a specific verb and resource ("Lists every page in the latest crawl of a Hi, Moose project that is related to a topic") plus the intended output use (content inventories and audits). It then explicitly names the sibling it is not (check_site_coverage) and the condition that selects it, so an agent can distinguish the two 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?

It gives a use case (inventories/audits of what already exists), an explicit exclusion with an alternative ("Use check_site_coverage instead when the question is whether a topic is covered"), and a behavioral rule for the user-facing case ("Give the user the whole list unless they asked for part of it"). When-to-use, when-not-to-use, and the alternative are all present.

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

All Hi, Moose AEO 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?