Find email and phone details for people on your next 10 Planning Center schedule entries by searching any part of their name.
Email and phone for someone on your upcoming plans, found by any part of their name.
Searches the people scheduled on the plans of your next 10 schedule entries. emails or phones is null where Planning Center doesn't let you see that person's details.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this as a read-only, open-world lookup. The description adds useful behavioral context beyond the annotations: the scope is limited to the next 10 schedule entries, and email or phone fields may be null when Planning Center hides a person's details due to permissions.
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 purpose is front-loaded in the first sentence, and the second sentence adds scope and permission-based null behavior without redundancy. Every sentence earns its place and the definition is appropriately short for a one-parameter lookup tool.
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 read-only lookup with no output schema, the description is complete enough: it names the returned fields, states the search scope, and explains when those fields may be null. An agent has what it needs to call the tool correctly.
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?
With 0% schema description coverage, the description must carry parameter meaning, and it does by specifying that the single name parameter matches on any part of a person's name. It does not, however, clarify case sensitivity, exact-match fallback, or handling of ambiguous partial names.
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 returned (email and phone) and the search method (any part of the person's name). It is clear enough to distinguish this from a generic directory tool, but it does not explicitly contrast itself with close siblings such as team_contacts or my_schedule.
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 implies the context of use by specifying people on upcoming plans and the next 10 schedule entries. It does not state when to choose this tool over alternatives like team_contacts, nor does it offer exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.