Skip to main content
Glama

Sewlore Measurement Reference

by io.github.gokimedia
OverviewDiscussionsAdmin

sendFeedback

Report an issue in the documentation of Sewlore Docs so the team can fix it. Use it whenever, while helping a user, you come across content that is outdated, contradictory, missing information, or otherwise unhelpful. Also use it when the user themselves reports a problem with the docs, even if you could not verify it yourself. If it's your own observation, do a quick sanity check that the issue is real before reporting — no need to exhaustively re-read the page. Send one call per distinct issue and do not report the same issue twice in a conversation. Do not use this tool to confirm that a page is accurate; it is for reporting problems only.

Input Schema

NameRequiredDescriptionDefault
goalNoThe broader end goal you were ultimately trying to accomplish (as/on behalf of the user) when you hit this issue. Gives the team the context you were working towards. Optional.
contentYesExplain the issue in full, as if writing to a documentation maintainer who never saw this conversation. Describe what is wrong, where on the page it appears (quote the exact sentence or section title when possible), what the user was trying to do, and, when relevant, what the correct or expected information should be. Write a few clear, specific sentences in English. Never include personal or confidential information from the conversation. Up to 2048 characters.
pageUrlYesThe full URL of the page the issue is about (e.g. https://sewlore.gitbook.io/sewlore-docs/getting-started), so the finding is linked to the exact page.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / pageUrl / description
      Previous value: -"The full URL of the page the issue is about (e.g. https://sewlore.gitbook.io/sewlore-docs//getting-started), so the finding is linked to the exact page."New value: +"The full URL of the page the issue is about (e.g. https://sewlore.gitbook.io/sewlore-docs/getting-started), so the finding is linked to the exact page."
  2. First observed

TDQS

A4.3/5.0
Behavior4/5

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

Annotations declare a non-read-only, non-destructive, non-idempotent, open-world write; the description fills in what that actually means — the report goes to a human documentation team, must be deduplicated per conversation, and must exclude confidential conversation content. What's missing is what the caller gets back (confirmation, ticket id) or any rate limits.

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?

Purpose and trigger conditions are front-loaded, and each sentence adds a distinct rule (sanity check, unverified user reports, dedupe, exclusion). Slightly longer than needed — the 'no need to exhaustively re-read the page' aside could be folded into the sanity-check clause.

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 3-parameter reporting tool with no output schema, the description covers what triggers it, how to scope a submission, and privacy constraints. Only the post-submission outcome is left unspecified, which is a minor gap given no output schema exists to describe it.

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?

Schema description coverage is 100%, so goal, content, and pageUrl are already fully documented with length limits and examples. The description adds only a light constraint ('one call per distinct issue' implies one issue per content field) and no format details beyond the schema.

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 ('Report an issue in the documentation of Sewlore Docs') plus the consequence ('so the team can fix it'). It is unmistakable against siblings getPage and searchDocumentation, which read versus report.

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?

Explicitly enumerates when to use (outdated, contradictory, missing, unhelpful content; user-reported problems even if unverified) and when not to ('Do not use this tool to confirm that a page is accurate'). It also gives operational guidance — sanity check before reporting, one call per distinct issue, no duplicates in a conversation.

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

All Sewlore Measurement Reference toolsInspect
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