get_salesperson_installationReturn the exact one-line script to add to a website so its salesperson appears for visitors, plus where to place it and whether HeySale has detected it yet. Give it the salesperson_id returned when the salesperson was created.
| Name | Required | Description | Default |
|---|---|---|---|
| salesperson_id | Yes | The salesperson_id returned by create_website_salesperson. |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Input schema / properties / salesperson_id / descriptionAdded value: +"The salesperson_id returned by create_website_salesperson."Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint and idempotentHint as true, and the description's 'Return' wording aligns with these. The description does not add extra behavioral context (e.g., rate limits, auth requirements) beyond what the annotations provide, so it meets the baseline but adds no additional depth.
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?
The description is two sentences, directly states the output (script, placement, detection status) and the required input, with no redundant words or unnecessary detail. It is well-structured and front-loads the essential action.
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?
The description clearly enumerates the three expected outputs (script, placement, detection status) and the input source. Since there is no output schema, it gives enough context for an agent to anticipate the response, though it omits potential error cases (e.g., not-found salesperson). Overall it is sufficiently complete for a low-complexity getter.
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?
The schema covers 100% of parameters with a description for salesperson_id, and the tool description repeats the same origin ('returned when the salesperson was created'). No additional meaning is added beyond the schema's existing clarification, so it stays at the baseline for full schema coverage.
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 clearly states the tool returns the exact one-line installation script, placement instructions, and detection status, directly tied to the salesperson_id. It identifies the ID source (created via create_website_salesperson) and distinguishes this from sibling tools like verify_salesperson_installation by explicitly mentioning the script content.
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?
The description implicitly signals when to use this tool (when needing the installation script for a salesperson) but does not explicitly contrast with siblings like check_salesperson_status or verify_salesperson_installation. The primary purpose is clear, and the mention of 'returned when the salesperson was created' gives context, but it stops short of explicit when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.