Skip to main content
Glama
Sign In

Marsell

by com.getmarsell
OverviewDiscussionsAdmin

Name the business's own places

add_places
Destructive

Names the business's own places, when it has any: its shop, office, studio, kitchen or venue at its real address, or an imagined home such as a mascot's HQ (real: false). Each with what it is in a sentence, and for a real place where it is. Then send pictures of it with add_pictures or get_upload_link, giving place: Create lists it first under Places, and a picture or film set there is made from those pictures. A name already on file is updated, never doubled. Works during setup and after it (give project when no setup is open). Spends nothing.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "places": "<places>"
    },
    "name": "add_places"
  }
}

Input Schema

NameRequiredDescriptionDefault
placesYesOne or more places, each with its name, what it is and, for a real one, where.
projectNoOnly with no setup open: the project's id or exact name.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4/5.0
Behavior4/5

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

Adds real context beyond the annotations: upsert semantics ('A name already on file is updated, never doubled'), a visible side effect ('Create lists it first under Places'), downstream consequences (pictures become source material for a film set there), and cost ('Spends nothing'). Given destructiveHint=true, it does not spell out which fields of an existing place get overwritten, which is the main remaining gap.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded and information-dense, but the second and third sentences are run-on and grammatically loose ('Then send pictures of it with add_pictures or get_upload_link, giving place: Create lists it first under Places'), forcing the agent to parse clause fragments. Some content, like the title restatement, does not earn its place.

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 two-parameter tool with annotations and no output schema, this covers what an agent needs: scope, examples, upsert behavior, cost, setup-vs-post-setup context, and the next step in the workflow. Only the merge behavior for pre-existing places and any validation expectations are left unstated.

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% and the nested item fields (name, real, what, where) are already documented, so the baseline is 3. The description adds only modest meaning on top — restating that a real place needs 'where' and that imagined places use real: false — while the transitive 'place:' convention it introduces belongs to other tools.

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 ('Names the business's own places') and immediately grounds it with concrete examples (shop, office, studio, kitchen, venue, imagined mascot HQ) plus the real:false distinction. An agent can tell this apart from add_pictures or add_brand_file without opening any schema.

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 context for when it applies ('when it has any', 'works during setup and after it', 'give project when no setup is open') and routes the follow-up step explicitly to add_pictures or get_upload_link with the place field. It stops short of naming an exclusion or contrast with the sibling place_open, so the routing is one-directional.

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

All Marsell 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