Questions that shape the route
profile_questionsReturns the shared questions, with their answer options, that shape a founder’s review. A fact the founder hasn’t given stays unknown.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
profile_questionsReturns the shared questions, with their answer options, that shape a founder’s review. A fact the founder hasn’t given stays unknown.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, idempotentHint=true, and openWorldHint=false, so the safety profile is clear. The description adds the behavioral note that 'a fact the founder hasn't given stays unknown,' which hints at state handling but is vague and doesn't fully explain what that means (e.g., no defaults, requires prior input). With annotations covering safety, this is marginally informative.
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 short sentences and front-loads the main action. However, the second sentence is cryptic and doesn't clearly earn its place—it leaves the agent guessing about its meaning. The structure is concise but lacks clarity.
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?
Given the tool has no parameters and rich annotations, the description should still clarify its role among siblings and what 'questions' and 'review' mean in this context. The description is too vague and doesn't provide enough context for an agent to understand when and why to use it, especially without an output schema.
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 tool has zero parameters, so parameter semantics are not applicable. The baseline for zero parameters is 4, and the description doesn't need to compensate for schema coverage since there are no parameters to document.
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 says it 'returns the shared questions, with their answer options, that shape a founder's review.' While it states a verb (returns) and resource (questions with answer options), the phrase 'shape a founder's review' is vague and doesn't clarify what a review is or how this differs from siblings like build_route or get_program. The second sentence about unknown facts is cryptic and doesn't aid purpose clarity.
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?
There is no guidance on when to use this tool versus alternatives. Sibling tools like build_route or get_program are not mentioned. The description implies it's for retrieving questions that influence a route, but doesn't state the context or prerequisites for calling it.
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.