Skip to main content
Glama
oliverhruby

EduPage MCP Server

by oliverhruby
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

custom_request

Destructive

Send raw GET or POST requests to EduPage endpoints not covered by dedicated tools using the active session, then inspect the returned status, content type, and text.

Instructions

Send a raw request to the Edupage server using the active session. Can perform writes depending on the endpoint — treat as write-capable.

Args: url: Absolute URL, or a path like '/export/ajax_prevedene_meno.php' (resolved against https://<subdomain>.edupage.org). method: 'GET' or 'POST'. data: Request body (for POST). headers: JSON string of extra headers, e.g. '{"Accept": "application/json"}'. subdomain: School whose session to use (defaults to the active).

Returns: dict: {'status_code': int, 'content_type': str, 'bytes': int, 'text': str, 'truncated': bool}. bytes is the raw body length and text is it decoded.

Notes: - Low-level escape hatch for endpoints not covered by the dedicated tools — prefer those when available. Parse the returned text yourself; fields are not pre-serialized. - Text only. A binary body (an Office/PDF/image/video attachment) is refused rather than returned as lossily-decoded errors="replace" garbage; use download_attachment(url=…, subdomain=…), which writes the raw bytes to disk and accepts any authenticated attachment URL. - text is capped at 60000 characters so the cap is this tool's, not the MCP client's silent one. EduPage's own pages ignore Range, so a truncated text body cannot be paged through: narrow the request instead (a more specific path or a dedicated tool), or save the whole body with download_attachment.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
urlYes
dataNo
methodYes
headersNo{}
subdomainNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changedv0.6.0
    • addedInput schema / properties / data / anyOf
      Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]
    • removedInput schema / properties / data / type
      Removed value: -"string"
    • addedInput schema / properties / headers / anyOf
      Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]
    • removedInput schema / properties / headers / type
      Removed value: -"string"
    • addedInput schema / properties / subdomain / anyOf
      Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]
    • removedInput schema / properties / subdomain / type
      Removed value: -"string"
  2. First observedv0.4.6

TDQS

A4.9/5.0
Behavior5/5

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

Annotations declare destructive/openWorld/write-capable, and the description reinforces rather than merely repeats them by disclosing the text-only constraint, the 60000-char cap being tool-imposed, the inability to page through truncated bodies (EduPage ignores Range), and that the caller must parse text themselves. These are non-obvious behaviors beyond 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.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with purpose, then Args/Returns/Notes blocks — well-organized and mostly waste-free. It is long, and the opening 'treat as write-capable' line lightly overlaps the destructiveHint annotation, but the length is largely justified by the 0% schema coverage.

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?

No output schema exists, yet the description fully specifies the return dict (status_code, content_type, bytes, text, truncated) and the meaning of `text`/`bytes`, plus the truncation and binary limitations. 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.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must carry the burden — and it does: it documents url path resolution against the subdomain host, method values 'GET'/'POST', data as the POST body, headers as a JSON string with a concrete example, and subdomain defaulting to the active session.

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 ('Send a raw request to the Edupage server using the active session') and explicitly distinguishes itself from the dedicated sibling tools ('prefer those when available'), which is exactly the differentiation an agent needs to choose this escape hatch over the ~30 named siblings.

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 explicit when-to-use (endpoints not covered by dedicated tools), when-not (binary bodies go to download_attachment, prefer dedicated tools), and what to do when truncated (narrow the request or use download_attachment). Alternatives and exclusion conditions are named, not inferred.

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