get_person_photosGallery image URLs for a CRM contact. Returns photos[{ id, url, is_primary, created_at }] plus inline MCP image attachments for chat render. Accepts person_id. ($0.10; API key required)
| Name | Required | Description | Default |
|---|---|---|---|
| person_id | Yes |
| Name | Required | Description | Default |
|---|---|---|---|
| count | Yes | ||
| photos | No | ||
| person_id | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, non-destructive behavior. The description adds meaningful operational context beyond annotations: it discloses the $0.10 cost, the API key requirement, and the inline MCP image attachment behavior for chat rendering. This helps an agent anticipate side effects and prerequisites.
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 compact and front-loaded with the core purpose, then returns format, then operational notes. The sentence 'Accepts person_id' is somewhat redundant with the schema, but the overall size is appropriate and each other sentence adds value.
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 one-parameter read-only tool with an output schema and rich annotations, the description covers the return shape, presentation behavior, cost, and auth requirement. It does not discuss empty results, ordering, or pagination, but these are minor for this tool and the output schema likely covers structure.
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 input schema has one parameter, person_id, with no description (0% coverage). The description only says 'Accepts person_id,' which largely restates the schema, though the phrase 'for a CRM contact' implies person_id refers to the CRM contact's ID. This is minimal compensation for the missing schema description.
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 states the specific resource ('Gallery image URLs for a CRM contact') and the output shape (photos array plus inline attachments), making it immediately distinguishable from sibling photo tools like get_photo, get_photos_for_event, and get_photos_for_place. The verb is implied by 'Returns' and the tool name, so the function is unambiguous.
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 provides clear context: use this when you need gallery image URLs for a CRM contact and have a person_id. It does not explicitly mention alternatives or exclusions, but the 'for a CRM contact' scoping is enough to signal the intended use case against event/place photo tools.
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.
Many tools have explicit 'prefer X' guidance and mostly target distinct resources, but get_money_between_people is literally an alias for get_person_transactions, get_context_pack and get_life_context overlap heavily, and upload_asset/upload_photo both upload and re-encode images. Detailed descriptions partially rescue it, but the agent still faces avoidable near-duplicates.
The vast majority follow verb_noun snake_case conventions (get_, log_, update_, search_, delete_, add_, archive_, resolve_, etc.). Deviations like the notable_* family and verbose aliases such as get_money_between_people are internally consistent subdomain patterns rather than chaotic naming. No camelCase or mixed style conventions appear.
At 71 tools this far exceeds the 50+ threshold for an extreme tool count. Each domain may have legitimate operations, but the sheer volume would make agent navigation and tool selection expensive. Many listing, search, and upload variants could be consolidated without losing functionality.
The set broadly covers calendar, food, people, inventory, money, travel, assets, photos, Gmail, memories, and notable-people lookup with mostly CRUD-style operations. Notable gaps include no delete_expense, no delete_person, and no direct food-diary listing/getter, so some lifecycles end in workarounds. Overall it is broad but not fully complete.