OnPage.dev

Snippets and share cards

snippet

Read-onlyIdempotent

How a page looks in Google and when shared, measured in pixels the way Google truncates. Use it instead of estimating title or description length. Pick with mode: search = Title and description as Google shows them; give title (and description) or a url to read them. social = Open Graph and X cards, and the share image. Needs url.

Input Schema

Name	Required	Description
`url`	No	Page to read the current title and description from, when no title is given.
`mode`	No	Default search.
`title`	No	Proposed title tag text.
`detail`	No	brief = short summary.
`memory_key`	No	site_memory key, records this call.
`description`	No	Proposed meta description.

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 14, 2026

removedOutput schema / description

Removed value: -"The result as structured data; fields depend on mode."

Changed2 schema fields changedOct 13, 2026

changedInput schema / properties / detail / description

Previous value: -"brief returns a short summary, default full."New value: +"brief = short summary."

changedInput schema / properties / memory_key / description

Previous value: -"Optional site_memory key, to record this call in the site memory."New value: +"site_memory key, records this call."

Changed2 schema fields changedOct 12, 2026

addedInput schema / properties / detail

Added value: +{
+  "description": "brief returns a short summary, default full.",
+  "enum": [
+    "full",
+    "brief"
+  ],
+  "type": "string"
+}

changedInput schema / properties / url / description

Previous value: -"Full address of the page."New value: +"Page to read the current title and description from, when no title is given."

Changed1 schema field changedOct 12, 2026

addedInput schema / properties / memory_key

Added value: +{
+  "description": "Optional site_memory key, to record this call in the site memory.",
+  "maxLength": 80,
+  "type": "string"
+}

AddedOct 12, 2026

TDQS

A4/5.0

Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive, open-world. The description adds behavior they don't cover: results are 'measured in pixels the way Google truncates', and social mode imposes a url requirement. It does not discuss return format, but the output schema handles that.

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 the core value (pixel-accurate snippet/sharing preview), then mode selection and requirements. Dense and mostly waste-free, though the mid-sentence mode explanations read a touch run-on.

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?

For a read-only preview tool with a 6-param, fully documented schema and an output schema, the description covers purpose, mode selection, and input requirements well. Return values are delegated to the output schema, so nothing critical 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 baseline is 3, but the description adds real meaning: it clarifies the mode enum ('search = Title and description as Google shows them; social = Open Graph and X cards'), the title/description-or-url interplay, and that social mode 'Needs url'. This is more than the schema restates.

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 states a specific verb+resource: how a page renders as a Google snippet and as a social share card, measured in pixels. The two-mode split (search vs social) makes the scope concrete. It doesn't explicitly differentiate from siblings like 'share' or 'explain_google', so it stops short of a 5.

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

Usage Guidelines4/5

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

Gives clear when-to-use guidance: 'Use it instead of estimating title or description length' names an alternative practice to avoid. It also explains what each mode is for and which inputs each needs. No explicit when-not-to-use, but the alternative framing is strong.

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

All OnPage.dev tools Inspect

Try in Browser

Context Every Agent Can ShareAgents share what they learn, hand off work, and keep it when you switch models. Start with 5 GB free.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.