Skip to main content
Glama
MeruLocal

raivatedu-mcp-server

by MeruLocal
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Get RaivatEdu Page Content

raivatedu_get_page_content
Read-onlyIdempotent

Fetch and summarize the content of a known public RaivatEdu page, returning its title, headings, body text, links, and FAQs; arbitrary or external URLs are refused.

Instructions

Fetch and summarize the text of a specific public RaivatEdu page.

Accepts a path (e.g. "/in/pricing" or "in/features/admissions") or a full raivatedu.com URL. For safety the page MUST be one of the known public pages (use raivatedu_list_pages to discover them); arbitrary or external URLs are refused, and /api/ paths are blocked per robots.txt.

Returns the page title, meta description, heading outline, main body text (truncated), internal links, and any FAQ entries found in the page's structured data.

Args:

  • path (string, required): page path or full raivatedu.com URL.

  • max_text_chars (number): cap on returned body text, 200–20000 (default 6000).

  • include_links (boolean): include the list of internal links (default true).

  • response_format ('markdown' | 'json'): output format (default markdown).

Returns JSON shape: { "url": string, "type": string, "title": string, "description": string, "canonical": string | null, "headings": [ { "level": number, "text": string } ], "text": string, "faqs": [ { "question": string, "answer": string } ], "links": [ { "text": string, "url": string } ] }

Errors:

  • "not a known public RaivatEdu page" if the path is unknown — call raivatedu_list_pages.

  • "Page not found" (HTTP 404) if the page no longer exists.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pathYesPage path (e.g. "/in/pricing") or full raivatedu.com URL.
include_linksNoWhether to include the page's internal links.
max_text_charsNoMaximum characters of body text to return (200–20000).
response_formatNoOutput format: 'markdown' for a human-readable summary (default) or 'json' for the full structured object.markdown

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive, and the description adds substantive behavior beyond them: the whitelist enforcement, robots.txt blocking of /api/ paths, text truncation, and the specific error strings with the recommended recovery call. That is exactly the kind of constraint an agent needs before invoking.

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?

Well front-loaded: purpose, constraint, return contents, then parameters and errors in a predictable order. Slightly over-long because the Args block duplicates a schema that already has 100% description coverage, but the return-shape and error sections earn their space given there is no output schema.

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?

With no output schema available, the description supplies the full JSON return shape (url, title, headings, text, faqs, links) and documents the failure modes. For a read-only fetch tool with four parameters and enum output, nothing an agent needs to call 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 the Args block is largely restatement under the baseline-3 rule. It does add real meaning in one place: distinguishing response_format 'markdown' as a human-readable summary versus 'json' as the full structured object, which clarifies the semantic difference the enum alone doesn't convey.

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 pair and resource: 'Fetch and summarize the text of a specific public RaivatEdu page,' and immediately narrows scope to known public pages. This distinguishes it from raivatedu_search_content (query-based) and raivatedu_list_pages (discovery), so an agent can route correctly without opening any 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 states the selection rule explicitly ('the page MUST be one of the known public pages'), names the discovery alternative (raivatedu_list_pages), and gives concrete exclusions (arbitrary/external URLs refused, /api/ blocked by robots.txt). The only minor omission is not naming raivatedu_search_content as the alternative for keyword lookup, but the when/when-not framing is otherwise complete.

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