Skip to main content
Glama

Shipfound

by co.shipfound.api
OverviewDiscussionsAdmin

Confirm the repo

repo_confirm

Whether the repo you are in is this site's code, kept so nobody is asked again. Call it when workspace says the repo is UNCONFIRMED: by agent, yes only, with evidence (the file and line where you found the site's domain); by founder, their yes or no. The founder's answer always stands over yours. Free.

Input Schema

NameRequiredDescriptionDefault
byYesagent: you found the domain in the deploy or site config. founder: they answered you.
repoYesThe same `repo` you passed to workspace.
answerYes
productNoAnother of the account's products this repo is the code for: its id from workspace's `products` (or its domain). The answer is kept for that product and this session moves to it. Leave out for this session's own product.
evidenceNoWith by agent: the file and line that shows the domain, e.g. vercel.json: "alias": ["acme.com"]

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / product
      Added value: +{
+  "description": "Another of the account's products this repo is the code for: its id from workspace's `products` (or its domain). The answer is kept for that product and this session moves to it. Leave out for this session's own product.",
+  "maxLength": 200,
+  "type": "string"
+}
  2. Added

TDQS

A4.2/5.0
Behavior4/5

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

Annotations tell the agent this is a write that is not destructive and not open-world. The description goes beyond that, disclosing that the answer is persisted ('kept so nobody is asked again'), that it is Free, and that founder input overrides agent input. It does not describe side effects on the session or what confirmation unlocks, so it falls short of a 5.

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?

Three compact sentences with the trigger condition front-loaded after the purpose. Every sentence carries information (purpose, trigger, per-role usage, precedence, cost). The first sentence is somewhat dense and could be clearer, but there is no padding.

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?

No output schema exists, and for a mutation-confirmation tool the description covers purpose, trigger, role-specific behavior, precedence, and cost. It does not spell out what changes after confirmation (e.g., session moving to the `product`), which the schema's product description partly covers, leaving a modest gap.

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 80%, so most parameters are documented in-schema. The description supplements this by clarifying `by` semantics (agent requires evidence, founder gives a yes/no) and describing evidence content ('the file and line where you found the site's domain'). It adds real meaning over the schema for the agent's evidence path.

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 — recording whether the current repo is this site's code — and the title 'Confirm the repo' reinforces it. It distinguishes itself from the `workspace` sibling by describing its role relative to workspace's UNCONFIRMED state. The lead sentence is slightly indirect ('Whether the repo you are in is this site's code'), which keeps it from 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 Guidelines5/5

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

Explicit trigger: 'Call it when `workspace` says the repo is UNCONFIRMED.' It names the alternative path for agent versus founder ('by agent, yes only, with evidence...; by founder, their yes or no') and states a precedence rule ('The founder's answer always stands over yours'). The when-to-use condition is fully specified.

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