Skip to main content
Glama

Shipfound

by co.shipfound.api
OverviewDiscussionsAdmin

Site fixes

site_fixes

Audit the live site the way AI crawlers and Google read it (robots rules for AI crawlers, firewall, rendering, indexing, canonicals, page titles and descriptions, structured data, sitemap, llms.txt, internal links to key pages, share images, answer pages) and return fix specs { id, theme, page, issue, evidence, fix } grouped by theme, one PR per theme, minus fixes already shipped. Costs 6 credits, charged only when it returns. Nothing is charged when it finds nothing to fix. When you record the PR, put the fix ids in meta.fixIds so they are not suggested again. The robots fix is the whole corrected robots.txt, with a note on each crawler it changes for the PR. Training crawlers (GPTBot, ClaudeBot, CCBot...) are the founder's call: while they have not answered, that fix carries fix.choices, the whole file for allow, block and keep; ask, use the one they pick, and put their answer in the PR's record as meta.training so later checks follow it.

Input Schema

NameRequiredDescriptionDefault
urlNoA page on this workspace's site. Default: the homepage
trainingNoThe founder's answer on training crawlers: allow (let them in), block (keep them out), keep (leave robots.txt as it is for them). Kept for later checks; left out, the last answer stands

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / training
      Added value: +{
+  "description": "The founder's answer on training crawlers: allow (let them in), block (keep them out), keep (leave robots.txt as it is for them). Kept for later checks; left out, the last answer stands",
+  "enum": [
+    "allow",
+    "block",
+    "keep"
+  ],
+  "type": "string"
+}
  2. First observed

TDQS

A4.1/5.0
Behavior5/5

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

The description goes well beyond annotations by disclosing credit cost, that charging only occurs when fixes are returned, idempotency behavior around already-shipped fixes, the PR-per-theme model, and the special workflow for training crawler choices. This adds substantial operational context without contradicting 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?

The description is long but appropriately dense for a complex audit tool, and the main purpose and return shape are front-loaded. It could be more scannable, but most sentences carry operational value rather than repetition.

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?

There is no output schema, so the description must explain return values and side effects; it does so by describing the fix-spec shape, grouping by theme, PR-per-theme behavior, and filtering of already-shipped fixes. It also covers cost, persistence, and training-crawler follow-up, making it complete for an agent to call correctly.

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 schema documents both parameters. The description still adds useful semantics for training by explaining that the answer is persisted and affects later checks, and clarifies the default URL behavior indirectly through the audit context.

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 and resource: audit the live site as AI crawlers and Google read it, then return structured fix specs. The enumerated checks make the tool's scope clear, but it does not explicitly distinguish itself from adjacent tools such as check_content or index_status.

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?

It implies the tool is used to produce fix specs and gives workflow guidance for recording PRs and training-crawler answers. However, it does not explicitly say when to use this instead of sibling audit or check tools, nor does it state when not to use it.

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

All Shipfound toolsInspect
Try in Browser
Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources