Skip to main content
Glama
Sign In
Crawlora MCP

Crawlora MCP

Official
by Crawlora-org
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

psastore_page

Get a PSA Team Store static page by handle to return its title, URL, plain-text content, and created, published, and updated timestamps.

Instructions

Get a PSA Store static page. Returns one PSA Team Store static page by its handle: title, URL, plain-text content (HTML is stripped), and created, published and updated times. An unknown handle returns 404. When the store's standard page data is unavailable, transport_mode is ssr_embedded and id is omitted.

Input Schema

NameRequiredDescriptionDefault
handleYesPage handle

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.17.5

TDQS

A3.8/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does well: it discloses the returned fields, that HTML is stripped from content, that an unknown handle yields 404, and the ssr_embedded transport_mode edge case where id is omitted. This is genuinely useful behavioral context beyond a plain 'get' claim.

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?

Two tight sentences, front-loaded with the action and resource, followed by return contents and edge-case behavior. No filler or redundancy.

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 no output schema and no annotations, the description compensates by enumerating return fields and describing the 404 and ssr_embedded fallback behaviors. Slightly incomplete in that it does not explain the return shape of id/transport_mode beyond the edge case, but an agent has enough to call it correctly.

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?

Only one parameter exists and schema description coverage is 100% ('Page handle'), so the schema already documents it. The description restates 'by its handle' without adding format or syntax detail, matching the baseline 3 for schema-covered params.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb+resource ('Get a PSA Store static page') and immediately clarifies it returns ONE page by handle, which implicitly separates it from the plural psastore_pages listing sibling. It is clear what the tool does, though it does not explicitly name the alternative list tool to differentiate in a crowded sibling set.

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

Usage Guidelines3/5

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

Usage is implied by the 'by its handle' retrieval framing and the 404 note tells the agent what happens on a bad handle, but there is no explicit when-to-use vs when-to-use-a-sibling guidance (e.g., when to prefer psastore_pages or psastore_store). Minimum-viable context only.

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