Fetch a full StitchAPI documentation page as Markdown — the "read the whole thing" escape hatch for a search_docs hit. Pass a url (as returned by search_docs) or a slug like "guides/resilience/throttle".
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | Page URL from search_docs (absolute or /docs/…). | |
| slug | No | Page slug, e.g. "guides/resilience/throttle". |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral burden; it discloses the return format (Markdown) and implies a read-only fetch operation. However, it doesn't state edge-case behavior such as requiring exactly one of url or slug, what happens when both are provided, or error handling for invalid slugs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences carry the entire definition with no filler; the main action and purpose are front-loaded, and the usage guidance follows directly. Every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter fetch tool with no output schema, the description is nearly complete. The only notable gap is that it doesn't explicitly state that one of url or slug must be provided, despite the schema listing both as optional.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds meaningful parameter semantics by explaining the provenance of url ('as returned by search_docs') and giving a concrete slug example. It also conveys that the two parameters are alternatives, a relationship the schema does not express since both are optional.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Fetch'), names the resource ('full StitchAPI documentation page'), and specifies the output format (Markdown). It clearly distinguishes itself from sibling search_docs by positioning as the 'read the whole thing' escape hatch after a search hit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly frames when to use get_doc versus search_docs: when you need the full page rather than a search hit, and it instructs the agent to pass a url returned by search_docs or a slug. It doesn't include explicit exclusions or when-not-to-use scenarios, but the intended context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
The two tools have clearly distinct purposes: one searches and returns excerpts, the other fetches a full documentation page. Their descriptions explicitly cross-reference each other, eliminating any ambiguity about when to use each.
Both tool names follow a consistent verb_noun pattern (get_doc, search_docs). The slight singular/plural difference between 'doc' and 'docs' is semantically appropriate and does not hurt predictability.
Two tools is on the thin side for a documentation server, but the pair covers the essential workflow of discovering and reading content. It feels slightly minimal rather than elegantly scoped, hence the borderline score.
The domain is documentation retrieval, and the two tools form a complete workflow: search to find relevant sections, then fetch the full page when needed. Get_doc also accepts direct slugs/URLs, so there is no dead end. No other operations are expected for this purpose.