fix: Errata for 1.0-draft

[nbarbettini]

Fixing some nits and problems in draft-1.0.

[nbarbettini]

Renamed for expected consistency with a future pagination interface.

[eyurtsev]

An example of where this is useful? Does it help somehow with parameterizing types on the client side for static type purposes?

[nbarbettini]

Removed parameters to flatten and make this consistent with output_schema.

[nbarbettini]

Removed input_ and output_ from required to reflect the fact that these MAY be null.

[eyurtsev]

IMO these should be required.

• The input should be explicitly an empty object to denote a parameterless function. You could argue in this case a bit if you really believe that positional arguments should be supported.
• The output should be very explicit: Either it is known and can be specifically denoted as null or some other value, or it is not known and should be marked as any.

[nbarbettini]

Added this to provide a structured way for the OXP server to let the client know that some requirements are missing.

[eyurtsev]

An example of where this is useful? Does it help somehow with parameterizing types on the client side for static type purposes?

[eyurtsev]

This is more general than current function calling that LLMs do.

I think that restricting the input schema to be an object is reasonable?

The alternative is also allow positional arguments by that would still require restricting to either object or array or combination of array + object.

{
  "type": "object",
  "properties": {
    "input_schema": {
      "type": "object",
      "properties": {
        "type": {"const": "object"}
      },
      "required": ["type"]
    }
  },
  "required": ["input_schema"]
}

---

The object description is popular because it allows documenting the individual arguments and naming them.

[eyurtsev]

OK i suspect that this is actually a realization of an openapi.json instance rather than JSONSchema describing how to validate that a particular openapi.json instance implements the appropriate spec?

[eyurtsev]

IMO these should be required.

• The input should be explicitly an empty object to denote a parameterless function. You could argue in this case a bit if you really believe that positional arguments should be supported.
• The output should be very explicit: Either it is known and can be specifically denoted as null or some other value, or it is not known and should be marked as any.

[Spartee]

Moving future work to 0.1.0 release to avoid PR sprawl